Re: [lisp] LISP NAT Traversal [Was: Virtual meeting]

[Dino Farinacci <[e-mail]>]

Pruning some texts. Answers to your questions inline.

> On Apr 1, 2020, at 2:28 AM, Albert López <[e-mail]> wrote:
> 
>> When the remote ETR isn’t behind NAT, the RTR can reach it directly but so can the ITR. 
> You say " That causes the non-NAT ITR and the remote RTR to do mapping lookup to get the global/non-translated RLOC" but who sends them an SMR to update the mapping? ETR can not do it because he doesn't have their entries in the cache. 

The 3 mechanisms I mentioned in previous email. SMRs (both control or data-driven), Map-Notify with pubsub from Map-Server, or map-cache TTL management.

>>>> What I was referring with this question is , If we are behind NAT using an RTR as a default gateway and then we handover to an IPv6 connection (at that point we are not considering the publish/subscribe solution), If we don't want to lose established connections, xTR has to notify the RTR (SMR) of the change of the mapping. To notify it, 
>> 
>> Yes. But now I’m not clear if you the “IPv6 connection” is referring to an IPv6 EID or RLOC. Please clarify.
> I am referring to IPv6 RLOCs

Then you don’t need NAT-traversal.

>> 
>>> the RTR should have an IPv6 RLOC that should be included in the list of RTRs of the Info Reply message.  Depending on what the RTR does with the SMR,  remote ITRs could move stablished connections to direct path or continue using the RTR.
>> 
>> If IPv6 is an RLOC, it is assumed anyone can reach it and a site xTR need not encap packets to an RTR. RTRs for NAT-traversal are used only for IPv4 RLOCs, regardless if the EID is IPv4 or IPv6.
> If we want to maintain established connections, when we handover from NAT to IPv6 RLOC, we need to notify the change of mapping. If we use SMR procedure, our only entry is the RTR, so if it doesn't have an IPv6 RLOC, we can not SMR it and the xTR will loose the already established connections. 

This is true. That is why you use an RTR for NAT-traversal only for IPv4 RLOCs.

>> 
>> Note, that SMRs will cause a flurry of messages depending on how aggressive the ETR wants the ITRs sending to it to be updated. And requires queuing demands on the ETR for reliable delivery. Hence why data-driven SMRs were introduced in implementations. But that only happens for EID-mobility (EID is not co-located with RLOC) and not in LISP-MN (where EID and RLOC are co-located).
> From my point of view a TTL of 3-5 seconds is also quite aggressive from the perspective of the Map Server that receive the queries (probably will have several MN registered to it). May be, a good point would be to evaluate all the pros and cons of each mechanism and recommend to use one for each case. In any case, I believe that we need to specify what is the behaviour of an RTR when receiving an SMR.

It depends where your mobility domain is. And how fast the requirements are to change mappings. We have 3 mechanisms and they all have their disadvantages.

>>>>> 
>>>> It needs to be reachable RLOCs. And in the lispers.net implementation, an xTR behind a NAT registers it’s translated RLOC and the RTR RLOCs. That is so the remote RTR can use the translated RLOC (and the translated port it learns from Info-Requests) and remote ITRs to use the RTR’s RLOC (since that RTR is the only node that can get packets through the NAT).
>>> I don’t have the full details of the lispers implementation of NAT-Traversal solution. Is any document describing it?.
>> 
>> I don’t have something written up but I do have slides that show protocol flow. See at the end of this email. It can all be explained in one slide. ;-)
> The Info Request message contain authentication section, is the key shared between MS,xTR and RTRs?

I don’t use authentication for Info-Request and Info-Replies. Otherwise, you need a security association with the RTR that can change quickly. You don’t want to provision keys between xTRs and RTRs but since xTR to MS is more of a provision based admission control to the control-plane system, it is acceptable and necessary there.

>> 
>>> My concern here is regarding section 5.1.2 of the draft (Map-Request and Map-Reply handling). When we sent an Encap Map-Request to get a mapping, we add a list of iTR addresses to receive the Map-Reply. We can add here the global address of the xTR but if the NAT has not been previously punched, we will not receive never a Map-Reply, at least for symetrics NATs.
>> 
>> You MUST put public-RLOCs in the mapping and the only node that can do that is the ETR. And it discovers its public-RLOC but receiving a Info-Reply from the MS that echos the outer source address and source UDP port from the Info-Request message. The message that the NAT translated the source address and source port.
> May be I am wrong but the scenario of open the NAT with the Info-Request Info-Reply messages is only valid for a scenario with a single MS where all EIDs are registered with proxy mode. If the reply of the Map-Request comes form other MS or remote ETR, then we don't have a hold in the NAT and the Map-Reply  message will not be received.

No, not true. My implementation allows an ETR to send Info-Requests to 2 map-servers and assumes/requires that the RTR-list configured on each map-server is the same.

Yes, and proxy mode is required because in my implementation, the map-server returns ETR public-RLOCs to requesting RTRs and RTR RLOCs to requesting ITRs. Plus the map-server can’t send packets to destination port 4342 through the NAT. But this part is solvable. Just not documented or implemented.

>> Also note, there is a requirement for an xTR to have two interfaces, each connected to different NATs. And load-splitting is required across the two intefaces (inbound)
> I think that the draft already contemplate this scenario, at least when both interfaces use the same RTR despite using different NATs. If they are using different RTRs, both RTR's RLOCs will be included in the mapping, then is the ITR the responsible to split the traffic between RLOCs. Does it cover your scenario?

Yes, and it also supports two xTRs behind the same NAT to know the fact so they can encapsulate each other via private-RLOCs. I call this short-cut NAT-traversal in my implementation.

Cheers,
Dino