Subject: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Jun 2007 12:16:15 +0300

Authors, WG,

IETF last call and IESG review produced a number of
comments relating to the selection of a home agent
via anycast. See in particular Sam Hartman's Discuss
and Brian Carpenter's comments.

There a number of ways in which we could address
these issues. What I would like to try is to separate
the anycast functionality from this draft and pursue
it as a general IKEv2 extension for any application.
The mip6 document would then advance immediately.
Would this be a good way forward? Comments
appreciated.

Here are the comments from the IESG:
> *Lars Eggert:*
> *Comment:*
> *[2007-06-20]*   For all the different components of the solution, the
> document
>   discusses a number of design options before describing the recommended
>   solution. I find this confusing. It would be much cleaner if there was
>   a normative section that talked about what is recommended, and an
>   informative section (or appendix) that would discuss options that are
>   not part of the recommended set.
>
> INTRODUCTION, paragraph 13:
> >    The solution defined in this document solves the Mobile IPv6
> >    bootstrapping problem (RFC4640) when the Mobile Node's mobility
> >    service is authorized by a different service provider than basic
> >    network access, and is therefore generically applicable to any
> >    bootstrapping case.
>
>   I'm a bit confused by this. Title says this is for "split scenario"
>   bootstrapping. Abstract then says it's therefore generally applicable
>   for any bootstrapping scenario? (Also, it'd be good if the abstract
>   could define the words "split scenario" from the title somewhere, so
>   that folks not familiar with the term understand what it means.)
>
>
> Section 5.1., paragraph 1:
> >    As
> >    mentioned before in the document, the only information that needs to
> >    be pre-configured on the Mobile Node is the domain name of the
> >    Mobility Service Provider.
>
>   This paragraph says "need only domain name." Next paragraph says "MN
>   is configured with DNS server." So apparently MN needs to be configure
>   with at least two pieces of information?
>
> *Sam Hartman:*
> *Discuss:*
> *[2007-06-21]* A question to the aps folks: Doesn't the first label of
> aSRV
> registration need to be a well known port or at least get taken from
> the same namespace?  If so, has mip6 been registered there?  Also, is
> ipv6 an acceptable second label for the srv record?
>
> I'm concerned that the anycast behavior modifies IKEV2.  I don't think
> it is appropriate for MIP6 to be extending or modifying IKE in MIP6
> applications.  Wouldn't it be better to run that extension by the
> IPsec community and make it available generally?
>
> *Russ Housley:*
> *Discuss:*
> *[2007-06-20]*
>   Significant comments were included in the Gen-ART review from
>   Brian Carpenter.  These need to be handled as any other Last
>   Call comments.  (Note: Last Call is not concluded yet.)
>
> *Tim Polk:*
> *Discuss:*
> *[2007-06-20]* This document is underspecified with respect to
> certificate processing and retrieval and CRL
> checking.  The document refers to CRL checking, but Figure 3 and the
> accompanying text
> seem to imply online status checking.  Without additional details, it
> seems unlikely interoperable
> implementations could be developed.
And from Brian Carpenter's last call comments:

