IETF 103LISP Meeting Minutes Monday, November 5, 2018 9:00 - 11:00, Morning Session I, 120 Minutes Room: Boromphimarn 3 Agenda Bashing: Sharon Barakai couldn't make it ot Bangkok so the "Automotive Network" is cancelled. o WG Items - LISP YANG Model - draft-ietf-lisp-yang-09 10 Minutes (Cumulative Time: 15 Minutes) Reshad Rahman Presented the changes between latest two versions (09 & 10) Mostly about mapping of VNI to VRFs and an updated the security section. The YANG document is a bit out of sync and need some updates. Need to add some changes due to bis documents. Once these changes finish would like to request a WG Last Call. Discussion Victor: Regarding the VNI references they need to be updated to instances as soon as possible to be aligned with all the specs. Reshad: Yes. Joel: You mentioned VNI and use VNI in the mapping indexes but what's supposed to happen if the VNI is the public Internet? If it is not a private network, the mappings grouping and it looks this looks like a mandatory key and what value would you'd put in? Reshad: You would have a default IID. Joel: You do not have an Instance ID for the public Internet. That's I'm a little confused. Dino: If you encode an Extended EID with an Instance ID and it's for the public Internet the values. If you don't include the Instance ID, it's assumed to be zero because it's unspecified. So, we probably should note in the YANG that zero is the value for public Internet and we'll double-check the VPN document that formally defines Instant ID that zero means public Internet . Joel: OK Reshad: In the private version we have these changes and it will be published soon. Do you Chairs or anybody in the room having an issue if after we've made those corrections that I have mentioned that we start a WGLC? This will push people to read and comment the document. Joel: After changes have been made going for WGLC and make people read the document seems entirely sensible. Fabio: There may be also something that we need to look at. Is related with the scope of the password or the shared key that is associated with the with the map registration because we introduced the xTR-ID and so we have changed that scope in 6833bis. That needs to be reflected in this document. Reshad: It is in the private version Alberto's started making those changes but yes, you're right. Those changes have to go in maybe they won't go in version 10 but they'll go in version 11. - Update on 6830bis/6833bis documents 20 Minutes (Cumulative Time: 35 Minutes) Albert Cabellos Presented a short summary of changes on the two bis documents per areas of change. Main changes can be summarized as follows: Scope of applicability has change to focus on precise use-cases, not on global deployment. Hence, the term "global" has been removed. LISP-Sec is now Mandatory To Implement. It is not mandatory to use, but deployers that feel concerned can use it. Nonce manipulation has been changed, it has to be incremented by one for each new Map-Register, so to avoid replay attack for Map-Register. ETR/MS must store the nonce in persistent storage. Concerning UDP and congestion Control, implementers need to follow the guidelines from RFC8085 “UDP Usage Guidelines”. Discussion Luigi: I had 2 comments. On the reserved bits that they should be actually be assigned according to the comments Med's comment on the mailinglist. If we say reserved they will not be used in the future. If they are unassigned they can be used in the future. Dino: Wherever there are references to bits that are labeled "R" then there is an explanation for them say reserved and unassigned Luigi: okay it's not the really compliant. The second comment was just a clarification, I think we should specify that the last nonce is by ETR, because if we have two ETRs they will both register to the same server, they can use different nonces. Albert: The nonces are indexed by xTR-ID. Dino: Since the ETR can move and change our RLOCs you want something that's persistent so this is why we have the xTR-ID in the specs. It was being used only for NAT traversal we took it out. But now, to deal with the replay attack we put the xTR-ID back. Eric: I haven't read the spec on this but these nonce can they actually get out of sync suppose that the XTR is sending nonce to that map registry is never received by the map server. Then moves and it starts sending nonce three that's never received by the Map-Server etc. So, the xTR can keep on advancing the nonce because it keeps on moving. Then you know three days later and the Map-Server shows up and the nonce advanced far beyond the stored last-seen-nonce value. If so how do you resynchronize? Can you actually move that way, or does the nonce advance only when it gets a map notify back? Albert: They will know that the Map-Server is not responding because it is not receiving the Map-Notify. The nonce must be stored in persistent storage to keep track of the state. Dino: The Map-Server always accepts a nonce that's greater than the last one, so it doesn't have to be plus one. Erik: But does it actually advance the nonce it's going to use only when it gets to Map-Notify, because then you're advancing in lockstep. Dino: Since it's an acknowledgment to the Map-Register the Map-Notify copy for nonce from the Map-Register and then when the next Map-Register is sent it could be sent +1 or +. Erik: The only way you could get messed up is if you wrap around during the nonce number space. Luigi: If I register to two different map servers I use the same nonce? Joel: You could choose to use the same one, that would be legal, but you're not required to, as I understand. Dino: Yes, this is true. Luigi: How do we choose the nonce at the beginning? Fabio: Since the space is 64-bit and we basically use modulo two to the power of 64 we just pick one random. Dino: I could share with my implementation does. If an ETR comes up for the first time it doesn't have any persistent storage it allocates a random number of that to 2 to the power of 64 space, and then it does +1 and it stores it in persistent storage so if it crashes and comes back up it can go where it left off someone. - LISP EID Anonymity - draft-ietf-lisp-eid-anonymity-04 10 Minutes (Cumulative Time: 45 Minutes) Padma Pillay-Esnault Presented the draft and discussed the benefits and objectives. Make EID private and not trackable. Asked for WGLC after update to be posted. Question Prakash : Question on use case. Padma : Explained the use for mobility and how it can be helpful. Luigi asked the room if ready to go to WGLC. No one in room opposed. Luigi : Will send to the list for last call - LISP Control Plane ECDSA Authentication and Authorization - draft-ietf-lisp-ecdsa-auth-00 10 Minutes (Cumulative Time: 55 Minutes) Dino Farinacci Presented the draft and discussed the benefits, namely: - Strong Elliptical curve crypto using DSA. - Verify and invalidate single XTR. - Can use the signature ID for registering an EID. - xTR public key to encrypting resulting. Discussion Luigi: It's interesting, but this means that maybe we will have to update the specs somehow. Dino: I was hoping that we would do this independently of those specs Luigi : Absolutely. You have to make sure that if there is an update to the main specs then in that case you have to clearly state it. Fabio: Do you think there will be such changes? Dino: There will be at least a bit stating whether the Map-Record is encrypted or not. Most likely there will be packet format changes. We need more work on this, right now we will just keep it WG document. Fabio: There is no dependency between this one and anonymity. Dino: They are complementary. Erik: Notion of being able to encrypt everything is interesting. Has anybody looked at what's the performance impact of using public key crypto for all? Dino: I'm supposed to figure out a way of having some asymmetric scheme if you're going to do. Erik: you can imagine to use a session key. But what is the impact on performance? Dino: Doing some performance measurements encrypting Map-Register using chacha. I will report on this. - Publish/Subscribe Functionality for LISP - draft-ietf-lisp-pubsub-01 10 Minutes (Cumulative Time: 65 Minutes) Alberto Rodriguez Natal Fabio Presented the diffs from -00 version of the document. Added Site-ID and xTR-ID definitions. Changed IANA considerations and clarification in the security sections. Added rate limit for Map-Notify sent to an xTR-ID Because of the important changes in 6833bis regarding nonce, there is an open question on Map-Request used for subscription and Map-Notify used for publication? How to distinguish them from Map-Notify sent to acknowledge Map-Registers. No questions o Non WG Items - Multi-Domain LISP - draft-moreno-lisp-underlay-00.txt (To Be Submitted) 10 Minutes (Cumulative Time: 75 Minutes) Victor Moreno Describing the problem of having multiple domains that you concatenate with LISP. Joel: I can interrupt you right there because looking at the draft I was left confused. The first point I'd make is that the comment you made just now about having a mapping system, or a portion of the mapping system, that this site can take responsibility for, therefore the intra site connectivity works as long as this site is working. That's an important point to call out, which is not clearly called out in the draft. Having said that, the converse a lot of the this seems to actually make robustness and survivability worse. The whole design of LISP was to be extraordinarily scalable, and that the Mapping System was extremely flexible. This doesn't really improve Mapping System scalability, because the ability to delegate in any of the Mapping System version we've used gives you very good scaling already and this introduces re-encaps and additional specific points of failure along the inter-site paths. And if you didn’t do this it would have been more robust. It's not that you can't do it. It clearly works, but except for the Mapping System, and I think that could be done in simpler ways, most of this looks like it actually undermines its own argument instead of bringing us further forward. I think you need to focus more if there's a benefit than it needs to be much better explained before getting into the details. I see how you can make it work, I do not see why. Dino: I think we missed messaging the benefit the idea wasn't we trying to make the Mapping System scale well. Those are three independent mapping systems that are managed independently. It's not a subtree of one versus the other. Joel: Why are they managed independently? Dino: Because these sites are not wholly owned by one organization. Joel: Okay if you're just worried about the Mapping System wouldn't it be simpler to see if there's a way to attach this set of Mapping System which has delegated some things to a larger Mapping System and inject all the information. Dino: Because that's what we do today. But, you have to coordinate with another organization. Joel: You're going to have to coordinate for all the inter site stuff anyway and you don't have to coordinate if you can't reach the other organization. It should be possible to solve this problem purely inside of the mapping system. We entertain lots of Mapping System alternatives, that's one of the nice properties of LISP, without getting into the complexities of adding tunnel routers to provide interconnection. I'm just thinking that mixing the two instead of increasing robustness it actually seems to decrease robustness because now there are two points which if both of them fail you have no inter-site connectivity. As opposed to before where you have to fail all of your Internet connectivity to lose it. Victor: One of the things that we did in coming to some of these ideas, was that we thought we could do is with DDT as is. One of the things that happens in these networks is that there is a high degree of mobility. We want to re-anchor basically the devices as they move from one place to the other. It was not evident how we would actually do with DDT alone but you're right the DDT gives me a distributed structure where I could actually emulate those Mapping Systems. But, I don't have a good way for rehoming a moving device. Joel: If you inject aggregate information, when I re-home in a different site I do not have connectivity unless I change my EID. The whole point is not to change the EID. Doesn't seem to match what we set as our objectives. The document needs to be clear about the objectives. Victor: Fair enough. But we were not able to solve it with the tools we had at hand. Joel: If we need small changes in the Mapping System that looks cleaner than using tunnels for something that claims to be robust and scaling. Joel: Actually, the split horizons (for mapping announcements) is a little bit tricky, because you have site prefixes which are going to show up from the overlay into the local site legitimately is there has been movement, but accidentally if something else is going wrong. Victor: There's a couple of checks that we put in the draft, but yes, for sure it's one of the trickier things. Joel: Trying to build logic that depends on the RLOCs with which one receives the information is fragile. Victor: Yes, we also suggested some checks on the actual away tables, which basically indicated its mobility event. Dino: We had this exact same problem with the ID mobility. The question is: is there somebody spoofing you over there on that subnet or did the guy actually move there. That's why you had to add access lists. Victor: Those procedures at the end systems are consistent with the ad mobility procedures. We try to basically make sure that we don't reinvent things where we're not necessary. The other thing that we do is we relay events across the domain. So, we relay mobility events, basically with Map notifications that that go back to the departure sites. We are going to also relay Map notifications that go towards the sources of multicast. We're relaying a lot of the signaling. Joel: In many ways this is behaving like one Mapping System. Victor: Yes, you could say that. The only difference being if there is a failure of one of them, basically all the other sites remain unaffected. Dino: One benefit we did not talk about is how these Uberlays and Site Domains can help the underlay. RLOCs are local and do not need to be re-distributed in the Uberlay. Zheng: Would you use inter-site multicast? Victor: Yes. It's all documented. Is just concatenating LISP signal-free multicast. Luigi: What about sites using different encapsulations? Victor: Good point can be one of the use cases driving the work. Dino was also mentioning NAT, when the underlay requires NAT. Encap translations can naturally fit in our design. Fabio: Looking at the ICAO, that's the case, there will be different transport for different organizations. Victor: Very good point. Part of what is driving this is the use case having the civil aviation ground being restructured. It needs to be modular. Different countries will choose different technologies. They will meet in the center, the Uberlay. So, part of the motivation of this work has been to achieve this modularity. Joel: this is interesting. Different parties can even use different Mapping System technologies, and that could be an argument for not just concatenating the Mapping Systems. Going down to the xTR is the only way to have a clean separation.