Hi Tony, I had overlooked the proxy ND siphoning off traffic exchanged between two on-link link-local addresses. I agree that this is a difference with the compromised router threat and should be acknowledged in the document. How about the following?
Thanks to the authorization certificate it is provisioned with, a proxy ND is authorized to issue ND signaling on behalf of nodes on the subnet. Thus, a compromised proxy is able, like a compromised router, to siphon off traffic from the host, or mount a man-in-the-middle attack. However, when two on-link hosts communicate using their respective link-local addresses, the threats involved with a compromised router and a compromised proxy ND differs because the router is not able to siphon off traffic exchanged between the hosts or mount a man-in-the-middle attack, while the proxy ND can. As for SEND which does not protect against attacks involved with the compromise of a router, as described in Sections 9.2.4 of [RFC3971], Secure Proxy ND Support for SEND does not protect against similar attacks involved with the compromise of the proxy ND. However, the additional threat of siphoning off or mounting a man-in-the-middle attack between two link-local addresses is countered by having SEND nodes receiving both unproxied and proxied messages give priority to unproxied ones. Here, the "unproxied" messages are those that contain a valid signature option as specified per the SEND specification [RFC3971], and "proxied" messages are those that contain a valid proxy signature option (PSO) as specified in this document. As to specifying that the proxy ND is always authorized to proxy for addresses in the fe80::/64 prefix vs. inclusion in the certificate of either a list of node's link local addresses that the proxy ND is authorized to proxy, or of the whole fe80::/64 prefix, I have no strong opinion and would like to ask the WG participant what is their preference there? --julien > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Tony Cheneau > Sent: Saturday, November 21, 2009 1:53 AM > To: Laganier, Julien > Cc: [email protected]; [email protected] > Subject: Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-01 > > Hi Julien > > On Fri, 20 Nov 2009, Laganier, Julien wrote: > > > Tony, > > > > If a router is compromised, it can send a RA containing a PIO with > the L bit set to zero, and thus two hosts on the link trying to > communicate will sends their packets to the router and will not attempt > to resolve each others' address. Doing so, it can mount a MiTM attack > of siphon off packets sent by a host. This is acknowledged in section > 4.2.1. of RFC 3756. > Indeed, I forgot this L flag. You're right. > > > > Regarding the fe80::/64 prefix, it does not need to be advertized by > the router or proxy. It should be assumed that a ND proxy is always > authorized to proxy signaling for the fe80::/64 prefix. That does not > need to be signaled in the certificate, it has to be written down in > the draft however :) > This is a good way to go (other way around seems to add the fe80::/64 > prefix to > the Secure Proxy ND's certificate). However, can you add a security > consideration specific to this new "rule" ? I see a security issue here. > > From RFC 4861, section 4.6.2 (the Prefix Information Option): > "A router SHOULD NOT send a prefix option for the link-local prefix and > a host > SHOULD ignore such a prefix option." > > Meaning that the attack in 4.2.1 of RFC 3756 "SHOULD NOT" work on two > nodes > communicating directly using their link-local addresses (as the PIOs > sent by > the router will more likely be ignored). > Here, the Secure Proxy ND seems to be able to siphon off the > communication of > the same two nodes using their link-local addresses (as it is always > authorized > to proxy signaling for the fe80::/64 prefix). > > Maybe I am (again) missing something here. > > > Regards, > Tony > _______________________________________________ > CGA-EXT mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cga-ext _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