> >    ...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...
>  
> That is not IPv6 anycast. The definition of IPv6 anycast addresses is
> quite clear (RFC 4291):
>  
>     Anycast:   An identifier for a set of interfaces (typically
>                belonging to different nodes).  A packet sent to an
>                anycast address is delivered to one of the interfaces
>                identified by that address (the "nearest" one, according
>                to the routing protocols' measure of distance).
>  
> In other words, an anycast HA implementation would assign
> the anycast address to *all* the HAs and the first one to
> respond would "win".
>  
> What is described in the current draft is a perfectly reasonable
> redirect mechanism for load sharing (albeit with a single point
> of failure) but it is *not* IPv6 anycast. It would be anycast
> if *any* of the HAs could respond with the redirect.
>  
> Either the design should be modified to do this, or the word
> "anycast" should be dropped from the description.
>  
> I don't know IKEv2 well enough to find fault with the cookie
> mechanism for implementing a secure redirect. Even though
> it's a bit of a hack, it seems to work. I note that RFC 4306
> does not use the term '"under attack" cookie'.
>  
> ...
> >    The use of anycast address as specified above requires the
> >    implementation of anycast forwarding in such a way that the Home
> >    Agent can distinguish between an IKE_SA_INIT forwarded through an
> >    anycast address and one sent directly from the Mobile Node.  One
> >    possible mechanism is to use IP-in-ip tunneling for forwarding the
> >    IKE_SA_INIT.  In this case, the Home Agent can identify a forwarded
> >    IKE_SA_INIT based on the incoming interface or based on the
> >    additional IP header.  Other mechanisms may be used.
>  
> This is underspecified and will make it impossible to deploy
> heterogeneous HAs together.
>  
> ...
> >    A mobile node's security associations with its home agent may expire
> >    while it still has a valid binding cache entry at the the home
> agent.
> >    In this case, the mobile node MUST NOT use an anycast address as the
> >    destination address in the IKE_SA_INIT exchange to setup new
> security
> >    associations.  It MUST try to setup security associations with its
> >    existing home agent.
>  
> By definition, the MN doesn't know that a given address is an anycast
> address, since anycast addresses are syntactically indistinguishable.
> I think you mean: if the MN obtained its HA address via the "under
> attack"
> cookie exchange, it MUST continue to use that address and not revert
> to the address it got from DNS.
>  
> > 5.3.2.  Home Address auto-configuration by the Mobile Node
> ...
> >    For this reason the Mobile Node needs to obtain the home link
> >    prefixes through the IKEv2 exchange.  In the Configuration Payload
> >    during the IKE_AUTH exchange, the Mobile Node includes the
> >    MIP6_HOME_PREFIX attribute in the CFG_REQUEST message.  The Home
> >    Agent, when it processes this message, should include in the
> >    CFG_REPLY payload prefix information for one prefix on the home
> link.
>  
> It seems that 'should' should be a MUST. I don't see any alternative
> case.
>  
> > 5.4.  Authorization and Authentication with MSA
> ...
> >    The definition of this backend communication is out of the scope of
> >    this document.  In [16] a list of goals for such a communication is
> >    provided.
> ...
> > 6.  Home Address registration in the DNS
> ...
> >    ...The
> >    detailed description of the communication between Home Agent and AAA
> >    is out of the scope of this document.  More details are provided in
> >    [16].
>  
> I see a significant dependency here. I don't see how interoperable
> implementations can be made while these issues are undefined. If  
> these issues are left open, there is a high risk of MSA/MSP interop
> depending on interim or proprietary choices. I don't get this, since
> the whole point of an MSA/MSP split is presumably to avoid
> walled garden deployments. Since [16] is Informative, there is
> nothing at present to prevent this.
>  
> > 9.2.  Home Address Assignment through IKEv2
> ...
> >    RFC 3775 [1] requires that a Home Agent check authorization of a
> home
> >    address received during a Binding Update.  Therefore, 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.
>  
> It isn't obvious why both are needed, but in any case the document
> should specify whether these are MUST implement or MUST deploy.
>  
> > 9.5.  Dynamic DNS Update
> >  
> >    If a Home Agent performs dynamic DNS update on behalf of the Mobile
> >    Node directly with the DNS server, the Home Agent MUST have a
> >    security association of some type with the DNS server.  The security
> >    association MAY be established either using DNSSEC [18] or TSIG/TKEY
> >    [19][20].  A security association is required even if the DNS server
> >    is in the same administrative domain as the Home Agent.  The
> security
> >    association SHOULD be separate from the security associations used
> >    for other purposes, such as AAA.
>  
> Should 'required' be 'REQUIRED'?
>  
> Since use of dynamic DNS is optional, is this a
> 'MUST implement' security requirement?
>  
> ...
> >    In the case where the Mobility Service Provider is different from
> the
> >    Mobility Service Authorizer, the network administrators may want to
> >    limit the number of cross-administrative domain security
> >    associations.  If the Mobile Node's FQDN is in the Mobility Service
> >    Authorizer's domain, since a security association for AAA signaling
> >    involved in mobility service authorization is required in any case,
> >    the Home Agent can send the Mobile Node's FQDN to the AAA server
> >    under the HA-AAA server security association, and the AAA server can
> >    perform the update.  In that case, a security association is
> required
> >    between the AAA server and DNS server for the dynamic DNS update.
> >    See [16] for a deeper discussion of the Home Agent to AAA server
> >    interface.
>  
> Again, is this 'MUST implement'? If so, it increases my concern about
> [16] being non-normative (and again two paragraphs below).
>  
> >    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.
>  
> Again, worrisome in terms of an MN implementer knowing
> what to implement. We don't want MNs that only work with certain
> types of HA/MSA/MSP setups.
>  
> Editorial:
> ----------
>  
> (these are typos that are actually technical errors)
>  
> > 3.  Split scenario
> ...
> > ... the Mobile Node potentially requires a certificate
> >    revocation list check (CTL check)
>  
> s/CTL/CRL/
>  
> > 5.1.  Home Agent Address Discovery
> ...
> >    The Mobile Node needs to obtain the IP address of the DNS server
> >    before it can send a DNS request.
>  
> s/the DNS server/a DNS server/
>  
> > 5.1.1.  DNS lookup by Home Agent Name
> ...
> >    Note that the configuration of a fixed home agent FQDN does allow
> >    dynamic assignment of a localized home agent.
>  
> s/does/does not/
>  
> > 5.2.  IPsec Security Associations setup
> ...
> > ...  This is
> >    needed because the Mobile Node has to provide it is the owner of the
> >    FQDN provided in the subsequent DNS Update Option.
>  
> s/provide/prove/

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

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 26 Jun 2007 02:25:04 -0700

Hi Jari,

I'm fine if we separate the anycast functionality from this draft. 

This functionality was not in the original design team solution and was
added later based on WG discussion. I see it as an optimization that may
be useful in some scenarios, but not generally needed to dynamically
bootstrap MIPv6. 

I would like to get the opinions from Francis and Kilian too, as they
suggested the anycast extension.

Thanks
Gerardo

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2007 11:16 AM
> To: [email-masked]
> Cc: Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter
> Subject: bootstrapping-split anycast/ikev2 ha selection feature
> 
> Authors, WG,
> 
> > >    mentioned before in the document, the only information that
needs
> to
> > >    anycast address.  The node which has the anycast address
assigned
> to
> > >    In this case, the mobile node MUST NOT use an anycast address
as
> > >    detailed description of the communication between Home Agent
and
> AAA
> > >    under the HA-AAA server security association, and the AAA
server
> can
> > >    needed because the Mobile Node has to provide it is the owner
of

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 26 Jun 2007 12:00:11 +0200

Giaretta, Gerardo wrote:
> This functionality was not in the original design team solution and 
> was added later based on WG discussion. I see it as an optimization 
> that may be useful in some scenarios, but not generally needed to 
> dynamically bootstrap MIPv6.
> 

I would also like to learn the oppinion from Francis and Kilian.

IMHO

Separating the anycast feature from the draft: I have no oppinion.  I
agree 'anycast' could be less widely agreed on but at the same time I'm
wondering whether it is possible to design a bootstrapping or discovery
mechanism without anycast or multicast concepts.

The fact that Brian suggests that the anycast behaviour is not as
suggested by this draft (draft suggests the anycast address is assigned
to only one interface whereas in reality the anycast semantics means
that it is assigned to all HAs interfaces) is not anycast's fault but
specifiers' understanding of anycast.

I mean the spec _could_ be improved to take that IESG remark into
account.  The implementation of DHAAD acts as Brian suggests it should act.

>>>> ...The Mobile Node sends the IKE_SA_INIT request to the anycast
>>>>  address.  The node which has the anycast address assigned to 
>>> That is not IPv6 anycast. The definition of IPv6 anycast 
>>> addresses is quite clear (RFC 4291):
>>> 
>>> belonging to different nodes).  A packet sent to an anycast 
>>> address is delivered to one of the interfaces identified by that 
>>> address (the "nearest" one, according to the routing protocols' 
>>> measure of distance).
>>> 
>>> In other words, an anycast HA implementation would assign the 
>>> anycast address to *all* the HAs and the first one to respond 
>>> would "win".
>>> 
>>>  of failure) but it is *not* IPv6 anycast. It would be anycast if
>>>  *any* of the HAs could respond with the redirect.

This is right, and it is the way DHAAD works in theory and in practice: 
MN sends DHAAD-Req to the anycast all-HA address, all HAs receive it and 
only one HA sends back to MN the DHAAD-Rep (collective decision of 
_which_ HA responds is done previously by HAs exchanging values in RAs), 
with its source address that will become the HA address as recorded by MN.

>>> "anycast" should be dropped from the description.

I have no strong oppinion on eliminating the anycast concept from this
draft.

[...]
>>> By definition, the MN doesn't know that a given address is an 
>>> anycast address, since anycast addresses are syntactically 
>>> indistinguishable.

