Subject: [lisp] LISP NAT Traversal

From: "Amjad Inamdar (amjads)" <[email-masked]>
Date: Tue, 3 Nov 2015 07:03:29 +0000

Hi,

It will be useful if LISP NAT traversal draft (draft-ermagan-lisp-nat-traversal) can elaborate on the following

1) Why LISP NAT traversal cannot be accomplished without RTR (another network entity) which has implications on deployability, complexity and latency. There are other protocols (e.g IKE/IPsec) that achieve NAT-D and NAT-T without the need for additional network entity.

2) Some more details on RTR deployment
- location of RTR in the LISP deployment like there are recommendations on PITR/PETR deployments
- is RTR shared across LISP sites behind NAT or each site needs a dedicated RTR
- what if RTR is behind another NAT (SP-NAT)

3) How is multiple-NAT handled (e.g. enterprise and SP NAT)

Thanks,
-Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK
Senior Technical Leader
CSG PI Services Security - India

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 3 Nov 2015 05:59:48 -0800

> It will be useful if LISP NAT traversal draft (draft-ermagan-lisp-nat-traversal) can elaborate on the following

See comments inline. Thanks for having a look at the draft.

> 1) Why LISP NAT traversal cannot be accomplished without RTR (another network entity) which has implications on deployability, complexity and latency. There are other protocols (e.g IKE/IPsec) that…

There are 2 important scalability reasons:

(1) You want to keep the number of cache entries in the NAT to a minimum. By using an RTR to encapsulate packets to, there is only a single NAT entry.

(2) When the xTR moves, you want its new locator to be advertised to the fewest number of places in the network. So if the RTR is the only one encapsulating to the xTR then it only has to be updated.

> - location of RTR in the LISP deployment like there are recommendations on PITR/PETR deployments

The location of the RTR is desiraable to be close to the current location of the xTR so we can minimize packet stretch. Hence when an xTR moves, the Map-Server (which is fixed and doesn’t need to be close to the moving xTR since it is a control-plane function), tells the xTR of a new set of RTRs that is close to it, in the xTRs new location.

This is mostly policy information in the mapping system.

> - is RTR shared across LISP sites behind NAT or each site needs a dedicated RTR

Yes, we envision that millions of xTRs can use the same set of RTRs (i.e. a pair of RTRs that are topologically close to each other and the xTRs that are using them).

> - what if RTR is behind another NAT (SP-NAT)

By protocol specification, it should be in public space. But I have an implementation where NAT-traversal works when both the xTR and RTR are behind NATs (different NATs).

> 3) How is multiple-NAT handled (e.g. enterprise and SP NAT)

If you have an xTR that is multi-homed to 2 NATs, then Info-Requests are sent each way to both the map-server and to RTRs that map-server has advertised. In the registration, one can decide which RTR is used by remote ITRs encapsulating toward the EIDs behind the xTR. And the xTR can load-split traffic (outgoing traffic) across the RTRs in the list the map-server provided.

Thanks,
Dino

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Sharon <[email-masked]>
Date: Tue, 3 Nov 2015 07:02:17 -0800

Can also add a  carrier use case -

The RTRs are in POPs, racks of equipment or clusters of servers, stable underlay, very responsive low latency mapping. 

The XTRs are across the access, on or off the carrier footprint, (NAT wise) high latency lookup, potentially shaky conditions.

The RTRs anchor the XTRs. The XTR can reach any of the RTRs (any cast) move, recover from a topology change, or access carrier change.

The mapping Service & Resource Schema apropos yesterday discussion regarding easy mapping abstraction (Albert) for orchestrating NSH (Vina, Fabio) is made available to potentially millions of semi loose XTRs aggregating billions of very loose EIDs, using traversal anchoring without creating a global data consistency nightmare. 

--szb

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 3 Nov 2015 16:37:39 +0000

> Yes, we envision that millions of xTRs can use the same set of RTRs (i.e. a pair of RTRs that are topologically close to each other and the xTRs that are using them).

Well, a given RTR is limited by the # of destination UDP ports available.

-Darrel