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

<Basavaraj.Patil@nokia.com> Fri, 03 February 2012 22:41 UTC

Return-Path: <Basavaraj.Patil@nokia.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 BB8BE21F85E6 for <mext@ietfa.amsl.com>; Fri, 3 Feb 2012 14:41:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.652
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pnsy-600r6Gd for <mext@ietfa.amsl.com>; Fri, 3 Feb 2012 14:41:21 -0800 (PST)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id EA5F721F85AF for <mext@ietf.org>; Fri, 3 Feb 2012 14:41:11 -0800 (PST)
Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q13Mf8JB010451; Sat, 4 Feb 2012 00:41:09 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 4 Feb 2012 00:41:08 +0200
Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Fri, 3 Feb 2012 23:41:08 +0100
From: <Basavaraj.Patil@nokia.com>
To: <jari.arkko@piuha.net>, <draft-ietf-mext-mip6-tls@tools.ietf.org>, <mext@ietf.org>
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: <CB51B97A.18D0F%basavaraj.patil@nokia.com>
In-Reply-To: <4EFD6DC6.3070904@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [172.19.59.134]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <715FFC53E21F18488BF335B0D19FEA2F@mgd.nokia.com>
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-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: 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" <jari.arkko@piuha.net>; 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
>others.

Sure. 

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

Okay.

>
>> 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].

Okay.

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

True. Will revise this text.

>
>Please clarify.
>
>>     form of a Network Access Identifier (NAI) [RFC4282
>><http://tools.ietf.org/html/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
>>HA
>>     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"
>>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?

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
>><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.
>
>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
>problems).
>- 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
>registry?

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

-Basavaraj

>
>Jari
>
>_______________________________________________
>MEXT mailing list
>MEXT@ietf.org
>https://www.ietf.org/mailman/listinfo/mext