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

[Padma Pillay-Esnault <[e-mail]>]

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
>>>>
>>>