Subject: [Gen-art] Re: Gen-ART review of draft-ietf-mip6-bootstrapping-split-05.txt

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 07 Jul 2007 23:41:25 -0700

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

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Jul 2007 09:34:00 +0200

Thanks, that all seems to be fine.

     Brian

On 2007-07-08 08:41, Vijay Devarapalli wrote:
>> The draft is generally very clear if one accepts the underlying model 
>> of a split between the Mobility Service Authorizer (MSA)
>> 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'
>> 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.
> 
>> implementations can be made while these issues are undefined. If these 
>> issues are left open, there is a high risk of MSA/MSP interop

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2007 09:46:22 +0200

I'm happy with the -06 version. Thanks!

    Brian

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Jul 2007 14:40:35 -0400

I cleared.

At 03:46 AM 7/12/2007, Brian E Carpenter wrote:
>>>encourage the formation of walled gardens, which is the last thing 
>>>the Internet needs in mobile service. Also the term 'anycast'