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 <[email protected]> wrote: > Sure, but please add the TSVWG reference for NAT. > > > > On Thu, Jan 4, 2024 at 11:10 AM Padma Pillay-Esnault <[email protected]> > 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 <[email protected]> >> wrote: >> >>> SG, please mention these points in the text. >>> >>> On Thu, Jan 4, 2024 at 8:38 AM Padma Pillay-Esnault < >>> [email protected]> wrote: >>> >>>> Hi Martin >>>> >>>> Please see PPE for my comments inline >>>> >>>> On Tue, Jan 2, 2024 at 11:50 AM Martin Duke via Datatracker < >>>> [email protected]> 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 >>>> >>>
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
