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

[Brian Haberman <[e-mail]>]

Tom,
    The below is all fine with me.  I will clear when the updated draft
is posted.

Regards,
Brian

On 7/22/14 6:01 PM, Tom Henderson wrote:
> 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