LISP WG IETF 100 Minutes - Administration Halpern/Iannone - Blue Sheets - Agenda Bashing - Status reports for WG drafts 5 Minutes (Cumulative Time: 5 Minutes) Luigi: The last security draft that was in ISG last call came back for the simple reason we are chartered to do standard track work while the security draft was still experimental. The document has been already changed to standard track and we'll work on it make sure is coherent with the bis documents and then move it forward for last call. I'm doing the write up and will hand it to Deborah. Side effect of having the security document back is that the introduction document will wait a little bit longer because there is a missing reference to the security document it's been there for 900 days so a couple of months more is not a big issue. Deborah: Regarding the security doc it wasn't so much that it was experimental versus standards track. I think it's because there's a lot of emphasis on security as you all know now here at IETF, and I felt that we need to ensure that we make the best documents. It is really important to have the security document and it's not going to be favored so much that's just experimental so let's just make it standards track so that we have a good reference. o WG Items Presentations 1. Update on LISP 6830bis & 6833bis draft-ietf-lisp-6830bis draft-ietf-lisp-6833bis Albert: Short preso on changes since last IETF. Latest version 6830bis -07 List of changes Clarified UDP IPv6 checksums following RFC6936 • Clarified definition for RTRs • Removed EIDs MUST NOT be used RLOCs since this is relative to the deployment • State that RLOCs are routable in the RLOC space, not globally routable • State that the map-cache is generally short-lived as opposed to short-lived • State that AFI pertains to the data-plane rather than an IPv4 or IPv6 address • State that ETRs may (not will) send map-replies • Change ‘mandate’ to ‘recommend’ in the maximum number of LISP headers prepended • Add reference to [I-D.ietf-lisp-vpn] in InstanceID • Clarify that E-bit is conveyed in RLOC-probe Map-Reply • Clarify when to use private IP addresses • Clarify when to use InstanceID, remove reference to RFC1918 - 6833bis version 06 changes I: This is the xTR-ID bit. When this bit is set, what is appended to ignored on receipt. the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage procedures in [I- D.rodrigueznatal-lisp-pubsub] for details. Luigi: Comment or questions? Dino: We had one comment from you Albert about a reference in 6830 on some research that's going on, while actually that research has finished a long time ago. So, the recommendation by Albert was to remove it. We can put a new update out and send it to the list and see what they think. 6833-bis just came out and Alberto added a set of clarifying comments that look non-controversial from first glance but we'll have a deeper look at them next week. I think we've had a lot of opportunity for commentary for over a long period of time I think we're ready for last call. We'd like to request that I don't know what you guys think. Luigi: I have a comment that I was reviewing thoroughly the 6830, and there is some text that does not belong there. We need to review 6830 and then we will look at 6833bis. Luigi: There is still some text that doesn't really fit in the data plane. We don't have time to go into details today but I want to push this on the mailing list in the coming weeks because I would like to be done at least with 6830 by Christmas. Keep an eye on the mailing list. Dino: okay the goal for 6833-bis is a little bit later then. The next IETF this should be all in the RFC editor queue. 2. LISP-Security - draft-ietf-lisp-sec-14.txt 5 minutes (Cumulative Time: 25 Minutes) Fabio Maino Fabio presented the changes on behalf of the co-authors. Changes Since rev-12 • All changes were introduced in the “Security Considerations” section to address the last call review 1. Recommendation to periodically refresh LISP-SEC shared keys to address key aging and key compromise 2. Clarification on resiliency to Replay Attacks based on use of nonce 3. Considerations on role of LISP-SEC to mitigate DoS and DDoS Fabio: Ask if we move back to last call? Luigi: We will need to redo last call after we moved forward the bis documents. Fabio: OK Joel: There is a message here for the WG, because we will be last calling all three of them soon. You don't want to be trying to fully read from scratch if you haven't looked at all the three documents, so read them. They're close enough to be finalized. Please look at them now get comments to the list if you see something so that we can make sure these are in good shape and we can get them through last call and hand them to Deborah for the IESG. 3. LISP YANG Model - draft-ietf-lisp-yang-05 5 minutes (Cumulative Time: 30 Minutes) Reshad Rahman Reshad: Introduced the NMDA guidelines and the impact on the lisp yang model draft and resulting changes NMDA guidelines • Network Management Datastore Architecture (NMDA) guidelines are documented in dra -dsdt-nmda-guidelines • Addresses “OpState problem” which has been discussed at IETF: duplica on of nodes in separate con gura on and opera onal containers • New datastore for opera onal data added in dra -ie - netmod-revised-datastores. Contains data/state and con gura on which is in use by the system • Metadata annota on indicates the origin of the data in datastore. E.g. intended or learned. LISP YANG updates for NMDA guidelines • Removed duplicate containers across the models • Single map-cache on (P)ITR (for both sta c and dynamic) • Single mapping database on MS (for both sta c and dynamic) • Removed references to “state/con g/cfg/etc” from descrip ons Site-ID/xTR-ID • Only one xTR-ID/Site-ID per LISP router-instance across all its LISP roles Map Server • Authentication key now per Site-ID • Site-ID/xTR-ID added to mapping records • Removed ‘registered-mappings’ • VNI is now the parent for mappings Dino: Why the authentication is per site-id rather than by prefix. Reshad: Most common usage is by site-id and it can be augmented to cover prefix-id. The implementations I'm aware of have it per site ID Dino: So, if somebody wanted different authentication for different eid-prefixes for the same site they would have to configure them as separate sites. Reshad: Well, with this model yes. If you want to support what you just asked, we would need to augment the model. It could be a vendor specific augmentation or maybe it can be part of the IETF. Dino: So, if you want ID prefix authentication just configure it a separate site you're not taking the functionality away just have to do it a little differently and if you say there's popular implementations that do it that way then it's probably not that much of a problem. Reshad: That is our opinion yes. Next steps: • More operational data needed, e.g. counters? • Compare with LISP MIB • Comments/feedback from LISP WG Luigi comment: If you say that the ETR is per-ITR and not per-mapping which means that you have no choice but use one ETR for different prefixes. Reshad: You cannot do it per prefix right now with the way the model is today, so if you people feel that this functionality is either needed or fairly common implementation, we can definitely consider adding that back either via an augment of that base or by adding it in the base model. Deborah: I saw this is experimental most of the young work we're doing it's standards track in IETF. I was just wondering could this be standards track because especially you say you have implementations. Reshad: I was not one of the initial authors. I think it was experimental because that's what the other the work was started. Joel: We started working on this before putting the base work on standard tracks. I think it would make very good sense to move this to be proposed standard as well and we'll advance it behind, but not very far behind, the other documents. Reshad: So the community now has four documents to read. Deborah: There is a strong interest right from the IESG not only in security but in management and so if we can show you also have a document in the pipeline for the yang that would be great. I would strongly encourage if you could get some of this to the hackathon that we could show the implementations and if you have any open source. That is why I'm also thinking to make it standards track because of the open source community. Fabio: we have a few implementations available and if we can put it on standard track that would be really cool. Non WG Items 1. LISP Map Server Reliable Transport - draft-kouvelas-lisp-map-server-reliable-transport-04.txt 10 minutes (Cumulative Time: 40 Minutes) Reshad Rahman Reshad presented on behalf of the authors Changes Replaced draft-kouvelas-lisp-reliable-transport That was last presented at IETF91 Main change since then is addition of scope field in the refresh procedure Authors: Asking for WG Adoption. Dino: This might be a radical comment, but we are probably in a technology transition now maybe the question should be asked if we can keep the messaging same as LISP and run it over QUIC. We'll have a UDP interface we can use the same port number and we get security for free. You haven't said if you use TLS here and I'm seeing requirements for having the interaction between the mapping system be encrypted. So, I'm just wondering if we should maybe spend some time there get some folks together and see how LISP can work over QUIC to make it reliable so I don't know if you think that's radical. Reshad: I can't say because we've done this, you have a good point, but that's where we are now. Luigi: Asked how many people read the draft – not many hands in the room Please all read the documents we'll come back to this question 2. Ground-based LISP for the Aeronautical Telecommunications Network 15 minutes (Cumulative Time: 55 Minutes) Reshad Rahman Reshad presented as co-author Background - Use of LISP to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS) • International Civil Aviation Organization (ICAO) is proposing to replace existing services with an IPv6 based infrastructure for Air Traffic Management (ATM). • ATN/IPS handles Air Traffic Controllers (ATC) and Airline Operation Controllers (AOC) • draft-haindl-ground-lisp-atn was presented at the ICAO IPS Mobility Sub-Group • Builds on mechanisms defined in draft-ietf-lisp-eid-mobility The different types of exchanges were presented - Aircraft registration and ground to air traffic with preference to a specific region - forwarding path before the resolution by the map server and also after resolution. (necessary for no packet drop) - optimized multi-link mobility Next Steps: Looking for comments from the wg Peter Ashwood Smith: Is there any requirement for a ground-based wired connection when the aircraft is at an airport? Reshad: I don’t know Fred? Fred Templin: So, the question was from ground-based to the aircraft's wired link? They call that GW link actually. That's just another example of a link that an airplane would use to route. It could be VHF or another link. The ICAO is actually meeting this week in Bangkok and I was there on Monday and ground-based LISP is one of three proposals that they're looking at for what they call the mobility solution. A second proposal is the simple BGP method that I talked about last time. Now they've also brought proxy mobile ipv6 into the into the picture. There are 3 solution proposals that are being looked at and the selection will happen over the course of the coming months. Dino: When you're parked at the gate and you have a wire connected that could just be another mobility event right? I think that's maybe what you're getting to use the same machinery and it doesn't matter if it's wireless or wireline. There will be a ground-based xTR that would have a new locator at the airport Luigi: Is there any critical traffic that goes over these links? Because you can imagine to actually duplicate the traffic' on the various links, meaning that you increase the probability that arrives at the destination. Reshad: I think we got comment like that. Fabio: I think it's interesting to note one of the few optimizations that can be done is using pub/sub that is the direction where we are trying to move the protocol. I think it's a nice use case articulating the value the LISP. It's probably confirming that some of the direction that the working group has been going on to evolve. Dino: I agree with Fabio. I'm kind of excited because the idea of the mobility draft could be used for all these use cases. The ID mobility for aeronautical application and the 5g proposal we're making is using the exact same mechanism. The generality in the level of indirection is becoming quite useful for many use cases with no new machinery being added. 3. VXLAN GPE - draft-brockners-ioam-vxlan-gpe-00.txt 5 minutes (Cumulative Time:60 Minutes) Franck Brockners In situ OAM in a nutshell - Gather telemetry and OAM information along the path within the data packet, (hence “in-situ OAM”) as part of an existing/additional header No extra probe-traffic (as with ping, trace, ..) “Hybrid, Type-1 OAM” per RFC 7799 - Generic, Transport independent data-fields for IOAM Scope: Per-hop, specific-hops only, end-to-end Data fields include: Node IDs, interface IDs, timestamps, sequence numbers, ... Encapsulation - IOAM data fields can be embedded into a variety of transports, including: IPv6, SRv6, NSH, GRE, Geneve, VXLAN-GPE ... Base IOAM document adopted by IPPM! • draft-ietf-ippm-ioam-data-01 Authors: Request Feedback Joel: Lisp working group is not going to define alternative encapsulations. Fabio: There are capabilities in 6833bis that can be used in other data planes. We have separated the control plane and the data plane for LISP. The question is whether there are some capabilities in RFC 6823 Bis that can be used independently from the transport. Joel: We're not going to get into defining works of other groups. We will happily consult to some other group. If the NVO3 would like to be able to use LISP as a control plane we would work with NVO3. I specifically do not want to get into any risk of this working group trying to standardize other WG fallouts. That's why I'm trying to be careful here. Luigi: We are specifying a protocol that can be doing layer 2 overlays. I would suggest from my point of view is can we look at RFC6833 and if you want to use it with a different data plane that allows you to use define new features that would not be available with the LISP encapsulation. That could be a draft you can bring up to this working group. Joel: New encapsulations are not in charter right now. Luigi: We can certainly have a discussion on control plane for other data planes. That’s all. Dino: Joel, so what if they said that the data that they gather from this data plane, even though it's not chartered in the LISP working group, is data they may want to store in the mapping system, that could be in charter? Fabio: Adoption for this particular draft I don't think is on the table today. I can bring up a draft where I try to specify how you can use 6833 with another overlay. This is a discussion that we should have in the working group. Franck Brockeners: We have running code for this very encapsulation in VPP Fido. There is running code of this very encapsulation in hardware with a bunch of chipset vendors we're using LISP implemented in open daylight for the mapping system, where you basically set up tenant networks which are VxLAN based and LISP controlled through OpenStack. So it is happening as we speak. We can say okay we don't want to have it here and but it's there in the industry and it's happening. Let's make sure that we reflect what happens in the industry and don't close our eyes and put our head in the sand. Luigi: You mention you are using the LISP control plane. The working group could be interested because we have charted the control plane to support multiple encapsulations. The encapsulation itself: we are not chartered for it. Uma Chunduri: I see this as a different way regardless of VxLAN data plane or LISP native data plane; this gives LISP actually more OAM capabilities which is good. Dino: Does this data only get written to the packet by the encapsulator and only read by the decapsulator? Mickey Spiegel: We haven't really specified that in the document as it is right now. But that seems to be a natural fit for something that would insert information. Joel: The original ITR would put this in the packet, the RTRs would preserve it and might processing, that would be a new functionality for the RTR, then the ETR would process it and strip it. Dino: I was kind of thinking the same. Mickey Spiegel: All three of those ITR, RTR, and ETR would be adding there are no data fields into this format and then when you end up reporting you're getting information right every one of us Dino: The reason I brought that up is because you may have an RTR topology that's made up of a multicast distribution system. I'm wondering if you have thought about this working on multicast branches? Mickey Spiegel: It's certainly possible to do that. Dino: If the RTR can rewrite the information that was put on by the ITR, as it goes down this tree do the spec allows additional appends to happen to the packet? Mickey Spiegel: If you're replicating the packet the information that was there before will be the same, while the new information that you're adding may be different. Padma: I really like the OAM, I am worried about one thing. How we're going to actually reconsider having to get it encrypted and who is reading their information. How about eavesdroppers who actually look at it in the middle. I know there's been so much of discussion both in SFC and other places about monitoring and the abuse of monitoring have you thought about that? Dino: If this has to work with LISP-crypto then maybe the data plane did just come in charter. The big question is an ITR prepends this packet data and encrypts the packet, sends it to the RTR or ETR, let's say in RTR because it seemed more interesting, there it decrypt and decaps then it can read the data hopefully the data is only in memory so it's not exposed on the wire. So, the question for the chairs is if they want this to work with LISP-crypto working then you're asking this OAM stuff to go in the LISP encapsulation format or how it works with the data planes that have been defined in this working group. Padma: Before you respond I want to say something else. What I'm worried is when you said this is stored in the map server. Maybe that's not the way to go. I think we need to think carefully about what to do with this information, where it should be, who can read it. I think there's a lot of things think about before we actually make a decision. Dino: There's no reason the data that's stored in the mapping system has to be in plain text it could be encrypted. Padma: I agree. You know just to say some of our latest woes is the fact that this encryption is considered not enough by some people and that's why I'm kind of erring on the side of caution before we actually say we will do this or we will do that I think we have to look at the implications of what kind of comments is going to come from other areas. 3. Publish/Subscribe Functionality for LISP - draft-rodrigueznatal-lisp-pubsub-01.txt 15 minutes (Cumulative Time: 75 Minutes) Fabio Maino Publish/Subscribe Overview • Map-Servers configured in proxy-reply mode • xTRs provisioned with unique xTR-ID • Subscription piggybacked on the Map-Request (no new messages) • N-bit (notification) introduced in the EID-Record to ask for subscription • Map-Reply returned if subscription not supported or rejected • Map-Notify returned if subscription accepted • Publication of mapping updates via Map-Notify • Ack’ed with Map-Notify-Ack Erik: Is the nonce of the Map-Notify is not the same as the map-Request. Dino: The nonce should be returned in the Map-Notify. Luigi: Why not using a bit? If you have an explicit bit you do not need to look at TTL zero. Dino: If you process a map reply today with a zero TTL it basically allows you to delete the map cache entry right away so when you get this map notify it's the same code that you use. Luigi: If you have a bit you don't even need to process the reply. I mean you don't need to look at the TTL zero. Dino: You're going to look at it anyway because you have to parse all the EID records in there, because this map notify may have other entries in it. Erik: What is the lifetime of the subscriber table? Is this soft state or does it stay around forever? Fabio: The TTL of the mapping or a detail of the subscription are the same. Erik: If I have a mapping has a 24-hour lifetime the subscriptions would implicitly be 24-hour lifetime and if you want to update, that seems to imply that the map server now has to keep this in persistent storage for 24 hours so that if it restarts it can still honor those subscriptions. That part of reliability is important. I guess there's two different things at least in my mind the lifetime of that mapping as opposed to the lifetime of the subscription. Dino: I mean he's making a good point. If there's a XTR that's registering a prefix and that has a TTL , why is that TTL have the same relationship of a subscriber. The subscriber may want to have notifications for less than that time or maybe more than that time. 4. LISP Traffic Engineering 15 minutes (Cumulative Time: 90 Minutes) Yan Filyurin Reshad: I understood what you mentioning for S- BFD are you just saying you're going to be using as S-BFD or you need to extend the S-BFD as it's defined today? Yan: We don't necessarily want to extend S-BFD, but S- BFD has the capability to probe individual paths. We are thinking of capitalizing this as a way for S-BFD to be encapsulated in the LISP packet and use LISP as a capability to probe. Reshad: I thought you were trying to maybe exchange discriminators. Yan: Possibility the discriminators. Could also be exchange IGP, but that I don't think we've thought this through enough to really speak on it. 5. LISP on Android & iOS 10 minutes (Cumulative Time: 100 Minutes) Oriol Mari Oriol Presented the Android system Sri Gundavelli: What is the trigger for your handover? Oriol: We are using a framework of Apple. It gives us a system configuration framework that we can register a notification system that the system when detects some changes on the network configuration. Sri: Does the framework allow you to specify if the RSSI value falls below certain value? Does it allow you that level of control? It allows you to detect the change? Oriol: Will follow offline. Dino: You are sending info requests and info replies that means it can support going through NATs as well? Oriol: We thought of NAT devices. Yes it works with them. Dino: Can you keep both interfaces LTE and Wi-Fi up at the same time and make it multi-homed and make it active-active? Does the framework allow you to do that? Oriol: Yes you can. It means to double our procedure but I'm not sure if you can use it at the same time both interfaces. Dino: In other words at the remote ITR can probe and find the best path and come in on either direction that would be more useful. If the framework only allows you to send on one that's not the end of the world, if you could receive on both that would be cool okay. Dino: Do you think it'll work over the Bluetooth interface as well? Would be cool because then you can do peer-to-peer networking easily. Oriol: I think that you can use it. 6. LISP Control-Plane ECDSA Authentication and Authorization - draft-farinacci-lisp-ecdsa-auth-00.txt 10 minutes (Cumulative Time: 110 Minutes) Dino Farinacci Reshad: I haven't read your draft but what kind of performance impact do you have because you're using public private key right? Dino: This draft is only putting signatures in the packet there's no encryption. We are only solving authentication authorization but now that we have a public key system available we have the opportunity in the future to decide when and where to encrypt. Fabio: Is there an equivalent for LISP-crypto where you can use elliptic curve for the diffie-hellman exchange and make it more efficient? Dino: LISP-crypto already use elliptic curves. Uma Chunduri: I think you used ECDSA for public key private key generation. he's asking about the DH so that you can create the secure channel. Dino: There is another RFC that's the data plane and already support cipher suite and uses EC with AES encryption and ChaCha 20 . Albert: When you want to authorize a map request the map request will be signed, then the map server will take the public key and hash it. Dino: No. When the map request is signed the signature ID is there. When you have the signature ID the hash is in the lower bits and is used as lookup key to the mapping system to retrieve the public key. Albert: How did the public key get there? Dino: A third party registered that hashed distinguished name. Joel: You have to worry about who's authorized to enter those? Dino: When they send a map register they have to share a key to be accepted, so it has to have a security association between itself. Joel: One way to attack someone is to cause there to be a different public key for them they can't register because their private key doesn't match the public key. Dino: It's always a good sanity check when somebody actually registers to use the same hash algorithm to make sure that the hash and the public key actually match. There's some other data that's in there too so it's just not the public key. Uma Chunduri: this is very good for LISP actually, it's giving basic security properties. What is important is also anonymous ID generation with one-way hash but maybe we cannot with this approach. Multiple ephemeral IDs can be generated, I'm not sure about. I think Bob was working on this. Dino: I thought about this quite a bit. The ephemeral IDs from the other specs, I think the conventional wisdom is that hashes are pretty random. Key management is not a trivial matter so you have to consider that you know this isn't an XTR. Should I give them 16 key pairs that they can just spin and use and the answer is yes, they can do that for sending data packets. Uma Chunduri: Is this one of the discussions we were having with Bob. We can discuss offline how to do this action. 7. LISP for the Mobile Network - draft-farinacci-lisp-mobile-network-00.txt 10 minutes (Cumulative Time: 120 Minutes) Dino Farinacci Padma: This draft is also coupled with other documents which are looking at the aspect of provisioning and how to integrate it with the 5g especially for the mapping systems. This draft is just part of the whole solution but there is much more being published elsewhere Sri: This is still an overlay solution right, I'm curious how do you see this working with the 3gpp. Because you can enable the QOS part for a particular flow, but how does that work? Dino: The 6830 specifies that you copy the inner header QoS to the outer so it's maintained across the core. The ToS bits in an ipv4 and the flow label in the ipv6 is copied to the outer header when it can be. Meaning that a flow label of 24 bits can't go into an outer ipv4 header with 8 ToS bits. Sri: You can do the marking but my point is yet the PGW it has to allocate the resources. Initially there was PGW1 it has allocated the network resources so now after you hand over or you route the flows through a different path you're no longer anchored through the same PGW so now I'm wondering how you move the QOS Dino: Like Padma said there's a lot of other specifications and there's a lot of other machinery that's operating here. What we're trying to show here is a way to get shortest paths on the data plane and pulling state from the mapping database. There's a lot of other stuff that needs to be worked out and that's why we want to go to all these standards groups that have expertise in this area. Sri: I understood that with the overlay approach you can find the optimized route but my point is that you need to have some interworking with the 3gpp signaling so that you can move the QoS. Uma Chunduri: The mapping system here is one of the components in the 3gpp that is what Padma was describing. It is described in it's a NGP document. Padma: There are other documents that actually show how the actual registration involves the mapping system in the 5g. These documents are currently under review and so they're not ready yet but there are much more machinery behind this. But the part that Dino is presenting today is just a data plane and we know that on the 3GPPG GTP control plane there's a lot of discussions happening right now and there's a lot of things in flux. But at least this shows one solution without anchors which removes the triangular routing and that's what we're really trying to push. Yan: I assume that you guys are working on all the different aspects of service function chaining to integrate into the solution. Dino: As you know RTRs can be placed anywhere and since we know there's going to be a lot of virtual functions that are going to be in the 5g Network we could hop through them where necessary. We have to be a little bit careful about that because we can suggest all this functionality, but as you take additional hops it's going to affect this one millisecond latency. if that's going to be in the data path there's going to be a huge cost to the end user for special applications. Yan: Many people are just interested in say placing traffic shaping devices. People will want all kinds of things to control. Dino: I do want to mention is that Peter and the guys up in Ottawa have done some really good research on this. I'm using ID locator separation on a 5g network and they've done it with some real devices and virtualized some stuff. Maybe next IETF we can show you a demo. : I'm curious what kind of scaling number is in the mapping system you would need for that kind of functionality for the mobiles Dino: I have some slides of how to deploy a mapping system with a billion nodes in it. I don't think the state is the scaling problem I think it's distributing the map-request load across the mapping system and trying to fix DDoS attacks of the mapping system is the thing that should keep us up at night and that's the stuff that needs more people to think and look at. Peter Smith: Just on the scale issue, we've been doing some experimentation with pub/sub in conjunction with LISP-like data plane. We've been using different massive scale already deployed already working on the billions scale pub/sub systems and we're seeing one or two hundred millisecond response times just using those existing systems. what Google and the others are doing is what we could actually achieve with a worldwide scale mapping system so that it's very promising and I invite you to look at our demonstration if you're if you're interested. Dino: Application level databases scale better than a DNS like structure like DDT and I think we need to do experiments in this area to see what is better. Now all these database schemes all have the same sort of problems they have to deal with. I think some of the advantages of LISP DDT is that the same database does not have to be store. The cost of that is that you have to go find the information when you need it and do you want to pay the cost at that time. A lot of people have said why don't you connect a bunch of map servers together with Cassandra or the blockchain. Lot of research is ongoing trying to figure this stuff out. Uma Chunduri: Just one clarification for this question. It also depends on where you are putting the mapping system. Scale question doesn't come into picture at all if it is a 4G system. Today the P-GW region is 1000 kilometres some cells and IoT's are connecting. In 5g the thousand of km are shrinking to 100 kilometers that's why your you PGW of mobility comes into picture and LISP solving that that's the crucial problem. Session Continuity across P-GW is the key problem here. Erik: I was wondering if it's this goes forward do you think that there will be additional security requirements? Dino: I think it will be inevitable. Maybe Padma or Uma Chunduri Chunduri could comment to that I asked the question yesterday a 5gangIP, if LISP crypto would be required and how much you know how much encryption versus monitoring of flows people need because that pendulum has to go back and forth. I'm not sure how much security actually. Uma Chunduri Chunduri: that's a very valid question. The mapping if it is put it into the providers control plane it has to have interfaces where it can attach to the authentication. Padma: One of the things that we've been looking is not only the placement of where the mapping system is, it's how distributed it can be. There's one question that we haven't really approached here is how do we leak those prefixes and it's a little bit different from pub/sub as well because we will have to really integrate with the 5g roaming scenarios. Actually this is under study right now at least by our team so anybody who wants to collaborate with us is more than welcome.