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 PROTECTED] > Sent: Wednesday, February 06, 2008 2:53 PM > To: Chowdhury, Kuntal; Alper Yegin > Cc: [email protected]; 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 protected] http://www.ietf.org/mailman/listinfo/gen-art
