Hi Julien,
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 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 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?
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
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
