Minutes for the off-path-bof, 66th IETF. Minutes submitted by Paul "Live" meeting minutes taken by Matt Zekauskas (and copied below in original form) The agenda closely followed the originally posted agenda. Presentations are also posted. Summary: Meeting well attended (a couple hundred folks?) There seemed to be broad support for the idea of creating an IRTF group along the lines proposed by Francis and Handley: broadly explore requirements for end-middle-end approach to signaling, narrow down the requirements to something manageable, design "ideal" protocols based on those requirements without paying much attention to existing work, see how existing protocols mesh with ideal design, decide whether to move forwards with ideal design or existing protocol, write specs and build prototypes A decent number of folks indicated through show of hands that they'd be interested in participating in the research group (30 - 40). (Note: the mailing list now has roughly 50 members.) Action items: Handley and Francis are to produce a draft charter to be discussed on the mailing list. This will lead to a request to create an IRTF group. (Note: proposed name for the RG is EMMERG, for End-Middles-End Research Group.) Matt Zekauskas' raw live minutes: irtf is 2014 requirements are different, mostly looser bof is req to form new rg closely enough related to ietf work to have this discussion see interest, collect feedback from ietf community. research groups tend to be focussed, long-term, mall, open or closed, may or may not meet at IETF no special status w/in IETF so how might IETF benefit? make tech mature before comes to IETF mobility optimization... focus researchers on ideas bring researchers into IETF orbit from researcher point of view.. .why should they go there? cross org collab real problems obtain crit mass increase viz and impact increas probablility of deployment on real nets criteria for RG clarity of scope utility [to the internet community, not necc ietf) energy & expertise in group? leadership about research... scope broader than current ietf proposing IETF work is out of scope -- q's for later is there realated not mentioned? are there related communities that might participate or have perspective? will you as individuals participate? note well applies to this. IRTF doesn't have IPR policy, but since at IETF meeting... considered ietf contributions... === important preliminary step. note taker and jabber scribe. is there a jabber room? ====================== paul francis off-path bof problem/solution overview both love and hate coming to ietf caveats: i'm a researcher, not a standards weenie skin has grown thin... here all week, wil talk 1-1 haven't keept up, please don't crucify :D a number of ways to look, think in a nutshell... robust secure connection establish. by robust, "always works" pre firewall days mostly did this post firewall/nat days, mostly doesn't work. but... want to do in a secure sense. willing to take questions as go. can take questions as we go. -- more tech goals not replacing cli/server like cnn.com think it might be a relatively heavy weight thing. so don't see much problem with client to public server as is today. client to non-public server, sort of "peer to peer". think it should be name based. have connectivity via dns. not tied to a single net layer... have something that provides firewalls (broadly, on your laptop, at enterprise edge, elsewhere) all info to understand what a connection is all about. addrs/ports don't do it today. issues with this too. authenticated, named endpoints and applications... -- like to see something that is more explicit about all the policy players involved in a given connection. much more open about each to have say. ends and middle control; let market/courts deicde who controls what. pepole come up with new security, trnasport protos. not a good way for endpoints to negotiate about all possible choices... negitate characteristics is another goal. security, transport, network, routing through middleboxes with some nerviousness mention others: mobility, multihoming. -- ultimately new sockets layer 30% leave now. not focus of work (??) think about this as something that needs to be ubiquitous. set of functions an app can count on; in the os and infra. today: IPO, transport ports, DNS goal: ubiquitous and generic support for signalling. let's just call this "newsock" for now. new sockets layer that is name based, invokes signalling instead of uttering packet, and info that firewall would usu be configured with. calling work NUTS... presuposes solution, what we've been doing. but if create group, open to other opinions, newsock, is some signalling proto, in-path andout-path, and support in os and infra. henning: assuming pt-pt only? multipoint multicast... pf: answer cannot be no, has to include multipoint. not necc IP multicast... but hasn't been our focus. BoF goals: IRTF want to create an IRTF gorup. here because don't want it to be just a bunch of researchers. and those focussed on next conference. want feedback from groiup, and participation. Why is this a TSV and not IRTF bof?... ask allison. -- why a signalling approach? some ob servations.. i'll have slides, then mark will talk, and sycot will talk. interested ina couple of years... derives from work in terms of STUN and ICE and stuff... you can punch through firewalls better than previously thought. most done in context of UDP. we've also done it with TCP. thought that was interesting, and lead to signalling in cleaner way. don't think IPv6 deals with firewalls. don't think igoing away... good reaons to have them.. like original SIP spec. name based, discovery, redirection. separate you from where in net you are connected. so always interested in signalling, dealing with data broadly. different from dealing with media... -- a quick technical overview our model... data path is default off. tends to be that way anyway. default on path, though. the signalling path. is path decoupled, hence title of bof. goes through policy boxes... doesn't have to be firewall per-se. for many reaons don't want this to be firewall. all of policy boxes have a say. access control on policy box. policy is in policy boxes and drive what firewalls do aaron: make distinction between policy and policy enforcement why policy boxes are not firewall? yes. they make decisions, firewall allows things in. -- either have legacy firewalls or newsock firewalls in path. if legacy, do tricks like today; make it look like both ends initiating connection. connection behaves as if internally initiated. if have a newsock firewall, then policy boxes might create secure tokens hat are used to travers on-path firewalls (either control, or authentication flows). -- est connections today: make an attempt to argue that... people tend to do this today (in many ad-hoc ways) and IETF doesn't take care of this today. * man config of nat box, firewall. * DynDNS, but it lacks privacy. does name-based conn setup, but no negotiation. and lacks privacy, anyone can know ip addr. picked an arbitrary dyns.com george & sally come up with valid addrs. say you wanted to track... notright way to do things. * various IM signaled apps... setup file transfer view IM signalling. * these push access control to individ apps, leave hte firewalls in thecold. want to take IM stuff, and put in sockets layer, and get isps to do. have lots of proprietary stuff, different name spaces, kinda silly. why not one place. henning: UPNP is proably most popular version today. microsoft thinking. most linksys style boxes support it. nat and firewall control. ?: a couple minor problems. no security, multihoming, la la la. (balding, blue shirt in front) not end to end either. -- related standards efforts -AFAIK hate to put IPv6 up there... hope you stand up and say I'm wrong... IPv6 supposed to take us back to original. globally unique addrs, set up connections with anyone. firewalls get in the way, and nothing to do. and IPvr4 for forseeable future. NAT traversal an ongoing issue ues DNS for naming, but there is aprivacy issue... philosophically: ipv4 originally meant as a way to allow different nets to interoperate, newsock woul dhearken back to that. not a protocol, but a way of things to communicate. bring different addressing spaces to one space. boxes on different networks. became the network at some point. MPLS is pressing below. having signalling and global naming as URIs would be a way to bring this back. NSIS. know lots about it. lots about QoS, but lots about NAT traversal. nsis is on-path, although looking for off-path component. on-path component is still major thing. believe newsock and nsis are complementary. before nsis can kick in, endpoints must have an address to talk to each other. some signalling in advance, nsis can punch hole through firewall. HIP similar. not up to date with HIP, actually naming and rendesvous. but can think of name based signalling as a way for endpoints to find each other, and even tell to use HIP. see as complementary. SIP might serve as the path-decoupled signalling protocol although IRTF might want to start clean slate. ICE+STUN+TURN: media and UDP foucssed, but started me on this path SIMPLE: focussed on a specific app, but similar. DynDNS mentioned already to be clear... fairly recnetly last year ICE+STUN done a lot of TCP TURN does it too. jonathan rosenburg andre gou? co-chair HIP. have HIP-aware firewall, based on HIP-ids. called HITS host identity tags. available with prototypes. make up rules according to 128 bit things. afalk: voice a concern. casting a broad net. idnetity communication multihoming.. many many topics that this touches on. initial concern might be that proposal is scoped too narrowly, now concerned some biling ocean here. can solve in how articulate scope of work, but haven't heard it yet. dyndns as a way of doing identity... privacy, similar to phone numbers and white pages as priv risk... paul: phone # that tells you where you are wherever you go. aobut scoping... can't avoid fact that it brings up mobility and multihoming. not sure how to state something very simple and focussed. can not mention, but not sure how to avoid. bob briscoe: story development... not sure what peripheral bits were going to do with authentication. not interested if authentication bits on firewall that you can just DoS. if have to authenticate request to firewall, must have interface that checks auth, which creates work, and people can just DOS. in any auth a dos attack somewhere. policy boxes, replicated many times, allows you to absorb attack a bit better. can also use HIP tricks like auth cooke once authenticated & like, can get IP dr to go throug firewall. point is valid. dave crocker: once upon a time, community pressure to make changes in response to vague needs. people with ideas for significant arch chagnes proposed, but community wasn't in a plce to think about it. you and noel were trying to make conceptual chanes that hav relationshiop to what you're doing now. but back then, emergency, focus, but no will to consider conceptual change. but back here now with IRTF-oriented effort, observing that things ahave not gotten less messy since started IPv6 effort. more messy. current collection of internet stuff, is messy and jury-riggfed in cases and problematic in cases. if take presentation as a solution path, am confused. if description of problem situation, then ... in irtf world... find a path that encorporates things that are curently messy in a way that are less messy tussel boundaries as embodied by firewalls/nats decoupling addr /names in better ways (intend as examples, not proposals) getting a discussion that works at a different pace than WG, and doesn't know exactly what problems trying to solve, knows about problem space working in, nad goal that is ... involves hand waving... find something simpler than do now, and in process more efficient, flex, whatever. you're not reacting in a way that says what I'm sayin gis working. reacting to an awful lot. if try to tackle it all, won't succeed. otoh, listing messy environment and core ideas. name-baed, middleboxes as part of arch. know policy and other boundarys need to put in arch, going to create a new arch. tim shepard. henning: comment. potential to deal with dos attacks, can differently rate limit signalling requests than generic app requests. brute force mechanism one layer below to limit.. phillip mathews question: most of time talking about changing apps, chainging stuff in middle? want to change stuff in middle, but can deal with legacy. would like IRTF group to be foccssed on signalling oriented soln. wouldn't want soething that is broadly revisiting naming/addressing/ tusel. -- many open problems. feel like have a handle on a bunch, but plenty for a resarchy group to do. ========================================================= mark handley will be next. I have a slightloy differnet take on this than paul. half backed talk but same space. conneciton signalling -- the problems list... can argue about scope. mobility/multihoming/firewalls/nat/addr spoofing/dos attacks think can fix e'm all in one go. maybe 70% of problems internet has. -- all have one thing in common, depart from traditional e2e model. -- connections. perhaps original end to end session model of TCP is the problem. fix that? 'traditional self-contained TCP modle of a session connecting a pair of IP addresses and ports' -- warning -- philosophy and assumptions consensus towards, IP addreses being addrs, not identifiers. identify a location should be possible to aggregate routes transport protocols capable of supporting rebinding of addr & port. before/during conn est. in mid-connection. feasable... TCP by dfault can't. but there is alex norem's work. sctp, dccp can. UDP can if flows... but... -- strawman: Connection Signalling PRotocol. not necessarily sip, personally don't believe should be sip. lets hypothesize, and see where it leaves. intent is not to build virtual circuits. or is step on that path, perhaps. (abuse this stuff :) a clean place in arch to tackle problems signal app intent to middleboxes signal middeleboxes intent to end hosts mobility signal aternative path info to end systems exssamples... maybe solve, ton't take particualr solution. -- stack. think of ConnSigProto as alongside, not over transport protocols. like ICMP to IP. paul and I agree right place, we might not agree on details. -- simple connection, what might do. set up a tcp connection between 2 addrs and ports get connection, then shutdown at end. simple example of how look. in this form not much use. pf: ongoing... why that one starts with an address. don't have to answer that now. well, don't wan tot say is an address in example. doesn't have to be an address. some cases. johnathan rosenberg: is this path coupled? yes and no. probably more so than what paul is thinking, but not entirely. are observations. -- simple example: firewalled UDP connection signal connection, r in connection response, firewall can tell you that it will timeout state in 10 sec. app can cange to 5 min make stuff implicit explicit. put in arch. -- unidirectional udp in thru firewall. with signalling, firewall can understand, until edetach -- one where not onpath. firewall redirect to offpath proxy local policy: all http connections out thru proxy. and proxy isn't in firewall. setup. firewall intervenes, and says redirect to proxy. so it sets up connection to proxy proxy to far end and inserted proxy to connection. everyone knows it's there, not scott brim: call off path, but just signalling onto a different path. -- firewall rejection. firewall can intercept, reply with failure and why and maybe contact. -- NAT traversal. make clear what the heck is going on. setup intercepted makes clear what you should do with ports so rebind, and then setup connection. have address you're going to see as N. everyone knows what is going on. and NAT didn't have to rebind port, because asked host to change ot start. -- nat traversal, 2. get in through nat. firs tthing where need something othe rthan IP addr in packet. setup message, but saying here is where I really wnat it to go. setup & response both modified to say what's happening. at end, nat can be transparent in both directions. -- mobile client. relatively easy to tackle at this point in arch. mobile client, knows will be mobile. sticks in add'l info, so can resolve when change addrsess. (security/nonce knida thing) fairly similar to dccp mobility. -- hidden mobile server ??? -- offpath firewall for mobile host. moving around. firewall policing traffic. network that can't trust affect security... setup goes to home, firewall at home site intercepts and does it's own setup with mobile. then communication goes direct. signalling off path of where data traffic might go. -- simple multihoming. host with 2 addrs. set up connection tell client can use either address. up to sending host to decide which way could include prioritization. firewalls can also redirect paths -- spoofing do a initial rt with sender, so if spoof ip addr, won't work. -- can also do dos prevention now seriously half-baked gateway loosely assoc with sender pupose of gw... is when other end says "don't send", it can toss to floor. plus security stuff so dos isn't used in own right. bob briscoe: this diag is good ot use for general point. most of diags like this, assumption that CSP message is being picked up by things that understand csp along path. but need to talk aobut how to addr stuff along path. so not evertything picking up messages and seing if for them. can imagine filtering bits. bobb: addressing to functions... yeah, role based arch liek a ways back. view that as an optimization. ?: when present CSP protocol, 90% of what NSIS does. yeah, told you i'd overlap. bob: [suggestion, and I missed it] rosenberg: this struck me as 'it's not going to be so simple'. fuzzy line between on path and off path will become gaphing hole when talk about naming issues... yeah, trying to give solution hint of space. jrosenberg: also posit something... largest piece of problem is how to get deployable, in way that is incrementally deployable. would you have to change target design, because pure design is unachievable. if we agree to move forward, deployability is part of story. I think it's fiarly well incrementallydeployable. philip mathews: if you have to change middleboxes, it's less deployable afalk: WG vs RG. a valid way to conduct research is to investigate some point solutions and expand. paul and mark presented two different points in design space. backwards compat at start means don't get anywhere. opportunities for RG to expand. get enough insight to come up with widely deployable thing. commments are valid, but can't understand implications until flushed out proposals. mark h: yeah, a good research strategy is to look at where might be then work towards that. paul: sycot and I are interested inboth. do socket level interception and gw doesn't know. always try both. tomas karn?: at least one iteration too early to think about backwards compatability . henning: effort ongoing, GENI meant as a test bed, national scale testbed, wehre this sort of thing could be done. a slew of probvlems -- last slide... asserting that we can solve, but these slides are not proof by example. hope that can tackle by these mechanisms... lots of questions, tho. serious "second system" syndrome danger here. unless it's simple, afalk: question from RG formation pov. proposed some work, position to pursue? yes. letter from chair? -- ================================================== allison on angenda and context when I saw that the IRTF was doing this, mention some historhy. IETF History and Architecture mankin@psg.com point is not to anchor this back to IETF protocosl, but to give people a little background... we tend to live in the moment. research folks sometimes find themselves working on something done badly bfore. "not these guys here" look at experience, not because of backwards compatability, but can understand problems encountered when trying to deploy. brief bakground on signalling at IETF ietf perspectives earlier considerations of offpath considerations if you want to do extensions. -- rsvp is original signalling proto. started out as QoS primarily. never intended to be off path. extensibility has been lessons learned problem has developed into multiple variants by multiple users. nsis layered structure so build apps on top of transport some effort to create a bit of decoupling. discovery mode and connection mode. -- rsvp extension history lots of ability to have people add things differnet orgs can create thier org strucutres in it. when first pub in 1997, didn't say how. just register object and filter specs and carry. a bucket protocol people built buckets. used syntax. MPLS changed state machine while filling up buckets others did same. RSVP built into something that doesn't look like it did, but use same objects. nature of signalling. -. warning about extensibility. 9 years after create protocol, have a rulebook about how to extend. closing barn door late. -- NSIS extension transport protocol called GIST. qos protcol called NSLP and a nat firewall protocol. "..." (uncharted) - can develop other apps extensibility design is in NSIS group, final stages. don't want something that might change state machines and protocol. but GIST might be useful in research. -- SIP paul asked me why SIP is not NSIS. we never thought about it. henning could talk to paul about that. UA describes media stream, has rendesvous. have been difficulties because it's decoupled. people try to recouple in practice. when think about mark's csp, and what might do... look at measured behavior deploymjents congestion problems described & measured. look at proxies and deployments. not a clean thing to separate, even though looks like henning: all of 3GPSCF effort, is to bring SIP back to onpath. -- sip design, unordered headers, text base also lent to orgs making up own SIP. can have dialectization of SIP. only waited 1 year to come up with rulebook to get under control. don't just take protocol for your purposes, not necessarily as temptingly extensible. -- offpath signalling NSIS had a huge amount of pressure to not do on-path signalling. operators like central control. ever since put together charger, have asked for central control instead of follow the signalling along path. -- in 2003, PADS bof to do that. sevaral parties laied out ideas... came up with tihngs like VPNs orientation QoS and traffic engineering. like what current PCE WG and MPLS. bof was massivly negative on proposal. not a good IP approach. every 3-4 years have same bofs. -- partial decoupling nsis has proposal that was mentioned. good doc to read. -- conclusions... look at experiences like idea of looking at clean slate, then think about backwards compatability. understand SIP and RSVP experiences think research here is a great ideas even with caveats. this is important, important that people think about it. ============================================ saikat gupta using off-path and on-apath signaling for internet security by default hosts cannot communicate with each other, punch holes via offpath signalling channel, on by default. where put all heavyweight security stuff. rate limits mediation end up with securte token, and firewall lets data path through. -- examples... chain of registrations. creates a backward path from global internet that allows default-on registration. -- polcy boxes could append keys for thier own firewall. then when put data connections, put tokens in data packet [[where?]] and can communicate. little on-ath signalling to couple offpath to data path. went through one set of design choices. -- network elts off path policy/presence/messging on-path firewall, ... -- once have policy, how find it? static dhcp off-path query (a-la dns) or on-path query (a-la redirection) -- offpath signalling needs to be secure. potentially locations, applications. -- ... -- what needs to be in token? can be a negotiation too... once in token, need to couple with data path. some sort of oob signalling (like nsis) (add'l to firewall) or something inside tcp. -- we did a prototype implementation Sip express router proxy as policy box config with static policy rules. map q/response onto SIP. have a modified TURN server... to do policy enforcement. nutss.net/bof/cf.txt quick, questions? [10 min...] that's tech presentation on subject at hand. -- I wanna know, how many people are participating in this work. that means reading/writing/coding/exercising coding as opposed to ml participations. 11 or so. who of you are curently on ML. 4. on bof description, ptr to web page at cornell, coordinates for subscribe to ML. would like to see some discussion on scope and activities for RG on that ML. see some indication that people interested can come to agreement of work that you want to do. are there communities, that aren't here that should here or might want to participate. or are stakeholders thinking of parts of IETF. recognize SIP box lars: HIP and shim6. API for HIP & shim6 apps. this is a socket API extensions. HIP is meeing now, too. sigh. helpful to send pointers to this activity, get folks involved there as well. cast a wide net... paul: who thinks this is a bad idea. aaron: can have conflicting RG, tho. just curious. tim shepard: I think a good idea, but coming to mike to get a more concise explanation of what "this" is. even if back, not a bad thing. tom: asking if a bad idea is wrong, bad oint. hard to scope what's really going to be done & problem space. short term: focus on problem space, problem areas, get head around areas to tackle. the way paul gave very broad picture. any piece in scpe... is that right? take a small piece of bigger problem, do prototypes & learning & iterate. want some sort of agreeement about what talk about, even tho broader than thypical IETF wg. afalk: want discussion on list. pekka savola. not sure if bad idea or not, but reasonably high probabilyt of creating ISPs that hold users captive. 5$ per commuinication period. have to talk through ISPs box. some concerns there. maybe unavoidable in any case. bob braden: one comment -- seems to be name of rg "offpath signalling" doesn't come anywhere near scope of arch changes suggested. veryinterested work. perhaps better names explicit poloicy signalling or ... history: when rsvp wg working for a few years, close to proto spec. came to attn of well known powerful curmudgeon in community. blistering message to IETF list. blasphemous, stupid. "doesn't scale" as mantra. statement had a huge impact on RSVP in real world. backed away from it . people forgotten, so nsis did get started. tim shepard: when asking for what this is... seemed like an awful lot in pauls vision. clean slate, and then covered a large space. not necessarily bad, but a fairly large effort to pull of prototypes, etc. multiple people implementing... think it's really great to do all of it. on principle say yes. go do it. enables people to book room at IETF meetings. sort of happened in HIP. HIP WG purpose, to write down... produce experimental RFCs. so multiple people could impl same thing, so then do experiments. seems like might wnat to do same thing here. and maybe 5 wg for different comnponents. this kind of experimenting ought to be encouraged. want RG. but also maybe want community around this thing. way for IETF to do experimental work. actually try things not on stds track. afalk: try some RT feedback. my reaction... very broad touched on many topics. but the last presentation is a point solution in that space. what brought us, a point solution and context to put it in. mark had different context. not impossible to articulate crisp dfn of problem (marks talk did a good job, handling things not handled by pure e2e communication) want one harmonious solution. tim: maybe not a RG, but an architectural exploratory effort. maybe needs to be an understood way to explore new arch as a group spinning off whole mini-IETF to do alt arch engr. afalk: makr proposed arch researchy groups. is room for that in IRTF. henning: proposal a few years ago, permission based networking. if you need a term... :). a lot of general arch unhappiness... led to FIND, GENI. knowplane effort. lot more related things once take a broader perspective. most of those individuals not here. running into distinct problems making e2e system work. danger of solving everything... motivation comes from protecting provider not customers. PCSCF? exactly same notions. "all good for customer too". one problem with IMS and NGN and other wireless space things... becomde holy mess. conflate naming at various layers, signalling. once solve one thing, try to solve universe at once. hardest thing, separable problem statement. goes beyond what's here. other issues: geni motivational paper, reliability, trustworthiness, ... since taking a broad perspective, not pick random 3/5 thing which just happens to fit signalling. but look at whole, and see what problems can chop off into sueful modular narrow interface thing. johnathan rosenberg: always a big fan for names... end-to-middle research group; unifying thy of all this stuff. having to communicate with middle not well solved in e2e. if could talk to and coop w/middle, what would they look like. off-path or on-path, could be both... all aiming to solve that particular whole. a lot to bite off nature of beast. what is min thing to do, set up TCP conn between endpoints. gotta knock off... maybe could od dos as secondary, but... high-level models and protocols. just a lot to make it all work, why things in reality are ugly messes. it's a big ugly problem. dunno if there is a way to break up into simple small pieces. please join ML to continue to participate!