Agenda bashing:

--------------



Darrel Lewis => Victor Moreno could not make it and we do not have a

copy of the slides, so I suggest crossing that off. 



Terry Manderson => So, no lisp-mib presentation.





Working Group Documents

=======================





Dino Farinacci presenting: draft-ietf-lisp

------------------------------------------



Dino Farinacci => Probably we will issue a new version before last

 call, to fix mainly editorial issues. We have already seven changes

 that need to go in.



Joel Halpern => Any further editorial issue will be included in the

 next version and we will make sure that the working group sees

 them. The chairs very much appreciate Dino's efforts.



Dino Farinacci => (on the final slide of the presentation) We ask for

 WG Last Call for the main set of drafts (ietf-lisp,

 ietf-lisp-multicast, ietf-lisp-alt, ietf-lisp-interworking,

 ietf-lisp-ms, ietf-lisp-lig).



Joel Halpern => The chairs went through all of the comments in the

 tracker. We are trying to make sure that they can all be closed or

 deferred, since sometimes they are no issue now and we can deal with

 them later or they just belong to a different document. 
 We hope to get all of these documents, may be not these versions, in 
 the Last Call in the very near future. We hope people will re-read 
 them and comment. I hope there will be very few problems because we 
 went over the documents thoroughly. We are pretty happy with the 
 state of the documents even if there are still few issues, but most 
 of them are solved. 







Luigi Iannone presenting draft-ietf-lisp-map-versioning

-------------------------------------------------------



Luigi Iannone => The only remaining open question from the last

 meeting is whether should we keep the security considerations section in

 this draft or should be centralized in the draft-saucez-lisp-security

 document, even if it is still an individual submission?



Terry Manderson => Questions or comments or discussion on whether the

 security consideration should go in the security draft?



Darrel Lewis => I think security considerations for versioning should

 be kept in the versioning document. It looks more coherent.



Terry Manderson => Any other comments on that? I would like to bring 
 the discussion on the mailing list to hear comments from  people that 
 are not here today. 









Individual submissions

======================





Albert Cabellos presenting draft-jakab-lisp-deployment

------------------------------------------------------



Darrel Lewis: One of the things that came up at the last meeting was

 that there is an issue concerning prefixes in the ALT and the DFZ,

 messing up with SIDR. We are discussing the issue and we did not make

 for this version of the draft, but hopefully we will make it for

 version -03. We will talk about practical way for generating EID

 space that does not rely just on raw cross vrf distribution.



Jari Arkko => I have a question concerning your third model, which I

 do not fully understand. I was trying to look at clarification in the

 draft but I did not find any either. You are saying that there is an

 issue with not global coverage of announced prefixes and I did not

 get that. The tier-1 ISP is not announcing the EID aggregate in the 
 global BGP network? 



Albert Cabellos => That is why I put a second item. The announcements

 are downstream, so they are not going to the DFZ. This way a legacy

 site can reach the LISP site through the Proxy-ITR, as shown in the

 figure. But it seems there is an issue with no global coverage, which 
 is why I said this will probably work either with the first or the 
 second one.



Darrel Lewis => Let me help clarifying this. In this example, the

 Tier-1 would advertise the EID to its customers but not its peers. So,

 if one of its peers is another Tier-1, it would not see the

 announcements. So there has to be another origin, one of the other two

 mechanisms, to get that to other parts of the network.



Jari Arkko => I sort of understand it, but I do not understand

 why. What is the benefit in advertising just to your customers?



Albert Cabellos => The Proxy ITR is on path.



Darrel Lewis => The benefit we have heard of, from people looking at

 this, is that they fill up the pipes to their customers. If the

 customers are multi-homed with them and another Tier-1 that does not

 have a Proxy-ITR, all the LISP traffic goes through them so they fill

 the pipes and derive revenue. So it is an incentive to fill pipes.



Jari Arkko => I think I need to think more about this, but I think I

 understand now.



Dino Farinacci => Let me try. We are trying to get packets to the

 Proxy-ITR, so that they can be encapsulated to LISP sites and we want

 to be on the shortest data-path. But we do not want to advertise

 these EID prefixes everywhere, so we want to mitigate the amount of

 EID prefixes that are in the total network. 



Joel Halpern => A comment about this draft: as you see at the moment

 it is an individual contribution but we are expecting to call for

 adoption in the very near future. We want to give the working group a

 chance to comment on it, and there are some items the authors know

 they need to clarify. Jari, have a look at the text version of this

 not just the slides, to see if we need to add clarification. 



Jari Arkko => I have.



Joel Halpern => Because no long after that, when we will go for all of 

 the working group documents to last call, we will try to get this to

 last call as well. We will push the timeframe for this one. It is

 very important for folks in understanding the overall LISP

 picture. This has been started later, but is a very important

 document and working with the authors and the working group we will

 try to get out this one with all the rest.









