Subject: Re: [Gen-art] Gen-ART review of draft-ietf-mip6-bootstrapping-integrated-dhc-05

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 12 Feb 2008 16:38:53 -0500

Dear Eric,

Thanks for the review comments/questions. I apologize for the long delay
in responding to you. Please see inline my comments/answers.

BR,
Kuntal

> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]]
> Sent: Wednesday, February 06, 2008 2:53 PM
> To: Chowdhury, Kuntal; Alper Yegin
> Cc: [email-masked]; Jari Arkko
> Subject: Gen-ART review of
draft-ietf-mip6-bootstrapping-integrated-dhc-05
> 
> Alper/Kuntal,
> 
> 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:
> ========
> 
>  MIP6-bootstrapping for the Integrated Scenario
> (draft-ietf-mip6-bootstrapping-integrated-dhc-05)
> 
> Reviewer:
> ========
> 
> Eric Gray
> 
> Review Date:
> ===========
> 
> 06 Feb 2008
> 
> IESG Telechat date: 07 Feb 2008
> 
> Summary:
> =======
> 
> This draft is nearly ready to publish as a Proposed Standard RFC.
> 
> My comments and questions are not to be construed as imputing any
> sort of negative evaluation for the excellent work that went into
> this document - from the authors/editors and the many contributors,
> and the end product of all that work.
> 
> I have a few general questions, comments and NIT(s) below...
> 
> Comments/Questions:
> ==================
> 
> One thing that doesn't jump out at me is the answer to this question:
> 
> How does the mobile component know which of the two scenarios - split
> or integrated - applies; i.e., how does the mobile component know to
> use the procedures in this document instead of the procedures in RFC
> 5026?
> 
[KC>] It is upto the MN's preference. The MN can use either of the
procedures. In this document we have described a fallback case when the
MN is unable to obtain the home agent address using DHCPv6. In that
case, the MN will use DNS to obtain the home agent address as described
in RFC 5026.  

> I doubt that "by configuration" would be a valid answer, given the
> very nature of the mobile component.  So I suspect that there is a
> point at which the component needs to determine which scenario will
> apply at any gven time.  If - as I suspect - this is true, where is
> that spelled out?
> 
[KC>] Please see my comment above.

> Also, I assume that the technique given in this document is actually
> an optimization and that the "split" scenario would work even in the
> case where the ASA and the MSA are the same.  Given that it is likely
> that the mobile component will need to be informed of which of the 2
> scenarios apply, is the advantage of this optimization sufficient to
> overcome the complexity of having the alternatives?

[KC>] The procedure defined in this document is NOT an optimization over
split scenario bootstrapping solution. The ASA == MSA, i.e. the
integrated bootstrapping scenario allows the network operator to
_assign_ a particular home agent to the MN using the AAA. This is an
important aspect of the solution which allows the network operator to
control the location where the MN's mobility session will be anchored in
the network. This is the preferred method in most of the SDOs where
Mobile IP is used in large scale, i.e. 3GPP2, WiMAX. BTW, ASA == MSA is
not a split scenario by definition.

