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

Gerardo,

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

I'm reading on...
>
>> 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..."
>
Yes.

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

I understand the need, but if we include this functionality
the spec needs to be very clear about it. You could either
work on the details or leave it out.

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

Ok.

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

A reference would suffice, if it is described in the
reference.

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

Ok.

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

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

Ok.

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

Ok. James?

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

I think so, but you are of course free to provide something
else, too, as long the details are there.

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

Yes. Or a new AVP, at least. CUI might apply here, but it might
not have exactly the semantics you want.

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

This sounds preliminarily better.

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

Ok.

Jari

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