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

<> Fri, 03 February 2012 22:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB8BE21F85E6 for <>; Fri, 3 Feb 2012 14:41:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.652
X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pnsy-600r6Gd for <>; Fri, 3 Feb 2012 14:41:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EA5F721F85AF for <>; Fri, 3 Feb 2012 14:41:11 -0800 (PST)
Received: from ( []) by (Switch-3.4.4/Switch-3.4.4) with ESMTP id q13Mf8JB010451; Sat, 4 Feb 2012 00:41:09 +0200
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 4 Feb 2012 00:41:08 +0200
Received: from ([]) by ([]) with mapi id 14.01.0355.003; Fri, 3 Feb 2012 23:41:08 +0100
From: <>
To: <>, <>, <>
Thread-Topic: [MEXT] draft-ietf-mext-mip6-tls AD review
Thread-Index: AQHMxsgJhcpil0FY0UWn6iJGyo2ht5Yrhu+A
Date: Fri, 3 Feb 2012 22:41:07 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Feb 2012 22:41:08.0847 (UTC) FILETIME=[EC0A57F0:01CCE2C4]
X-Nokia-AV: Clean
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: Fri, 03 Feb 2012 22:41:22 -0000

Hi Jari,

Thanks for the review. Please see my responses inline:

On 12/30/11 1:52 AM, "ext Jari Arkko" <> wrote:

>I have reviewed this specification. I think it is in good shape and
>almost ready to move forward. I have some comments below, please address
>them in a new revision of the draft. My main comments relate to sequence
>numbers, Section 7, and IANA considerations.
>> The HAC can be co-located with the HA, or can be an
>> independent entity.  For the latter case, communication between HAC
>> and HA is not defined by this document.  The Diameter protocol can be
>> used between the HA and HAC when the two entities are not collocated.
>I'd change the last sentence to: "Such communication could be built on
>top of AAA protocols such as Diameter, for instance."
>(You can't just use Diameter, you'd have to define a specific way of
>doing it.)

Okay. In the context of this I-D, I believe it is sufficient to provide an
example of the protocol(s) between the  HAC and HA.

>> The security framework proposed in this document is not intended to
>> replace the currently specified architecture which relies on IPsec
>> and IKEv2.  It provides an alternative solution which is more optimal
>> for certain deployment scenarios.
>Add to the end:
>This and other alternative security models have been considered by the
>MEXT working group at the IETF, and it has been decided that the
>alternative solutions should be published as Experimental RFCs, so that
>more implementation and deployment experience with these models can be
>gathered. The working group may reconsider the status of the different
>models in the future, if it becomes clear that one is superior to the


>>    Mobile IPv6 implementation complexity increases quite dramatically.
>I would just say "... complexity increases."


>> At an abstract level it can
>> be said that implementing Mobile IPv6 with IPsec and IKEv2 is
>> possible only with modifications to the IPsec and IKEv2 components.
>> The original design intent was to reuse IPsec without having to
>> modify them.  The current security model requires an IPsec/IKEv2
>> implementation that is specific to Mobile IPv6.
>I don't think this is quite right. I'd reword to:
>Implementing Mobile IPv6 with IPsec and IKEv2 requires modifications to
>both the IPsec and IKEv2 components, due to the communication models that
>Mobile IPv6 uses and the changing IP addresses. For further details, see
>Section 7.1 in [RFC3776].


>Section 3 felt a little bit duplicated text from Section 1. Might be an
>idea to look at merging the two. Don't spend too much effort on that
>however, I can live with the current two sections as well.

Will revisit the section and see how best to improve it.

>>     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
>>        SA includes two independent sequence numbers (MN ->  HA, HA ->
>>        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?

True. Will revise this text.

>Please clarify.
>>     form of a Network Access Identifier (NAI) [RFC4282
>>        mn-id = "mn-id" ":" nai CRLF
>>        nai = username
>>            | "@" realm
>>            | username "@" realm
>>        ...
>I'd prefer you to just say after the first line that "nai" is as defined
>in RFC4282, not repeat the definition here. Or if you do repeat it,
>please indicate that it is copied here for convenience. Otherwise people
>have to go back to RFC 4282 and check that the definition is the same. (I
>did that, for instance.)
>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 will just reference RFC4282 which would be optimal.

>>       mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date
>>       CRLF
>>     The HAC SHOULD provision the MN with an UDP port number, where the
>>     expects to receive UDP packets.  If this parameter is not present,
>This comes suddenly for the reader, who at this point has not been
>introduced to the change that you run everything on top of UDP. Please
>explain this better earlier in the document.

Okay. Will do.

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

Good questionĊ  Need to rethink why this was designed as such. Will come
back with an answer.

>>    All
>>     packets that are specific to the Mobile IPv6 protocol and contain a
>>     Mobility Header (as defined inSection 6.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 
>This seems like an inconsistency. HOTI messages are MH messages. Which
>format do you require for them? Please ciarify.
>Section 7 seems odd. First, you say that you don't cover the RO part and
>then you go on explaining nice ideas that could be done. I would replace
>Section 7 with the following information:
>- statement that this specification does not change any of the procedures
>for RO
>- explanation that tells the reader how the TLS-based HA security model
>can still support the existing RO procedures (and if it can not... I
>think you'd have to change your spec... but I don't see why it would have
>- identification of possible gaps for future work, such as supporting RO
>to IPv4 destinations (but we don't support that today, so this isn't the
>fault of your document). But do not include extra new ideas that could be
>done (like HAC-based RO).

Agreed. Will make this change.

>IANA considerations seems to need some material for the attributes used
>in your new protocol. Who can allocate them, and should there be a

Will beef up this section further and propose a registry if needed (not
sure if that is the case yet).


>MEXT mailing list