Hi Eric,
I'd be interested by your (implementor) thoughts on the following if you
have some time.
I thought SEND specification (RFC 3971) would support the following
scenario but in the end, it is unclear (I would say the spec is
contradictory on that aspect):
A MIPv6 MN with partial support for SEND: it supports only the
certificate-based part of the spec and knows nothing about CGA. It is
configured with trust anchors and supports sending RS with Timestamp
and Nonce option. It would allow it to verify RA messages sent by
SEND-enabled routers. One possible interest of such a mode is for
securing the MIPv6 home link detection mechanism (see [1] for
rationale).
In the specification, we have the following:
Section 5.3.3:
"If the node has been configured to use SEND, all advertisements sent
in reply to a solicitation MUST include a Nonce, copied from the
received solicitation. Note that routers may decide to send a
multicast advertisement to all nodes instead of a response to a
specific host. In such a case, the router MAY still include the nonce
value for the host that triggered the multicast
advertisement. (Omitting the nonce value may cause the host to ignore
the router's advertisement, unless the clocks in these nodes are
sufficiently synchronized so that timestamps function properly.)"
Section 8:
o Unsolicited advertisements sent by a SEND node MUST be secured.
o A SEND node MUST send a secured advertisement in response to a
secured solicitation. Advertisements sent in response to an
unsecured solicitation MUST be secured as well, but MUST NOT
contain the Nonce option.
I may have missed something in the specification but it seems both
sections are contradictory on that aspect.
So, what is a SEND router expected to do when receiving a unsecured RS
with a Timestamp and a Nonce option?
Cheers,
a+
[1]: http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext