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

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

Hello Arnaud,

I have made the changes as we have discussed.
Additional comments inline below:

Arnaud Ebalard wrote:
>   
>> 5.3.  Dynamic Home Agent Address Discovery
>>
>>    No security is required for dynamic home agent address discovery.
>>     
>
> May be it is the way I understanded it but this sounds like "no security
> is needed". It should sounds like "No security is provided for that
> mechanism".
>   

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.


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


>
>>
>>    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.  I'll try to treat the other instances with the same philosophy.
Thanks for pointing them out.


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


>>>> >>>    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?
The question is how to make it work.  And rfc3775bis might not be the
right place for that.

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.

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


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



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.

Regards,
Charlie P.