Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split

A few comments inline.

Gerardo Giaretta wrote:

>> >    Additionally, the ability to provide a mobile node with a
>> >    localized home agent (e.g. on the visited link) can help to
>> >    optimize handover signaling and improve routing efficiency in bi-
>> >    directional tunneling mode. There are a variety of ways this can
>> >    be achieved in an interoperable way. One way is to provision the
>> >    mobile node with an FQDN for a local home agent when it configures
>> >    for the local link. Another way is to specify an interoperable
>> >    naming convention for constructing home agent FQDNs based on
>> >    location. For example, an operator might assign the FQDN
>> >    "ha.locationA.operator.com" to the Home Agent located in "location
>> >    A" and the FQDN "ha.locationB.operator.com" to the Home Agent
>> >    located in "location B". If the Mobile Node wants to use a Home
>> >    Agent located in "location A", it will set the QNAME to
>> >    "ha.locationA.operator.com" in the DNS request. The exact way in
>> >    which localized Home Agents are configured is out of scope for
>> >    this draft.
>> This part is rather handwavy. I could not implement anything
>> interoperable based on it.
>>
>> I realize that we debated this in 2005, based on my earlier
>> review of the same document. From the mailing list discussion
>> that I went through, it seemed that there was some support
>> in the WG for keeping the local assignments out of scope.
>>
> 
> Yes, and this is what is stated in last sentence of the paragraph; the
> naming convention was just to give an example or a hint of how we may
> do that.
> 
>> Here's a suggested rewrite:
>>
>>   Note that the configuration of a fixed home agent FQDN does
>>   allow dynamic assignment of a localized home agent. Such
>>   dynamic assignment would be useful, however, for instance
>>   from the point of view of improving routing efficiency in bidirectional
>>   tunneling mode. Enhancements or conventions for dynamic
>>   assignment are possible, but are outside the scope of this
>>   specification.
>>
> 
> I guess your text proposal is "Note that the configuration of a fixed
> home agent FQDN does not allow dynamic assignment of a localized home
> agent..."
> 
> If so, I'm ok with this text. As mentioned earlier, the naming
> convention was just an example provided by Vijay. Vijay: do you agree
> to replace the paragraph with the text provided by Jari?

There was an explicit requirement to support local HA
assignment using DNS. IMO, local HA assignment is
required for any HA discovery/assignment mechanism. So
I would like to keep the text instead of saying it is
out of scope.

The example is trying to describe how a particular
operator may "name" the home agents, what entries appear
in the DNS servers, and what FQDNs are provisioned in
the mobile node.

This particular paragraph underwent multiple changes.
I can re-write the text to better explain how it can be
done or to address any specific concern.

>> >    If an anycast address is returned in response to DNS resolution of
>> >    an FQDN, the IKEv2 transaction between the Mobile Node and Home
>> >    Agent is slightly modified. The Mobile Node sends the IKE_SA_INIT
>> >    request to the anycast address. The node which has the anycast
>> >    address assigned to one of its network interfaces selects a Home
>> >    Agent address from the set of Home Agents managed by the node, and
>> >    forwards the IKE_SA_INIT. If the set of Home Agents is empnty, the
>> >    node simply drops the packet. The Home Agent answers using its own
>> >    address, and includes an "under attack" cookie, in accordance with
>> >    RFC 4306 [7]. The Mobile Node notes the Home Agent address and
>> >    resends the IKE_SA_INIT message to the Home Agent, along with the
>> >    cookie.
>> There are several issues in this. First, I think I understand
>> at least one reason why the cookie exchange makes sense,
>> but is that something that has to be mandated? What if the
>> home network simply figures out what HA should be used and
>> responds in the usual IKEv2 way?

I don't think the IKE SA can be setup if the destination
address on the IKE_SA_INIT request is an anycast address
and the source address on the IKE_SA_INIT response is a
unicast address of a particular responder. You need the
cookie exchange to tell mobile node to initiate IKE_SA_INIT
exchange again to setup the IKE SA. The IKE SA is setup
only after the second exchange.

>> Secondly, responding with the home agent's own address
>> is in violation of a MUST in RFC 4306, Section 2.11. I talked
>> to one of the IKEv2 designers about this and his advice
>> was that the MUST may have been a mistake. Or at least it
>> should be limited to unicast addresses, and leave the behaviour
>> for anycast addresses for future documents. In any case,
>> this deviation from RFC 4306 should be highlighted and
>> justified in the document.

Sure. It is obvious that if the packet was sent to an
anycast address, the response comes back from an unicast
address. Any host that sends an IP packet to an anycast
address should except this irrespective of what protocol
is used. We can mention that the "MUST" in section 2.11
is violated in this case.

>> The third issue is the above notion of a node that owns an
>> anycast address. How does this relate to the usual arrangement
>> where the routing system handles the delivery of the anycast
>> packets to the "closest" place that advertises that address?
>> When you say "forwards", do you mean that the packet is
>> forwarded unmodified, or that the particular home agent's
>> address replaces the destination address? Do you allow
>> each home agent to configure the same anycast address?

When the home agents are part of the anycast group, they
all configure the same anycast address on one of their
interfaces. The current text is confusing since it says
that one node is configured with the anycast address and
it decides which home agent the request should be
forwarded to. This needs to be fixed to say that one of
the home agents gets the request and based on the load
conditions forwards the request to another home agent
that is part of the anycast group.

