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

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

Jari

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