Monday 26th July Administration - Jabber Scribe(s): Nobody volunteered - Blue Sheets Agenda Bashing Presentation and Note well 10 presentations scheduled: Status updates and issues for WG drafts draft-ietf-lisp draft-ietf-lisp-ms draft-ietf-lisp-alt draft-ietf-lisp-multicast draft-ietf-lisp-lig Individual submissions LISP Map-Versioning LISP Security Threats LISP Canonical Address Format (LCAF) LISP-MN-NAT-Traversal. EEMDP proposal for managing holes in maps No issues rose concerning the agenda. Action items --------------------------------------- --> Terry Manderson: Since IETF 77th the draft-ietf-lisp-interworking-01 has not been uploaded. --> Darrel Lewis: There have been a set of comments that came in on the mailing list, about one month ago, that I wanted to address before submitting. Or you want me to just upload and address them later? --> Terry Manderson: Are the comments substantial? --> Darrel Lewis: I don't know because I haven't read the email. I was a bit busy, otherwise I would have responded directly on the mailing list. --> Terry Manderson: I would be happy if you upload -01 and then change it to -02 if we need to. --> Darrel Lewis: OK, no problem. --> Terry Manderson: Concerning the deployment draft, it is underway. We expect to have a -00 to be out shortly. --> Terry Manderson: There was a call to adopt draft lisp lig become a working group item and we reached consensus on the adoption and draft-ietf-lisp-lig has been submitted. --> Terry Manderson: There have been a number of issues that are in the tracker. Darrel and the other authors started to address them. Darrel Lewis presenting: draft-ietf-lisp ---------------------------------------- --> Vince Fuller: Suggested text is always appreciated. If you want a change to happen and you provide suggested text it's a lot more likely that they get in sooner than if we have to come up with something. Darrel Lewis presenting: draft-ietf-lisp-ms ------------------------------------------- --> Vince Fuller: The changes presented are in response of comments we received during the last IETF and have been made at the end of April, following the IETF in March. We are trying to listen and incorporate all the changes. Darrel Lewis presenting: draft-ietf-lisp-alt -------------------------------------------- No comments from the room. Dino Farinacci presenting: draft-ietf-lisp-multicast ---------------------------------------------------- --> Dino Farinacci: Who is implementing multicast? No Answer from the room. --> Dino Farinacci: We would like to solicit people to think about multicast implementations. We want to do one or two implementations as well. I hope to increase the multicast activity in fall, in a prototype form. Anybody that is interested can contact us or send something to the list. Dino Farinacci presenting: draft-ietf-lisp-lig ---------------------------------------------------- No slides available. --> Dino Farinacci: No changes since the last IETF. We have three implementations. It is working very well on the prototype network. --> Terry Manderson: Any plans to move from there? --> Dino Farinacci: It is working very well and I do not see any enhancements unless we want that it works also for the new EID formats, depending on what the outcome of the LCAF stuff is. Luigi Iannone presenting: draft-iannone-lisp-mapping-versioning --------------------------------------------------------------- --> Sriram Kotikapaludi: You mentioned stale mappings. Can you briefly describe how staleness is detected? --> Luigi Iannone: There is a notion of ordering in the map version. When you have a new mapping you increase the map version number and this gives you an ordering that you use to detect if a mapping is stale or not. --> Terry Manderson: We will take it as an action item on the list to request this to be a working group item. Damien Saucez presenting: draft-saucez-lisp-security ---------------------------------------------------- --> Joel Halpern: Thanks for the effort in writing this document. Sitting in the back there is Sandy Murphy, from the security area, that agreed to help to have a more comprehensive review in conjunction with what you started. She shall work with you, because I am sure there are more questions and issues that have not been addressed. Then, we will need the working group to work on what needs to be addressed now and what can be done later. Thank you very much! --> Jari Arkko: Can you go back to slide 1, where you were going over the reasons for attacking? It seems to me that any routing scheme has issues with "traffic hijacking" as well as eavesdropping. I claim that I have your address space and I can portend to be you. --> Joel Halpern: Fully agree --> Damien Saucez: The risk exists but there are ways to try to mitigate the risks. --> Joel Halpern: The point is that this is an area to be included in the set of security threats we are looking at. --> Jari Arkko: This is another thing an attacker may want to do. What we do about it is another question. By the way, Joel you were mentioning we could leave something for the future, we can do something now. I think is OK not to handle some security issues, as long as that's documented somewhere. --> Joel Halpern: Exactly. --> Damien Saucez: It is not only a security issue. Can be also a configuration error in this case. Because if you have a configuration error where you put /0 instead of /16, it is not an attack by itself. Like we have in BGP today. --> Joel Halpern: Misconfiguration can be the equivalent of a security issue. --> Damien Saucez: Yes, but the intention is not there. --> Joel Halpern: Most of the BGP security is about misconfiguration in the current world. Dino Farinacci presenting: draft-farinacci-lisp-lcaf ---------------------------------------------------- --> Joel Halpern: I would be interested in comments from the room. Obviously a final decision has to be made on the list but if people have opinion, whether this makes sense for the working group, please speak up. --> Alu Agarwal (?): I think the document has to spell out which use cases are in the charter and which are not. The ones that are not in the charter I think, before asking whether the document should be adopted or not, have to be taken out, or the charter has to be re-done. -- Jari Arkko: I wouldn't worry about the charter issue. What is in the charter and what is not. I guess you are creating a generic capability that can be used in various ways and you are chattered to do the generic capabilities. Having said that, I have a question mark on why we would be doing this. Even without this you are able to pass around IPv4 and IPv6 addresses, either as ID or locators. I didn't read the entire document but there is some text that specifies some cases where you can do it. So the working group should think about the trade-off here. We do this? This is a bit more complicate that what we have currently. We can do more, perhaps, with that, but this is the question: do we need this complexity to do the things that we need? Or not? --> Dino Farinacci: These LCAF addresses are just EIDs and RLOCs. What could be regarded as complex is that there is more parsing code that has to be written to parse the addresses. But you would use this new LCAF encoded EID for database mapping lookups, for sending map-requests. It's the use case that has the complication not the encoding format really. --> Jari Arkko: Agreed. Is not the encapsulation the issues here. The issue is more what kinds of identifiers you can pass around? What do they mean? And do we use them? That's the part I am mostly concerned about. --> Dino Farinacci: You want to point to the LCAF document when a new use case comes up and a separate document says we want to use lisp for server load balancing or something like that. This is how the EIDs would have to look and this is how they have to be encoded according to the LCAF encoding. --> Jari Arkko: All of this makes sense. What I am saying is that after reading 60% of the arguments in the draft I am not yet convinced that we need this. But this is a question for the working group to answer to. --> Dino Farinacci: I am actually hoping that some of the operators will say what format they want to use and the use cases, because they see the benefits of locator ID separation and they will come up with saying "I need an EID that looks like this". Maybe I can get a notion of IPv4 and IPv6 vs. an instance ID or something like that. I am hopping that this triggers thoughts and that gets in the document. Then, we decide if this should be a working group document or not. --> Jari Arkko: If people have specific uses cases they want to do or specific deployment problems they want to solve, may be that's the rule we should using not the theoretical possibilities. --> Dino Farinacci: Absolutely. --> Terry Manderson: We will take this as action item to the list for more review and workgroup status. ------------------------------------- --> Terry Manderson: Michael Menth is stuck in another working group. We will continue with Sriram Kotikapaludi. Sriram Kotikapaludi presenting: EEMDP ------------------------------------- --> Jesper Skriver: In which way is this useful, that I know a hole exists but I do not know where is. --> Sriram Kotikapaludi: Let me explain. I did not complete my explanation yet. --> Joel Halpern: I think the question is not what good is this /24, but what good is the /20 since you know there are other holes. Anything which matches the /20 and does not match the other information, then you have to re-query anyway. --> Sriram Kotikapaludi: I think I have an answer to that. Let me just go to the format slide. --> Joel Halpern: If it keeps falling in the same hole it has to keep asking. --> Sriram Kotikapaludi: It keeps falling in the same hole, which it has not asked before? Is that what you mean? --> Joel Halpern: Or it keeps falling into the common space but not falling into the holes. It just keeps asking. It feels that it is counterproductive. The other thing I would observe is that the current format has a counter. Counts the cases 0, 1, and more than one. The fact that you want an exception for which is not resolved is an interesting idea, but you don't need a type indicator for that in the main message. You need it in the response itself, the detailed. This would cover all of your cases without having enumerated cases. I always get nervous when we claim we have enumerated all possible cases in a protocol. --> Sriram Kotikapaludi: We can do it differently. It is just a question of semantics. I agree with you. There are these three possibilities and you want to be able to cover all of them in terms of informing the ITR. --> Jesper Skriver: The first three cases you mentioned, they all make sense. The fourth one, I still don't see the use, as Joel also pointed out on the less specific prefix. I think one way of doing this is not really a special case. You can say that if the ETR responsible for the /20 receives a data packet for a hole he can use a data triggered event saying "for this particular destination I know there is a more specific out there, go ask it". But this is a data triggered thing, not a control plane thing. Because I do not think it is useful when you get a reply to say "here is the /20, there are some holes, but I do not tell you where the holes are". If instead I send a packet and you reply "there is a more specific" this is something I can use. But this is a data triggered thing that has pros and cons. --> Joel Halpern: Or, you can split the answers until your reply does not have any hole. --> Jesper Skriver: Yes, but this is map proliferation. But I think that case 3 is the novel one, where you say "here is a short prefix, but there are lot of more specific, ask if you are going to talk to them". This we can already encode today, but is a new implementation technique. --> Sriram Kotikapaludi: I agree that if we cover up to case 3 we are probably in pretty good shape, and as Joel says, if you have too many holes, you have the choice to break up the maps in more maps, getting down to a granularity where you have to inform the ITR of few holes, not many holes. The operator has this flexibility. --> Jester Skriver: My point is, and I think Joel shares this, either we are misunderstanding what you are trying to tell when you say that there is a more specific present or what can ITR use this information for. If you cannot show what use there is for the ITR to know there is a more specific that exists, why even talk about it. --> Sriram Kotikapaludi: If there are 4 exceptions like in this case and suppose two of them take 95% of the traffic and I don't want to overload the ITR with all four of them or ten of them if there are even more, then I inform the ITR only about this two specific maps. The operator will know that 95% of the packets will be able to benefit from those specific maps. For the other specific maps, if a give to the ITR a count, "I gave you 2 out of 4", the ITR will use the two for 95% of the time. For the remaining 5% if it queries again for a couple of times, then it has all 4 in the cache and then it is done. --> Dino Farinacci: The ETR may not have all the information. Even though an ETR can know about a /24, may be a /28 out of that moves somewhere else. It does not know where it moves, and it can't and we do not want that the new place tell the old place where it is because it might not be reliable. But we have SMRs, and if the thing that moves talks to an ITR it will be automatically SMR'ed. When a Map-Request is sent back to that new location now, the granularity is discovered on-demand, when it needs it. You do not have to fill holes when you don't need it, it is all on-demand and it is all spec'ed in the main specs right now. --> Sriram Kotikapaludi: Are you in agreement that the first three make sense? --> Dino Farinacci: No comment. I am worried about the complexity. It is kind of overwhelming. --> Sriram Kotikapaludi: Yes, but in the last meeting Darrel had a presentation where you guys do some exceptions, inform about exception in the maps in LISP. --> Joel Halpern: Yes, there is already stuff in the specs to inform about exceptions. --> Sriram Kotikapaludi: It seems that there is agreement on the first three cases, but not on the fourth one. --> Dino Farinacci: The reason I say "no comment" is because I am worried about the solution that is complex. --> Joel Halpern: I think Sriram is asking if the conceptual problem is dealt with, and the answer is yes. It is not dealt with by encoding case numbers in the LISP reply and I do not think it needs to be dealt with in that way. But the conceptual problem is addressed already in the protocol. --> Dino Farinacci: Exactly. --> Sriram Kotikapaludi: I am not worried about the implementation at this point. --> Joel Halpern: I think, this was partially misleading in your diagrams. --> Sriram Kotikapaludi: I did that for a paper but not for LISP in particular. The intention was that if the ITR knows how many exceptions there are, it got a few of them, and after few queries if it got all of them, then it is covered fully. This was what my part was, but I do not insist that it must be necessarily done. --> Dave Meyer: I do not think that anybody can actually know how many exceptions there are. We need to do this more on demand, because we do not have any idea how EID are chopped, what the downstream does with its block. --> Joel Halpern: Usually when you allocate downstream you will be also answering. The case Sriram is hypothesizing is the case where you answer for high level aggregates, middle level aggregates, and low level aggregates, but this is a deployment question not a protocol question. --> Dave Meyer: Yes. --> Joel Halpern: And I hope it does not happen much, because EID do not need to be topologically and we should take advantage of that. --> Dave Meyer: That's the point. Right. Michael Menth presenting: draft-klein-lisp-mn-nat-traversal ---------------------------------------------------------- --> Dino Farinacci: Do you believe the problem occurs also for mobile nodes' initiated connections or only in the direction you just said? --> Michael Menth: The problem occurs when the connection is initiated from the outside world. --> Dino Farinacci: When the mobile node is a server. That's the problem statement you're going after. --> Michael Menth: When the mobile node is a phone. --> Joel Halpern: When the mobile node is a responder. It may be or may be not a server, but it is a responder. --> Dino Farinacci: Ok, it is not initiating a TCP connection. --> Jesper Skriver: Dino, I do not think it makes any difference. Because in the data plane, any data packet is sent to the same UDP port number, we are not using a socket. So the NAT router will not have a NAT translation for the returning data traffic, regardless if the node is initiating the traffic or not. --> Joel Halpern: Fair point. The two flows are essentially independent with regards to LISP. --> Dave Meyer: How does the mobile node know about the outside address of the NAT? --> Michael Menth: It does not. --> Dave Meyer: Ok. So what is the destination RLOC? --> Michael Menth: The Map Server. --> Dave Meyer: OK --> Ross Callon: Does the NAT box itself know about LISP in this case? --> Joel Halpern: No. The NAT is a complete naive NAT the works as usual. --> Michael Menth: Yes. It is completely unaware of LISP. --> Dino Farinacci: Two negative comments and one positive comment. I want to give you the positive comment first. We thought about this for a long time and we struggled that the source port of the packet would have to be well known, but you solved the problem by using 4341, and whatever is the current hashing algorithm is using the ITR, it can be still maintained and therefore we do not break lags in the core. That's wonderful! Excellent job! What I do not like is carrying private addresses in any kind of protocol payload. I think that's kind of not good. If we can put global addresses in that registration, and find it out with an out-of-band mechanism, I think that would be good. Another negative comment is that it now requires that all data packets go now through the map server box and if you have a mapping service provider that is doing only control plane services, now it has to offer data plane services as well. That's kind of nasty. --> Joel Halpern: It changes the scaling properties of the architecture, which is an unfortunate consequence. --> Michael Menth: Answering your second comment, this private address, which is in the payload it's not really used. It is just used for comparison but is nowhere stored. So this is data just for comparison but not for use. --> Dino Farinacci: Private addresses have the same problem as link local addresses in IPv6. People looking at these addresses cannot make any sense out of them, because of this local allocation that does not have any topological significance. If you want to go and get your global address by using ICE or STUN techniques you can get around that. --> Joel Halpern: What he is substantially doing is a subset of ICE, on the map server. And in ICE exchanges do carry the private address in the body. --> Dino Farinacci: No you do not have to because the private address is the source address of the packet you emit and the NAT is going to translate it to a global address. As long as that global address can go back, subsequent control packets can contain the global address, not the private address. --> Joel Halpern: I think you are asking a different question that should be explored more. --> Dino Farinacci: Does this work include the case when a LISP mobile node moves to a LISP site behind a NAT? --> Michael Menth: We did not think about this case. --> Joel Halpern: Most of this discussion has to take place after we make real progress on the core documents and got those done and work with Jari on the charter. In general, the question whether we are going to work on mobility needs to be addressed fairly in discussion with all the other folks who deal with mobility. We wanted just to give you the opportunity and I appreciate your work, to get people to know that you were working on this. We will not spend more working group time refining this at this stage of the effort. --> Gaetan Feige: Following Dino's comment. This brings together the data plane and the control plane, at some point. It would be interesting to keep them separated. Maybe it is just an implementation issue, but architecturally I would maintain the control plane and the data plane separation. --> Michael Menth: it is not required that the NAT traversal router which relays the traffic is the same box as the map server. Logically these are different functions that can be implemented in different boxes so there is no need to have them in one box. --> Jesper Skriver: But in your proposal only the Map Server has the sufficient information to actually respond to a Map Request and you cannot split them. Because the map server would not know anymore the port number and the NAT traversal router is not in the position to respond to a Map Request. --> Michael Menth: We should think about it. --> Luigi Iannone: I wonder if there is any risk in the fact that you are sending a message saying "my new RLOC is 10.0.0.1" but actually the source address is different, can open the possibility to spoofing. Are you sure the guy that is sending you the message is allowed to do so? Is the EID really behind that address? May be is something you should look at. --> Michael Menth: We did not look at it. Let's talk about it later. --> Jesper Skriver: Luigi, I think it is already the case today, because the source address of the Map Register message does not have to be in the locator set and authentication for Map Register messages exists: the SHA1 authentication. --> Luigi Iannone: Sure. But this is a mobile scenario, we need to enforce the authentication mechanism in order to be sure, when you receive a message, that it is not a spoof but it is the same guy that moved. Reusing the existing mechanism is just fine. --> Jesper Skriver: We obviously should not bypass existing authentication. --> Joel Halpern: There is also the interesting case that somebody else is changing the responses, as this Map Server is, and you got extensively authenticated information. At the moment, the content is not authenticated, but if we ever start doing so we start having mismatching set of requirements. Then we start to have something interesting, that is one of the reasons why mobility is for later. ---------------------------------------------------------------- Terry Manderson: We are done. See you in Beijing!