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: 172.24.1.254, CGA generated IPv6 address: 2001:DB8:1:1:3419:DE30:3DA7:1D02
Segment gateway router: “SEND”, IPv4 address: 172.24.1.1, CGA generated IPv6 address: 2001:DB8:1:1:20D5:2985:29C:40D5
Simulated host (standard 7200 router): “SEND_HOST”, IPv4 address: 172.24.1.2, 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 http://172.24.1.254:80
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 http://172.24.1.254:80
subject-name C=US, ST=VA, L=domain, O=info, OU=NSSTG, CN=router
revocation-check none
rsakeypair SEND
auto-enroll
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.
Password:
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 http://172.24.1.254:80
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
exit
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!