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

From: "Gerardo Giaretta" <[email-masked]>
Date: Thu, 1 Mar 2007 15:27:11 +0100

On 3/1/07, Vijay Devarapalli <[email-masked]> wrote:
> Gerardo Giaretta wrote:
>
> >> > The AAA exchange may not be an additional one. Currently we are
> >> > discussing this issue in DIME WG (please, it would be great if you
> >> > take part on that discussion too); there are two options under
> >> > discussion, depending if the authorization for MIPv6 bootstrapping is
> >> > performed during the bootstrapping or after the first BU. The latter
> >> > option derives from the consideration that the MN is actually using
> >> > the MIP service only after the first BU.
> >>
> >> Why would a mobile node setup security associations with
> >> a home agent or send a BU to the home agent if not for
> >> mobility service?
> >>
> >
> > I agree for the BU.
> >
> > However, suppose the HA is acting also as VPN concentrator (or 3GPP
> > PDG or similar): there may be cases where the MN sets up a SA with
> > this box and then use it not for MIPv6. This is an issue in DIME
> > design: we are discussing when the authorization for MIPv6 should be
> > performed.
>
> That should be irrelevant. We are talking about DIME extensions
> to support MIPv6. If someone co-locates a PDG and a Mobile IPv6
> HA, why do we care? It is for them to figure out how to make it
> work. :)
>

Not sure about that. The MIP6 service must be explicitly authorized,
so the IKEv2 responder should understand that the IKEv2 exchange is
related to MIP6. Otherwise you need to authorize the service when the
first BU is sent.

--Gerardo

> Vijay

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 Mar 2007 12:24:21 -0800

> related to MIP6. Otherwise you need to authorize the service when the

As far as the use of IKEv2 for Mobile IPv6 signaling messages
goes, a mobile node would not do IKEv2 authentication with a
home agent unless it is for MIPv6 service. So I don't think a
separate step is required.

We didn't add a goal in the HA-AAAH goals document to separate
authentication and authorization, correct?

I don't think that someone co-locating a VPN concentrator with
a MIPv6 home agent is reason enough for us to require separating
authentication and authorization for basic MIPv6 operation. What
am I missing here?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 Mar 2007 15:03:39 -0800

Jari Arkko wrote:
> 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.

I re-wrote the text a bit. Here is the new text.

    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 many mechanisms to assign a local home agent to a
    mobile node.  These mechanisms are out of scope for this document,
    but a couple of them are described here as examples.  One mechanism
    is to provision the mobile node with an FQDN for a local home agent
    when it attaches to the local link through an access link specific
    mechanism.  For example the FQDN of the local home agent can be sent
    to the mobile node using DHCP.  Another mechanism is to specify an
    interoperable naming convention for constructing home agent FQDNs
    based on the mobile node's location.  For example, a mobile network
    operator may 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 is attached to "location A" and 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 Mobile Node
    determines that it is attached to "location A" through access link
    specific mechanisms.  If the mobile operator changes the location
    information for a particular local link, the FQDNs for the home
    agents on the local link should also be updated with the new location
    information.

    If the mobile node is unable to discover a local home agent, it MUST
    use the home agent on its home link.

Comments?

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Fri, 2 Mar 2007 10:35:54 +0100

> authentication and authorization, correct?

Correct.

> authentication and authorization for basic MIPv6 operation. What

Nothing. The main reason for authentication and authorization split
discussed in DIME was not related to this issue (but to the EAP
application support). This was a side issue.

Anyway if the group is fine to not consider this issue, that is fine
with me too.

Going back to the original discussion: how can the AAA server provide
the right identity of the MN for DNS update to the HA?

--Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 02 Mar 2007 14:10:00 -0800

> the right identity of the MN for DNS update to the HA?

How about in the Diameter EAP Response message or the
AA Answer message depending on whether authentication
and authorization are done together or separately?

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Thu, 8 Mar 2007 15:27:33 -0800

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

Sure, go ahead and remove it. The point Jari raised about maintaining a 
single SA between the DNS server and the HA rather than multiple ones should 
be sufficient motivation.

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

It is a little tough to be more precise about this since the IKEv2 spec 
defines no less that 12 different certificate formats that may be used, and 
ultimately concludes that the exact certificate encoding is out of scope of 
the spec. In RFC 4718, Paul and Pasi recommend restricting use to only four 
types to facilitate interoperability. One of the recommended types in both 
documents is "X.509 Certificate - Signature". We could put more text in as 
follows:

       Since the IKEv2 specification [ref] does not include a required 
certificate
       type, it is not possible to specify precisely how the Moible Node's 
FQDN
       should appear in the certificate. However, as an example, if the 
certificate
       type is "X.509 Certificate - Signature" (one of the recommended 
types)
       then the FQDN may appear in the subjectAltName attribute
      extension [ref2].

[ref2] Housley, R., Polk, W., Ford, W., and Solo, D., "Internet X.509 Public 
Key Infrastructure Certificate and Certificate Revocation List (CRL) 
Profile", RFC 3280, April, 2002.

How does that sound?

                    jak