Re: [Hipsec] your DISCUSS comments on draft-ietf-hip-rfc5201-bis

[Tom Henderson <[e-mail]>]

On 07/22/2014 02:08 PM, Brian Haberman wrote:
> Hi Tom,
>
> On 7/22/14 2:51 PM, Tom Henderson wrote:
>> Brian,
>>
>> You left the following DISCUSS comments on draft-ietf-hip-rfc5201-bis
>> which I would like to address below:
>>
>>> I have no objection to the publication of this document, but I do
>>> have two small points to discuss in section 5.2.3.
>>>
>>> 1. The R1_COUNTER parameter was labeled as optional in RFC 5201, but
>>> made mandatory in this revision.  However, the text says it SHOULD be
>>> included in R1.  If it is not included in R1 (violates the SHOULD),
>>> where will it be included given it is mandatory?
>>
>> Support for it is mandatory (if the Responder sends it, the Initiator
>> must echo it back), but the inclusion by the responder is optional.
>>
>> To try to clarify this, I edited it (for version -15) to read:
>>
>>             Support for the R1_COUNTER parameter is mandatory although
>>             its inclusion in the R1 packet is optional.  It SHOULD be
>>             included in the R1 ...
>>
>
> The above is fine.  If this parameter is sent by the Responder, what
> packets could it be sent in (i.e., violate the SHOULD) and still be useful?
>
> The above question is just something for you to think about.  I will not
> hold a discuss on it.

R1_COUNTER can be sent in the R1 and I2 packets (Sections 5.3.2 and 
5.3.3) but is not found in any of the other packets.

>
>>>
>>> 2. The Type value of R1_COUNTER was 128 in 5201 and is now 129.  Is
>>> that correct?
>>
>> Yes, by making its support mandatory, it is now deemed a "critical"
>> parameter and the LSB of the type value must be 1.  This necessitated
>> the change from 128 to 129.
>>
>
> Is there a need to discuss any backwards compatibility issues with this
> change?
>

I don't know whether any need exists.  If a legacy implementation 
provides 128, it also likely provides HIP version 1, in which case an 
ICMP packet with Parameter Problem should be generated (section 5.4.2). 
  If HIP version 2 is indicated but this parameter is encoded with 128, 
it will probably be covered by an implementation with the INVALID_SYNTAX 
notification (Section 5.2.19).

- Tom