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

From: "Gerardo Giaretta" <[email-masked]>
Date: Fri, 23 Feb 2007 15:40:49 +0100

Hi Jari,

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

On 1/2/07, Jari Arkko <[email-masked]> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
>

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 23 Feb 2007 11:24:39 -0800

A few comments inline.

> to replace the paragraph with the text provided by Jari?

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.

>> 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. You need the
cookie exchange to tell mobile node to initiate IKE_SA_INIT
exchange again to setup the IKE SA. The IKE SA is setup
only after the second exchange.

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

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

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

>> this spec is given that DNS can already provide

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.

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

>> DNS server and every mobile node.)

Agree.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 24 Feb 2007 12:05:07 +0200

Gerardo,

> naming convention was just to give an example or a hint of how we may

I'm reading on...
> home agent FQDN does not allow dynamic assignment of a localized home
Yes.

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

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

Ok.

> Isn't this described also in MIP6-IKEv2 draft? VIjay?

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

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

Ok.

> issue, giving also more details.

Ok.

> thoughts from James, since he has been very active in that part of the

Ok.

> Yes, this is certainly one option. Again I would leave to James the

Ok. James?

> ok, are you suggesting to have the same text here and above about FQDN

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

> "authorized" FQDN. This would require a change in current Diameter

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

> used by the HA to get the authorized FQDN from the AAA server in order

This sounds preliminarily better.

> on one of the two alternatives described above. What do you think?

Ok.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 24 Feb 2007 12:05:11 +0200

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

> unicast address of a particular responder.

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

> is violated in this case.

Ok. Do you have a text proposal?

> home agent unmodified if the home agents are all on the

Ok, sounds good. But we need text.

Ok.

> on the home agents instead of just returning a set of

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...
> to the mobile node. Jari's text below looks good to me.

Great.

Ok.

>>> DNS server and every mobile node.)

Great, thanks for the responses.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 26 Feb 2007 10:47:02 -0800

> This sounds preliminarily better.

I don't like this additional AAA exchange just for the
DNS update. We should go with the solution where the
AAA server sends the mobile node's true FQDN (the one
that appears in the DNS) to the home agent in the AA
Answer message or the Diameter EAP Answer message,
depending on whether authentication and authorization
is done separately or together.

(I haven't followed the work in Dime for a while. So
I don't know what the current thinking is).

>> needed in case EAP is used, 

IMO, whenever the mobile nodes uses different identities
in the IDi field and in EAP payloads, we should require
the AAA server to send the mobile node's identity to
the Home Agent.

Vijay

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 27 Feb 2007 10:30:14 +0100

Hi Jari,

sorry for the late reply. As Gerardo said, the anycast HA assignment was
contributed my Francis and me, so please find below my comments about
the anycast HA assignment. 

> but is that something that has to be mandated? What if the

There were two reasons for mandating the cookie exchange:
1. anycast HA address is typically a single well-known and public
address, which makes it a possible target of DoS attacks. 
2. less impact on IKEv2 exchange, since the complete IKEv2 exchange is
done with unicast address.

If nobody sees a big issue with an anycasted IKE_SA_INIT followed by a
unicast IKE_SA_INIT response without cookie, I'm fine with "SHOULD"
instead of "MUST" for the cookie (Vijay, from your reply it seems you
have concerns?). Using the cookie due to reason 1 can be left to
operator's decision IMHO.

> responds in the usual IKEv2 way?

yes, IMHO we can relax this and it can be left to HA
configuration/operator's decision whether HA always includes cookie or
not (see above). 

> justified in the document.

we could add something like "the MUST in RFC4306 refers to unicast
only". 

> packets to the "closest" place that advertises that address?

all HAs on home link should have same distance in hops from MN, so there
shouldn't be any impact on the notion of delivery of anycast packets by
the routing system. This forwarding allows the operator to control the
assignment of a HA on the home link on a per-case basis based on
parameters defined by operator(e.g., load).

> address replaces the destination address? 

good question. Some options for forwarding are 
1. MAC address replacement, 
2. IP tunneling,
3. IP address replacement. 

The first (and maybe the second) option have the issue that the receiver
of a unmodified packet has no way to determine whether the packet was
already forwarded by another HA or comes from the MN. Hence, it would
apply the same mechanism to forwarded packets as to packets received
directly from the MN. This means that unmodified packets may be
forwarded many times, if the considered parameters (e.g., load) have
changed since the last forwarding or are not the same at all HAs. This
could be prevented by modifying forwarded packets somehow, so that the
HA is able to identify those and doesn't apply the forwarding mechanism
to already forwarded packets. This is not needed if the third option is
used.

> Do you allow each home agent to configure the same anycast address?

yes. I assume that all HAs have at least one anycast address and one
unicast address. All HAs can have the same anycast addresses or
different anycast addresses if there are multiple anycast groups (i.e.,
some HAs have anycast address x, other anycast address y etc).

> or the address of the selected home agent?

Yes, some text should be added about that. The MN could first try to
re-establish the SA with the current HA's unicast address, as Vijay
said. But if this fails, the MN should try to find a new HA, e.g., by
using the anycast HA assignment. 

> this spec is given that DNS can already provide

The anycast mechanism enables initial HA assignment on per-case basis,
e.g., based on current load. This allows more fine-grained load
balancing than DNS-based HA discovery and may save an additional HA
switch for moving the MN to a less loaded HA after bootstrapping. The
anycast mechanism may also be superior in case of DDos attack on certain
HAs (due to more fine-grained load balancing). Finally, the operator has
more control about which HAs will be used by MNs.

Regards,

Kilian

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 27 Feb 2007 14:15:52 +0100

Hi Vijay,

one comment inline...

> I don't know what the current thinking is).

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.

> the AAA server to send the mobile node's identity to

That is the first option I described, isn't it?

--Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 27 Feb 2007 16:59:52 -0800

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

Yes.

Vijay

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Wed, 28 Feb 2007 10:18:36 +0100

> a home agent or send a BU to the home agent if not for

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.

--Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 28 Feb 2007 18:30:57 -0800

> design: we are discussing when the authorization for MIPv6 should be

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

Vijay