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

From: "Eric Gray" <[email-masked]>
Date: Wed, 6 Feb 2008 14:53:15 -0600

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-masked]
http://www.ietf.org/mailman/listinfo/gen-art

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Feb 2008 10:01:48 +0200

Eric,

> 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.

> 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.

> 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.

Added to RFC Editor notes.

Jari