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

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 7 Mar 2016 14:35:07 +0200

Hi,

I have just talked with Miika and he has volunteered to take the pen and
add the necessary clarifications to the draft so that it is more
readable. Thanks, Miika!

First he will look into adding clarifications to the existing draft
while still referencing the old RFC. If the group is not happy with the
readability after the editorial pass (or our AD does not finally let us
downref the old RFC), we can consider bringing material from the old RFC
directly into the new one.

I would also like the group to comment on the following two proposals:

1) the draft will allow implementers to use HIP native relays only. In
addition, the use of STUN and TURN relays will be optional.

2) in addition to covering the base exchange, the draft will also cover
the mobility readdressing exchange.

Thanks,

Gonzalo

On 29/02/2016 4:41 PM, Miika Komu wrote:
> Hi,
> 
> On 02/27/2016 10:49 AM, Gonzalo Camarillo wrote:
>> Hi Jeff,
>>
>> thanks for your feedback.
>>
>>> Regarding pros/cons:
>>> How widely-deployed is STUN/TURN? Are public servers widespread?
>>
>> there are several of them. They are mostly used for VoIP. You can google
>> for "public stun turn servers" or something similar. There are a few
>> lists out there.
> 
> I guess the situation is like this:
> 
> HIP control plane relay:
> * new critical infrastructure that needs to be deployed anyway (TURN
> server cannot be used for this)
> 
> Gathering of address candidates:
> * from a STUN server (many available)
> * ...or from control plane relay registration (which is mandatory anyway)
> 
> Data plane relay:
> * using TURN server (it seems some are available)
> * ...or using the ESP relay as specified in native NAT spec (none
> deployed, but I guess could co-locate with the HIP control plane relay)
> 
> So, the critical part are the HIP control plane relays which provide
> also similar functionality as STUN servers (i.e. provide server
> reflexive candidates). So I guess the question boils down to the
> availability of TURN servers.
> 
> P.S. Nothing really prevents to use STUN servers to discover address
> candidates in the native NAT traversal version. The discovery process is
> independent of the NAT penetration process.
> 
> 
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 29 Mar 2016 00:51:06 +0100

> directly into the new one.

Sorry,  that I'm quite late in looking at these,  but have been doing
so recently...

I have to say that I find the it difficult to decode simply because
of having to refer to 3 (the draft, 5770, 5245) plus possibly the
STUN/TURN docs at once.

I'd certainly find it easier to comprehend if the text from 5770 was
incorporated (suitably modified to account for not doing STUN/TURN)
within the draft.  That way the references to the significant pieces
of 5245 text would be easier to nail down.

As it is,  I currently find it a bit like reading an Act of Parliament!

e.g. $3.8 Connectivity Checks
   refers to $4.6 of 5770 with some exceptions, $4.6 of 5770 refers to
$5.7 of 5245 and $7 of 5245,  where the exceptions (use of UPDATE instead
of STUN) have to be applied to that $7 referencing 5389,  so possibly
I don't have to read 5389, since hopefully it would just be packet formats.

> addition, the use of STUN and TURN relays will be optional.

I'd suggest the draft be native only,  but say with an appendix referencing
5770 for use of STUN/TURN,  maybe indicating which bits of the 5770
to take heed of.

> the mobility readdressing exchange.

Not having read that recently,  I can't really comment.

DF

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 31 Mar 2016 17:46:21 +0300

Hi Miika,

what is the status of this?

Thanks,

Gonzalo