A side note here, not intended to disgress the discussion.  I think the
all_HA anycast address Interface Identifier is reserved by IANA and only
the prefix is variable.  Thus I think a node _can_ distinguish very well
when the address is anycast, especially all_HA anycast.

I also think this address _could_ be used as an address in the SA.

But of course, an anycast address is indeed 128bit as any other IPv6 
address, and in this way indistinguishable.

Just a side note and again, I have no strong oppinion on getting rid of
the anycast aspect from this spec.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Jun 2007 06:10:31 -0700

Hello Jari, Brian and Sam,

I saw three significant comments regarding the use of anycast address.
Let me respond to them.

1. The MIPv6 community has a very good understanding of how IPv6
anycast works. We have been using it for the dynamic home agent
address discovery [RFC 3775] for years. The text in the document
that talks about assigning the anycast address to the one of the
interfaces is the result of some "careless text". Sorry about
that. Needs to be fixed. All the home agents in the anycast group
would have the anycast address configured.

2. The mobile node might not know it is using anycast address
since anycast addresses are supposed to look like unicast address.
MIPv6 home agents anycast address is a special reserved address.
See RFC 2526. The mobile node would know.

3. MIPv6 WG shouldn't be extending IKEv2. Why? Since when? We
have added quite a few attributes/payloads/etc... to IKEv2 already.
We have specified a mechanism to dynamically update the IKEv2 SA
(the 'K' bit in RFC 3775 and 3776). We dynamically update the
tunnel mode IPsec SA with a binding update.

For this document we have extended IKEv2 to ignore the mismatch
between the destination address on the IKE_SA_INIT request from
the MN and the source address on the IKE_SA_INIT response to the
MN. We spoke to a number of IKEv2/IPsec folks on this topic. Most
agreed that the "MUST" in RFC 4306 about matching the destination
address on the IKE_SA_INIT request and the source address on the
IKE_SA_INIT response is wrong. It shouldn't have been a "MUST".

So I don't yet see a reason to remove it.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Jun 2007 06:14:05 -0700

> suggested the anycast extension.

It is true that they suggested it, but we had WG consensus to add
this feature. So it means the MIP6 WG thinks it is a good
optimization. :)

Vijay

> anycast

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 26 Jun 2007 16:05:33 +0200

Hi Jari,

As Vijay said, Brian's comment about wrong use of "anycast" is a
misunderstanding due to unclear wording in the draft. It was the
intention that multiple node (i.e., typcially all HAs) have the anycast
address assigned and that *any* one of those (i.e., the one that receive
the IKE_SA_INIT request) forward it to the "best" HA. The text in
section 5.2.1 should be modified accordingly. This should resolve
Brian's main concern.

Regarding the proposal to separate the anycast assignment from the
draft: The MIPv6 WG has already extended IKEv2 in various ways even in
the same draft, e.g., the MIP6_HOME_PREFIX attribute in the CFG_REQUEST
message or the "USE_ASSIGNED_HoA" Notify Payload for address assignment
in draft-ietf-mip6-bootstrapping-split. I don't understand why the
anycast mechanism should be handled differently (i.e., separated from
the draft) than the other IKEv2 extensions.

Also, I'm concerned about the delay introduced by such a separation and
that it may have impacts on potential deployments. Some operator folks
(e.g., Jean-Michel if I remember correctly) requested a HA assignment
mechanism for the split scenario, and the anycast IKE mechanism is
currently the only mechanism providing this. 

So in conclusion, I also prefer to keep it in the document.

A compromise could be to keep the mechanism in the draft and at the same
time pursue a general anycast-based IKEv2 extension in another WG. When
the general IKEv2 anycast extension will be completed and standardized,
the MIPv6-specific mechanism in the split scenario draft can still be
removed (in a bis-version). 

Kilian

> Sent: Dienstag, 26. Juni 2007 11:16
> Subject: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature
> 
> Authors, WG,
> 

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Jun 2007 09:24:34 -0700

Hi Jari,

I'd certainly be happy with that solution.

If this change is acceptable to the WG, I'd suggest that we remove the 
anycast, then when the general solution is on track for publication, we 
update the bootstrapping RFC to include the anycast feature. I think this 
will facilitate getting the bootstrapping work completed.

                  jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: <[email-masked]>
Cc: "Mobile IPv6 Mailing List" <[email-masked]>; "Sam Hartman" 
<[email-masked]>; "Brian E Carpenter" <[email-masked]>
Sent: Tuesday, June 26, 2007 2:16 AM
Subject: bootstrapping-split anycast/ikev2 ha selection feature

Authors, WG,

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 26 Jun 2007 18:43:42 +0200

Hi all,

> Hi Jari,

[snip]

> (e.g., Jean-Michel if I remember correctly)

Yes. I confirm this fact.
The two main reasons were:
1. The HAs are owned by an operator and so it is natural this ones
decides finally which HA will be provided to a MN.
2. A HA is a point of failure for IPv6 mobility protocols (eg. MIPv6,
NEMO) and, from a security point of view, I don't like the idea to
have the list of all the HAs owned by an operator easily accessible
just with a DNS request.

Best regards.

JMC.

> requested a HA assignment

[snip]

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Jun 2007 09:49:33 -0700

While I don't feel strongly about most of the points made below (though I 
don't agree), there is an implication here that not having the anycast 
feature would somehow delay deployment of the bootstrapping solution 
described in this draft.

Let's be pretty clear about this: the probability of this draft being 
implemented and deployed is effectively zero right now as far as I know. 
Neither of the 3G's or Wimax Forum have included this in their next 
generation architecture and, as we all know, what these groups specify in 
their architecture is what gets deployed. So I don't agree that this is an 
argument for keeping anycast in the draft.

That said, I would really like to get this draft finished and I don't 
believe, given the slim chances for deployment, that it really makes much 
difference at this point if anycast is there or not. This is likely to be 
another one of those RFCs that languishes with little or no implementation 
and deployment, until with a good deal of luck, some set of favorable 
technical and business circumstances develop causing interest to perk up 
(example: the FCC agrees to Frontline's request for a 700 MHz allocation for 
general and public saftey use resulting in a new business model for wireless 
outside of the traditional cellular carriers).  I agree with Sam's argument 
that it makes sense to separate anycast/IKEv2 out as a general feature, get 
a draft going on that, then do an update on this document that describes how 
to use anycast for bootstrapping. Unlike the other "extensions" of IPsec/IKE 
that the WG specified, this particular one involves fundamental changes in 
the basic key agreement protocol, and if there is some kind of subtle bug, 
it could result in an attacker being able to spoof a victim into 
establishing a security association. Cases like this where there are 
multiple parties and lots of stuff going on are often difficult to reason 
about.

