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

[[e-mail] (Arnaud Ebalard)]

Hi Charles,

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

> I replaced this sentence by the following:
>
>   Dynamic home agent address discovery has been designed for use in
>   deployments where security is not needed.  For this reason, no
>   security solution is provided in this document for dynamic home agent
>   address discovery.

fine with me.


>>> 6.1.7.  Binding Update Message
>>>
>>>    ....
>>>
>>>    Home Registration (H)
>>>
>>>       The Home Registration (H) bit is set by the sending mobile node to
>>>       request that the receiving node should act as this node's home
>>>       agent.  The destination of the packet carrying this message MUST
>>>       be that of a router sharing the same subnet prefix as the home
>>>       address of the mobile node in the binding.
>>>     
>>
>> This prevents the MN to communicates with the HA on another
>> interface. Is there any reason for that limitation, i.e. not having a
>> SHOULD here instead of a MUST. Or I should ask, what is the reason to
>> have a MUST here.
>>
>> For instance, the main connectivity of the home agent can be provided by
>> a given provided (symmetric line) while the MN are on a subnet for which
>> the prefix is provided by another provider. That way, the download
>> bandwidth used by the MNs is not shared with the upload bandwidth:
>>
>>      ISP1 -- home subnet ---[HA]--- ISP2
>>   
>
> I am willing to change the MUST to a SHOULD, since the message is
> secure and the mobile node ought to be able to decide its fate.  But,
> I would only do so if this seemingly slight change were approved by
> the working group.  I think it goes beyond the kinds of clarifications and
> improvements I can unilaterally decide to do.

I agree with you. I would understand if this is kept as is for that reason.


>>>    In a Router Advertisement, a home agent MUST, and all other routers
>>>    MAY, include at least one Prefix Information option with the Router
>>>    Address (R) bit set.  Neighbor Discovery specifies that, if including
>>>    all options in a Router Advertisement causes the size of the
>>>    Advertisement to exceed the link MTU, multiple Advertisements can be
>>>    sent, each containing a subset of the options [20].  Also, when
>>>    sending unsolicited multicast Router Advertisements more frequently
>>>    than the limit specified in RFC 4861 [20], the sending router need
>>>     
>>
>> s/RFC 4861 [20]/Neighbor Discovery [20]/
>>
>> IMHO, this is easier to read. Note that there are various places in the
>> document where the replacement should be done.
>>   
>
> O.K.  In this particular paragraph, the same document was cited twice, but
> in two different ways stylistically.  I think it would be better like this:
>
>   In a Router Advertisement, a home agent MUST, and all other routers
>   MAY, include at least one Prefix Information option with the Router
>   Address (R) bit set.  Neighbor Discovery (RFC 4861 [20]) specifies
>   that, when including all options in a Router Advertisement causes the
>   size of the Advertisement to exceed the link MTU, multiple
>   Advertisements can be sent, each containing a subset of the Neighbor
>   Discovery options.  Also, when sending unsolicited multicast Router
>   Advertisements more frequently than the limit specified in RFC 4861,
>   the sending router need not include all options in each of these
>   Advertisements. 
>
>
> The citation is made only once in the paragraph, both the protocol name and
> the RFC number are clearly associated, and a small bit of repetitive
> verbosity is reduced.

looks ok.


> I'll try to treat the other instances with the same philosophy. Thanks
> for pointing them out.

Thanks


>>> 8.4.  IPv6 Home Agents
>>> ...
>>>     
>>
>> No opinion on whether this is a good idea or not, but probably worth
>> asking: what about also adding a reference to RFC 4389 (experimental
>> doc)?   
>
> I don't think that the simple existence of an experimental document that
> describes various features of proxy ND agents is a strong argument for
> inclusion.  Did you check whether the RFC 4389 specifications are fully
> compatible with Mobile IPv6 as currently specified?  I think it would be
> wise to do so before making the citation.  If there are cases that are
> handled better in RFC 4389 (e.g., ICMP messaging, neighbor cache
> operations), then it would be a good idea to (a) make Mobile IPv6
> more correct and then (b) cite RFC 4389.  I don't think we can rely
> on RFC 4389 to identify the correct behavior, however, because then
> the citation would be normative and that would be trouble for an
> experimental RFC.
>
> That's a long way of saying I am quite leery of making this citation.
> But I'm interested to hear your further comments, and especially if
> you have assurance that there are no incompatibilities between
> RFC 4389 and rfc3775bis.

ok. Let's just drop that comment then. I don't think this is worth
losing our time on that.


