Re: [MEXT] draft-ietf-mext-mip6-tls AD review

Jari Arkko <jari.arkko@piuha.net> Wed, 15 February 2012 13:30 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9DF21F85D2 for <mext@ietfa.amsl.com>; Wed, 15 Feb 2012 05:30:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.557
X-Spam-Level:
X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, 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 PSNzv9dQtV6R for <mext@ietfa.amsl.com>; Wed, 15 Feb 2012 05:30:42 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA3C21F851E for <mext@ietf.org>; Wed, 15 Feb 2012 05:30:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CDD242D35A; Wed, 15 Feb 2012 15:30:19 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3yrSSVSOc4w; Wed, 15 Feb 2012 15:30:15 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 532002CC3C; Wed, 15 Feb 2012 15:30:15 +0200 (EET)
Message-ID: <4F3BB367.7050402@piuha.net>
Date: Wed, 15 Feb 2012 15:30:15 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: jouni korhonen <jouni.nospam@gmail.com>
References: <4EFD6DC6.3070904@piuha.net> <310097C0-2F35-4F88-A47D-99BB2037100C@gmail.com>
In-Reply-To: <310097C0-2F35-4F88-A47D-99BB2037100C@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-mext-mip6-tls@tools.ietf.org, "mext@ietf.org" <mext@ietf.org>
Subject: Re: [MEXT] draft-ietf-mext-mip6-tls AD review
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2012 13:30:47 -0000

Thanks for the new version. I have sent it for IETF Last Call.

Jari

On 14.02.2012 08:12, jouni korhonen wrote:
> Hi Jari,
>
> We pretty much agree all comments. Here are answers/comments to those few
> that might require some more clarifications.
>
> On Dec 30, 2011, at 9:52 AM, Jari Arkko wrote:
>
> [snip]
>
>>>     Sequence numbers:
>>>
>>>        A monotonically increasing unsigned sequence number used in all
>>>        protected packets exchanged between the MN and the HA in the same
>>>        direction.  Sequence numbers are maintained per direction, so each
>>>        SA includes two independent sequence numbers (MN ->   HA, HA ->   MN).
>>>        The initial sequence number for each direction MUST always be set
>>>        to 0 (zero).  Sequence numbers cycle to 0 (zero) when increasing
>>>        beyond their maximum defined value.
>>>
>> I don't understand why sequence numbers have to be agreed on between the MN and HAC. Perhaps the use of sequence numbers should be, not the numbers themselves?
> Hmm.. the sequence numbers are between the MN and the HA, not HAC. And they are
> not agreed per se but only set to a known initial value when the SA between the
> MN and the HA gets created. This followed the principle e.g. for ESP sequence
> numbers (RFC4303 Section 2.2).
>
>> Please clarify.
> [snip]
>
>> You should use ABNF, please respecify the syntax in ABNF. If I take your syntax and change "|" to "/" I still get at least one error here:
> We should also state the grammar follows Augmented BNF like HTTP header grammar does.
>
> [snip]
>
>>>     The SPI value is followed by a 32-bit Sequence Number value that is
>>>     used to identify retransmissions of encrypted messages.  Each
>>>     endpoint in the security association maintains two "current" Sequence
>>>     Numbers: the next one to be used for a packet it initiates and the
>>>     next one it expects to see in a packet from the other end.  If the MN
>>>     and the HA ends initiate very different numbers of messages, the
>>>     Sequence Numbers in the two directions can be very different.  In a
>>>     case encryption is not used, the Sequence Number MUST be set to 0
>>>     (zero).
>> It seems odd to use sequence numbers only for encrypted packets. What about integrity protected packets?
> Sequence numbers are used in all packets that are protected i.e. PType=1
> and PType=8. We will clarify that if a NULL cipher with integrity protection
> is used (like NULL_SHA256 ciphersuite), then sequence numbers are still used
> as well.
>
>>>    All
>>>     packets that are specific to the Mobile IPv6 protocol and contain a
>>>     Mobility Header (as defined inSection 6.1.1<http://tools.ietf.org/html/draft-ietf-mext-mip6-tls-02#section-6.1.1>;. ofRFC 6275<http://tools.ietf.org/html/rfc6275>;) SHOULD use
>>>     the packet format shown in Figure 7.  (This means that some Mobile
>>>     IPv6 mobility management messages, such as the HoTI message, as
>>>     treated as data packets and using encapsulation described in
>>>     Section 6.4<http://tools.ietf.org/html/draft-ietf-mext-mip6-tls-02#section-6.4>;).
>> This seems like an inconsistency. HOTI messages are MH messages. Which format do you require for them? Please ciarify.
> Good point, we'll clarify this. The language is a bit sloppy here, though not wrong
> imho. The text should state messages with MH that are terminated at the HA use packet
> format shown in Figure 7. Other messages with MH like HoTI then use formats shown
> in Figure 8 (when protected) or in Figure 9 (when in clear text).
>
> - Jouni