Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-01

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: cga-ext-bounces@ietf.org [mailto:cga-ext-bounces@ietf.org] On
> Behalf Of Tony Cheneau
> Sent: Saturday, November 21, 2009 1:53 AM
> To: Laganier, Julien
> Cc: draft-ietf-csi-proxy-send@tools.ietf.org; cga-ext@ietf.org
> 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
> CGA-EXT@ietf.org
> https://www.ietf.org/mailman/listinfo/cga-ext