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

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

The reason that I am reacting on this is that we should
either explain, fully, how to do it or otherwise declare
it out of scope.

I see several holes in the example text, including, for
instance, how the mobile nodes determine the locations,
how changes in the available locations are managed
between the MN and HA implementations, etc.

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

Why? There is nothing special about anycast addresses,
syntactically...

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

Ok. Do you have a text proposal?

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

Ok, sounds good. But we need text.

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

Ok.

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

But it is a pretty special way to use anycast. Anycast
deliveries are essentially driven by the routing system,
not application state. Here you do deliver it via routing,
but then you re-deliver it based on application logic.
Architecturally, it might be better have "application"
(Mobile IP in this case) signaling to deal with this.
But perhaps the IKEv2 signaling to refer to another
node can be seen as such...
>
>>> >    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.

Great.

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

Ok.

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

Great, thanks for the responses.

Jari

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