[Gen-art] Gen-ART LC/Telechat review of draft-ietf-mext-mip6-tls-03

Ben Campbell <ben@nostrum.com> Tue, 28 February 2012 23:34 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C78F21F8472; Tue, 28 Feb 2012 15:34:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.255
X-Spam-Level:
X-Spam-Status: No, score=-102.255 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNiCanWg9zKy; Tue, 28 Feb 2012 15:34:24 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BF98121F8470; Tue, 28 Feb 2012 15:34:23 -0800 (PST)
Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q1SNYMB3099708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Feb 2012 17:34:22 -0600 (CST) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Feb 2012 17:34:27 -0600
Message-Id: <03557735-170E-422A-B507-45A07DEC22AE@nostrum.com>
To: draft-ietf-mext-mip6-tls.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, The IETF <ietf@ietf.org>
Subject: [Gen-art] Gen-ART LC/Telechat review of draft-ietf-mext-mip6-tls-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Feb 2012 23:34:24 -0000

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

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"