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? 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? 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? ________________________________________________________________________ ___ 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. ________________________________________________________________________ ___ 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). ________________________________________________________________________ ___ 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).