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

[<[e-mail]>]

Inline:


On 10/9/09 5:26 PM, "ext Arnaud Ebalard" <[e-mail]> wrote:

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

Only if you disagree about my comment. 3775 does not discuss the security
details and hence mentioning Pfkey interface here has no value.

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

Agree about what the intent of 377bis is. However the reference that you are
suggesting should be a part of the IPsec/IKE(v2) RFCs because it makes more
sense there.  

> 
> Even if you are against the use of IPsec/IKE with MIPv6, this is the
> security mechanism used by the protocol.

I am not "against" the use of IPsec/IKE with MIP6. I just think that it is
an impractical security model for MIP6.

> 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

Right. But not in the context of 3775bis. The aspects of security are
specified in other RFCs which would be the relevant place to provide the
reference. 

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

FWIW we do have a working implementation of MIP6 with IPsec/IKEv2. So I have
never stated that it does not work. I am of the opinion that there are
better security approaches that are easier to implement and deploy for MIP6.
IPsec/IKEv2 was the wrong choice for MIP6 security. However just because
that is what has been specified does not mean we cannot improve it. It is in
the WG and IETFs interest to specify a protocol that is actually
implementable and used rather than defining something which would challenge
implementers without any real benefit.

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

Sure.

-Raj

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