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

["Charles E. Perkins" <[e-mail]>]

Hello folks,

O.K.  I will hold off on submitting the document until this
situation is cleared up.  It is easy for me to omit these new
citations and accompanying text (a lot easier than writing
them in the first place).

Anyway I will put the completed revision on a website
for review before submitting it to the Secretariat.

Regards,
Charlie P.


[e-mail] wrote:
> 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. It is more relevant in the
> context of 3776 or 4877.  Adding this reference even in the Informative
> section is not required.
>
>   
>>> 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 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.
>
> -Basavaraj
>
>
>
>