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

[Jeff Ahrenholz <[e-mail]>]

Hi all,
We’ve been discussing the NAT traversal approaches here at Tempered Networks (Seattle-based company using HIP to build secure overlays between customer networks.) We like the native HIP-based approach proposed in draft-ietf-hip-native-nat-traversal. Mostly due to the simplicity of implementing this — by extending existing HIP messages versus using the ICE/STUN/TURN machinery.

We currently use UDP encapsulation of HIP and IPsec, so to implement the native NAT-traversal draft, it may be a matter of supporting the control/data relaying server. We may implement this some time in the future.

Regarding pros/cons:
How widely-deployed is STUN/TURN? Are public servers widespread?

thanks,
Jeff Ahrenholz
Jeff Costlow
Orlie Brewer



On 2/24/16, 6:26 AM, "Hipsec on behalf of Gonzalo Camarillo" <[e-mail] on behalf of [e-mail]> wrote:

>Hi Tom,
>
>I agree it is better to separate both questions: the right thing to do
>from a technical point of view and how to document it.
>
>Let's focus on doing the right thing, regardless of what each of you
>think the group agreed to do years ago. What are the pros and cons of
>obsoleting the old STUN-based approach?
>
>Thanks,
>
>Gonzalo
>
>On 23/02/2016 4:08 PM, Tom Henderson wrote:
>> 
>> 
>> On 02/16/2016 06:22 AM, Ari Keränen wrote:
>>> Thank you for the review Tom! Please see below.
>>>
>>>> On 12/02/2016 11:54 PM, Tom Henderson wrote:
>>>>> Gonzalo and all,
>>>>>
>>>>> My understanding is that the WG reached consensus several years ago
>>>>> that the standards-track NAT traversal variant would be the native
>>>>> NAT traversal and not the RFC5770-based ICE/STUN/TURN version.
>>>>>
>>>>> I reviewed the above draft and noticed that it still contains
>>>>> normative references to RFC5770 (pointers to material found only in
>>>>> RFC5770) throughout, and contains RFC5770 as a normative reference
>>>>> in Section 8.1.  It seems to me that the WG ought to produce a
>>>>> specification that can stand alone from RFC5770, because as it
>>>>> stands now, it seems to me that someone implementing it would need
>>>>> to consult both drafts and may be uncertain about what is still
>>>>> applicable from RFC5770.  For example, is the UDP-ENCAPSULATION
>>>>> mode still valid?
>>>
>>> Indeed this variant is the standards-track solution, but I think it 
>>> makes sense to not obsolete the RFC5770. For example, in some scenario 
>>> the STUN based solution could be better than native HIP based. And also 
>>> the UDP-ENCAPSULATION mode should be still valid.
>>>
>>>>> ICE (RFC 5245) is also still listed as normative but it seems to me
>>>>> that it should also be informative in this draft.
>>>
>>> The details of e.g., how ICE checklists are used are defined in RFC5245 
>>> so I think it needs to be normative.
>>>
>>>>> I think it would be appropriate to just reference 5770 in the
>>>>> Introduction, stating that this specification replaces RFC 5770
>>>>> with a different mechanism than ICE/STUN/TURN, and then try to
>>>>> avoid referencing 5770 from then on.
>>>
>>> Avoiding RFC 5770 altogether would require lots of editorial work with 
>>> this draft for a questionable amount of benefit, so I think it's better 
>>> if we simply have it as normative reference. The maturity level of 5770 
>>> (experimental) is an issue, but I think it is possible - and makes sense 
>>> - to make an exception here.
>> 
>> Ari, I have thought about this and it seems to me that there are two issues to discuss.
>> 
>> There is a technical issue to resolve, which is whether the WG wants to keep RFC5770 solutions as non-obsolete, and how to express these options to future implementers.  I had thought that the WG position was to drop support for STUN-based solutions, but you are suggesting now to keep it active, perhaps as a MAY implement?   It seems to me that the basic UDP-ENCAPSULATION mode should still be kept mandatory since it is the basis for the other approach and is useful by itself.
>> 
>> Then there is the editorial issue about how to meet IETF guidelines on how things are cross-referenced and use of informative/normative references, which seems to me risky at the moment (i.e., I am anticipating a downstream reviewer expressing this same concern).  Plus there is the goal of making it clearer to implementers.
>> 
>> - Tom
>> 
>
>_______________________________________________
>Hipsec mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/hipsec