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

[<[e-mail]>]

Hi Jari,

Thanks for the review. Please see my responses inline:

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