Hi,
I went thought the document and I have some concerns regarding
interaction with Secure Neighbor Discovery (SeND).
I am unclear in section "Security Considerations" of the document. and
whether it suggests SeND cannot be enabled on the DSL scenario, or just
the option-(Line Identification Neighbor Discovery Option) is not
protected. Neither sounds acceptable.
Assuming the latter (option not part of the signed message), I had a
quick re-look at RFC3971and both sections 5.2.1 and 5.2.2 are in
contradiction with what is proposed here.
In 5.2.1, "The RSA Signature option is added as the last option and in
5.2.2, "The receiver MUST ignore any options that come after the first
RSA Signature option"
In the context of SeND, that pretty much mandates any option to be part
of the signed message, and pretty much prevent intermediary nodes to
insert/delete options unless they do proxy-SeND, which is yet to be
standardized.
Note that ignoring an option in SeND is not that easy anyway: the
checksum is also signed. The (icmp) checksum obviously checksum the
entire message, including the LIO. It's in 2463; section 2.3. So in
order to ignore an LIO, the sender would have to sign a pseudo message
containing a pseudo-checksum that would ignore the LIO. Starts to be
very messy. And anyway, should be explained in the draft
I would suggest that you synchronize with proxy-SeND work so that AN can
re-sign the message.
Eric
Suresh Krishnan a écrit :
Hi Folks,
We have published a new version of the DSL line identification draft
that addresses the comments received at the last IETF meeting.
* It includes a network reference diagram
* It adds text describing the Broadband Forum TR-101 model and adds a
reference to the model
* It adds text describing the n:1 vlan model that causes issues with
SLAAC
* It addresses issues raised at the Broadband Forum IPv6 interim
meeting about adding the option in the RAs
The draft is available at
http://tools.ietf.org/html/draft-krishnan-6man-rs-mark-02
Please take a look at the document and let us know if you have any
issues or suggestions or if you support this work.
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
