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

From: Tony Cheneau <[email-masked]>
Date: Thu, 19 Nov 2009 11:54:48 +0100 (CET)

Hello,

I reviewed draft-ietf-csi-proxy-send-01 and have the following
comments/remarks:

- In section 4.1, "figure 1: Proxy ND operations", in the first message,
   I think the "SLLAO = B_LL" should be "SLLAO = A_LL"

- Small typo in section 6,  "(PSO.)" should be "(PSO)."

- I have a concern about the content of the Security Considerations
   (Section 8).
   It would be nice to have a warning text such as: "Note that if a Secure
   Proxy ND is corrupted, it can impersonate all the node in the subnet
   in which it is authorized to act as a proxy."

- The section 10 (normative references) contains a reference to
   [I-D.ietf-netlmm-proxymip6] that is now RFC 5213

As you can see, I have only minor comments. The document is in a good
shape.

Hope it helps.

Regards,
 	Tony Cheneau

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 19 Nov 2009 09:21:29 -0800

Hi Tony,

Thanks for reviewing the draft!

Replying to your concern on the security considerations "t would be nice to have a warning text such as: "Note that if a Secure Proxy ND is corrupted, it can impersonate all the node in the subnet in which it is authorized to act as a proxy."

I wouldn't use the term impersonate -- the delegation certificate doesn't allow the proxy to impersonate nodes (they're only used for SEND), only to issue ND signalling on their behalf. So a compromised proxy is able, like a compromised router, to siphon off traffic from the host, or mount a man-in-the-middle attack. 

Looking at RFC 3971 for compromised router, it states:

   SEND does not protect against brute force attacks on the router, such
   as DoS attacks, or against compromise of the router, as described in
   Sections 4.4.2 and 4.4.3 of [RFC3756].

(as a side note the sections number of RFC 3756 being referred to above do not exist, I believe it should say 4.2.2 and 4.2.3. Could be fixed in a revision of RFC 3971)

So maybe we want to say something like:

   Thanks to the authorization certificate it is provisioned with, a proxy ND
   is authorized to issue ND signalling 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. As for SEND, 
   which does not protect against against compromise of the route as 
   described in Sections 9.2.4 of [RFC3971], Secure Proxy ND Support for
   SEND does not protect against compromise of the proxy ND.

What do you think?

--julien
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Tony Cheneau [[email-masked]]
Sent: Thursday, November 19, 2009 2:54 AM
To: [email-masked]
Cc: [email-masked]
Subject: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-01

Hello,

Hope it helps.

Regards,
        Tony Cheneau
_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Tony Cheneau <[email-masked]>
Date: Fri, 20 Nov 2009 16:05:37 +0100 (CET)

Hi Julien,

Comments inline:

> I wouldn't use the term impersonate -- the delegation certificate doesn't allow the proxy to impersonate nodes (they're only used for SEND), only to issue ND signalling on their behalf. So a compro…
I agree that "impersonate" may be to strong as the node will likely
realise that they are processing Proxy Signature Option.

However, to me, it seems that the attack I describe and the attack you
describe (on a compromised RFC 3971) router are slightly different.

Allow me to clarify my point:
Generally, without RFC 3971, given that two hosts are on the same link
and uses two addresses with the same prefix, they will communicate
directly. 
When you use RFC 3971, the two nodes will be able to perform
a secured Address Resolution. If an attacker want to perform a MITM
attack, it will try to send NS, NA or redirect message. However, since
it does not know any of the Private Key, he will not be able to sign the
messages, and the attack will fail. This is the expected behaviour.
Even a router can not mount a MITM attack here (the worse he can do is a
DoS by announcing a Prefix Lifetime of 0).

Your draft proposes a new entity named Secure Proxy ND. If we suppose
that a Secure Proxy ND for a specific prefix is corrupted, then the two
hosts from before which are communicating using two address from the
same prefix, are vulnerable to a corrupted Secure Proxy ND that can
send NS/NA and sign using the Proxy Signature Option. Its (compromised)
certificate would authorize it to do so. Do you agree ?  On that
specific point, I think you solution provide more incentive to an
attacker to corrupt the Secure Proxy ND enabled routers. That is
perfectly fine as long as it is stated to be vulnerable to this kind of
attack.

>   SEND does not protect against compromise of the proxy ND.
While I agree with the general phrasing, I think that you should
emphasis that attack is "wider" that the generic SEND compromised
router, as it allows man-in-the-middle attack on node that are
communicating on the link (as stated before).

Another question that comes to my mind just now, and that may need
clarification in your document is:
Is your solution able to provide Secure Proxy ND for the fe80::/64
prefix ? I mean, a router does not announce this prefix as it not a
routable one. Then, there will be no CPS/CPA exchange for this prefix,
meaning no certificate exchange.  What is the processing of a host
receiving a ND message toward a fe80::/64 address signed with a Proxy
Signature Option ?  How can he learn the certificate of the Secure Proxy
ND ? This should be addressed as it is a use case of RFC 4389 (I think).

Feel free to ask if I'm not clear enough and you need clarifications.

Best regards,
 	Tony

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 20 Nov 2009 17:19:30 +0100

Hi Tony,

>> Thanks for reviewing the draft!

<snip>

> ND ? This should be addressed as it is a use case of RFC 4389 (I think).

IMHO, securing ND Proxy for fe80::/64 case is out of scope.
AFAIK (e.g. on FreeBSD, Debian), there is no proxied DAD process for
fe80::/64 based address in a multilink scenario because a router is
able to uniquely differentiate two nodes having the same Link Local
address on two different links: that's why when you want to ping one
node using its Link Local address from a router you have to specify
the interface of the router connected to the node also.

Cheers.

JMC.

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 20 Nov 2009 09:21:25 -0800

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.

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 :)

--julien

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tony Cheneau
> Sent: Friday, November 20, 2009 7:06 AM
> To: Laganier, Julien
> Cc: [email-masked]; [email-masked]
> Subject: Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-01
> 
> Hi Julien,
> 
> Comments inline:
> 
> > Replying to your concern on the security considerations "t would be
> nice to have a warning text such as: "Note that if a Secure Proxy ND is
> corrupted, it can impersonate all the node in the subnet in which it is
> authorized to act as a proxy."
> >
> > I wouldn't use the term impersonate -- the delegation certificate
> doesn't allow the proxy to impersonate nodes (they're only used for
> SEND), only to issue ND signalling on their behalf. So a compromised
> proxy is able, like a compromised router, to siphon off traffic from
> the host, or mount a man-in-the-middle attack.

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 20 Nov 2009 09:32:48 -0800