>>>>> >>>    o  The node MAY support stateful address autoconfiguration mechanisms
>>>>> >>>       such as DHCPv6 [32] on the interface represented by the tunnel to
>>>>> >>>       the home agent.
>>>>> >>>             
>>>> >>
>>>> >> How is that supposed to happen/work? Is that to support provisioning of
>>>> >> *additional* addresses (not HoA) from the Home Network? It is unclear.
>>>> >>         
>>> >
>>> > What if (a) the mobile node gets an address from DHCP and then
>>> > (b) runs IKE with its home agent?
>>>     
>>
>> Sorry, I do not understand what you mean. Can you describe more
>> precisely the steps? The tunnel does not even exist prior to the binding
>> (which require the HoA) so I don't see how this can work.
>>
>>   
>>> >  How should the statement be made clearer?     
>>
>> Well, I don't even see how this can work so at the moment, I would
>> remove that item.
>>   
>
> I should have thought more about this before answering the first time.
>
> I agree it isn't clear, because I think there are several scenarios.
>
> First, we can agree that mobile nodes MAY support DHCPv6, right?

yes, it might.

> The question is how to make it work.  And rfc3775bis might not be the
> right place for that.

I agree. There are some thoughts on the topic in 10.4.4 but I don't
think this would help a lot.

> But here are some (slightly) better considered ideas.
>
> -  the mobile node might use DHCPv6 for configuration information
>   other than its IPv6 address
> -  the mobile node might use DHCPv6 to extend the lifetime of its
>    existing home address
> -  the mobile node might try to use its existing home address, but
>    get a new address from the DHCPv6 server in reply.
> -  for such a new home address, it might need to use IKEv* to
>    make a new security association
> -  perhaps the old address is still valid for a short time while the
>    new IKEv2 packets are tunneled with the home agent
> -  the mobile node should be able to run DHCPv6 to get care-of
>    addresses to be used on the same network interface as
>    is used to support the tunnel to the home agent.
>
> I don't claim that having the abovementioned possibilities makes
> the bulleted item in question any more clear, but I'm not sure
> how to make it clearer, and I somehow don't think that section
> is the right place to lay out all the possibilities for DHCPv6
> interactions.
>
> So unless someone tells me different, for now I'll just leave
> it alone.

ok.


>>>    attempt to intercept packets on the mobile node's home link that are
>>>    addressed to the mobile node.
>>>
>>>    In order to do this, when a node begins serving as the home agent it
>>>    MUST multicast onto the home link a Neighbor Advertisement message
>>>    [20] on behalf of the mobile node.
>>>     
>>
>> As specified in section 10.3.1:
>>
>>    Unless this home agent already has a binding for the given home
>>    address, the home agent MUST perform Duplicate Address Detection [21]
>>    on the mobile node's home link before returning the Binding
>>    Acknowledgement.
>>
>> So, the last sentence should be modified to indicate that the NA is sent
>> only after that initial DAD.
>>
>>   
>
> How about:
>
>   In order to do this, when a node begins serving as the home agent it
>   MUST have performed Duplicate Address Detection (as specified in
>   Section 10.3.1), and subsequently it MUST multicast onto the home
>   link a Neighbor Advertisement message [20] on behalf of the mobile
>   node.
>
>
>>>
>>>    o  In addition, for all security associations bound to the mobile
>>>       node's home address established by IKE, the mobile node MUST
>>>       include an ISAKMP Identification Payload [6] in the IKE phase 2
>>>       exchange, giving the mobile node's home address as the initiator
>>>       of the Security Association [5].
>>>
>>>    The Key Management Mobility Capability (K) bit in Binding Updates and
>>>    Acknowledgements can be used to avoid the need to rerun IKE upon
>>>    movements.
>>>     
>>
>> 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.

Considering Basavaraj's comments and unless other people in the WG
supports the inclusion, this introduction to the content of the draft is
more for you to understand what it discusses if you decide to read it:

MIPv6 requires the use of IPsec for protection of signaling
traffic. Static keying must be supported. Dynamic keying (using IKE) is
optional. Traffic tunneled between the MN and its HA may optionnally be
IPsec protected. 

When a handovers occurs, the CoA changes. For IKE this basically implies
that the IKE_SA (Phase 1 for IKEv1) is no more usable. Additionally,
when tunnel mode is used, the states maintained by the IKE daemon
(mirrored SP and SA endpoints information) are wrong (they reference the
wrong address). The endpoint of the tunnel mode SA present in the IPsec
stack are also wrong for the same reason after the handover.

The draft provides *a* solution to support the update of previous
elements, and prevent the need to drop and rekey everything (and/or
force the user to manually update its SP/SA).

Implementations of the mechanism are publicly available (Linux Kernel,
racoon IKEv1 daemon, StrongSwan IKEv2 daemon and UMIP MIPv6 daemon).


>>>    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 has returned home.
>>>     
>>
>> 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.

Works for me. But let's let the WG decide if this fits.


> And, finally:
>
>> 17.  Acknowledgements
>>
>>    We would like to thank the members of the Mobile IP and IPng Working
>>    Groups for their comments and suggestions on this work.  We would
>>    particularly like to thank (in alphabetical order) ...
>
> I wonder if anyone noticed the names had not been in alphabetical
> order :-) for a really long time.
>
> There is still one more issue I am working on before considering this
> revision to be complete.
> But I thought it would be better to send this long-ish email out first
> because it will take me a
> while to puzzle over that issue.  Plus there are all those citations
> to modify.

Thanks for your work,

Cheers,

a+