Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis

[[e-mail] (Arnaud Ebalard)]

Hi,

<[e-mail]> writes:

> A few comments about some of the citations being proposed:
>
>
> On 10/9/09 4:14 PM, "Charles Perkins" <[e-mail]> wrote:
>
>>> Considering the mechanism is implemented and such an interface needed to
>>> support that, 3775bis could at least point MIGRATE doc given below as an
>>> informational reference document. This clarifies the need and gives a
>>> possible solution.
>>> 
>>>  http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00
>>>  
>> 
>> So that I can finish revising rfc3775bis before having to stop and read
>> that draft,
>> can you provide some suggested text for the proposed citation?  I'll try
>> to read the
>> draft in the next few days understand your citation and text.
>
> This reference does not add any value to 3775bis.

I'll take that with salt ;-)

> It is more relevant in the context of 3776 or 4877.  Adding this
> reference even in the Informative section is not required.

I think rfc3775bis is about correcting issues and clarifying parts of
3775 based on existing feedback. IMHO, this is exactly what this
informational reference provides.

Even if you are against the use of IPsec/IKE with MIPv6, this is the
security mechanism used by the protocol. And providing informational
pointers in the spec to possible solutions to support

 - correct use of IKE with MIPv6
 - efficient use of IPsec for protection of tunneled data

is useful. It's not fair to keep saying that MIPv6 does not work with
IPsec/IKE and in the meantime prevent efforts to clarify the
interactions between the protocols to be added to the specs.

That been said, I think I have argued enough on that aspect. I'll let
Charles capture the thoughts of the working group and decide what to do.


>>> It should be stated here or in the "Security Considerations" section
>>> that this procedure is insecure and may have security impact, as we rely
>>> on basic ND and undergo associated threats. This is documented:
>>> 
>>> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00
>>>  
>> 
>> How about:
>> 
>>    o  Given the availability of the home prefix, the MN checks whether
>>       or not the home prefix matches one of the prefixes received in the
>>       RA.  If it does, the MN concludes that it is connected to the home
>>       link.  Please see Section 15.10 for information regarding the
>>       security vulnerability associated with this determination.
>> 
>> 
>> and,
>> 
>> 15.10.  Vulnerabilities from Neighbor Discovery
>> 
>>    The ``Home Link Detection'' mechanism (Section 11.5.2) allows the MN
>>    to detect when it is at home.  When a MN detects it is at home, it is
>>    expected to deregister, and also (if in use) to stop IPsec protection
>>    for data traffic exchanged over the tunnel to its Home Agent.
>> 
>>    Unfortunately, Neighbor Discovery is not a secure protocol.  It is
>>    possible that some networks may harbor malicious routing agents that
>>    might advertise false information which would lead a mobile node to
>>    erroneously determine that it had returned to its home network.
>> 
>>    A draft [40] has been written that discusses the possible threats
>>    and security impacts associated with the use of this insecure NDP-
>>    based mechanism as a trigger to drop IPsec protection of data traffic
>>    for the MN.  It also provides some results on the implementation of
>>    the attacks against an existing MIPv6 module.  Possible solutions are
>>    suggested.
>
> This is a much larger change to 3775bis. I-D:
> draft-ebalard-mext-hld-security-00 has not really been discussed in the MEXT
> WG AFAICT

True. I think I only got a comment from Julien.

> and hence making this change based on this reference is not what I
> believe is in the scope of the current revision of 3775bis.
> If an when the MEXT WG agrees that the threats identified in the referenced
> I-D are accepted, it is okay to make these changes.

Fine with me.

Cheers,

a+