Hi Jean-Michel,
 
> > Signature Option ?  How can he learn the certificate of the Secure
> > Proxy ND ? This should be addressed as it is a use case of RFC 4389 (I
> > think).
> 

It is in scope and required for RFC 4389 as Tony pointed out, e.g., link-local addresses will be used by routers and will be present in RAs sent by routers, or in NS/NA when a node attempts address resolution for a router's link local. These packets need to be proxied. However the fe80::/64 prefix needs not to be present in the authorization certificates. The draft should simply specify (although it currently does not) that a proxy ND is always authorized to proxy addresses in the fe80::/64 prefix. That has to be fixed in the next revision of the draft.

--julien

---

From: Tony Cheneau <[email-masked]>
Date: Sat, 21 Nov 2009 10:52:48 +0100 (CET)

Hi Julien

> 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 at…
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…
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

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 24 Nov 2009 08:46:16 -0800

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

> Sent: Saturday, November 21, 2009 1:53 AM
> To: Laganier, Julien
> > 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.
> > 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 :)

---

From: Tony Cheneau <[email-masked]>
Date: Tue, 24 Nov 2009 23:40:13 +0100 (CET)

Hi Julien,

>   specified in this document.
I think the text is good now.

> 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 prox…
I would prefer a "prefix or inclusion in the certificate" based solution, as 
I think there is some scenario where you may want to proxy global 
addresses and not the Link-Local ones at all.

I haven't read RFC 3775 recently. Please correct me if I'm wrong, but,
I think, RFC3775 (section 10.4.1) allows this kind of behavior:
"  In order to do this, when a node begins serving as the home agent it
    MUST multicast onto the home link a Neighbor Advertisement message
    [12] on behalf of the mobile node.  For the home address specified in
    the Binding Update, the home agent sends a Neighbor Advertisement
    message [12] to the all-nodes multicast address on the home link to
    advertise the home agent's own link-layer address for this IP address
    on behalf of the mobile node.  If the Link-Layer Address
    Compatibility (L) flag has been specified in the Binding Update, the
    home agent MUST do the same for the link-local address of the mobile
    node."
I assume that if the flag is turned off, you do not defend the
Link-Local addresses. The Home Agent does not need to act as a secure
proxy ND for this address either. Meaning you can disallow the secure
proxy ND on the fe80::/64 prefix/address and lessen the effect of a
compromised secure proxy ND.

Regards,
 	Tony

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 25 Nov 2009 13:41:46 -0800

All right Tony, then I assume we want to have the fe80::/64 prefix present in the certificate when proxying of link local addresses is required (e.g., RFC 4389, RFC 5213.) Do you think we have to include additional text in the draft to reflect that? If yes, any suggestion?

--julien

Tony Cheneau wrote:
> 
> Laganier, Julien wrote:
> > 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?
>

---

From: Tony Cheneau <[email-masked]>
Date: Thu, 26 Nov 2009 09:53:46 +0100 (CET)

Hi Julien,

> All right Tony, then I assume we want to have the fe80::/64 prefix present in the certificate when proxying of link local addresses is required (e.g., RFC 4389, RFC 5213.) Do you think we have to i…

I think some text may be needed to clarify the issue (which is new and 
related to the Secure ND proxy).
Maybe a new section, right after 6.2, named "Handling of Link-Local
Addresses". Containing:

"Secure Neighbor Discovery [RFC3971] relies on certificate to 
prove that routers are authorized to announce a certain prefix.
However, Neighbor Discovery [RFC4861] states that router does not
announce the Link-Local prefix (fe80::/64). Hence, it is unusual for a
SEND certificate to hold a X.509 IP address extensions that authorizes
the fe80::/64 prefix. Some scenario ([RFC4389], [RFC5213], etc) imposes
that the Secure ND proxy provides proxying function for the Link-Local
address of a node. When Secure ND proxy functionality on a Link-Local
address is required, either the address or the Link-Local prefix MUST
be explicitly authorized in routers certificate."

What do you think of it ?

Regards,
 	Tony

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 30 Nov 2009 16:26:59 -0800

Tony Cheneau wrote:
>  
> Hi Julien,
> 
> > All right Tony, then I assume we want to have the fe80::/64 prefix
> > present in the certificate when proxying of link local addresses is
> > required (e.g., RFC 4389, RFC 5213.) Do you think we have to include
> > additional text in the draft to reflect that? If yes, any suggestion?
> 

Ok.

> Maybe a new section, right after 6.2, named "Handling of Link-Local

Maybe rather "Proxying Link-Local Addresses"?
 
> announce the Link-Local prefix (fe80::/64). Hence, it is unusual for a

s/unusual/not required/

> What do you think of it ?

Sounds good Tony, thanks for the text!

--julien