By "forwarding", we meant the packet can be sent to another
home agent unmodified if the home agents are all on the
same link.

>> Four: What happens when the IKE SA dies or is
>> deleted, but a binding for the mobile node remains
>> in the selected home agent? Will the mobile node
>> re-establish the IKE SA using the anycast address,
>> or the address of the selected home agent?

If the mobile node has a binding with a particular home
agent it must send the IKE_SA_INIT request to the same
home agent and not use the anycast address. I guess this
needs to be said explicitly.

>> Finally, I wonder how useful the anycast part of
>> this spec is given that DNS can already provide
>> a set of addresses.

This mechanism was added because some folks wanted a
mechanism that can return home agents based on the load
on the home agents instead of just returning a set of
addresses.

>> >    The Home Agent MUST set up authorization by linking the home
>> >    address to the identity of the IPsec SAs used to authenticate the
>> >    Binding Update message. The linking MUST be done either during the
>> >    IKE_AUTH phase or CREATE_CHILD_SA phase when the IPsec SAs are
>> >    constructed.
>> >
>> >    If the address is auto-configured, RFC 3775 requires the Home
>> >    Agent to proxy-defend the address on the home link after the
>> >    Mobile Node performs the initial Binding Update. Since it is not
>> >    currently possible to securely proxy CGAs using SEND, attacks on
>> >    address resolution for Neighbor Discovery listed in RFC 3756 are
>> >    possible on dynamically assigned home addresses that are proxied
>> >    by the Home Agent.
>> I do not know what to implement based on the above
>> description. Its clear that a link must be established between
>> the IKE identity and the requested home address. But how?
>> What should be done with the information about the link?
>>
> 
> Isn't this described also in MIP6-IKEv2 draft? VIjay?

draft-ietf-mip6-ikev2-ipsec only deals with home address
assignment. The HA always gives out an 128 bit home address
to the mobile node. Jari's text below looks good to me.

>> "The home agent MUST authorize each home address
>> allocation and use. This authorization is based on linking
>> the mobile node identity used in the IKEv2 authentication
>> process and the home address. Home agents MUST support
>> at least the following two modes of authorization:
>>
>> o   Configured home address(es) for each mobile node.
>>      In this mode, the home agent or infrastructure nodes
>>      behind it know what addresses a specific mobile node
>>      is authorized to use. The mobile node is allowed to
>>      request these addresses, or if the mobile node requests
>>      any home address, these addresses are returned to it.
>>
>> o   First-come-first-served (FCFS). In this mode, the home agent
>>      maintains a pool of "used" addresses, and allows mobile
>>      nodes to request any address, as long as it is not used by
>>      another mobile node.
>>
>>      Addresses MUST be marked as used for at least as long as
>>      the binding exists, and are associated with the identity
>>      of the mobile node that made the allocation.
>>
>>      In addition, the home agent MUST ensure that the requested
>>      address is not the authorized address of any other mobile
>>      node, if both FCFS and configured modes use the same
>>      address space."
>>
> 
> Text is fine with me. The original idea is that we need to add an
> authorization step in order to check if the MN can or cannot
> auto-configure the Home Address. I think your text resolves this
> issue, giving also more details.
> 
>> >    Mobile IPv6 bootstrapping recommends the Home Agent to update the
>> >    Mobile Node's FQDN with a dynamically assigned home address rather
>> >    than have the Mobile Node itself do it (see Section 6 above). This
>> >    choice was motivated by a concern for preventing redirection-based
>> >    flooding attacks (see draft-ietf-mip6-ro-sec [21] for more
>> >    information about redirection-based flooding attacks and the role
>> >    preventing them played in the design of Mobile IPv6 route
>> >    optimization security). Exactly as for route optimization, it is
>> >    possible for a node that is the legitimate owner of a DNS FQDN -
>> >    in the sense that it has a security association with the DNS
>> >    server allowing it to perform dynamic DNS update of its FQDN - to
>> >    bind its FQDN to the address of a victim, then redirect large
>> >    volumes of traffic at the victim. The attack may be propagated
>> >    without the owner's knowledge, for example, if the node is
>> >    compromised by malware, or it may be intentional if the node
>> >    itself is the attacker.
>> >
>> >    While it is possible to prevent redirection attacks through
>> >    ingress filtering on access routers, ISPs have little or no
>> >    incentive to deploy ingress filtering. In some cases, if an attack
>> >    could result in substantial financial gain, it is even possible
>> >    that a corrupt ISP may have an incentive not to deploy ingress
>> >    filters such as has been the case for spam. Consequently, the
>> >    security for dynamic Mobile Node FQDN update has been assigned to
>> >    the Home Agent, where active network administration and vigilant
>> >    defense measures are more likely to (but are not assured of)
>> >    mitigating problems, and the owner of the Mobile Node is more
>> >    likely to detect a problem if it occurs.
>> There are good reasons why using a proxy to do the
>> DynDNS update from your behalf makes sense. But I
>> don't think the above is such a good reason.  The
>> route optimization redirect problem assumes that
>> traffic from an ongoing session is suddenly moved
>> to a new address. If you just change the DNS information,
>> ongoing sessions are not affected, and all new sessions
>> go through the usual TCP slow start etc.
>>
>> (A good reason why it makes sense to use a proxy
>> is that then you just need a secret between the
>> DNS server and the home agent, not between the
>> DNS server and every mobile node.)

Agree.

Vijay

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6