Luigi Iannone presenting draft-meyer-lisp-eid-block

---------------------------------------------------



Terry Manderson => Microphone open to the floor. Is a /16 what we want?



Terry Manderson => Silence...



Terry Manderson => Does anyone have any comment? Should we make the

 effort to go to IANA and having a prefix allocated for this purpose?

 There was some agreement in Beijing and quite some discussion on the

 mailing list towards it. Now we have the ID, again comes the same
 question.



Joel Halpern => Maybe we are asking the question in the wrong order. I 
 want a "Humm" if folks think we should get an IPv6 prefix for whatever 
 size, we will come to that in a minute. As working group, should we ask 
 IANA for a prefix in IPv6 for EIDs?



Jari Arkko => I was just looking at the document, it is basically

 asking for a "/" something and it does not have that much background

 or explains the trade-offs that are involved. One of the trade-offs

 is that the less you ask, the shorter the discussion will be. There

 should be some kind of justification. Do we have a document that

 explains to IANA and the rest of the IETF why do we need this? And

 why has to be of a certain size?



Joel Halpern => There is a big difference between the size issue and

 "why we need it" issue. That's why I am trying to ask the questions in

 the right order.



Jari Arkko => I do not think there is any issue in asking for a block. 
 But if we go up in the size there will be some discussion. This is my 
 only concern.



Joel Halpern => We will get to the size issue in a minute, but we want

 to have an answer from the room. Do folks want that we go ask for a

 block? 



Hum from the room.




Joel Halpern => There are folks that think this is a bad idea?



Silence in the room.




Joel Halpern => Ok, silence. Does anyone wants to come up to the

 microphone to express a preference whether do we need a /12, a /16?

 What size should we be asking for? 



Jari Arkko => Any size will do.



Erik Nordmark => Let me ask a question first: is this something like 
 a protocol constant that will be hard-coded or is something that can

 change over time if it turns out that we need more?



Joel Halpern => It definitely can be changed. Presumably, there will

 be implications, since code will use it as shortcut for things that

 match this block of well-known EIDs. If we extend it things get more 
 complicated for implementations. If we really really know for sure 
 that we are going to use only this we will get to this only during an 
 experiment.



Erik Nordmark => Yes. You can ask for something small if you have very

 small mechanism of changing so to distribute something bigger

 overtime.



Jesper Skriver => I would say: let's start with something reasonably

 sized, get experience with it. If this takes off and we run out of

 space, then we get a second block. That will be bigger and we will 
 have two blocks. And while it takes off we can have five block, which 
 from a protocol behavior point of view is much better than five 
 millions. I would say, let's start with something small that we can

 get without too much effort and move on.



Terry Manderson => If I can paraphrase what you are saying is: get one

 block, but in the considerations section request IANA to have room

 after that block for contiguous space.



Jesper Skriver => Yes for something twice of four times as big, assuming 
 we can prove we can need it later.



Darrel Lewis => Just wanted to point out that the beta network that we

 are running, with multiple implementations participating right now,

 actually got a /32 from ARIN that we are using as experimental and

 paying onerous fees for. That has been useful in terms of numbering

 sites for experimentation purposes. But because is transitory, we have

 not been able to actually see any value in putting in the implementations 
 themselves an a priori that this is an EID and more importantly when it 
 is outside this block, when it is to an EID, so we do not even need to 
 make a lookup for non-LISP transiting traffic. This is just some 
 deployment experience we had.



Dino Farinacci => Your point about the contiguous blocks is important

 because all we have to do is not generating a new advertisement from

 the Proxy-ITR. All we have to do is shorten the mask length.



Terry Manderson => With that, we still did not hear any number or a 
 starting number, we understand there is growth there, but where you want 
 to start? 



Joel Halpern => /16?



Dino Farinacci => yes.



Terry Manderson => Can I have a hum for /16?



Hum from the room.



Terry Manderson => Can I have a hum for something not a /16?



Jari Arkko => Which direction?



Terry Manderson => Does not matter.



Darrel Lewis => Yes it does because certain thing are so long that

 are not routable. I just want to point out that the /32 that we have

 is probably too short, because you cannot divide it usefully and still

 having something routable.



Joel Halpern => Sounds like we should go for a /16. The most positive

 response were for /16 so that is what we will go for in the document.



Terry Manderson => Since to go on we need to adopt this as working

 group document, can I have a hum from people that wish to have this

 adopted as working group item?



Hum from the room




Terry Manderson => And a hum from people do not want to see this as

 working group item.



Silence in the room.




Terry Manderson => We will take this to the mailing list for further

 clarifications. 



