Hi Brian,
Thanks for the detailed review.
We mostly probably will remove the Anycast based assignment of the
Home Agent from the spec and standardize it separately. The use of
anycast address for the IKE_SA_INIT request message and then picking
a particular responder might have uses beyond just Mobile IPv6. Sam
wanted this standardized separately with adequate review from IPsec
folks.
I am responding to your other comments.
Brian E Carpenter wrote:
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?
The text is a bit loose. The above text should have been
If, instead, PKI is used, the Mobile Node and HA use certificates to
authenticate each other and there is no AAA server involved [8].
It will be configuration on the mobile node that tells it what
kind of authentication it must use with the home agent. It could
vary from pre-shared secrets, EAP (SIM, AKA, etc..) or
certificates.
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.
If the mobile node needs to be reachable at its newly bootstrapped
home address, then the DNS entry must be updated. If the home agent
does not support updating DNS entries, it indicates this in the
binding acknowledgment. So, the mobile node would know if its DNS
entry was updated.
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?
Added some more text.
If the Home Agent of choice does not
respond to the IKE_SA_INIT messages or if IKEv2 authentication fails,
the Mobile Node SHOULD try the next Home Agent on the list. If none
of the Home Agents respond, the Mobile Node SHOULD try again after a
period of time that is configurable on the Mobile Node. If IKEv2
authentication fails with all Home Agents, it is an unrecoverable
error on the Mobile Node.
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?
It would be decided by configuration on the mobile node. Added some
text.
Choice of an IKEv2 peer
authentication method depends on the deployment. The Mobile Node
should be configured with the information on which IKEv2
authentication method to use.
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.
Changed it to 'MUST'.
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.
draft-ietf-mip6-aaa-ha-goals-03 describes the goals for the interface
between the Home Agent and the AAA server. RADIUS extensions for this
interface are defined in
http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-02.txt.
Diameter extensions for this interface is defined in
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-03.txt
I added references to the above two drafts.
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.
Both MUST be implemented by the home agent. One of them can be used
in a deployment. Modified the text as follows.
Home agents
MUST implement at least the following two modes of authorization:
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'?
Ok.
Since use of dynamic DNS is optional, is this a
'MUST implement' security requirement?
If is a "MUST implement" requirement if DNS update is supported by
the home agent.
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).
[16] defines what is required for an interface between the HA
and the AAA server. The RADIUS and Diameter extensions documents
talk about how to support 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.
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.
If the DNS update for the home address fails, the mobile node
would know about it. Isn't this sufficient?
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/
Done.
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/
It is supposed to be "does". We had deleted some text that
described how one could also resolve a Home Agent in the
visited network by appending some "locaation information"
to the FQDN. We had removed that text. But we do want to
say it is possible to assign a local home agent.
Re-wrote the paragraph
Note that the configuration of a home agent FQDN on the mobile node
can also be extended to dynamically assign a local home agent from
the visited network. 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 of local home agents are outside
the scope of this specification.
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/
Done.
Vijay
