RE: Node Requirements: Issue 13 - CGA/SeND support

["Laganier, Julien" <julienl at qualcomm.com>]

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: john.loughney at nokia.com [mailto:john.loughney at nokia.com]
> Sent: Wednesday, July 22, 2009 9:03 PM
> To: hesham at elevatemobile.com; Laganier, Julien; narten at us.ibm.com;
> ipv6 at ietf.org
> 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: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of
> ext Hesham Soliman
> Sent: Wednesday, July 22, 2009 11:46 PM
> To: Laganier, Julien; Thomas Narten; ipv6 at ietf.org
> 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" <julienl at qualcomm.com> 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: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf
> >> Of Thomas Narten
> >> Sent: Tuesday, July 21, 2009 2:36 PM
> >> To: ipv6 at ietf.org
> >> Subject: Node Requirements: Issue 13 - CGA/SeND support
> >>
> >> Tim Chown <tjc at ecs.soton.ac.uk> 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
> >> ipv6 at ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6 at ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------