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" <[email protected] on behalf of [email protected]> 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 >[email protected] >https://www.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
