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

[Hesham Soliman <hesham at elevatemobile.com>]

On 23/07/09 2:29 PM, "Laganier, Julien" <julienl at qualcomm.com> wrote:

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

=> Agreed.

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

=> Not sure about that. What does PPP tell you about a 3G link? Nothing
useful. Ideally, there should be such API and it is there in some cases but
not all.

Hesham

> 
> 3. The node uses SEND.
> 
> --julien
> 
> Hesham Soliman <hesham at elevatemobile.com> 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" <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
>>> --------------------------------------------------------------------
>> 
>