In summary, having anycast/IKEv2 in as a feature isn't critical at this 
time, I think we ought to wait and make sure it is done right, then update 
bootstrapping to include it.

            jak

----- Original Message ----- 
From: "Kilian Weniger" <[email-masked]>
To: "Jari Arkko" <[email-masked]>; 
<[email-masked]>
Cc: "Mobile IPv6 Mailing List" <[email-masked]>; "Sam Hartman" 
<[email-masked]>; "Brian E Carpenter" <[email-masked]>
Sent: Tuesday, June 26, 2007 7:05 AM
Subject: RE: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature

Hi Jari,

Kilian

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Jun 2007 11:21:00 -0700

James Kempf wrote:

> generation architecture and, as we all know, what these groups specify 
> in their architecture is what gets deployed.

I believe 3GPP2 is moving towards using IPsec with Mobile IPv6.
Anybody knows better? If/when this happens, configuring a home
address is going to be through IKEv2.

Regarding 3GPP, I am attending the 3GPP SA2 meeting this week in
Orlando. There is one contribution, advocating the use of DNS to
discovery a Mobile IPv6 home agent, that is being handled in
this meeting. We may know at the end of this week how 3GPP is
going bootstrap a Mobile IPv6 home agent.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Jun 2007 11:43:52 -0700

jak>> Just because they use IKEv2 doesn't mean they'll use split 
bootstrapping. I think they already have provision in their architecture for 
the integrated scenerio (some kind of DHCP hack) in fact, if I recall 
correctly, they specifically asked IETF to standardize the integrated 
scenerio, through not through a formal liason. At least, at the time the 
design team concluded, 3GPP2's interest was the justification for doing the 
integrated scenerio.

jak>> Hmm. From my perhaps now out of date knowledge of the LTE 
architecture, SA2 has been slowly whittled away at any relevence of MIP6 for 
LTE until it would only be on S2a and S2b, between WLAN or other non3GPP 
network and 3GPP networks. I think the option of using Mobile IP has already 
been there since R99 in a somewhat different form, but nobody deployed it.

jak>> My point isn't that split bootstrapping will never get deployed, my 
point is that given the rather tenuous interest exhibited by the 3Gs and 
Wimax Forum at this time (which I don't see your note contradicting), there 
is not any real need to put a feature in that looks, with some justification 
in my opinion, to require some extra thought. I think the bootstrapping 
draft without anycast/IKE is sufficient until such time as anycast/IKE has 
been thoroughly examined and found OK. Certainly, split bootstrapping 
becomes much more functional and interesting with anycast/IKE, but I think 
it can be added later.

              jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Jun 2007 12:00:36 -0700

(I trimmed the cc list)

Irrespective of which SDO adopts this mechanism, we still need a
generic mechanism to discover a MIPv6 home agent. And we need a
mechanism that works independent of any access network. DNS-based
HA discovery fulfills that.

James Kempf wrote:
> bootstrapping. I think they already have provision in their architecture 
> for the integrated scenerio (some kind of DHCP hack) in fact, if I 
> recall correctly, they specifically asked IETF to standardize the 
> integrated scenerio, through not through a formal liason. At least, at 
> the time the design team concluded, 3GPP2's interest was the 
> justification for doing the integrated scenerio.

Note that draft-ietf-mip6-bootstrapping-integrated has a normative
dependency to the split scenario solution document to setup IPsec
security associations.

> jak>> My point isn't that split bootstrapping will never get deployed, 
> my point is that given the rather tenuous interest exhibited by the 3Gs 
> and Wimax Forum at this time (which I don't see your note 
> contradicting), there is not any real need to put a feature in that 
> looks, with some justification in my opinion, to require some extra 
> thought. I think the bootstrapping draft without anycast/IKE is 
> sufficient until such time as anycast/IKE has been thoroughly examined 
> and found OK. Certainly, split bootstrapping becomes much more 
> functional and interesting with anycast/IKE, but I think it can be added 
> later.

Ok. I do agree that the IKEv2 anycast method is not required for
split scenario bootstrapping to work. The main advantage is that
it brings together anycast-based load balancing with DNS-based
solution. Many folks were concerned that DNS-based mechanism only
allows a "discovery of home agent", not "assignment of a home agent".
Assignment is now possible with the anycast approach.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Jun 2007 12:29:27 -0700

jak>> Agree.

jak>> Agree also. But I believe Sam has raised some legitimate concerns, and 
I don't see any harm in taking some time to ensure that there are no 
suprises in anycast/IKEv2.

jak>> How about this?

   - Split off anycast/IKEv2 and immediately put it into a draft for 
discussion in the right security forum. Sam can tell us what WG he thinks it 
should be sent to. If the draft gets written by July 2 (this coming Monday!) 
it might even be possible to start discussion in Chicago.

    - Split off bootstrapping on top of anycast/IKEv2 and immediately put it 
into an update WG draft for the MIP6 WG, with normative dependency on the 
anycast/IKEv2 draft.

The anycast feature can advance separately from the base bootstrapping 
draft, until people are sufficiently comfortable with anycast/IKEv2.

                     jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Jun 2007 12:33:27 -0700

James Kempf wrote:
> jak>> Agree also. But I believe Sam has raised some legitimate concerns, 
> and I don't see any harm in taking some time to ensure that there are no 

His concern was about MIPv6 WG not being chartered with extending
IKEv2. Was there anything else?

> discussion in the right security forum. Sam can tell us what WG he 
> thinks it should be sent to. If the draft gets written by July 2 (this 
> coming Monday!) it might even be possible to start discussion in Chicago.
> 
>    - Split off bootstrapping on top of anycast/IKEv2 and immediately put 
> it into an update WG draft for the MIP6 WG, with normative dependency on 
> the anycast/IKEv2 draft.
> 

I don't have a problem with splitting the spec, but we really haven't
see any significant issue yet.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Jun 2007 12:50:35 -0700

jak>> Well then maybe it's my issue. My issue is that it makes sense to me 
to spend some additional time considering whether there are some subtle bugs 
in anycast/IKEv2. It is a major modification in how key exchange is done, 
and a subtle bug could result in an attacker able to spoof a victim into 
thinking trust is established and setting up a security association. Maybe 
I've been spending too much time lately with my head embedded in security 
protocols, but I really don't think we want to set ourselves up for a WEP 
Catastrophe. If I thought there was sufficient deployment pressure, I might 
be more inclined to push for including it in the document, but I just don't 
see any deployment pressure there.

jak>> The point is that reasoning about protocols where there are multiple 
parties involved is difficult, and therefore I think it makes sense to spend 
time making sure the protocol is right. Maybe Sam had to couch his concern 
in some bureaucratese about the MIP6 group not doing IKEv2 enhancements, but 
his core point is still valid, in my opinion. Let's take some time to make 
sure it is right, publish it as a document that will benefit any protocol 
that wants to use it. Right now, it's hidden at the end of this very MIPv6 
specific document.

        jak

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 27 Jun 2007 09:19:15 +0200

Hi all,

I'm not sure what exactly Sam meant with his comment, maybe he can

> IPsec community and make it available generally?

Is it that he has concerns with MIP6 WG modifying/extending IKEv2 for
MIPv6 applications in general or is it that he has security concerns
specifically with the anycast extension?

If it is the latter, I do understand the argument to split off the
anycast IKEv2 extension (although it is difficult to evaluate a security
concern if there is no information what exactly the threat/security
issue might be). But if it is the former, I don't see a strong argument
to split it off, since MIP6 WG modified or extended IKEv2 already many
times.

Fact is that the anycast extension is on the table since November 2005.
It had consensus among the authors of the split scenario WG draft (incl.
James ;), was discussed several times on the mailing list, went through
WGLC, and now through IETF last call/IESG review. During all this time
nobody raised a security issue with the solution in the draft AFAIK.
Also, several MIP6 people (e.g., Vijay, Francis) discussed the anycast
extension with IKEv2/IPsec experts from other WGs and no security
concern was raised AFAIK. 

Regarding the argument of broadening the applicability, I guess we can
have the same argument for other IKEv2 extensions done in MIP6 WG. For
instance, the MIP6_HOME_PREFIX attribute for HoA auto-configuration in
draft-ietf-mip6-bootstrapping-split could also be useful for other
applications than MIPv6 to allow stateless address autoconfiguration of
a remote address, right? So why not split this off? I don't see why it
should be different for the anycast extension. 

And from the other IETF last call/IESG review comments there should not
be any technical issue left with the anycast extension that would result
in a delay of standardization of the split scenario bootstrapping
mechanisms IMHO.

In conclusion, if Sam has no security concerns specifically with the
anycast extension, I still don't see why we should remove it from the
draft. 

BR,

Kilian

---

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Jun 2007 11:16:58 +0300

Kilian,

A comment regarding the MIP6 WG role:

> But if it is the former, I don't see a strong argument
MIP6 WG has been chartered to work on Mobile IPv6
protocol and its extensions. It is true that we have
dealt with some extensions to IPsec/IKE in areas where
IPsec and mobility mechanisms have had to interact.
However, I think it is reasonable to keep those
interactions to minimum, and strive to maintain
independence and generality. In particular, where
we see something might be a generally useful
feature for the IPsec protocol set, it seems wrong
to develop a version of specific to one particular
application.

Jari

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 27 Jun 2007 10:45:48 +0200

Hi Jari,

I fully agree that it makes sense to apply the independence and
generality principle when it makes sense. I also agree that it may make
sense in this case, although this case may be a bit special for the
following reasons:

IMHO, we should apply this principle
1) earlier in the process of a document, so that the standardization of
the "to-be-generalized" mechanism is not unnecessarily and significantly
delayed.
2) equally to all mechanisms/drafts. For instance, what about stateless
address autoconfiguration of a remote address, i.e., HoA
auto-configuration with MIP6_HOME_PREFIX attribute in
draft-ietf-mip6-bootstrapping-split? Shouldn't this also be a candidate?

