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

Jouni Korhonen <jouni.korhonen@nsn.com> Wed, 29 February 2012 07:14 UTC

Return-Path: <jouni.korhonen@nsn.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 C890B21F85B4; Tue, 28 Feb 2012 23:14:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level:
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 ISdmzJ3cyVvP; Tue, 28 Feb 2012 23:14:22 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8E84321F855A; Tue, 28 Feb 2012 23:14:21 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1T7EJa8012121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Feb 2012 08:14:19 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1T7EDwg022419; Wed, 29 Feb 2012 08:14:19 +0100
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 08:14:18 +0100
Received: from 10.144.254.14 ([10.144.254.14]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server demuexc023.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Feb 2012 07:14:18 +0000
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 29 Feb 2012 09:14:16 +0200
From: Jouni Korhonen <jouni.korhonen@nsn.com>
To: ext Ben Campbell <ben@nostrum.com>, <draft-ietf-mext-mip6-tls.all@tools.ietf.org>
Message-ID: <CB739CE8.143E2%jouni.korhonen@nsn.com>
Thread-Topic: Gen-ART LC/Telechat review of draft-ietf-mext-mip6-tls-03
Thread-Index: Acz2sb7wE1W7YQs4502UdTOzhMgCUQ==
In-Reply-To: <03557735-170E-422A-B507-45A07DEC22AE@nostrum.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 29 Feb 2012 07:14:18.0706 (UTC) FILETIME=[C08DBB20:01CCF6B1]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 5263
X-purgate-ID: 151667::1330499660-000015E0-4D29BBA1/0-0/0-0
X-Mailman-Approved-At: Wed, 29 Feb 2012 04:48:45 -0800
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, The IETF <ietf@ietf.org>
Subject: Re: [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: Wed, 29 Feb 2012 07:14:22 -0000

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" <ben@nostrum.com> wrote:

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