I think there's three cases: 1. If a link is physically secured it means the link is heavily managed in which case it seems plausible that an admin configures the host on this link as plugged on physically secured link and turns off SEND, e.g., using whatever configuration knob is available on the particular OS. Otherwise (i.e., the link is not physically secured, or the node doesn't know if it is or not),
2. If the link is point-to-point and link layer security is enabled, the node IP layer can figure it out from the link layer through an appropriate API, and as a result turn off SEND. Otherwise, 3. The node uses SEND. --julien Hesham Soliman <[email protected]> wrote: > > 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 always 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 --------------------------------------------------------------------
