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

jouni korhonen <jouni.nospam@gmail.com> Tue, 14 February 2012 06:12 UTC

Return-Path: <jouni.nospam@gmail.com>
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 6098121F8748 for <mext@ietfa.amsl.com>; Mon, 13 Feb 2012 22:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.869
X-Spam-Level:
X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599]
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 Wl6GM7kadRAB for <mext@ietfa.amsl.com>; Mon, 13 Feb 2012 22:12:56 -0800 (PST)
Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C653621F873C for <mext@ietf.org>; Mon, 13 Feb 2012 22:12:55 -0800 (PST)
Received: by lbbgk8 with SMTP id gk8so3378272lbb.31 for <mext@ietf.org>; Mon, 13 Feb 2012 22:12:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ljmtlhMYbXJATUOVz5xKOgz1a5X7KlmqJkCyjk9LFBM=; b=wUPxzKNevzYCOggGSz9ZBHmvyY2sDDM0v+DAyI2bmwambyu37aLqs+xOospvsq0DXH MEw1bfxDEM55czRqfq8ZQmxaATu5sfYLbHTfJ9QFD83dO6ewIxR+D/ht7SaaWf4hwHpM wL+HK9ruaYtI4vCoxK9bf0v9t2eQ3kJziYUzM=
Received: by 10.152.147.38 with SMTP id th6mr13016235lab.47.1329199974498; Mon, 13 Feb 2012 22:12:54 -0800 (PST)
Received: from a83-245-213-3.elisa-laajakaista.fi (a83-245-213-3.elisa-laajakaista.fi. [83.245.213.3]) by mx.google.com with ESMTPS id l11sm15279500lbu.13.2012.02.13.22.12.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 22:12:52 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <4EFD6DC6.3070904@piuha.net>
Date: Tue, 14 Feb 2012 08:12:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <310097C0-2F35-4F88-A47D-99BB2037100C@gmail.com>
References: <4EFD6DC6.3070904@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.1084)
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: Tue, 14 Feb 2012 06:12:57 -0000

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