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

Hi Jari,

please see my comments below. Sorry for the late reply.

On 1/2/07, Jari Arkko <jari.arkko@piuha.net> wrote:
>
> 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)

Actually the open access was one of the main motivations for this
architecture therefore I'll add the text you suggest.

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

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

I will leave other authors (James, Francis and Kilian in particular)
to handle the specific issues on anycast. One comment from my side,
though: this mechanism was included in the document in order to
respond to a request from several WG members to define a HA assignment
mechanism in split scenario. The DNS mechanism provides just a
discovery mechanism and based on this the network provider is not able
to assign a specific HA to a specific UE. The mechanism based on
anycast and IKEv2 should fill this gap and provide means to have HA
assignment also in the split scenario, as we have HA assignment in the
integrated scenario based on DHCP.

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

It's a FQDN format. I'll fix it.

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

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

Yes, that's right. The identity is the IKEv2 identity.

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

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

I'm fine with removing that text. However, I would like to hear
thoughts from James, since he has been very active in that part of the
draft.

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

Yes, this is certainly one option. Again I would leave to James the
proposed text on this.

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

ok, are you suggesting to have the same text here and above about FQDN
in certificates?

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

In case the FQDN is known by the AAA server via EAP, I see two
possible approaches:

- the AAA server provides the HA with the MN's FQDN received via EAP
(e.g. during Diameter EAP application) and the HA stores the
"authorized" FQDN. This would require a change in current Diameter
application

- the HA performs a AAA exchange when it receives a BU with a DNS
Update mobility option; this AAA exchange should be part of the Mobile
IPv6 Diameter application (work in progress in DIME WG) and should be
used by the HA to get the authorized FQDN from the AAA server in order
to update the DNS

The draft should leave the actual definition of either mechanism as
out of scope (as you suggested), but we should put a reference to the
solution.

As a summary, in this draft, I think it is enough to clarify the need
of the FQDN in the cert for the certificates scenario. For the AAA/EAP
scenario, we should provide a reference for the HA-AAA coordination
needed in case EAP is used, but we should at least include some text
on one of the two alternatives described above. What do you think?

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

Thanks, I will fix these editorial issues in next version.

Regards,
--Gerardo

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

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