Jari Arkko => Sorry am a bit late in this. I was browsing some old 
 documents and the HIP-ORCHID prefix is a /28, just for past reference 
 on what has been done easily. We can probably go shorter than that. I 
 would probably prefer something longer than a /16 to start with.



Terry Manderson => I think we will end up taking this as well, for a

 final run, because it will go in a working group document and a

 working group discussion on the prefix length. Is not set in stone 
 yet.



Jari Arkko => I do not have a big concern about that. My main desire is 
 to make this document fly through and not get stuck in some discussion

 where some people think we're grabbing too much.







Luigi Iannone presenting draft-saucez-lisp-security

---------------------------------------------------





Jesper Skriver => On slide 3, for the check on the destination EID, I do

 not see why you need to do anything, because the Proxy-ITR should

 receive the traffic only if it originated the route for it. So just

 make sure you do not originate routes for anything you are not a

 Proxy-ITR for. So that if you do not originate the route, you do not

 receive the traffic, there is nothing to check.



Luigi Iannone => Yes, you are absolutely right. But you still can have

 unwanted traffic for whatever reason.



Jesper Skriver => Yes, but the Proxy-ITR does not receive any traffic

 unless it originates a route for it, so it does not have regular

 customers attached to it.



Darrel Lewis => The interworking draft does not prevent the customers

 from doing something non-optimal like also announcing a default route

 for that box. It is a bad idea but there is no reason that it could not
 happen in the real world.



Jesper Skriver => But if you are a Proxy-ITR only for EID address

 space A and for whatever reason you receive a packet that goes to EID

 address space B, then you should not drop it. Just the fact you are

 not a Proxy-ITR for it does not mean the packet should not be

 delivered via some other Proxy-ITRs somewhere else in the Internet.



Luigi Iannone => Someone else, so you should not receive the packet in

 first place. And what you are saying is, correct me if am wrong, that 
 if everything works correctly, as specified in the various documents, 
 we do not have any issue and I agree. But security is about something 
 going wrong or somebody doing nasty stuff. So I do not see any harm in 
 using such filtering policy.



Jesper Skriver => As long as you make sure that you do not drop legitimate 
 traffic.  



Luigi Iannone => Absolutely right.



Joel Halpern => Let's see if I got your question. Imagine you have a

 Proxy-ITR advertising some block, if it receives something for that

 block it encapsulates it. If it is also a  router in the network, with

 somebody else somewhere is advertising some other EID block because is

 also a Proxy-ITR and this Proxy-ITR happens to be in the middle. So it

 can receive packets for a certain EID for which it is not the Proxy-ITR, 
 so better it does not drop those packets, it better does not encapsulate 
 those packets, it better just forward those packets in the data-plane 
 because somebody else is advertising a route for them. You do not drop 
 the packet just because is for an EID you are not responsible for. You 
 drop it if it is for EID you do not have a route for.



Luigi Iannone => I see, I fully agree with this scenario.



Joel Halpern => You start to touch on the question am about to ask you:
 what is the relationship between this document and the document we are 
 going to see next (draft-maino-lisp-sec) which is also a document about 
 security, analysis and mechanisms, so it seems there is a conceptual 
 overlap.



Luigi Iannone => I disagree on this. Actually, I think they complement 
 each other perfectly. Because this is an analysis and the other one is 
 presenting a solution.



Fabio Maino => Exactly. We tried to keep all the security analysis out

 of the solution proposed. This is the threat model we are referring

 to. We are addressing all of the threats they describe, but we address

 all of the threats we believe are important at this point. So, I agree

 with Luigi. We need to identify data-plane and control-plane issues

 and make a clean distinction so that we can address them with different

 documents or at least make clear the scope of them.



Joel Halpern => It sounds like you are asking for a last call for

 adoption by the working group. I do not think we are going to get the

 main spec on this, but we can adopt it as working group item to

 continue advancing it and continue completing the analysis. As a

 complementary item we will look to adopt, assuming folks are

 interested,  the solution proposed in the draft-main-lisp-sec as a

 separate matter, keeping the analysis separate from the proposals. 



Fabio Maino => I agree. Maybe it would be good to change the name of

 this document because is a bit confusing since it says lisp-security. 
 This is a lisp threat model or threat analysis. That may help and avoid 
 the confusion. 



Luigi Iannone => Agree. 




Terry Manderson => Any further comments?



No one in the room.



Terry Manderson => So to get this right you are asking for adoption by

 the working group.



Luigi Iannone => Yes.



Terry Manderson => May I have a hum from people that wish to see this

 adopted.



Hum from the room.




Terry Manderson => May I have a hum from people do not wish to see

 this adopted.



Silence in the room. 



Terry Manderson: Silence. Thanks.









Fabio Maino presenting draft-maino-lisp-sec

-------------------------------------------



