Subject: Gen-ART LC/Telechat review of draft-ietf-mext-mip6-tls-03

From: Ben Campbell <[email-masked]>
Date: Tue, 28 Feb 2012 17:34:27 -0600

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-mext-mip6-tls-03
Reviewer: Ben Campbell
Review Date: 2012-02-28
IETF LC End Date: 2012-02-29
IESG Telechat date: 2012-03-01

Note: Since the Telechat review deadline is a day before the end of the IETF last call, this review serves both as a Telechat review and an IETF Last Call review.

Summary: This draft is basically ready for publication as an experimental RFC. There are some clarification issues that might should be addressed prior to publication.

Major issues:

None

Minor issues:

-- general: 

The draft seems to be missing information on how to match TLS certificates to identities for HAC authentication.

-- section 1, paragraph 1, last sentence: "Client implementation experience has shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex."

It might be worth elaborating on why this is true. Could this be solved with a cleaner software architecture rather than a protocol change?

-- section 5.4:  "The actual domain name used in queries is up to the deployment to decide and out of scope of this specification."
 
This seems under specified for SRV

-- 5.7.4:

Are more than one DNS server allowed for each protocol?

-- 5.8:

I find this section confusing,as the first and second paragraphs seem to make contradictory statements about the authentication, particularly about the use of PSK. I think you are talking about authentication of the HAC in the TLS handshake vs an higher level authentication of the MN using PSK or EAP. I think this could use some clarification, as both paragraphs talks about authentication between the MN and HAC without mentioning direction.

Note that this is more clear in the security considerations section, but it would help for it to be more clear here.

-- 5.9, 2nd to last paragraph:

How do the first and last sentences relate? It seems to say set it to "1", except for this case in which you set it to "1".

-- 8.1:

Is this registry only for TLS based MIPv6? If so, does it need to be explicitly constrained to not used for MIPv6 in general?

Nits/editorial comments:

-- section 4.1: 

A picture showing the element and key relationships could be helpful here.

-- section 4.3, third paragraph:

Please expand BA on first mention

--section 4.3, "Security association validity times", : "hours or weeks"

Hours _to_ weeks?

-- section 4.3, "selected cyphersuite": " The selected algorithms SHOULD be one of the mutually supported ciphersuites"

How could it be otherwise? (i.e. why the SHOULD, and is this really normative vs descriptive?)

-- section 4.4: "Home Agent IP Address" : "Concerns both IPv6 and IPv4 home agent addresses."

Dual stack only?  (same applies to "Home Address" section)

-- section 5.1, second paragraph: "All data inside the Content portion of the message container MUST be encoded using octets."

I suspect I'm missing a subtlety here--but how else could you do it? Is this intended to imply a byte-field, or to imply no additional encoding is used?

-- section 5.2: "From now on, we use TypeValue header (TV-header) term to refer request-response message content HTTP-like headers."
 
Maybe that should be moved to the terminology section?

-- section 5.3, 2nd paragraph: "The MN is also the peer that always sends only request messages and the HAC only sends response messages."

I'm having trouble parsing. Is their a spurious "always"?

-- section 5.5 : "same to that used by HTTP"

same _as_?

-- section 5.5.5

s/till/until

-- 5.5.8, 1st sentence:

Sentence fragment. Missing words?

-- 5.9, first paragraph:

Sentence fragment.

-- 5.9, 2nd to last paragraph:

s/"In case the"/"In the case that the"

-- 9:

A general discussion of threats would be helpful. Some aspects are scattered in the subsections, but a summary in one place would be nice.

-- 9.2: 

It's not clear to me if the text in the "Dictionary Attack" section is actually related to dictionary attacks.

-- 6.1:

A picture of the general packet format would be nice. You've got them later for specific packet types, but no "general" picture.

--6.2: 

Section seems mostly redundant to 6.1

-- 6.3:

Please expand HoTI on first use.

-- 7:

Please expand CoTI/CoT on first use

-- 8.3:

I'm not sure I understand the mnemonic relevance of "HALTSEC"

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 29 Feb 2012 09:14:16 +0200

Thanks Ben for a thorough review. Very good comments indeed. We'll come back
to this in a bit.. you know -00 deadline approaching and such ;)

- Jouni

On 2/29/12 1:34 AM, "ext Ben Campbell" <[email-masked]> wrote:

> Note: Since the Telechat review deadline is a day before the end of the IETF
> last call, this review serves both as a Telechat review and an IETF Last Call
> review.
> 
> Summary: This draft is basically ready for publication as an experimental RFC.
> There are some clarification issues that might should be addressed prior to
> publication.
> 
> Major issues:
> 
> None
> 
> 
> Minor issues:
> 
> -- general: 
> 
> -- section 1, paragraph 1, last sentence: "Client implementation experience
> has shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex."
> 
> It might be worth elaborating on why this is true. Could this be solved with a
> cleaner software architecture rather than a protocol change?
> 
> -- section 5.4:  "The actual domain name used in queries is up to the
> deployment to decide and out of scope of this specification."
>  
> I find this section confusing,as the first and second paragraphs seem to make
> contradictory statements about the authentication, particularly about the use
> of PSK. I think you are talking about authentication of the HAC in the TLS
> handshake vs an higher level authentication of the MN using PSK or EAP. I
> think this could use some clarification, as both paragraphs talks about
> authentication between the MN and HAC without mentioning direction.
> 
> How do the first and last sentences relate? It seems to say set it to "1",
> except for this case in which you set it to "1".
> 
> -- 8.1:
> 
> Is this registry only for TLS based MIPv6? If so, does it need to be
> explicitly constrained to not used for MIPv6 in general?
> 
> 
> 
> 
> Nits/editorial comments:
> 
> -- section 4.1: 
> 
> -- section 4.3, "selected cyphersuite": " The selected algorithms SHOULD be
> one of the mutually supported ciphersuites"
> 
> -- section 5.1, second paragraph: "All data inside the Content portion of the
> message container MUST be encoded using octets."
> 
> I suspect I'm missing a subtlety here--but how else could you do it? Is this
> intended to imply a byte-field, or to imply no additional encoding is used?
> 
> -- section 5.2: "From now on, we use TypeValue header (TV-header) term to
> refer request-response message content HTTP-like headers."
>  
> -- section 5.3, 2nd paragraph: "The MN is also the peer that always sends only
> request messages and the HAC only sends response messages."
> 
> A general discussion of threats would be helpful. Some aspects are scattered
> in the subsections, but a summary in one place would be nice.
> 
> -- 9.2: 
> 
> A picture of the general packet format would be nice. You've got them later
> for specific packet types, but no "general" picture.
> 
> --6.2: 
>