Eric, Thanks for your review. Inline:
> 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? > Good question. My assumption has been that the mobile node operates based on the information it has. For instance, if it wants to use the split scenario it needs to configure at least home network domain name and EAP credentials for IKEv2. The way that the current document is written (see Section 4.3) is that the integrated approach is the default, and the split approach is the fallback. > 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. > The correct reference is RFC 4301. I have added text to this effect to the RFC Editor notes. > 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). > See Kuntal's suggested change -- that change is also in the RFC Editor notes. > ________________________________________________________________________ > ___ > > 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). > Added to RFC Editor notes. Jari _______________________________________________ Gen-art mailing list [email protected] http://www.ietf.org/mailman/listinfo/gen-art
