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

[Alberto García <[e-mail]>]

Hi

|  -----Mensaje original-----
|  De: [e-mail] [mailto:[e-mail]] En nombre
de
|  Laganier, Julien
|  Enviado el: martes, 24 de noviembre de 2009 17:46
|  Para: Tony Cheneau
|  CC: [e-mail]; [e-mail]
|  Asunto: 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.

I don't think the solution is just prefer 'unproxied' information over
'proxied' information. 
For example, I think this would defeat MIPv6 operation (see RFC3775, section
10.4.1): when a node moves away from the home link, the HA multicasts a NA
message, with override flag set to 1 "indicating that the Advertisement
SHOULD override any existing Neighbor Cache entry at any node receiving it."
In this case, the proxied SHOULD override the unproxied message. 
To support this, an explicit mention to this behavior has been included in
the 'Processing rules for receivers' section of version 02 of the draft.

What do you think?

Regards,
Alberto

|  
|  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: [e-mail] [mailto:[e-mail]] On
|  > Behalf Of Tony Cheneau
|  > Sent: Saturday, November 21, 2009 1:53 AM
|  > To: Laganier, Julien
|  > Cc: [e-mail]; [e-mail]
|  > 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
|  > [e-mail]
|  > https://www.ietf.org/mailman/listinfo/cga-ext
|  _______________________________________________
|  CGA-EXT mailing list
|  [e-mail]
|  https://www.ietf.org/mailman/listinfo/cga-ext