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?
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).
_______________________________________________
Gen-art mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/gen-art
