Hi Michael, On Nov 15, 2011, at 10:26 AM, Michael Richardson wrote:
> > > >>>>>> "Lorenzo" == Lorenzo Colitti <lore...@google.com> writes: > Lorenzo> 4. For security, I think we should pick an auth scheme and > Lorenzo> stick to it, otherwise > Lorenzo> it will just lead to fragmentation. Some pre-shared key > Lorenzo> scheme might be adequate; I don't know much about security > Lorenzo> so I don't really care what it is, but I do think we need > Lorenzo> to have one and it needs to be the same for > Lorenzo> everyone. I think we should say MUST here. > > So, let me go over the options in order to violently agree. > > 1) OSPF is multicast, so we can't use any bilteral key-agreement > protocol on it's own. Statically keyed AH can be used for multicast > traffic, and a router can trivially ignore an AH validation failure in > order to provide some diagnostics by evaluating the contents of > the OSPF frame. (This requires hacks on platforms that already have > IPsec, but if you implement the AH inside the OSPF daemon....) > > (so diagnostics can say, "I saw router FOO on interface BLAH, but > the key didn't match, so I ignored it", or even, "I saw router FOO > on interface BLAH, and since the key didn't match, I treated it as a > guest network". What router FOO thinks of the packets it receives is an > open question) > > 2) While we could invoke some kind of group-KMP, these essentially work > out to a series of bilateral trust relationships which results in the > master machine giving out the pre-shared secret in a secure fashion. > The bilateral trust mechanism needs to be anchored by something, > and you can invoke public key mechanisms, or... shared secret. > > Public key mechanisms with a leap-of-faith and then confirmation via UI, > would be very cool, but completely exceeds our needs. > > 3) my understanding is that OSPFv3 eliminated the plain-text HELLO and > md5 methods. > > The major thing we need to specify for zOSPF is that we need to pick a > well-known SPI value for the AH header. That SPI value will need to > specify an algorithm (HMAC-SHA1, HMAC-SHA2, HMAC-SHA3...) and perhaps a > key length. We should publish a few choices for future interop, but we > will need to pick one MUST for today. We can't really be resistant > against a bid-down attack, but even HMAC-SHA1 is pretty resistant today > (vs bare SHA1), and I think that we can count upon being able to specify > HMAC-SHA3 for this work. We will soon have non-IPsec authentication for OSPFv3: http://www.ietf.org/id/draft-ietf-ospf-auth-trailer-ospfv3-10.txt The point that I don't understand from this E-mail thread is where the Security Association (SA) comes from to use for auto-configured OSPFv3 routers? I guess it is from a USB flash drive ;^)). Also, are you and Lorenzo suggesting we make authentication MANDATORY in for auto-configured OSPFv3 routers? Thanks, Acee > > -- > ] He who is tired of Weird Al is tired of life! | firewalls > [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE> > then sign the petition. > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
