The attached review was written for the General AD but is copied
here since the Last Call is still open. (And FYI, Jari is
holding a precautionary DISCUSS until the Last Call ends.)
Brian
-------- Original Message --------
Subject: Gen-ART review of draft-ietf-mip6-bootstrapping-split-05.txt
Date: Tue, 19 Jun 2007 09:10:56 +0200
From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
To: General Area Review Team <gen-art@xxxxxxxx>
CC: Jari Arkko <jari.arkko@xxxxxxxxx>, gerardog@xxxxxxxxxxxx, kempf@xxxxxxxxxxxxxxxxxx, vijay.devarapalli@xxxxxxxxxxxxx,
Basavaraj Patil <basavaraj.patil@xxxxxxxxx>
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-mip6-bootstrapping-split-05.txt
Reviewer: Brian Carpenter
Review Date: 19 June 2007
IESG Telechat date: 21 June 2007
Summary: This draft is in good shape but has some open issues
around underdefined interoperability. It misuses the term
'anycast'.
Comments:
Substantive:
------------
The draft is generally very clear if one accepts the underlying
model of a split between the Mobility Service Authorizer (MSA)
and Mobility Service Provider (MSP). However I have a concern
that under-specification of MSA/MSP interaction and some details
of MN/HA interaction may lead to interop issues and therefore
encourage the formation of walled gardens, which is the last
thing the Internet needs in mobile service. Also the term 'anycast'
is misused. Details follow:
> 3. Split scenario
...
> If, instead, a PKI is used, the Mobile Node and HA exchange
> certificates and there is no AAA server involved [10].
It is not indicated here or later how this is determined. How, in
an arbitrary deployment, does a MN know whether the AAA or PKI
model is used? Is a MN implementer supposed to code both solutions?
> 4. Components of the solution
...
> An optional part of bootstrapping involves providing a way for the
> Mobile Node to have its FQDN updated in the DNS with a dynamically
> assigned home address.
This turns out to assume that dynamic DNS updates are deployed. I wonder
whether this is a realistic assumption.
> 5.1.2. DNS lookup by service name
...
> ...If the Home Agent of choice does not
> respond for some reason or the IKEv2 authentication fails, the Mobile
> Node SHOULD try other Home Agents on the list.
This is underspecified - what is the timeout for non-response?
Also is the MN supposed to loop, or to try each HA once only?
> 5.1.3. Anycast Address for Home Agent Assignment
There is a serious problem with the way this document uses the
term "anycast address" - see details under section 5.2.1.
> 5.2. IPsec Security Associations setup
...
> ... Choice of an IKEv2 peer
> authentication method depends on the deployment.
Again: that is underspecified. Does an MN implementer have
to implement both, and how does the MN know which one to use?
> 5.2.1. IKEv2 Transaction with anycast Home Agent assignment
...
> ...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/
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf