[00:03:33] hide.zebra joins the room [00:03:49] gigix73 joins the room [00:03:50] Wes George joins the room [00:03:52] eburger joins the room [00:04:11] jlcJohn joins the room [00:04:17] shikob joins the room [00:07:02] marshall joins the room [00:07:06] becarpenter joins the room [00:07:16] J=I am the jabber scribe [00:07:22] Fuad Abinader joins the room [00:07:27] some items from stockholm [00:07:31] Joel Halpern [00:07:37] LISP mapping isues [00:08:03] Going to try and describe his personal take on this this and his effort to decompose it [00:08:10] there are a lot of bits and peices [00:08:20] there is no way to cover all of it [00:08:34] talking about the mapping system, map resolvers and map servers [00:08:55] somehow you have to go from an EID to an RLOC [00:09:00] there is a request [00:09:03] a eply [00:09:13] a positive reply - a list of RLOCs [00:09:23] a negative reply- has several flavors [00:09:35] there are two ways of looking at this [00:09:44] neither is wrong [00:10:01] they produce different conclusions, however [00:10:09] at the center [00:10:24] should the map request sent by the ITR have one IP header or two [00:10:28] one view [00:10:40] the mapping system is a relay agent [00:10:52] its job is to relay the message [00:10:58] the map request is secondary [00:11:02] that's one way [00:11:06] the other is [00:11:50] the mapping system is responsible for finding the answer [00:12:08] a valid mapping system could do this in many ways - it could cache it [00:12:10] kazuya joins the room [00:12:17] there are differences depending on which you do [00:12:30] if it is a relay system, content can be encrypted [00:12:57] it needs a header with a EID in it to use as a relay key [00:13:42] another difference - is the map resolver / server a convenience, or an insulation layer designed to hide detals from the ITR [00:14:06] mawatari joins the room [00:14:06] as currently defined, the debate was about the format [00:14:11] of the map request message [00:14:20] as currently definted [00:14:31] there are 2 successive IP headers [00:15:03] in the alternative viewpoint, the MAP Request could be put in the "outer header" [00:15:12] where does this matter [00:15:22] ? [00:15:50] one issue is how to handle the case where you need to couple the functionality - an ITR that can directly send requests [00:15:57] abaire joins the room [00:16:01] an ETR that sends BGP information [00:16:10] two ways to described [00:16:20] this edge box can do function X [00:16:48] or you can talk about logical components, like the resolver as conceptual entities [00:17:14] an ITR which can directly send messages to the ALT routers [00:17:29] this is conceptually an ITR plus a map responder [00:17:47] Joel finds this type of decomposition to be very helpful [00:18:08] Address families - another issue [00:18:12] ho to handle [00:18:39] we have to handle v4 and v6 [00:18:45] most of this works just find [00:18:55] EIDs can be in either address family [00:18:56] etc [00:19:05] CHENGANG joins the room [00:19:11] some combinations are a little harder to deal with [00:19:22] a EID from one address family [00:19:39] the ITR is from the other [00:19:54] lots of additional questions [00:20:14] what do we need to authenticae ? [00:20:17] and how? [00:20:35] the model chosen affects this [00:20:44] maybe only the end guys needs this [00:21:18] Is there part of teh mapping structure that should be hidden from the end ? [00:21:18] shamus joins the room [00:21:34] if the ALT is a routing system [00:22:09] you do not talk about hiding the routing header [00:22:25] rhe joins the room [00:22:37] if you view it as a question answering system, the header should be hidden [00:23:18] Chair : this is supposed to spark discussion and not be a conrete proposal [00:23:58] Joel : I find that it is better to view the mapping system as a question answering system [00:24:11] so I am uncomfortable with the double header [00:24:11] Wes George leaves the room [00:24:11] shamus leaves the room [00:24:11] eburger leaves the room [00:24:11] ljakab leaves the room [00:24:11] CHENGANG leaves the room [00:24:11] jlcJohn leaves the room [00:24:11] mawatari leaves the room [00:24:11] becarpenter leaves the room [00:24:11] Fuad Abinader leaves the room [00:24:11] tachibana@jabber.org leaves the room [00:24:50] Vince Fuller : You are referrring to the interface that the mapping system sees [00:24:58] Joel : Absolutely [00:25:08] there are lots of other pieces [00:26:18] Sam Hartman : One issue - the particular format of the relay header ends up being an IP packet, that increases the complexity [00:26:37] and you can get IP headers that are not intended for yourself [00:27:00] there are exceptions but this tends to be problematic [00:27:56] Dino : When the ETR receives an encapsulated addressed the source and destination address can [00:28:14] be routed and that packet has a port that says it goes to the control plane, so it [00:28:19] takas joins the room [00:28:34] goes to the control plane and it deencapsulates it [00:28:44] I beleive that this is not an issue [00:29:24] This is all done at the control plane [00:29:51] Sam : That is true if the implementation has its IP stack tightly coupled with the LISP stack [00:30:30] Dino : In a standard UNIX ssytem any packets addressed to the right port will go to LISP system [00:31:00] Sam : You have to put the IP stack in LISP and the kernel [00:31:29] Roque Gagliano : do you mean to talk about authentication or authorization [00:31:52] Joel : The reason I was vague is that there are interesting questions under there [00:32:02] there is binding information carried in a request [00:32:41] one may want to look at what is being is asserted with what confidence - [00:32:55] I don't know how we are going to do this [00:33:26] Dino : I think I understand what you are saying - since the map request is being sent somewhere to get an answer it actually contains some mapping information [00:33:27] benno joins the room [00:33:31] that is optional [00:33:37] the PTR never supplies it [00:34:01] you may trust the source, or ignore it, or send a verifying map request back [00:34:21] Joel ; that's just one example of where the architecture affects the pieces [00:34:31] Chair : I am looking for ways to resolve thias [00:34:40] ewburger joins the room [00:35:54] roque@hiroshima joins the room [00:36:04] Dino : Maybe ALT only routers that do not speak lisp could be pulled out of the mapping structure [00:36:31] do they need to implment LISP, or just look at the destination address in the IP headder [00:36:43] we wanted to give vendors the flexbility [00:37:03] Sam : What do you mean by upstram ? ALT or ITR ? [00:37:15] shikob leaves the room [00:37:31] Dino : The path from the map resolver to the map server registered [00:37:42] Joel : to return to architecture [00:38:12] at least in my head, there could be replacements by the ALT where the system looks at the content [00:38:48] the ability to replace pieces is highly valuable [00:39:56] Regi : As a destination address, since we speak of point of view, it could be seen as an optimatization for the ALT [00:40:07] we have to use tunneling or encapsulation [00:40:38] my point of view is that we leave all of the flexibility possible for the core mapping function [00:41:13] Sam : Dino and Joel are saying that if you do it exactly the opposite ways there is more flexible in the core [00:41:22] Joel : What kind of flexibility [00:41:36] Regi : Do you want a relay system in the core [00:41:46] shikob joins the room [00:41:53] [Chair means NOT Sam] [00:41:57] inami.masaaki joins the room [00:42:07] Chair : We have to have concrete proposals to evaluate [00:42:23] Sam : Joel had an original propsal [00:42:31] Dino sent a long list of questions [00:42:41] I sat down to write them [00:42:53] I realized it was more [00:43:08] complicated as I had to write extensions to various messages [00:43:25] ljakab joins the room [00:43:34] Chair : A way forward might be to continue the development of that draft [00:43:58] shamus joins the room [00:44:06] Dino :We want the mapping system to be as easy as possible. In the ITR we have enough CPU cycles to put extra headers on./ [00:44:20] I would rather do that and keep the map resolver simple [00:44:22] Next [00:44:25] HannuF joins the room [00:44:45] mawatari joins the room [00:44:55] Wes George joins the room [00:45:32] Sam Hartman :: LISP security [00:45:46] there are a couple of different efforts underway [00:46:06] I wanted to do my work in an open forum [00:46:16] Luigi is working on another system [00:46:17] Fuad Abinader joins the room [00:46:27] Luigi - we started this on request of the chairs [00:46:37] Sam : Abslutely, and we appreciate that [00:47:06] we are not the first people to thin of the security of mapping systems [00:47:17] BCP 72 and 84 [00:47:45] RFC 4218 4225 =4219 draft-bagnulo-lisp-threat-01 [00:48:03] The mobility people and the SHIM6 people have all thought a lot about security [00:48:15] also the HIP folks [00:48:46] arifumi joins the room [00:48:49] there are basic documents for overall internet security [00:49:18] goals : In order to be successful you need an idea of the goals you would like to acheive [00:49:36] goal : LISP should not make Internet security worse [00:49:42] either in LISP or in general [00:50:18] LISP should not block IETF-wide security goals, such as encryption [00:50:31] what does it mean to make the security of the Internet worse [00:50:44] Dave Meyer : Are there more goals ? [00:51:05] I don't see deployability [00:51:38] Sam : We want LISP to be secure, deployable and to solve the routing table issues [00:51:45] we re in violent agreement [00:52:10] Scott.Brim joins the room [00:52:28] if we can't we meet these two security goals, and the other goals, we don't have a viable system. [00:52:49] if someone finds a security issue with list, some questions [00:53:01] how is this not a problem on the internet today ? [00:53:02] Scott.Brim leaves the room [00:53:12] Wat are the consequences of the attack [00:53:46] what is the previous IETF thinking on this problem ? [00:54:00] Sam : Are these reasonable goals ? [00:54:23] Wes George leaves the room: Replaced by new connection [00:54:43] show of hands - good showing for "reasonable set of goals" no one for "not" [00:54:53] security goals of teh control plane [00:55:26] the control plane's primary job is to maintain mapping integrity [00:55:39] protection against being used as a DOS tool [00:55:50] limit scope of replays [00:56:17] right now, there is a distinction between people on path, and people off path [00:56:37] or if i can become part of your address block [00:56:47] so the mapping system must prevent this \ [00:57:01] at least to the degree the Internet does this today [00:57:05] there is more on the wiki [00:57:36] Jari :integrity could be defined in many ways [00:58:09] Sam : It is ultimately a question of "do you have the right answer" [00:58:46] people shouldn't be able to pretend to be you, or at least no too much [00:59:21] Roque ; You said to limit scope of replays - do you mean,say, no worse than DNSSEC [01:00:02] Sam : DNSSEC is not a vulnerability of the routing architecture [01:00:37] End to end cryptography is not the total solution [01:00:41] abaire leaves the room [01:00:44] anthony.baire joins the room [01:00:55] ietfdbh joins the room [01:01:06] we have found that offloading this functionality is useful [01:01:40] it's going to take a long time to specify and deploy cyrpto [01:01:47] cryptography [01:02:00] we want to run experiments today [01:02:34] Dave Meyer : I was reading "we was sufficient security for our experiments" [01:02:54] I don't kn ow what sufficient or experiment means [01:03:46] Sam : there are things in place to prevent me from stealing your address today [01:04:03] Dave : Are we talking about things like MD5 on BGP today ? [01:04:39] Sam : An example, the NONCEs in the map request makes LISP more secure [01:05:14] Chair : What we are trying to get at here is that we don't want security in LISP so poor that no one wants to try it [01:05:16] Scott.Brim joins the room [01:05:37] Sam : My hope is that we can get LISP to be as secure as the Internet is today [01:06:07] Joe Touch : Is there some reason you believe that the security in LISP has to be stronger than ARP ? [01:06:32] Sam : There are environments where the security of ARP is inappropriate [01:06:55] Also, I cannot spoof you on ARP if I am not on your link [01:07:06] Layers of Security [01:07:23] IRT -.> Map Resolver [01:07:37] Jari : On the previous slide [01:08:15] I want to understand why it has to be better than the Intenret [01:08:44] Sam : I believe that eventually that there will be end to end signatures for mapping [01:08:54] but that is out of scope for this WG [01:09:28] Many people say, all we have to do is sign it end to end, and I don't buy it [01:09:33] becarpenter joins the room [01:09:49] Jari : And that has to be the case even for experiemtns [01:09:53] Sam : Right [01:10:02] Layers of Securty [01:10:25] ITR -> map resolver [01:10:29] mapping core [01:10:34] map server to ETR [01:10:40] ETR to ITR [01:13:27] Chair : Today in the mapping system of BGP is not signed [01:13:37] Sam : We have an effort today to get signed BGP [01:13:43] its an on going effort [01:13:48] for BGP [01:14:06] I don't think we need to move faster than that [01:14:19] but I hope we can't move slower than IPSEC [01:14:35] Wes George : If this is an overall framework [01:14:56] there are two options - a lightweight and a heavy option [01:14:58] Sam : Yes [01:15:17] [Marshall : Can someone put the address of the wiki here on jabber ?] [01:15:44] http://tools.ietf.org/wg/lisp/trac/wiki/Security01 [01:15:49] Margaret Wasserman : I just wanted to comment on the discussion on the mop system [01:15:56] [thanks - for remote attendees] [01:17:16] Margaret : There are things that are not the same - BGP is not like LISP, it is more bilateral, etc. [01:17:50] Roque : There are signed objects today. I need some guidance on the non converged efforts [01:18:15] Sam : A sample attack [01:18:26] Map reply delegation integrity [01:18:36] potential attack [01:18:54] The ITR sends a map request [01:19:05] the ETR responds directly to the ITR [01:19:36] the ETR lies about how large its prefix is. Suppose it claims 0::0/0 [01:19:51] instread of the /24 it has [01:20:05] or a /22 or a /16 [01:20:13] how do you verify this ? [01:20:45] the NONCE means that the right ETR is responding but you don't know if you can trust it [01:21:00] Why is this worse than what we have today ? [01:21:35] An attacker could potentially become on path for any victim [01:21:41] there are means to prevent this today [01:22:07] inami.masaaki leaves the room [01:22:08] consequences also include hijacking a long chunk of address space [01:22:09] Fuad Abinader leaves the room [01:22:28] I propose we take this on as a high priority requirement to fix [01:23:12] benno leaves the room [01:23:37] Dino : There is a potential solution [01:23:50] benno joins the room [01:24:18] Sam : This is an attack where I have an authentication key [01:24:33] Dave Meyer : BGP doesn't have this today [01:26:43] Joel : The conceptual idea of keeping ETRs from overclaiming I think that everyone agrees on [01:26:49] the wording is distracting [01:27:04] Chair : we will bring this up on the list [01:28:48] Jari : LISP introduces a lot of new players into the system, and some of them should be not trusted [01:29:09] Sam : there is more on the wiki and in [01:29:20] draft-saucez-lisp -security [01:29:34] Luigi : I was a little behind with the work [01:29:52] Chair : we will determine if separate drafts are neede [01:30:40] Next : Dave Meyer : [01:30:50] LISP Internet Groper [01:31:20] benno leaves the room [01:32:03] when the map resolver map serve came along we realized that we could use it sort of like dig [01:32:18] WE can answer a bunch of questions [01:32:21] benno joins the room [01:32:24] - is the mapping system working [01:32:35] is the site rfistered [01:32:38] etc [01:33:03] LIG fetches a database mapping entry and displays it [01:33:31] both router and host LIG is available [01:34:50] then we thought, can you see if you are in the mapping system [01:35:08] it supports cross-address families [01:35:15] Fuad Abinader joins the room [01:36:01] if you also find out if something is not a lisp site [01:36:21] the map server returns a negative cache entry [01:36:44] implementations [01:37:03] Dino did on the titanium [01:37:11] there is an IOS one [01:37:26] there is a free BSD version from Dave [01:37:42] github.com/davidmeyer/lisp [http://github.com/davidmeyer/lisp] [01:38:44] sorry, that is wrong [01:38:45] http://github.com/davidmeyer/lig [http://github.com/davidmeyer/lig] [01:38:48] is correct [01:39:08] jlcJohn joins the room [01:39:37] Dave Meyer - I would like to make this a working group document [01:40:35] Margaret : While it is not in the charter, I have no problem publishing it [01:41:45] Scott.Brim leaves the room [01:42:08] Jari : I have no problem either [01:42:18] Chair : OK, we will send this to the list [01:42:21] Jari [01:42:28] Scott.Brim joins the room [01:42:28] you can do 'git clone git://github.com/davidmeyer/lig.git' to get the code [01:44:16] We are going to get some new people as the chairs and as the editors [01:44:36] I have some good ideas of who these should be [01:44:47] but if you have ideas, please send them [01:49:24] sorry, I got pinged [01:50:02] Dave Meyer : This is kind of a radical move that you taking here. Is a lot getting down or is it all broken ? [01:50:13] shikob leaves the room [01:50:47] Jari ; I think that the WG at large is working well [01:51:20] but ,my perception is that the relationships at the personal level was such that they couldn't work well together [01:51:29] default999 joins the room [01:51:32] that was my assessment [01:51:46] I realize that this is a drastic action [01:52:07] shikob joins the room [01:53:54] Scott.Brim leaves the room [01:54:04] kazuya leaves the room [01:54:04] gigix73 leaves the room [01:54:09] shikob leaves the room [01:54:36] HannuF leaves the room: Computer went to sleep [01:55:00] takas leaves the room [01:55:10] default999 leaves the room [01:55:35] marshall leaves the room [01:55:38] shamus leaves the room [01:56:04] rhe leaves the room [01:56:15] hide.zebra leaves the room [01:58:04] arifumi leaves the room [01:58:55] benno leaves the room [02:03:37] anthony.baire leaves the room [02:03:38] ljakab leaves the room [02:05:37] mawatari leaves the room [02:08:31] mawatari joins the room [02:11:24] becarpenter leaves the room [02:16:27] roque@hiroshima leaves the room [02:17:48] Fuad Abinader leaves the room [02:19:10] arifumi joins the room [02:19:14] arifumi leaves the room [02:21:20] mawatari leaves the room [02:23:10] ietfdbh leaves the room [02:31:43] ietfdbh joins the room [02:33:19] Scott.Brim joins the room [02:39:10] ietfdbh leaves the room [02:47:03] ewburger leaves the room [02:47:17] jlcJohn leaves the room [03:16:05] roque@hiroshima joins the room [03:16:06] roque@hiroshima leaves the room [03:16:11] roque@hiroshima joins the room [03:17:49] roque@hiroshima leaves the room [03:19:14] anthony.baire joins the room [03:22:18] Scott.Brim leaves the room [04:19:38] anthony.baire leaves the room [04:39:35] Fuad Abinader joins the room [06:00:47] Fuad Abinader leaves the room [22:02:47] humbertogaliza joins the room [22:03:47] humbertogaliza leaves the room [23:43:54] gigix73 joins the room [23:44:07] gigix73 leaves the room [23:44:09] gigix73 joins the room