draft-ietf-karp-threats-reqs-01.txt (sec 2.1) on-path/in scope attack-actions
- how much it's real and applicable for RPs? - LAN: is replay a possibility with changed SRC Thanks, Uma -----Original Message----- From: Vishwas Manral [mailto:[email protected]] Sent: Tuesday, October 12, 2010 7:45 PM To: Uma Chunduri Cc: Bhatia, Manav (Manav); Joel M. Halpern; [email protected]; [email protected] Subject: Re: [karp] [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues Hi, I find this interesting. If a packet is modified so that it is dropped it could very well be dropped by the router itself. Thanks, Vishwas On Tue, Oct 12, 2010 at 6:49 PM, Uma Chunduri <[email protected]> wrote: > 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 >> > _______________________________________________ > karp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/karp > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
