Hi Uma, The reason I did just the source address was because that is the only vulnerability identified till date and is extremely simple to implement with no operational/computational overhead.
However, if the WG thinks that it makes sense for us to cover all the nonmutable fields of the IP header, then that too can be done. Cheers, Manav > -----Original Message----- > From: Uma Chunduri [mailto:[email protected]] > Sent: Tuesday, October 12, 2010 10.52 PM > To: Bhatia, Manav (Manav); Joel M. Halpern > Cc: [email protected]; [email protected] > Subject: RE: [karp] [OSPF] Mechanism to protect OSPFv2 > authentication from IP Layer Issues > > If this has to be protected - I guess it's better to do the > complete IP header (non-mutable) than only the SRC address. > > Thanks, > Uma > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Bhatia, Manav (Manav) > Sent: Monday, October 11, 2010 3:53 PM > To: Joel M. Halpern > Cc: [email protected]; [email protected] > Subject: Re: [karp] [OSPF] Mechanism to protect OSPFv2 > authentication from IP Layer Issues > > Hi Joel, > > [clipped] > > > It seems > > to me that > > if an attacker is present on enough links for this to be a problem, > > then one has a lot more issues than just the preservation of > > adjacencies. In fact, using this attack calls immediate > attention to > > the presence of the attacker. (It is not like a remote DoS or DDoS > > where the attack can continue once the victim is aware. network > > operators will be able to track this VERY fast.) > > Yup, I agree. However, it is a cheap solution to a > vulnerability that exists and which has been mentioned in > multiple documents. > > This attack vector also appears to be in scope as per > draft-ietf-karp-threats-reqs-01.txt (sec 2.1). > > Additionally you could also look at the section 3 of the > above document which says the following: > > 20. In most routing protocols (OSPF, ISIS, BFD, RIP, etc), all > speakers share the same key on a broadcast segment. Possession > of the key itself is used for identity validation and no other > identity check is used. This opens a window for an attack where > the sender can masquerade as some other neighbor. Routing > protocols SHOULD thus use some other information besides the key > to validate a neighbor. One could look at > [I-D.ietf-opsec-routing-protocols-crypto-issues] for details on > such attacks. > > 21. Routing protocols that rely on the IP header (or information > beyond the routing protocol payload) to identify the neighbor > which originated the packet must either protect the IP header or > provide some other means to identify the neighbor. > [I-D.ietf-opsec-routing-protocols-crypto-issues] describes some > attacks that are based on this. > > This solution attempts to fix the above mentioned issues. If > we think that such attacks are NOT in scope of KARP then we > need to remove them from the document lest folks spend time > working on them. > > > > > Second, how would this be deployed? It requests a > > This is an easy part and can be trivially taken care of once > we decide that its indeed a problem that we need work on. > > > modification in the > > sender and receiver behavior for authentication. Is your > assumption > > that this would be handled like a key change? First you > upgrade every > > router on the LAN to be able to receive this, then you turn > on sending > > it on the LAN? It seems to me that in terms of diagnosing > > communication failures one needs to be able to tell from > packet traces > > which behavior is actually being used. > > We could define a new authentication type, say 3, which would > indicate that the new mechanism (i.e. where Apad is not a > constant but derived from source IP of the packet) is being used. > > > > > The third question is actually the most important. Given that > > operators would ahve to choose to enable this new behavior, > is there > > any indication that they would do so? I have heard reports > that some > > operators have started turning off IGP authentication, or using it > > only as a stronger packet checksum. In either case, this > does not add > > value for those operators. > > While I agree that some operators use authentication only for > stronger checksum there are some that care for security. I > also agree that its not very simple to launch these attacks, > however, the idea behind this draft was as I had explained > earlier - it fixes a potential issue at zero (implementation, > computational and operational) cost that exists. My > assumption was that if we are repeatedly citing a > vulnerability then there is a willingness to fix it (see above). > > Cheers, Manav > > _______________________________________________ > karp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/karp > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
