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

Hi all,

I have reviewed this specification. Overall, I like
the basic approach and this will be very useful.
The document is generally in good shape.

However, there are a few technical issues
that need to be resolved before we can
move forward. In particular, the authorization
steps need to be specified in greater detail,
and I also had question marks about the
particular approach to anycast.

Also, I have asked the DNS directorate
to review the DNS-relevant parts.

Please find the detailed comments below:

Technical:

>    This
>    implies that the mobility service is bootstrapped independently
>    from the authentication protocol for network access used (e.g.
>    PANA, EAP).
Perhaps you should allow for the possibility
that there is no access authorization. Suggested
edit: "... from the security mechanisms used for
network access (e.g., EAP or even open access)
>    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.

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.

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

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.

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?

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?

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

>    o  MN identity - the identity of the Mobile Node to be used by the
>       Home Agent to send a Dynamic DNS update.  It is a variable
>       length field.
What format is this in? Please specify.

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

By the way, why does the text say "identity of the IPsec SAs"?
I believe you should talk about the identity used in the IKEv2
authentication process.

There are other reasons beyond lack of SEND proxy mode
that make the use of DAD for authorization bad. Its not
reliable, not all nodes may be on or reachable at all times,
etc.

Here's a possible rewrite of the text. Let me know if this
is what you intended to do:

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

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

>    Notice that if certificates are used in
>    IKEv2, the authorization information about the FQDN for DNS update
>    MUST be present in the certificate provided by the Mobile Node.
Yes -- but can you write this in more explicit
form? For instance, I assume that you meant
the FQDN must appear in some specific field
in the certificate.

>    Regardless of whether the AAA server or Home Agent performs DNS
>    update, the authorization of the Mobile Node to update a FQDN MUST
>    be checked prior to the performance of the update. It is an
>    implementation issue as to how authorization is determined.
>    However, in order to allow this authorization step, the Mobile
>    Node MUST use a FQDN as the IDi in IKE_AUTH step of the IKEv2
>    exchange. The FQDN MUST be the same that will be provided by the
>    Mobile Node in the DNS Update Option. This allows the Home Agent
>    to get authorization information about the Mobile Node's FQDN via
>    the AAA back end communication performed during IKEv2 exchange.
>    The outcome of this step will give the Home Agent the necessary
>    information to authorize the DNS update request of the Mobile
>    Node. See draft-ietf-mip6-aaa-ha-goals [14] for details about the
>    communication between the AAA server and the Home Agent needed to
>    perform the authorization. Notice that if certificates are used in
>    IKEv2, the authorization information about the FQDN for DNS update
>    MUST be present in the certificate provided by the Mobile Node.
This is another case where I believe the important
authorization step is underspecified, and needs to be
specified in more detail to make sure people actually
can implement it. And that they will get it right.

Also, I am unsure if the requirement to use the
FQDN in the IKEv2 exchange is helpful. If an
FQDN X is used in the IKEv2 exchange, but the
actual authentication employs IKEv2/EAP with
a method that does its own identity exchange
with FQDN Y, what happens? Also, you are
preventing privacy NAI usage in the IKEv2
exchange. And if you use a FQDN (no "@", i.e.,
not a NAI) in the IKEv2 identity, how will the
gateway be able to route the AAA request?

One alternative approach would be to require
the following:

- If certificates are used, then the FQDN must
  appear there (but see my previous comment).

- Otherwise, the mobile node's identity is
  taken as asserted in the EAP method
  where available and otherwise from the
  IKEv2 exchange.

- Home agent must be able to match
  mobile node identities to allowed FQDNs.
  For certs, step 1 above suffices. In other
  cases its basically configured information.

- The division of work between the home
  agent and AAA is outside the scope of
  this document. Note that there may be
  non-trivial issues, such as when the
  actual identity is end-to-end hidden
  between the mobile node and the AAA
  server.

Editorial:

>    mobility service.. 
s/.././

>    MSP. Figure 3 illustrates. 
s/illustrates/illustrates this/

>    forwards the IKE_SA_INIT. If the set of Home Agents is empnty, the 

Typo

>    o  Home Prefix (16 octets) - The prefix of the home link through
>       which the Mobile Node must auto-configure its Home Address.
s/must/may/ -- there can be multiple such prefixes, so the mobile
node cannot be mandated to use _this_ prefix. Alternatively,
you can explain that the use of a particular prefix or auto-configuration
is optional, but that if autoconfiguration is used, then one of the
provided prefixes must be used.
>    Security considerations for discovering HA using DHCP are covered
>    in draft-jang-dhc-haopt-01 [15].
>    [15]  Koodli, R., Devarapalli, V., Perkins, C., Flinck, H.,
>          "Solutions for IP Address Location Privacy in the presence
>          of IP Mobility", Internet-Draft, draft-koodli-mip6-location-
>          privacy-solutions-00, February 2005.
I suppose referring to draft-jang is no longer necessary, if
the contents are being moved to a MIP6 WG item draft.

Also, the draft name and reference number do not match.

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