So if it is only about broadening the applicability, how about a
compromise in this special case: We keep the anycast IKE mechanism in
the split scenario draft (to avoid delay in standardization) and in
parallel pursue a generalized IKEv2 anycast extension in a new document.
When this is completed, we can replace the text in the split scenario
bootstrapping document (in a bis version) with a reference to the
generalized version. We could do the same with the stateless address
autoconfiguration of a remote address mechanism.

Kilian

> Sent: Mittwoch, 27. Juni 2007 10:17
> To: Kilian Weniger
> Cc: [email-masked]; 
> Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter
> Subject: Re: [Mip6] bootstrapping-split anycast/ikev2 ha 
> selection feature
> 
> Kilian,
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Jun 2007 06:53:33 -0700

Brian E Carpenter wrote:
> Hi,
> 
> On 2007-06-26 15:10, Vijay Devarapalli wrote:
> That would be fine for me. (There are some other points in my review 
> though...)

Gerardo, the editor for this document, is a bit busy now. We will
respond to the comments soon.

> OK, but the text didn't make it fully clear that *only* the RFC2526 HA
> anycast address would be used.

You are right. Need to add some text pointing to RFC 2526.

Thanks
Vijay

> Unlike Sam, I've got no opinion on that.
> 
>     Brian
>>
>>>>> needs to
>>>>> assigned to

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Jun 2007 10:00:47 -0700

Killian,

jak>> As I recall, the authors and design team discussed issuing 
MIP6_HOME_PREFIX as a separate draft and rejected the idea because we felt 
that it was, as Jari says, a specific extension for Mobile IPv6. I believe 
we talked with someone in SAAG about this at the time we were considering 
putting it into a separate draft, and we were told to include it in the 
bootstrapping draft rather than separate it out. Other authors please 
correct me if my memory is faulty here. Also, as I mentioned in a previous 
post, anycast/IKEv2 is a change in key agreement, which is a much more 
serious and deep change in the security protocol than MIP6_HOME_PREFIX. 
Therefore, it makes perfect sense to me to spend more time on making sure it 
is right.

jak>> I disagree with this. There is, as I said, no compelling deployment 
reason that bootstrapping needs to be standardized right away (though I 
personally would really like to see this work *done* and published). Also, 
regarding your comment that I supported this extension, it was only "consent 
by silence", and that only in public. I have always believed that 
bootstrapping without anycast/IKEv2 would be useful in and of itself, and at 
the time adding anycast/IKEv2 was under consideration, we exchanged email 
among you, Francis, the other authors, and me about this. I have always had 
some concerns about it but was willing to forgo airing them since the WG 
seemed to be behind it, and because I couldn't quite articulate why I was 
uneasy. Recently, spending more of my time reviewing security protocols for 
some other work I am doing, I've come to appreciate how difficult it is to 
get security protocols right, and how important it is to spend the proper 
amount of time in reviewing them, especially protocols like key agreement 
upon which the security of future transactions is based. I'm glad that the 
IESG has decided to raise this DISCUSS, though I wish Sam's comments had 
been more technicallly directed rather that saying "MIP6 shouldn't do this" 
which, to me, sounds like a juicy invitation for people in the MIP6 WG to 
push back. Finally, I think incuding this in the bootstrapping draft then 
later standardizing a general version is not a good idea, since it could 
result in deployed systems with serious security bugs, if some bug is found 
in the initial version (reference: the WEP Catastrophe in 802.11).

