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

[Hesham Soliman <hesham at elevatemobile.com>]

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
> --------------------------------------------------------------------