John, I think the node can know this in a number of situations, and if it doesn't, it can still use SEND in mixed mode which would let the node issue SEND protected ND signaling, while accepting both SEND-protected and unprotected ND signaling.
But the question you're asking is indeed a good one: is SEND a basic feature of IPv6 that all nodes SHOULD support. Probably we should try to answer this before entering into the details of when to use it or not. --julien > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, July 22, 2009 9:03 PM > To: [email protected]; Laganier, Julien; [email protected]; > [email protected] > Subject: RE: Node Requirements: Issue 13 - CGA/SeND support > > Hesham, > > I agree with you, the Node cannot know this, it can only do the right > thing once the SeND process starts. Do people feel that SeND should be > a basic feature of IPv6 that all nodes SHOULD support? > > John > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > ext Hesham Soliman > Sent: Wednesday, July 22, 2009 11:46 PM > To: Laganier, Julien; Thomas Narten; [email protected] > Subject: Re: Node Requirements: Issue 13 - CGA/SeND support > > Looks good in general, but I'm not sure if the host can always > determine the nature of the link or the level of security available on > that link. It can probably infer (sometimes inaccurately) but it's not > laways possible to know. > > I agree with the SHOULDs and the intention of the MAY, I just don't > know if a host knows enough to decide about the MAY. > > Hesham > > > On 23/07/09 12:59 PM, "Laganier, Julien" <[email protected]> wrote: > > > Just for the sake of getting the discussion started, I drafted some > > text we can discuss: > > > > Secure Neighbor Discovery [RFC3971] SHOULD be supported. > [RFC4861] states: > > > > Cryptographic security mechanisms for Neighbor Discovery are > outside > > the scope of this document and are defined in [RFC3971]. > > > > Secure Neighbor Discovery [RFC3971] SHOULD be used when physical > security > > on the link is not assured. [RFC3971] states: > > > > The SEND protocol is designed to counter the threats to NDP. > These > > threats are described in detail in [22]. SEND is applicable in > > environments where physical security on the link is not assured > (such > > as over wireless) and attacks on NDP are a concern. > > > > Secure Neighbor Discovery [RFC3971] MAY be disabled when the link > is > > point-to-point and link-layer security is assured, including > mutual > > authentication of the link end-points and data origin integrity > protection. > > > > What do you think? > > > > --julien > > > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf > >> Of Thomas Narten > >> Sent: Tuesday, July 21, 2009 2:36 PM > >> To: [email protected] > >> Subject: Node Requirements: Issue 13 - CGA/SeND support > >> > >> Tim Chown <[email protected]> writes: > >> > >>> What about CGA/SeND support? I can't see any reference to this > >>> currently. Should there be? It's often waved as the answer to > >>> make rogue RAs 'go away', so perhaps we should. > >> > >> I agree we need to have a section that addresses this topic. > >> > >> If no one suggests text, I'll take a stab. > >> > >> Thomas > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> [email protected] > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