jak>> If you care so much about this, why don't you write a draft right now 
sectioning off the anycast/IKEv2 protocol, submit it by the Monday deadline, 
and put it up for discussion in a security WG in Chicago? I'm sure Sam and 
Jari would be happy to assist getting you set up with the proper venue, 
since they are requesting that it be removed.

                    jak

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 28 Jun 2007 02:29:27 +0200

Hi,

> Therefore, it makes perfect sense to me to spend more time on making sure it

As Kilian mentioned, there was also discussions with IPsec guys about
the anycast/IKEv2 extension and, IIRC, no issues were raised.

> in the initial version (reference: the WEP Catastrophe in 802.11).

You mean there needs more discussion about it (cf. below what are my fears)?

> since they are requesting that it be removed.

The issues I see now are that, knowing that IPsec WG is closed (even
if the ML is, more or less, still alive):
- I don't know where is the right place to discuss about this draft
- I am afraid to see the same (bad - IMHO) results we had with the
IFare BOF (knowing that a standardized IPsec Fail-Over solution is
needed for the HA reliability and we have exactly the same issue here:
a try for a general solution,which would be applied for MIPv6, and has
been aborted, for the moment)

Best regards.

JMC.

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 28 Jun 2007 10:32:01 +0200

James,

> From: James Kempf [mailto:[email-masked]] 
> Sent: Mittwoch, 27. Juni 2007 19:01
> To: Kilian Weniger; Jari Arkko
> Subject: *** Possibly SPAM *** Re: [Mip6] bootstrapping-split 
> anycast/ikev2 ha selection feature
> 
> Killian,
> 

Why is it specific to MIPv6? I guess stateless address autoconfiguration
of a remote address is something that could also be useful for other
applications and scenarios, e.g., using CGAs or privacy addresses in a
VPN scenario, right?

> bootstrapping draft rather than separate it out. Other authors please 

What was the reason?

> Therefore, it makes perfect sense to me to spend more time on 

As I said, fact is that the authors of the draft and the WG already
spent quite some time (almost 2 years) on this, talked to IKE/Ipsec
experts, and appearently all of them felt that the protocol is right.
Otherwise the draft would not have passed WGLC and AD review. 

Anyway, I have problems to understand your concerns, since you haven't
described a specific security issue. If you have a specific issue in
mind, can you please describe the specific threat and issue and how it
can occur in the current protocol? 

Please note that
- due to the mandated cookie exchange, there are two subsequent
IKE_SA_INIT request/reply exchanges. Only the IKE_SA_INIT request
message of the initial IKE_SA_INIT exchange is anycasted and any
following IKEv2 message (IKE_SA_INIT reply, request, reply, IKE_AUTH
etc) is sent by unicast.
- hence, a full RFC 4306 IKEv2 key exchange is done, which only comprise
unicast messages and two parties only. 
- the anycasted initial IKE_SA_INIT msg is forwarded between two HAs
*located on the same link*, i.e., the route taken by the IKE_SA_INIT msg
is the same in case of unicast and anycast (MN->home link) and no new
potential locations for on-path attackers are introduced.
- Since an IKE_SA_INIT request is not a protected message, it can be
spoofed/eavesdropped/replayed/modified/forwarded/etc by anyone anyway,
no matter if sent by unicast or anycast. 

> result in deployed systems with serious security bugs, if 

Note that I had the condition "if it is only about broadening the
applicability" in my sentence above... 

> since they are requesting that it be removed.

Jean-Michel raised already some concerns. Another concern is that I'm
not sure if there are enough people willing to spent time and energy in
standardizing this generalized version. I myself probably won't. What is
the motivation for the MIP6 people to again spent time and energy on
this? They already have developed a solution, which was agreed by the WG
to be standardized. So ideally this should be driven by people from the
IKEv2 community. But are there enough people from this community that
want to spent time and energy on this? Appearently they have not had a
need for such a solution so far...

Kilian

---

From: "James Kempf" <[email-masked]>
Date: Thu, 28 Jun 2007 11:29:54 -0700

jak>> Because the network operator of a VPN gateway  in a typical VPN 
deployment wants the gateway, not the host, to control the address 
allocation. For a VPN application, why would the gateway want to allow the 
host to autogenerate the address? VPN gateways are not deployed on networks 
where hosts can connect, they are deployed in the middle of a corporate 
network on a subnet with no end hosts, so there is no question of wanting 
hosts on the "home" network as in MIP6 to autoconfigure an address that can 
be defended using CGA. So autoconfiguration is not a general feature that 
would appeal to all IKEv2 users, it is specific to MIP6.

What was the reason?

jak>> See above.

jak>> Killian, this feature was added in the last 6 months of the draft 
after you and Francis raised the issue, in fact, I think it was raised 
during WGLC if I recall. At that point, everybody (including me) just wanted 
to get the thing done. I don't think anyone can really say that there has 
been extensive review of this feature. Most people in the WG had checked out 
by that time.

jak>> I've made these concerns abundently clear in my previous posts. I'll 
reiterate them here:

jak>> 1) The feature involves modifying the key provisioning protocol, which 
is a fundamental security feature that, if compromised, can result in 
compromise of all future security transactions. In order to avoid a possible 
WEP Catastrophe, it makes sense to seperate out the feature into a 
standalone document and subject that to extensive review over a longer 
period of time.

jak>> 2) The feature is one that is not specific to MIP6, and would be 
widely useful for many IKEv2 uses. Therefore, it makes sense to standardize 
it as a separate extension to IKE, rather than burying it at the end of an 
obscure MIP6 enhancement document.

jak>> I really wish Sam and Jari had been more clear about the IESG's 
objections, and would argue them for themselves. I don't particularly like 
doing IESG's dirty work,  but I do think they have a point here.

Please note that

jak>> Right, we discussed this. I still think it make sense to have more 
people look at this over a longer period of time. Experience with security 
protocols has shown that the more people that look at it, the more bugs are 
found.

