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

Jari Arkko <> Wed, 15 February 2012 13:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C9DF21F85D2 for <>; Wed, 15 Feb 2012 05:30:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.557
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PSNzv9dQtV6R for <>; Wed, 15 Feb 2012 05:30:42 -0800 (PST)
Received: from ( [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id 7DA3C21F851E for <>; Wed, 15 Feb 2012 05:30:20 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDD242D35A; Wed, 15 Feb 2012 15:30:19 +0200 (EET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A3yrSSVSOc4w; Wed, 15 Feb 2012 15:30:15 +0200 (EET)
Received: from [] ( [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id 532002CC3C; Wed, 15 Feb 2012 15:30:15 +0200 (EET)
Message-ID: <>
Date: Wed, 15 Feb 2012 15:30:15 +0200
From: Jari Arkko <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: jouni korhonen <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc:, "" <>
Subject: Re: [MEXT] draft-ietf-mext-mip6-tls AD review
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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<>.1>. ofRFC 6275<>) 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<>)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