Please see in-line: >>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. **IF** MitM can happen and some body can change the SRC address- it's quite simple to make the receiver drop OSPF packet by changing other fields of the IP header. I definitely feel it's better to protect complete IP header if at all it's attempted. One way could be with the new Autype - calculate message digest on IPHeader(nonmutable)+OSPF+etc..(RFC 2328 - D.4.3 6(c)). Thanks, Uma >>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