jak>> Well, what about you? Personally, if I had something like this that I 
really cared about, I'd much rather see it standardized as a general feature 
available to all IKEv2 users rather than buried at the end of an obscure 
enhancement to another protocol. And I would also want to know that it was 
reviewed by enough people to have some confidence that it is right. The ADs 
should be ready to help, since they are the ones insisting that it be 
removed. As for what WG to be standardized, that should be discussed with 
the ADs, but maybe it could be done through SAAG, like TLS over UDP was. It 
only takes one person who really cares about the protocol and is willing to 
do the work to make it happen.

            jak

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 28 Jun 2007 17:52:07 -0700

I'm just catching up with this thread.  I do support the notion of
separating out the anycast aspect to make it more generically an IKEv2
capability change, rather than in a specific MIP6 document.  I don't
think this is quite along the same lines of introducing new IKEv2
attributes to carry the home prefix, for instance.  

However, I do share Jean-Michel's concern about the actual possibility
of the work getting done independent of the MIP6 document.  Note that
I'm not as concerned about timeline in this particular case - as James
pointed out, most SDOs have gone the way of the integrated scenario for
HA discovery, as far as I know.  The use of IKEv2 for obtaining home IP
addresses is still being adopted, but, HA discovery via IKEv2 seems
unlikely for immediate adoption. 

That said, I'll also note that HA discovery using anycast in IKEv2 is a
good way of doing it, in my view.  So, I really believe we should
support it - if there is commitment to doing a more generalized
anycast-based discovery in IKEv2 as a separate activity, I'll support
that.  

Thanks,
Vidya

> Sent: Thursday, June 28, 2007 11:30 AM
> Subject: Re: *** Possibly SPAM *** Re: [Mip6] 
> bootstrapping-splitanycast/ikev2 ha selection feature
> 
> Why is it specific to MIPv6? I guess stateless address 
> autoconfiguration of a remote address is something that could 
> also be useful for other applications and scenarios, e.g., 
> using CGAs or privacy addresses in a VPN scenario, right?
> 
> deployment wants the gateway, not the host, to control the 
> address allocation. For a VPN application, why would the 
> gateway want to allow the host to autogenerate the address? 
> VPN gateways are not deployed on networks where hosts can 
> connect, they are deployed in the middle of a corporate 
> network on a subnet with no end hosts, so there is no 
> question of wanting hosts on the "home" network as in MIP6 to 
> autoconfigure an address that can be defended using CGA. So 
> autoconfiguration is not a general feature that would appeal 
> to all IKEv2 users, it is specific to MIP6.
> 
> > we talked with someone in SAAG about this at the time we were 
> > considering putting it into a separate draft, and we were told to 
> > include it in the bootstrapping draft rather than separate it out. 
> > Other authors please
> 
> What was the reason?
> 
> jak>> See above.
> 
> > correct me if my memory is faulty here. Also, as I mentioned in a 
> > previous post, anycast/IKEv2 is a change in key agreement, 
> which is a 
> > much more serious and deep change in the security protocol than 
> > MIP6_HOME_PREFIX.
> > Therefore, it makes perfect sense to me to spend more time 
> on making 
> > sure it is right.
> 
> As I said, fact is that the authors of the draft and the WG 
> already spent quite some time (almost 2 years) on this, 
> talked to IKE/Ipsec experts, and appearently all of them felt 
> that the protocol is right.
> after you and Francis raised the issue, in fact, I think it 
> was raised during WGLC if I recall. At that point, everybody 
> (including me) just wanted to get the thing done. I don't 
> think anyone can really say that there has been extensive 
> review of this feature. Most people in the WG had checked out 
> by that time.
> 
> Anyway, I have problems to understand your concerns, since 
> you haven't described a specific security issue. If you have 
> a specific issue in mind, can you please describe the 
> specific threat and issue and how it can occur in the current 
> protocol?
> 
> jak>> I've made these concerns abundently clear in my previous posts. 
> jak>> I'll
> reiterate them here:
> 
> jak>> 1) The feature involves modifying the key provisioning 
> protocol, 
> jak>> which
> is a fundamental security feature that, if compromised, can 
> result in compromise of all future security transactions. In 
> order to avoid a possible WEP Catastrophe, it makes sense to 
> seperate out the feature into a standalone document and 
> subject that to extensive review over a longer period of time.
> 
> widely useful for many IKEv2 uses. Therefore, it makes sense 
> to standardize it as a separate extension to IKE, rather than 
> burying it at the end of an obscure MIP6 enhancement document.
> 
> objections, and would argue them for themselves. I don't 
> particularly like doing IESG's dirty work,  but I do think 
> they have a point here.
> 
> Please note that
> - due to the mandated cookie exchange, there are two 
> subsequent IKE_SA_INIT request/reply exchanges. Only the 
> IKE_SA_INIT request message of the initial IKE_SA_INIT 
> exchange is anycasted and any following IKEv2 message 
> (IKE_SA_INIT reply, request, reply, IKE_AUTH
> etc) is sent by unicast.
> - hence, a full RFC 4306 IKEv2 key exchange is done, which 
> only comprise unicast messages and two parties only.
> - the anycasted initial IKE_SA_INIT msg is forwarded between 
> two HAs *located on the same link*, i.e., the route taken by 
> the IKE_SA_INIT msg is the same in case of unicast and 
> anycast (MN->home link) and no new potential locations for 
> on-path attackers are introduced.
> - Since an IKE_SA_INIT request is not a protected message, it 
> can be spoofed/eavesdropped/replayed/modified/forwarded/etc 
> by anyone anyway, no matter if sent by unicast or anycast.
> 
> people look at this over a longer period of time. Experience 
> with security protocols has shown that the more people that 
> look at it, the more bugs are found.
> 
> Jean-Michel raised already some concerns. Another concern is 
> that I'm not sure if there are enough people willing to spent 
> time and energy in standardizing this generalized version. I 
> myself probably won't. What is the motivation for the MIP6 
> people to again spent time and energy on this? They already 
> have developed a solution, which was agreed by the WG to be 
> standardized. So ideally this should be driven by people from the
> IKEv2 community. But are there enough people from this 
> community that want to spent time and energy on this? 
> Appearently they have not had a need for such a solution so far...
> 
> jak>> Well, what about you? Personally, if I had something like this 
> jak>> that I
> really cared about, I'd much rather see it standardized as a 
> general feature available to all IKEv2 users rather than 
> buried at the end of an obscure enhancement to another 
> protocol. And I would also want to know that it was reviewed 
> by enough people to have some confidence that it is right. 
> The ADs should be ready to help, since they are the ones 
> insisting that it be removed. As for what WG to be 
> standardized, that should be discussed with the ADs, but 
> maybe it could be done through SAAG, like TLS over UDP was. 
> It only takes one person who really cares about the protocol 
> and is willing to do the work to make it happen.
> 
>             jak
> 
> 
> 
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 29 Jun 2007 10:49:07 +0200