________________________________________________________________________
> ___
> 
> There are a few instances of the phrase: "IPsec Security Association",
> or
> "IPsec Security Associations."
> 
> There should be at least one reference to where this is defined.  This
> is
> particularly true since this specific phrase does not appear to have
> been
> clearly defined anywhere I can quickly find.  I have found the
> following:
> 
> 	Security Associations (RFC 4301 - unambiguously defined)
> 	IPsec Security Association (RFCs 4304, 5026 - not exactly
> defined)
> 	Internet Security Associations (RFC 4306 - used but not defined)
> 	IKE Security Associations (RFC 4306 - used but not defined)
> 	ESP Security Associations (RFC 4306 - used but not defined)
> 	AH Security Associations (RFC 4306 - used but not defined)
> 
> I suspect the best reference is RFC 4301, however - based on prior
usage
> - I wonder if it would not have been better to have used Internet
> Security
> Association.  However, the included (normative) reference to
> "BOOT-SPLIT"
> (now published as RFC 5026), uses this same phrase, and provides
> specific
> clarification in section 4 (subsection "IPsec Security Association
> setup").
> 
> While I am certain that - to those writing this draft - this phrase is
> not
> ambiguous, it probably would be better to clarify the usage, at least
> with
> a pointer to security architecture RFC 4301, or to "boot-split" RFC
> 5026.
> 
> Also, if this clarification is provided, it would also be good to
change
> the reference "BOOT-SPLIT" to RFC 5026.
[KC>] Good suggestion. I will change the BOOT-SPLIT reference to
RFC5026. Also, I will add reference to RFC4301 for IPsec Security
Association.

________________________________________________________________________
> ___
> 
> There are significant disconnects between RFC 4640's actual content
and
> the inferred content implied in this document (as well as,
> unfortunately,
> RFC 5026).  Both this document and RFC 5026 refer to two bootstrapping
> scenarios (referred to as "split" and "integrated"), claiming that
these
> scenarios are described in RFC 4640.
> 
> Reading RFC 4640, however, one cannot help but notice some
discrepancies
> in this reference.  For example, RFC 4640 clearly describes more than
> two
> scenarios.  For example, in the text at the bottom of page 12 (RFC
> 4640),
> the following deployment possibilities are mentioned:
> 
> Serving ASP = Home ASP, Serving ASP != Home ASP
> Serving ASP = Home MSP, Serving ASP != Home MSP
> Serving MSP = Home MSP, Serving MSP != Home MSP
> Serving MSP = Home ASP, Serving MSP != Home ASP
> Serving MSP = Serving ASP, Serving MSP != Serving ASP
> Home MSP = Home ASP, Home MSP != Home ASP
> 
> This represents a fairly large number of reasonable combinations, and
-
> for some subset of these, ASA and MSA may be the same OR credentials
> may be shared (for the case where home ASP and MSP are the same, for
> instance).
> 
> This seems like more than two possible bootstrapping scenarios.
> 
> Also, there is no scenario that is specifically identified as a
"split"
> bootstrapping scenario (the word "split" is not used at all in RFC
4640
> or - for that matter - in the terminology RFC 3753).
> 
> Section 8, on the other hand, describes two sets of parameters - one
of
> which applies if a dependency exists between authentication for
network
> access and authentication for mobility services (a security
association
> that is established as a result of authentication for network access
is
> re-used for authentication for mobility services) and another that
only
> applies if no such dependency exists.
> 
> But this is a description of parameter sets - not deployment
scenarios.
> 
> In the Introduction section of this document, it specifically states:
> 
> "[RFC 4640] ... defines two bootstrapping scenarios based on the
>  relationship between the entity that authenticates and authorizes
>  the mobile node for network access (i.e., the Access Service
>  Authorizer) and the entity that authenticates and authorizes the
>  mobile node for mobility service (i.e., the Mobility Service
>  Authorizer)."
> 
> In my opinion, the authors should provide a less oblique connection in
> relating the scenarios discussed in this document and RFC 5026 to what
> was described as a problem statement in RFC 4640.  Alternatively, yet
> another RFC could be (and maybe is being) written to describe how this
> document and RFC 5026 align with RFC 4640 (if that is already the
case,
> it is not clear that it is - perhaps there should be a reference).

[KC>] I understand your concern. The tie-in between the network access
authentication and the mobility service authentication as described in
RFC4640 is not part of the solutions document. The idea in RFC4640 was
to bootstrap keys to be used to establish IPsec/IKEv2/RFC4285 SA between
the MN and the home agent (for MIP6) via network access authentication
process. 

The IKEv2 SA can be established using EAP or PSK. If PSK method is
chosen, the shared secret to be used could be a derivative of the
network access auth process (e.g. using EAP keying framework if EAP is
used for network access auth). However, the integrated and the split
scenario solutions documents are not particularly concerned with this
aspect of the problem statement. This aspect should be addressed in the
AAA components of the solution suite:

http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-07.t
xt
http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-03.txt

It is unfortunate that the term "split" was never used or clarified in
RFC4640. However, from this document's perspective, the term
"integrated" is described in that document. So, we have terminology
alignment with the PS at least from the integrated scenario solution
perspective. 

In order to address your concern, I suggest replacing "two" with "the"
in the following paragraph in section 1:

From:

[RFC4640] describes the problem statement for Mobile IPv6 bootstrapping.
It also defines two bootstrapping scenarios based on the relationship
between the entity that authenticates and authorizes the mobile node for
network access (i.e., the Access Service Authorizer) and the entity that
authenticates and authorizes the mobile node for mobility service (i.e.,
the Mobility Service Authorizer).

To:

[RFC4640] describes the problem statement for Mobile IPv6 bootstrapping.
It 
             vvv
also defines the bootstrapping scenarios based on the relationship
between the entity that authenticates and authorizes the mobile node for
network access (i.e., the Access Service Authorizer) and the entity that
authenticates and authorizes the mobile node for mobility service (i.e.,
the Mobility Service Authorizer).

________________________________________________________________________
> ___
> 
> NIT:
> The caption of figure 1 should be "blocked" with the figure itself (it
> is
> on page 7 while the figure is on page 6).

[KC>] This should be addressed in our latest editorial cleanup.

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