Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

[Miika Komu <[e-mail]>]

Hi,

On 06/30/2016 08:44 AM, Tom Henderson wrote:
> Hi Miika,
>
>>
>> trying to recap your complete opinion... do you think the
>> UDP-ENCAPSULATION should be MUST and ICE-HIP-UDP SHOULD? And
>> RFC5770 MAY? Or do you think the draft should just deprecate
>> RFC5770?
>
> I think that UDP-ENCAPSULATION should be a MUST option because that
> option is sufficient if the implementation does not have to deal with
> inbound connections.

Ok. Btw, you mean "Responder" by inbound? I think you're referring to 
this section:

https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-12#section-4.7.2

> ICE-HIP-UDP should be a MUST for implementations that wish to support
> inbound, and I don't think that RFC5770 solutions for inbound should
> be suggested as options.

Added the following to the NAT Traversal Mode Parameter" section:

"Implementations conforming to this specification MUST implement both
UDP-ENCAPSULATION and ICE-HIP-UDP modes."

> Maybe the use of STUN servers for candidate
> gathering is fine as a MAY since it doesn't affect HIP
> interoperability, but otherwise, why suggest to support two parallel
> implementations for the same function?

A host behind a NAT will need a HIP relay anyway which can provide STUN 
functionality. The draft currently says:

    Gathering of candidates MAY also be performed as specified in
    Section 4.2 of [RFC5770] if STUN servers are available, or if the
    host has just a single interface and no TURN or HIP data relay
    servers are available.

Do you want this to be removed or is it ok?

> I would be fine with making an allowance for RFC5770 implementations
> to live on as an option; by this I mean to not overwrite RFC5770
> codepoints, etc. but stop short of suggesting it as a MAY in this
> document.

The draft does not reference RFC5770 as MAY implement. The current draft 
is completely a parallel to the RFC, and is described in a 
self-sufficient way.

>> Btw, RFC5770 is still a normative reference because we are
>> redundantly explaining some parts of the RFC in the draft.
>>
>
> I still believe that it would be better if this draft did not depend
> on reading RFC5770.

It doesn't anymore. RFC5770 is mostly referenced because some parameters 
are borrowed from there, but are always redundantly described in the draft.