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

[Gonzalo Camarillo <[e-mail]>]

Hi Miika,

what is the status of this?

Thanks,

Gonzalo

On 07/03/2016 2:35 PM, Gonzalo Camarillo wrote:
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hipsec
>>
> 
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec
>