Agenda bashing: ------------- Note Well and Blue Sheets. Jabber scriber: Carlos Martinez Terry Manderson => Any last minute change to the agenda? Darrel Lewis => I will present draft-ietf-lisp-mib instead of Moreno. Terry Manderson => We have a change on draft-ietf-lisp-threats as well. Damien Saucez presenting instead of Luigi Iannone. Status reports on the Working Group Documents =============================== Terry Manderson => There are 7 drafts going through Last Call. It was an extended last call with a lot of feedback. Write-ups have been done. Joel and myself are reviewing the write-ups and we will send them to Jari very shortly for IESG processing. Darrel Lewis presenting: draft-ietf-lisp-mib ------------------------------------ Darrel: Lots of updates in the last version No specific comments from the WG. Luigi Iannone presenting: draft-ietf-lisp-eid-block ----------------------------------------- Dino Farinacci => Do you recommend implementations to check for /12 or /16? Luigi Iannone => /16. Dino Farinacci => Better not commit to other parts of the block. Reserve it for LISP use not specifically for EID use. Terry Manderson => Clear question about /12. Any comments from the WG? Jari Arkko => The hard-coding part in the draft is currently using RECOMMENDED, while I wonder whether it should be a MUST instead. Darrel Lewis => The benefit on an ITR for this is based on the fact that an ITR has to do two things: decide whether or not the packet should be potentially encapsulated and in this case ask a Map-Resolver for the mapping. Hard-coding it seems to be a benefit for the ITR while not hard-coding makes the ITR do more work. I do not know if MUST is really important because it is an optimization rather than a requirement. Jari Arkko => Given that this is an experimental allocation where size might change and all that, we should prepare to the fact that this can be a different prefix in the future. Now if you're saying that if your implementation uses the wrong prefix but things are still fine just a little slower, that is fine. Not if it is the case that things actually break. I do not think that typical implementations will suffer with the requirement that you must be able to configure it. My take would be MUST but anyway it is up to the WG to decide. Jari Arkko => back to this size thing (since size matters! :) From past experience, we did the ORCHID for HIP and there are a couple of differences here. First of all, in ORCHID they use a /28, while here we ask to allocate a /12 and actually use a /16. Secondly, in that RFC there is an extensive explanation on why a particular size is needed. That is missing in this draft. To bring the document to the IESG, I think it should be written down. In particular the two levels, what is actually reserved (/12) and what is actually used in the implementation (/16). It seems also that we can go a bit longer. Still reserve the /12 but use something longer for what is used in the implementation. Thirdly, the other document had a timeout, in 2014, IANA will reclaim the space unless the IETF takes action. That would be also appropriate for the next experimental spec. Luigi Iannone => There are strong similarities between the two documents. The ORCHID rfc also asks IAN to reserve a bigger block. It is also true that in that document there is a longer explanation in why and how to use the prefix but this comes because associated to the address space there was a particular encoding of the addresses, which we do not have here. Jari Arkko => The rationale was related to the cryptographic strength of the hash. Here is completely different but there is still a rationale why people want this specific size. It comes from a calculation that should be visible (needs to be in the document) to justify the size. Luigi Iannone => I do not think there is a specific calculation in the WG. I can provide something, but the /16 was the outcome of the WG decision in the last meeting. Jari Arkko => My main point is that we need an explanation for the /16. It is not hard to do it and we need it because otherwise we have no idea whether /16 is enough or it is too much. Terry Manderson => Let's take it to the mailing list after revision if Luigi agrees to add text for a more solid rationale as to the prefix length. Then we will do a consensus call on the text. Is it ok for you Jari? Jari Arkko => Yes. Terry Manderson => For you Luigi? Luigi Iannone => Yes. Vina Ermagan presenting: draft-ietf-lisp-sec-00 --------------------------------------- On question by Terry Manderson about 10 people have read the draft. No specific comments from the WG. Damien Saucez presenting: draft-ietf-lisp-threats-00 ------------------------------------------- Dino Farinacci => Did you find any threat in lisp-sec? Damien Saucez => We did not look at that yet, but it might be. Dino Farinacci => On the cache overflow issue with positive or negative Map-Replies the text in the draft is misleading. The current text seems to imply that the ITR may receive unsolicited Map-Replies and fill up the cache that way. If you just say solicited, that would make a more accurate statement. Just state: either positive or negative mappings that have been solicited by the ITR. Damien Saucez => OK. Terry Manderson => Any comment concerning the issue of cache management that has been discussed on the mailinglist. Darrel Lewis => The negative cache entries highlight the overflow issue, but this is an issue common to any caching system in any technology. Capacity and classification is the only two ways we have to tackle the problem. Is good that we identified the problem and that we encourage the implementers to come up with clever ways to manage the cache. Damien Saucez => Yes, but for the moment in the specs there is no discussion on this. Only in the threats document we say that there is an issue with attacks, but it is more than just attacks. May be it can be discussed just in the deployment draft, because may be it can be solved just with some tricks or deployment solutions. Alia Atlas => I think it is an important problem. The discussion about the cache is keep coming over and over again and we says that can be solved by implementation tricks. If this is the case, that there are implementation tricks that solve the problem let's document at least some of them, or document pieces of solutions and approaches, so that we are sure is not going to fall over when it is deployed in a non-lab setting. The problem of cache trashing attacks is there and cannot be ignored in a security threats document, even if the solution is elsewhere and clearly stated in the draft. Any approach or piece of experimental solution should be documented. Terry Manderson => Do you think this would be a good topic for the deployment draft? Or should we create another draft that directly addresses this specific problem? Dino Farinacci => I would suggest we have an interoperability test and document all the implementations and how they do cache management. Damien Saucez => May be is more than that because we can describe the different implementations but there is no abstraction on what could happen. Dino Farinacci => We can put the main experimental current practices and may be put them in the main spec after experimentation. Rather than put a lot of possible solutions. In that case a new implementer can take all of them, build a complex implementation, which does not interoperate. So it is an implementation interoperability issue. Luigi Iannone => Agree with Dino. It is not clear to me what we should exactly document, because the cache management is not specified anywhere, and I like this way because any new implementer can come up with new ways to manage the cache. We can give some requirements stating that there are some threats, documented in this draft, and the cache management has to deal with and minimize impact. All this discussion is not new, since we use cache we know that there can be this problem, the fact that it can be done by using negative mapping is just a vector of attack, nothing more and in my opinion it is already documented in the threat draft. We can add text stating that cache trashing can be triggered in this way. We discussed the same problem in the past and each time we concluded that we do not sufficient experience to say what we should do. This is the reason why I agree with Dino that interoperability tests will allow us to go further on this topic. Jari Arkko => This is an important issue that should not be hidden in a footnote or something. We should be clear about it. We do not know if this will go to make the system failover in the open Internet. We can say that or we can point to some guidance on how to solve the problem. And if we do it, this should be fairly upfront in one of the main document or security document. I do not think we need to solve all problems but we have to be open about there being problems. Luigi Iannone => I was not saying that we should hide anything. I was only suggesting that we do not need to be too much alarmist. John Scudder => I paraphrase what Dino said and correct me if I get it right or wrong: we should specify something but we are not ready to write down and specs because we do not know what it is, so let's have a placeholder. Is that accurate? Dino Farinacci => I think we should do interoperability testing to find out how different people think to solve the caching problem and document it. John Scudder => So I would agree with the other speakers who have said that this needs to be captured in the specs. I do not have a solution so am not going to propose what should go in to the specs, but having a placeholder saying "example of solutions" would be good. The reason for that, like Alia pointed to you, is that if you want to talk about this as being a significant problem it is a very difficult discussion if the answer is that this is an implementation detail. Once you have at least one example of something that solves the problem than there is more to discuss about. So I think that it does need to be documented in whatever form we are able to. Joel Halpern => I am confused on what people want to be added. There is already text in the base lisp document that says this is an issue: that maintenance of caches is an issue. We are not pretending there is no issue. I cannot even figure out what to ask to the authors to write more in the current document. We may come up with something more but there is already text, we added text to respond to issues that were brought up on the list when we did not have enough text to deal with it. Maybe we're still missingÉ I am now puzzled because looking at the base document and the threats document talking about the security aspects, the fundamental problem is identified and I do not know there is more we need in the fundamentals. But I hear people asking for more in the base document and that's where I am confused. Jeff Hass => If there is negative mappings or any other overflow caching state, the simple solution is to have that box cut-off connectivity so that entries expire. In other words if you cause problems to the network you will be cut-off the network and stopping the problem. Joel Halpern => That is certainly an implementation that could be considered, but I certainly would not call that as the recommended one at this stage of the game. Jari Arkko => To answer to Joel's question about what is that we need to do more and responding from my personal perspective: if the main specs already says that this is an open issue that's fine. Then we can select any document, now or later, to try to workout the problem. I have not looked at the most recent version of the spec stating the problem, there might be some fine tuning of the text but fundamentally that's fine. Terry Manderson => I think what we are leading to is that we need some specific document about the cache management problem. I do not think it needs to belong to the main specs. I think another document will be created, I will be happy to see people coming talk to me about willing to author/co-author such a document based on current implementations. Jari Arkko => Clarifying question. Does the main spec says that there is a solution and is an implementation detail or does it says that this is an issue that we have not solved and there is a potential problem? Dino Farinacci => There has been 5 tracker items about cache that have been all addressed. Joel Halpern => Give that the ITR/PITR maintain a cache of EID-to-RLOC mappings, cache sizing and maintenance is an issue that has to be kept in mind during implementation. We do not currently think it is a protocol issue. That is what is said in the document, that it is a problem and implementation and experimentation will be used to understand which cache management strategy works best. Document also says: It should be noted that an undersized cache in an ITR/PTR not only causes adverse affect on the site or region they support, but may also cause increased Map-Request load on the mapping system. I have no problem to have another document if we have more to say, I was trying to separate what work should be done later and if there is a problem now that we need to fix. Alia Atlas => What is in the document I think is good. But a concern: there is a difference between saying to be careful in the way you implement your cache and saying that there is a trivial attack that will break the cache and we don't have no clear way to solve it. What I would like to see is in the threats doc some examples of trivial attacks that will break the cache and then in another document, if believed appropriate, the solutions that are believed to be good enough. Maybe we can solve it with cache management solution and the interop document will show that, otherwise let's be open to other kind of solution that are out there to solve this kind of attacks. Joel Halpern => Let me paraphrase because what I heard sound very reasonable. a) In the threats doc, we should put a little more attention on this. b) We should put as WG item a new document that addresses what is the right answer to this problem is. Alia Atlas => What the minimum answer to the problem is. Joel Halpern => OK. John Scudder => You said almost everything that I wanted to say. One exemplary solution would be enough. Joel Halpern => There is a very weak one in the base document and it says is a weak one. Luigi Iannone => Concerning the documentation of the different ways of attacks, I do not think is completely a good idea. It really depends on how much into details we go because it is useless to document N number of different attacks. One can come in one month with a new type of the same attack, what should we do then, document that as well? Maybe it is right to add more text in the current draft but I would not go too much into details. Joel Halpern => We need enough details that allows folks to understand the kind of attack and the kind of issue that attack causes. We do not need to list every possible way to induce cache trashing. We need to describe the general class of attack and its consequences. Damien Saucez => I think it is already in the threat document. Joel Halpern => May be we need to extent it a little bit. Alia Atlas => I did not read the draft in details but there is no cache trashing in the TOC as attack vector. Damien Saucez => Yes. Dino Farinacci => Let's think about BGP for a second. If I give a BGP update and I try to do a malloc to store the prefix that is in the update and it fails, what do I do? Does BGP say what you do? If it does not, should we be at the same coarse description like BGP? Or if BGP does say what to do let's look at the level of details in BGP and do the same thing. Comments? Dino Farinacci => this is supposed to stop the thread! :) John Scudder => I would be happy to give you 5 minutes in the IDR WG agenda to talk about what BGP should do, but this is the LISP WG. Dino Farinacci => I am asking what BGP does. Joel Halpern => Enough. I think we have an agreement on how to proceed in this context and that's what e need. Darrel Lewis presenting: draft-ietf-lisp-deployment-01: ---------------------------------------------- No specific comments from the WG. Joel Halpern => How close you think we are from going last call with this draft? Darrel Lewis => I have to discuss this with the other co-authors. Open Discussion for Rechartering -------------------------- Terry Manderson => No draft charter yet because we want to see a discussion first! John Scudder => I think we discussed one charter item during the security part, which Joel summarized pretty well. Luigi Iannone => I agree with John. We discussed several things to work on concerning security. Also, we should consolidate the experimental part and the experience that we have before going any further. Terry Manderson => There seems to be no will to change the charter scope in any way or form but simply add WG items to support the existing charter. Joel and myself will write something and send it on the mailing list to have an open discussion. Short and sweet! Done