Why 802.1x is Not Enough: How to Implement SeND – Part 2

Last month I presented the case as to why 802.1x authentication is not enough for local network (wired or wireless) security (go back here to read).  In this post I will present an alternative: IPv6 Secure Neighbor Discovery (SeND).  If you have an IPv6 enterprise, small IPv6 deployment, or a little IPv6 lab then pay close attention.  I will discuss what SeND is and what it is not, its limitations, and products/software that support and do not support it.  In the process of discussing SeND I will also show how it is setup on the router and host (configurations are in BOLD).  Feel free to use these same configurations in your own lab and/or enterprise production environments (or you can just hire us 😉

What is SeND and How Does it Work?

SeND is an awesome method of port-based/segment-based authentication for every host, router, and packet in the network.  In fact, the only thing close to SeND in operation today is 802.1x.  However, SeND takes the 802.1x architecture and makes it much more hardened and usable.  Think: SeND is 802.1x on steroids.  One more aspect to SeND is Cryptographically Generated Addresses (CGA).  By using CGA, not only are the packets authenticated, but the host and router develop a unique RSA key that generates a unique and secure address that will change and re-negotiate securely – not just randomly (unlike Windows that basically just randomizes the IPv6 address).

Build the Public Key Infrastructure (PKI)

The fundamental architecture of SeND uses the Public Key Infrastructure (PKI).  The lynch-pin of any PKI environment is the Certificate Authority (CA) server.  So you can follow along here while I help you build your own CA on a Cisco router – or use your own CA.  If you have a Microsoft CA then use that.  Most organizations have a good PKI in-place.  It’s best to just use that.  However, it is a little more difficult to use a CA that’s not another Cisco router because of the auto-enrolment capability you get.

The Environment:

CA router: “SEND_CA”, IPv4 address:, CGA generated IPv6 address: 2001:DB8:1:1:3419:DE30:3DA7:1D02

Segment gateway router: “SEND”, IPv4 address:, CGA generated IPv6 address: 2001:DB8:1:1:20D5:2985:29C:40D5

Simulated host (standard 7200 router): “SEND_HOST”, IPv4 address:, CGA generated IPv6 address: 2001:DB8:1:1:3012:418C:2951:C89E

Configuration Steps

The first step is configuring the CA (if you are using a Cisco router).   This includes creating the PKI policy and trustpoint:

crypto pki server CA
 issuer-name C=US, ST=CA, L=domain, O=info, OU=dude, CN=CAO lifetime ca-certificate
crypto pki trustpoint CA
 ip-extension prefix 2001:DB8:1:1::/64
 revocation-check crl
 rsakeypair CA
crypto pki trustpoint SEND
 enrollment url
 revocation-check none

Now let’s configure the router.  We need to generate the keys and add the CGA configuration:

 crypto key generate rsa label SEND modulus 1024
 ipv6 cga modifier rsakeypair SEND sec-level 1

 crypto pki trustpoint SEND
 enrollment url
 subject-name C=US, ST=VA, L=domain, O=info, OU=NSSTG, CN=router
 revocation-check none
 rsakeypair SEND

Now we need to add the certificate request and get the signed certificate from the CA:

 crypto pki authenticate SEND

Certificate has the following attributes:
Fingerprint MD5: FC99580D 0A280EB4 2EB9E72B 941E9BDA
Fingerprint SHA1: 22B10EF0 9A519177 145EA4F6 73667837 3A154C53
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
 crypto pki enroll SEND

% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
Re-enter password:

Now we just need to finish it up by applying our SeND and CGA configs on the interface to ensure all of our hosts can or should authenticate:

interface FastEthernet0/0
 ipv6 cga rsakeypair SEND
 ipv6 address FE80:: link-local cga
 ipv6 address 2001:DB8:1:1::/64 cga
 ipv6 nd secured trustanchor SEND
 ipv6 nd secured full-secure
 ipv6 nd prefix 2001:DB8:1:1::/64

The command “ipv6 secured full-secure” means that we are requiring any host on the network to authenticate.  To make your SeND policy a little less restrictive don’t enable “full-secure” and all hosts can still talk and if there is ever a conflict (meaning that an IPv6 address is being spoofed, SeND hosts on the network will ONLY listen to the properly authenticated one.

From the host side, the configuration is very similar to enrolling with the CA and setting the interfaces.  CA enrollment:

 crypto key generate rsa label SEND modulus 1024
 ipv6 cga modifier rsakeypair SEND sec-level 1

 crypto pki trustpoint SEND_CA
 enrollment url
 revocation-check none
auto-enroll regenerate

crypto pki authenticate SEND_CA

Then exit to the global config and type:

 ipv6 nd secured sec-level minimum 1

Now on the interface let’s get going!

int f0/0
ipv6 cga rsakeypair SEND
ipv6 addr fe80:: link-local cga
ipv6 addr 2001:db8:1:1::/64 cga
ipv6 nd secured trustanchor SEND_CA
ipv6 nd secured timestamp delta 300

Let’s get it on!
ipv6 nd secured full-secure

This will fundamentally enable it.  When you do the “show ipv6 neighbor” command, you probably won’t see anyone except for the router’s link-local address.  Go to the the router and copy the IPv6 address – you have to check it this way: “sh ipv6 int f0/0“.   Now ping the router from your “host router.” and do the show command again.  If everything works, you’ll see the Global Unicast address pop up in the IPv6 neighbor table.

So SenD is anything but intuitive, so let us know in the comments or send us an email if you have any questions, lessons-learned, or suggestions: info@tachyondynamics.com

What hosts and routers support IPv6 SeND and CGA?  Stay tuned for Part 3!

4 thoughts on “Why 802.1x is Not Enough: How to Implement SeND – Part 2”

  1. SEND is very difficult to deploy at scale because there is no standard way to load and maintain the trust anchors, especially in BYOD environments.

    Further, SEND creates some serious DOS issues of its own – faculty.nps.edu/xie/theses/07Sep_Pohl.pdf. In short, because each SEND-protected packet has to be validated, an attacker can flood the link with bogus packets causing excess RSA computations on the receiving node(s). You’d have to use rate-limiting on your switches.

    I don’t see SEND being deployed at scale anytime soon.

    1. Derek, great points you raise on (1) BYOD and (2) possible DoS related issues. BYOD is a more problematic issue because not everyone has a common operating system baseline. I tend to argue that SeND is probably the least of all worries with BYOD – I mean anti-virus management, security updates, a baseline config management are at the top of that list. Regarding DoS issues, this is a fixable problem. If SeND becomes a more widely used First-Hop security protocol, then folks like Cisco and others will have discarding/rate-limiting options. Then again, if you use multiple defense (eg. defense in depth) like 8021.x+RA Guard+ICMPv6 Rate Limiting+SeND, this should equal a very robust LAN security model. Great points you raise, and thanks for contributing!

      1. If you’re running 8021.x+RA Guard+ICMPv6 Rate Limiting, then I’m not sure I see the point of deploying SEND. There’s a lot of operational complexity in SEND, and few benefits. It also has serious issues in its failure mode.

        Do you know of any large-scale deployments of SEND? I’d be very interested in hearing how the admins dealt with the deployment challenges.

        1. Nope, I don’t know of any large-scale deployment to-date. Mostly because of the few host applications out there (i.e. no support from Microsoft). Moving forward, I see a lot of benefits.

Comments are closed.