Dino Farinacci => The Map-Server in Proxy mode is an important

 feature, since we do not have to use crypto on mobile phones saving

 battery life.



Joel Halpern => Clarifying question: I like very much this work. You are 
 not protecting against all over-claiming attacks. In particular if the 
 Map-Server is collaborating in the attack or if the ETR is the Map-Server 
 and is participating fully in the ALT, then it can claim almost anything 
 because the protection does not deal with that. We do not want to require 
 a RPKI at this time. We may look at that. We need to be clear in the 
 exposition on the scope of the mechanism. You are covering a large number 
 of the threats but I just do not want people thinking that you are taking 
 care of all of the problems. 



Fabio Maino => Yes. I think we already received a couple of comments,

 I think one was from you, that the language in the draft is inducing

 to think in that way. So we need to address that language and make

 sure that we are protecting against over-claiming attacks that are

 mounted by the ETR when is not co-located with the Map-Server. 



Erik Nordmark => This is very good work! What actually happens if RPKI

 is deployed for the ALT subsystem? Do we still have holes? Because

 RPKI can potentially verify the whole delegation chain down to a 
 relatively small EID prefix. We can glue these together somehow.



Fabio Maino => That is some work left. Up to you to decide whether it

 is for the working group or not. The assumption we are doing is that

 there is a way to trust the mapping system and clearly RPKI is very

 likely one possibility. Maybe there are other solutions, but possibly 
 this is the first thing I would look at. Maybe is simple maybe not, but 
 this is the working model we were assuming here. If you want to deal 
 with EID authorization then you have to think about SIDR and RPKI, 
 because you want to have a way to verify if a Map-Server is authorized 
 to claim a given EID-prefix.



Erik Nordmark => Particularly that system might say: this Mapping-Server

 can claim a /16 but when the packet actually arrives to that Map-Server 
 it can claim something bigger that it will sign with this mechanism and 
 pass it back. There is no coupling that I can see between these two 
 things that I can see. 



Fabio Maino => Exactly. This is part of the things that are under

 investigation. Clearly RPKI can secure the ALT because it is deigned 
 for that purpose. How that ties with what the ITR is doing? That is why

 we want to keep it separate because this is a simple mechanism. 



Joel Halpern: It will take some investigation but it may be able to

 tie the RPKI certificates in the ITR/ETR exchange. So that the ITR is

 able to verify if the ETR was allowed to claim that. Then we will have

 complete coverage when coupled with this. Exactly how to use the

 RPKI I do not know but I think it will be very useful. But let's keep

 with one step at a time.



Fabio Maino => This is exactly the spirit of this work.



Dino Farinacci => On the point when an ETR is connected to the ALT, we

 as a working group, should decide whether we want to discourage

 that. Architecturally we can do it, but should we make a clear

 statement in the deployment draft that ETR should be Map-Server

 connected to the mapping system?



Joel Halpern => Is an interesting question how we want to word that in

 the deployment document. I would not burden this with a requirement,

 but I think as long as we are clear here we can deal with that
 separately, because it is a logical vs. real entity issues.



Darrel Lewis => I think that the issues are kind of separate. Because, 
 I agree that we should not have ETRs directly connected to the ALT, 
 but if you still co-locate an ETR with a Map-Server you still have the 
 potential of one compromised box to compromise the separation of trust 
 that provides some security.



Wolfgang  => In the BGP space, if you want to propagate PI prefixes

 you have to have a RIPE route object. You need permission from RIPE

 and your upstream provider has to double check against the RIPE

 database whether your route object is there. So why you do not

 introduce something like this as security mechanism?



Fabio Maino => Yes. That would certainly be a mechanism that you may

 want to use to secure the ALT. It is orthogonal to what we are trying

 to do here. 



Terry Manderson => Just to clarify the answer: one of the reasons

 why you do not use something like the RIRs to secure the routing

 infrastructure is that there is no cryptographic model in the route

 registry. It does not provide path validation either. What you get is

 a fuzzy statement that you are in a prefix and you are the right

 person going to propagate that prefix on behalf of.



Dino Farinacci => Joel made a suggestion, about one year ago, on how

 ECMs should be sent from Map-Resolvers to Map-Servers. This is giving

 us an opportunity to exploit those ideas. 


Terry Manderson => Who read the documents?
Terry Manderson => More than two!!! 

Terry Manderson => Can I have a hum from people that would like to see

 this adopted as working group document?



Hum from the room.




Terry Manderson => Can I have a hum from people that do not want to

 see this document adopted as working group document?



Silence in the room.




Terry Manderson => Nothing. We will take it to the mailing list to

 confirm.



Fabio Maino => Any more question from the room?



Terry Manderson => It seems there are no more questions for you. This

 is the end of our agenda and the end of our session.