Re: [lisp] Martin Duke's Block on charter-ietf-lisp-04-06: (with BLOCK and COMMENT)

[Martin Duke <[e-mail]>]

Looks good to me.

On Thu, Jan 4, 2024 at 11:35 AM Padma Pillay-Esnault <[e-mail]>
wrote:

> Sure. New proposed changes.
>
> Original:
> NAT-Traversal: Support for a NAT-traversal solution in deployments where
> LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node).
>
> Proposed:
> NAT-Traversal: *LISP protocol extensions to* support a NAT-traversal
> solution in deployments where LISP tunnel endpoints are separated from by a
> NAT (e.g., LISP mobile node). The LISP WG will collaborate with the TSVWG
> working on NAT-Transversal.
>
> On Thu, Jan 4, 2024 at 11:12 AM Martin Duke <[e-mail]>
> wrote:
>
>> Sure, but please add the TSVWG reference for NAT.
>>
>>
>>
>> On Thu, Jan 4, 2024 at 11:10 AM Padma Pillay-Esnault <
>> [e-mail]> wrote:
>>
>>> Would these changes address your feedback?
>>>
>>> Clarified the text as we are not building a new NAT solution but rather
>>> adding LISP extensions needed to make it work.
>>>
>>> Original:
>>> NAT-Traversal: Support for a NAT-traversal solution in deployments where
>>> LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node).
>>>
>>> Proposed:
>>> NAT-Traversal: *LISP protocol extensions to* support a NAT-traversal
>>> solution in deployments where LISP tunnel endpoints are separated from by a
>>> NAT (e.g., LISP mobile node)
>>>
>>> and
>>>
>>> Original:
>>> Map Server Reliable Transport: LISP control plane messages are
>>> transported over UDP, however, in some cases, the use of a reliable
>>> transport protocol is a better fit, since it actually helps reduce periodic
>>> signaling.
>>>
>>> Proposed:
>>> Map Server Reliable Transport: LISP control plane messages are
>>> transported over UDP, however, in some cases, the use of a reliable
>>> transport protocol *(such as TCP)*  is a better fit, since it actually
>>> helps reduce periodic signaling.
>>> Thanks
>>> Padma
>>>
>>> On Thu, Jan 4, 2024 at 9:00 AM Martin Duke <[e-mail]>
>>> wrote:
>>>
>>>> SG, please mention these points in the text.
>>>>
>>>> On Thu, Jan 4, 2024 at 8:38 AM Padma Pillay-Esnault <
>>>> [e-mail]> wrote:
>>>>
>>>>> Hi Martin
>>>>>
>>>>> Please see PPE for my comments inline
>>>>>
>>>>> On Tue, Jan 2, 2024 at 11:50 AM Martin Duke via Datatracker <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> Martin Duke has entered the following ballot position for
>>>>>> charter-ietf-lisp-04-06: Block
>>>>>>
>>>>>> When responding, please keep the subject line intact and reply to all
>>>>>> email addresses included in the To and CC lines. (Feel free to cut
>>>>>> this
>>>>>> introductory paragraph, however.)
>>>>>>
>>>>>>
>>>>>>
>>>>>> The document, along with other ballot positions, can be found here:
>>>>>> https://datatracker.ietf.org/doc/charter-ietf-lisp/
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> BLOCK:
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>> Is the NAT traversal work going to prioritize existing solutions
>>>>>> (e.g. STUN,
>>>>>> TURN, ICE), or have all those already been determined to be
>>>>>> inadequate? If the
>>>>>> latter, LISP should coordinate with TSVWG on its NAT traversal
>>>>>> solution.
>>>>>>
>>>>>> PPE - The symmetric or endpoint-address-and-port-dependent mapping
>>>>>> NATs (ICE, TURN..) have been  have been determined to be inadequate
>>>>>> due to the nature of LISP that is typically unidirectional traffic and its
>>>>>> usage of UDP port 4341 without specification of source port.
>>>>>>
>>>>> Yes - on coordination with TSVWG.
>>>>>>
>>>>>
>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> COMMENT:
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>> Is the reliable transport protocol required to be secure? (e.g., are
>>>>>> you
>>>>>> looking at TCP/TLS, QUIC, and SCTP/DTLS, or just bare TCP/SCTP)
>>>>>>
>>>>>> PPE - The current reliable transport draft has a proposal for the use
>>>>>> of bare TCP and fallback to UDP using the existing mechanisms for security
>>>>>> in LISP. The document is being evaluated and reviewed.
>>>>>>
>>>>>>
>>>>> Thanks
>>>>> Padma
>>>>>
>>>>