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
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

Reply via email to