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

From: <[email-masked]>
Date: Fri, 3 Feb 2012 22:41:07 +0000

Hi Jari,

Thanks for the review. Please see my responses inline:

On 12/30/11 1:52 AM, "ext Jari Arkko" <[email-masked]> 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mext

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Feb 2012 09:40:33 +0200

Basavaraj,

Thanks for your responses. I think we are in sync, and awaiting for a new revision. But I'd love to progress this I-D while I'm still in the IESG. For that, we need a new version soon.

Jari

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 17:04:41 +0000

Hi Jari,

Appreciate that feedback. We will get a revised I-D to you by mid next
week (Feb 15th~16th).

-Basavaraj

On 2/10/12 1:40 AM, "ext Jari Arkko" <[email-masked]> wrote:

>Basavaraj,
>
>Thanks for your responses. I think we are in sync, and awaiting for a new
>revision. But I'd love to progress this I-D while I'm still in the IESG.
>For that, we need a new version soon.
>
>Jari
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Feb 2012 20:15:14 +0200

Thanks.

Jari

On 10.02.2012 19:04, [email-masked] wrote:
> On 2/10/12 1:40 AM, "ext Jari Arkko"<[email-masked]>  wrote:
>
>> Basavaraj,
>>

---

From: jouni korhonen <[email-masked]>
Date: Tue, 14 Feb 2012 08:12:49 +0200

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]

>>       direction.  Sequence numbers are maintained per direction, so each
>>       SA includes two independent sequence numbers (MN ->  HA, HA ->  MN).
> 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]

>>    endpoint in the security association maintains two "current" Sequence
>>    next one it expects to see in a packet from the other end.  If the MN
> 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.

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Feb 2012 15:30:15 +0200

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

Jari

On 14.02.2012 08:12, jouni korhonen wrote:
>>>     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
>>>     Section 6.4<http://tools.ietf.org/html/draft-ietf-mext-mip6-tls-02#section-6.4>).