IETF 108 LISP WG Meeting Minutes LISP CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com ) Luigi Iannone ( ggx AT gigix.net ) SECRETARY: Padma Pillay-Esnault ( padma.ietf AT gmail.com ) AGENDA Session 1/1 (50 Minutes) =-=-=-=-=-=-=-=-=- Wednesday, July 29, 2020 13:00 - 13:50 (UTC), Session II, 50 Minutes Video session can be found at : https://www.youtube.com/watch?v=Qg4EY7gpRaI - Administration Halpern/Iannone - Agenda Bashing - Status reports for WG drafts 5 Minutes (Cumulative Time: 5 Minutes) o WG Items - Update on 6830bis/6833bis documents - https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ - https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ 10 Minutes (Cumulative Time: 15 Minutes) Albert Cabellos Questions/Comments: Fabio Maino: Just wanted to add a comment about GPE draft progress. Published on Monday and addressed all the comments. Magnus has acked he is fine. Joel: Magnus confirmed that with me o Non WG Items - A Simple LISP NAT-Traversal Implementation - https://datatracker.ietf.org/doc/draft-farinacci-lisp-simple-nat/ 20 Minutes (Cumulative Time: 35 Minutes) Dino Farinacci Dino presented a simple version of NAT traversal. Based on the Nat Traversal draft by several contributors. The concept has been around in 2014 and used frequently (daily). Presented the list of requirements and that the IPv6 RLOCs are not supported and don’t need to be NATed. Discussions/Questions/Comments: Albert Cabellos: Is there any authentication between the XTR and the RTR? Dino: There is no authentication just like when you are not behind the NATs. You trust the mapping system to give you a set of RLOCs just like in any scenario. Albert: My understanding is that we went through several discussions regarding public Internet deployments. In my view, clearly NAT transversal are super important when you are dealing with mobile nodes where access point should be deployed on the public Internet. The fact there is no authentication means that anyone can use it as a sort of proxy to hide its own IP. Dino presented then some designs observations and then asked for the WG to adopt draft as informational. Dino: We can authenticate Map-Request and Map-Register messages by signing them using the authentication draft we put on, so not everybody can get a Map-Reply. Map-Servers are also Map-Resolvers that verify the signature in the Map-Request. If they are verified that means they are permitted to use those RTRs and we could use that. My implementation does support that as it supports authentication regardless of what’s being returned to any ITR behind a NAT or not. Albert: What the other draft is doing is sending the Map-Register through the RTR encapsulated and that the RTR is looking at the Map-Notify and we are using the secret association between the XTR and the Map-Server to authenticate the RTR. Dino: You have the RTR part of the control plane authentication and we never had to do that before. I wanted to stay with the previous model where we do not have a third party hairpin in the control plane. RTRs until now have only done data plane stuff and they get all their control plane info directly from the mapping system as well as all xTRs. Stayed with that homogeneous model. Albert: Yes. I see that, but I still see issues with the RTRs being accessible through the public internet with no authentication. Dino: Someone has asked the question: is LISP going to work on public Internet in general and if you say no, because of the -bis drafts, by pushing back a little bit it is not that the NAT traversal draft needs to support the public Internet. We need to be consistent about that on both ends. Obviously by using NAT transversal you are assuming that you have some sort of protection and then go into a public environment – the public environment can also be an enterprise network that is using NAT for whatever reason (it doesn’t have enough IPv4 addresses or whatever) Albert: The -bis documents are not saying that LISP cannot work over the public Internet, but rather that some mechanism expected in a specified list must not be deployed when using it over the public internet. But this can work over the public internet with LISP-SEC and so on. I guess this is a larger discussion. Fabio: I think Dino you need to document at least this discussion on the role of security and authentication in the document as this would really be the first question the security reviewers will bring up. Dino: Well, it depends on what the fate of this document is. Alberto Rodriguez-Natal: 2 quick questions. The XTR behind a NAT has a default map entry towards the RTRs, so when is it going to decide to send the Map-Request? Because the traffic is going to hit that default Map-Cache entry. Dino: You can install more specific routes in the Map-Cache. In my implementation you can install static Map-Cache entries and the RLOCs have an action that says send Map-Request. A forwarder would map to the more specific map entries that instruct it to send a Map-Request rather than use the coarser entry that has RLOCs. Alberto: This is a static config and you need to configure the xTR in that particular way. Dino: You can configure a set of prefixes that you know are not behind the NAT and that is easy to do – for examples servers in the public have known prefixes – services addresses that are not in our local directory. Alberto: When the xTR moves your draft assumes that it is still have the same set of RTRs. Is this correct? Dino: Yes. As long as it registers to the same Map-Servers. Future NAT traversal – do you want the Map-Server to give you a different set of RTRs depending on where you are moving? For example moving from one ISP to another or a long geographical area you may want the RTR to be close to the xTR but you may arguably want the remote ETRs to be close to the RTRs. What is the most important is that you want your set of encapsulators and decapsulators to have the RTRs relatively in the center of gravity so that there is no hair pining somewhat en route. Luigi: Interesting discussion we need to take it to the list. The WG has to discuss a little bit on this approach of using NAT traversals and alternate approaches, especially looking at the security discussions. Dino: I want to publish it as an informational RFC, unless the WG wants to do something different with it. I wanted to ask the WG an opinion if I can publish it as an informational RFC. Luigi: Take it to the list. Joel: If you take it to the IESG and ask to publish it as an individual informational, it will be punted back to us asking whether this is an end run. We will most probably say yes this is an end run and please hold up until after we have published the WG NAT traversal. Dino: OK taking it to WG list and discuss whether we merge the design or keep it separate. - LISP Uberlays - https://tools.ietf.org/html/draft-moreno-lisp-uberlay-01 15 Minutes (Cumulative Time: 50 Minutes) Victor Moreno Victor Moreno presented the LISP MS Federation Presentation Luigi: We will continue the conversation on the list to better understand the problem at hand. Victor: The requirements are becoming clearer and it might be an opportunity to write some text and summarize the requirements to move forward or we can have an interim meeting. Luigi: We can check on the mailing list if people are interested in an interim meeting focusing on these requirements and start writing texts. We will talk it to the list and may be organize an interim meeting on the uberlay