Hi James, 

I guess we have both made our opinions clear enough now to close this
thread. I'm still in favour of the compromise (keep feature in split
scenario draft and in parallel pursue a generalized version) because
otherwise the standardization of the anycast feature for MIPv6 HA
assignment may be significantly delayed or even aborted due to the
various reasons Jean-Michel and I mentioned. And this discussion as well
as the WG decisions in the past have clearly shown that there is
consensus that this feature is a desirable feature.

Let's see what the ADs decide....

Please see some more comments below.

Thanks,

Kilian

> Sent: Donnerstag, 28. Juni 2007 20:30
> Subject: *** Possibly SPAM *** Re: *** Possibly SPAM *** Re: 
> [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature
> 
> autoconfiguration
> question of wanting 

I think what you describe is one possible VPN scenario (you said
"typical"), but there may be others. As you know, VPN is a quite generic
term (according to Cisco "A VPN is a generic term that describes any
combination of technologies that can be used to secure a connection
through an otherwise unsecured or untrusted network",
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/vpn.htm).

> > considering
> was raised 

Well, the discussion of this idea started on the MIP6 mailing list in
October 2005. Francis wrote up the draft
(draft-dupont-ikev2-haassign-00.txt) in November 2005. It was presented
and discussed at IETF#64 in November 2005 and IETF#65 in March 2006. It
was discussed on the MIP6 mailing list multiple times (e.g., in April
06, July 06), on the Ipsec mailing list (Nov 2005), and offline with
IKE/IPsec experts. Later it was added to
draft-ietf-mip6-bootstrapping-split-03.txt, which came out in October
2006. Then there was the WGLC of this draft....

So I would say there were quite some discussions.

> protocol, which 

Of course I agree to your general statement that a buggy key exchange
protocol can result in severe security issues. My question is how
specifically the anycast IKE extension with the properties described in
the list below (only initial IKE_SA_INIT request is anycasted etc) can
result in a severe security issues. Nobody has brought up a specific
security issue during all the discussions so far...

> to standardize 

Hmm, why is the split scenario document obscure? Note that there is a
normative reference from draft-ietf-mip6-bootstrapping-integrated to the
split scenario document.

> particularly like 
> with security 

right, but the problem is that you can always spent more time on a
specification....

BTW, you said that this feature is currently not needed in the split
scenario draft since there is currently no deployment need. Then why do
you have problem with my compromise proposal? There cannot be a WEP
catastrophe if the mechanism is not deployed, right? ;)

> general feature

---

From: "Julien Bournelle" <[email-masked]>
Date: Fri, 29 Jun 2007 12:02:47 +0200

Hi all,

> unlikely for immediate adoption.

 We could provide an HA anycast address to the MN even in the
integrated scenario.

 Am I missing something ?

 Julien

---

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Jun 2007 14:05:34 +0300

> objections, and would argue them for themselves. I don't particularly
> like doing IESG's dirty work,  but I do think they have a point here.

Sorry, this is not the only issue on our table :-) so I'm
just getting to it now.

Anyway, I talked to Sam last night and his main issues are
sufficient review in the IPsec community and creating
protocols that have generic applicability when it makes
sense to do so, which he thinks is the case here. I also
think a generic service for anycasting session setup
for IPsec nodes is a great idea.

Now, I realize that the WG has been on this track for
some time. It would have good to realize we had an
issue earlier, but here we are. I am sensitive to pushing
back on ideas at a late stage, but we also need to
resolve the Discusses somehow so that we can ship
the document. My suggestion to move one part of
the functionality to another document is primarily
a management concern: if your product has a feature
that has problems, do you delay the entire release or
push the feature to another release?

Based on my discussion with Sam, I think our options
are the following:

1. Ensure a wider review of the anycast feature in
    the IPsec community. This could be done in various
    ways, from posting to the list to running a 2nd
    Last Call.

    The review itself will not take too much time (few
    weeks), but I'm concerned that there will be
    significant discussion. At least Sam felt that
    as a member of community he would rather see
    a generic mechanism.

2. Separate the anycast part to a 2nd draft and
    approve the current one in the next couple of
    days.

    The 2nd draft contents would be revised based
    on this discussion. It would be reviewed and
    discussed both on this list and in the IPsec
    community. I'm positive for AD sponsoring
    this document, so I don't expect a lot of
    process delay with regards to the document --
    time needed depends on how long it takes to
    revise it to make it more general, and about
    the review results. My personal guess is that
    this time is close to what it would take to get
    an agreement in approach 1...

    I realize that the question of willingness to
    pursue this outside the original document has
    come up. I would urge the authors to pursue
    this functionality no matter what the document
    packaging is. It is also not the case that
    having the functionality in this document implies
    no work and the separation involves a lot of work.
    In both cases you have get Sam's and the IPsec
    community's buy-in.

Jari

---

From: "James Kempf" <[email-masked]>
Date: Fri, 29 Jun 2007 14:52:21 -0700

I'm certainly in favor or 2). I agree that the amount of time required  is probably  about the same in both cases. 
 
       jak

________________________________

From: Jari Arkko [mailto:[email-masked]]
Sent: Fri 6/29/2007 4:05 AM
To: James Kempf; [email-masked]
Cc: Mobile IPv6 Mailing List; Sam Hartman
Subject: Re: *** Possibly SPAM *** Re: [Mip6] bootstrapping-split anycast/ikev2 ha selection feature

Jari

---

From: "James Kempf" <[email-masked]>
Date: Fri, 29 Jun 2007 14:55:07 -0700

Killian,
 
Like you said, you have your mind made up on this, so I don't see much point in continuing the discussion. My position is, I believe, also clear.
 
          jak

From: Kilian Weniger [mailto:[email-masked]]
Sent: Fri 6/29/2007 1:49 AM
To: James Kempf; Kilian Weniger; Jari Arkko
Cc: [email-masked]; Mobile IPv6 Mailing List; Sam Hartman; Brian E Carpenter
Subject: RE: *** Possibly SPAM *** Re: *** Possibly SPAM *** Re: [Mip6] bootstrapping-splitanycast/ikev2 ha selection feature

Hi James,

Thanks,

Kilian

https://portal02.jwebcity.net/http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/vpn.htm).

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 29 Jun 2007 18:43:09 -0700

>  We could provide an HA anycast address to the MN even in the 

Yes, but, this particular thread is more about using anycast in IKEv2
and whether that should be more generic a capability than specifically
for the HA discovery mechanism. 

Vidya