Ad-Hoc Meeting, notes mostly by Spencer Dawkins XPP (E. Ivov Presenting) Focus in this proposal is to be extremely simple. Probably too simple – UDP transport only, for example, and using stop-and-wait strategy with no windowing. Overlay-centric mechanism in XPP – clients don’t decide to join overlays, peers in the overlay invite clients to join the overlay as peers. DHT operations are session-oriented – why? Mostly to open ports before sending requests. LOCSER (J. Hautakorpi Presenting) This protocol proposal is based on unmodified HIP. Jonathan Rosenberg does not understand how this proposal works with ICE. This is a bad sign… In this proposal, the HIT is NOT the peer ID. EKR thinks this is a problem, not a detail. RELOAD (B. Lowekamp Presenting) This proposal evolved from dSIP proposal. Purely a binary protocol now. HIPHOP (P. Matthews Presenting) Presentation is focused on the differences between HIPHOP and other protocols. Proposal is actually to use three separate protocols - distributed transport, distributed databases, and overlay maintenance. Proposal is able to provide this functionality with few-to-no changes to the HIP API, but requires IPv6 to work correctly. EKR is very concerned about proposals that require kernel changes. Jonathan is concerned about the use of public keys related to HITs – it’s hard to come up with an exact match to the HIT, but you don’t need to guess exact matches – you just have to be able to compute a HIT that puts me closer to the target peer than any other peer is, in order to insert yourself next to the targeted peer. The more peers you have, the better the change you have to guess peer IDs, etc. ASP (J. Rosenberg Presenting) ASP proposal guards based on two threats – to storage, and to routing. General Discussion Everyone wants to reroute responses if a response is undeliverable because a peer ID has changed – but that’s really, really hard. Distinctions – kernel mods required, identifier selections, steps a client takes to establish a connection… whether proposal is considered complete or not, whether the proposal uses HIP or not… whether hop-by-hop security is provided, or only end-to-end security …relationship to SIP. SIP was never designed to work with malicious proxies. ICE inherently has “connection is coming semantics”, so all these protocols probably have this model implicitly. All the proposals probably support unmodified SIP clients, although this may not be well-fleshed out. Nobody talked about “non-SIP clients” in these proposals. A couple of proposals claim “mobility”, but Jonathan says this comes along with ICE restarts. Whether you route based on HIT or route based on peer ID which may not be a HIT. Main Meeting, notes mostly by Jeff Hodges --------------------------------------------------------------------------- how many foloks think having (some sort of interim meeting) was about 6..10 no agenda comments. p2psip concepts & terminology Dean Willis ----------------------------- is stuck on "Peer/Client divide" a crit question is figuring out which of the services a peer MUST provide the overaly, and which it (SHOULD) TedH: dean: u might see a squid cache in an overlay mumble ted: ?: p2p -- e2e -- clean/no intermediaries -- "overlays" are not the way to approach going forward in the next five years, this is like skype, shud ask why is it not the way to go, .... is that clear? brian: we unnersgtan the question, al sys we been talking about would work in that environ but we want them to also work in the real world ?: you don't NEED the overlay, you don't NEED stun, they all cost $ dean (dw): we're working from concept of overlay at this time, that's just the consensus in this room jon peterson(jp): dw: back to slides.....peer/client divide is key issue Phillip Matthews (pm): peers can run out of storage (agreeing), if all we put in is contact info, then we might be reasonable to say storage is no worry, but if you start putting lots of data in there you do need to address that, and need to address what haps if u max it out ekr: yes this is issue, expect design will have to say somthing about common storage and we need it and if don't have it what you do dw: need something that isnt sip ua and not a peer, call it a "client" ? and what is it? so leads to ques "what is a peer?" assuming store contract info on behalf of overlay, is that different than other sorts of data? spence dawkins (sd): do we think we have to know ans to this to move fwd, or can we add it later, do we need to nail it first time? dw: need to have short term ans for concepts doc, closer to consens closer to communicating amongst ourselves -- words mean diff things to difcf folks at this time ekr; 4 cats of things: go thru servers (?), deal with overlay, route traffic, and ones that do all the above ----- so a real peer vs not real peer.......it does seem clear there is a diff storing contact info vs storing VM............no ones expected to store more than ? as comapared to storing ? , but it doesn't addres patho case where..........there reeally is only one poss if yer a client ....... gen usable data........guarantee...service........ pm: but believe all could add "it" .... have heard two ideas recently why one might want "clients" --- using something other than "sip", and other one is the wireless arg -- there was disc last night --- do we unnstan the reqs there? mebbe SD idea of going fwd is good one? as we move fwd, with how we bring client in might be more clear.....not actually prot, but just using bits & pieces.... dw: this stuff leads to "what is our svc search mech?" and similar questions pm: thinking node that is sorta similar to how a sip peer would act, doesn't act like how others are imagining client, but if we have model of node that talks to one peer and interacts with overaly thru that one peer....then that's the model i think we have later on david schwartz (ds): ......ques: how long i maintian data.......how long before info needs to go away? ?: need to take into accoutn of ....there's variosu symmetric i'm adding capacity....but you are making demand on overlay and that needs to be taken ingto accoutn, if not will clutter up overlay....so mebbe TTL....so if only going to have data for a day when I join overlay.....so types of data are relevant..... greg?: always going to be devices that can't do all prots and need to be accomodated, so we have dev behind symm nat, but still want to participate, eg in location, so those things are useful for clients, so excluding clients is something we can't do until ..... sd: conv in dallas abt exp vs abstract, expr desire then is do we really need ps5 by end of last year (?), so mebbe we go fwd faster if we focus on what func of overlay is, and sep have conv abt svcs, so make prog on ovly funcs dw: raises ques of how we define svcs dw: "peer services" slide..... "client quirks" slide.... mebbe someother div more useful pm: that one might fit well with discussion wrt what happens if peer joins overlay and it doesn't support the dht that ovly is running...? phps somehow ...there is another reason want to have a client....bad descp.....clearly is something wants to be peer bvut doesnt impl dht, but ...... dw: do u need to rout around dht to act as stun svr -- mebbe not ?glasses deep voice, vest?: it seems that if ovly is a svc in ovly .... then in defn in spec .... wrt "storage needs" what do we mean by that ..... we need less ? clients that don't have storage..... questioning how much we put storage reqs on devs on lower end..... jon rosenberg (jr): what are constraints we havce on endpoints ..... look at things we wrt dht......each node contrib one of smthing and there's n nodes so hard to see strg is a prob.......until we unnstan those things will be hard to resolv this time..... dw: ?miss? jr: lets see what we need to do for sip and ensure dht supports that sd: likes diff btwn the routing and !routing nodes......but what about all these cases....is anone going to write code to handle them all? dw: "client quirks" cont'd mebbe we can work bkwds to figger out reqs..... ----------------------------------------------------- draft-bryan-p2psip-reqs -00 ? presenter ? Matuszewski slide: orderly appch to req m: some inconsistencies cuz several authors slide: p2p ovly reqs m: shd make sure there are no "hot spots" (load-wise?) ......(expanding on slide....) ekr: bad idea to base nodeid on ip, when go global need to map to dht, "engr tradeoff" --- not a requiement m: (back to slide) slide: sip-overlay interface slide: the client protocol slide: selecting a dht david bryan: ...we need to address this question (on this slide).... (deicded to do it later) ------------------------------ draft-*-sec requrements slide: attacks slide: p2psip security pm: need to think about all attacks....what can we mitigate....complex....need to think about as much as poss, then decide what's too hard to address...... m: ?..... pm: need to look at what are solns to probs david schwartz (ds): class of diff classes is more useful than looking at solns jr: this is engr group, look at solns, have to consider sec constantly, can't just (pawn off onto) dht.......e.g. disc on tue night wrt pub keys and sec impls of that...... m: disc on mailing list...sec impt.....decide what we can tackle..... (back to slide) slide: Open Issues ekr: dhts don't have authn for peers.....need to have own sys for peers....massive attacks..... ----------------------------------------------- db: Philip Matthews is going to present on the ques all authors have agreed on wrt this raft of I-Ds, then 5 min for each draft&author..... "p2psip peer protocol design questions" pm: joint effort btwn all authors, i am stuckee.... slide: Intro pm: don't think we'll make decisions today, cept for mebbe first question .... just wanna think about way forward.....there's abt 10 ques....... first question is: slide: should the p2p layer be distinct from the SIP layer? pm: seems that folks are thinking that having a distinct layer is the way to go br: this is point we really want to hum ted hardie (th): believe p2p layer box on left of slide "hides" a bunch of stuff, and with that in mind support that approach pm: ....subdivide p2player...... ?glasses & beard & quiet voice?: ..........(missed it)....... jr: p2p layer does all the distrib stuff......will have to describe other mechs on how to find each other......believe p2psip wg has work to do to do that..... pm: believe there's strong opinion that we have wk to do here..... br: hum wrt support for p2p layer hum for: loud. hum against: (none) br: that's consensus slide: Support for mult DHTs? pm: at least one prop arg against these/this approach.....keep in mind pm: doesn't seem to be any consensus on this......innaresting disc on mailing list.....wrt MTI for DHT..... ?: if do mti for dht.....a commercial provider will be able to say "use this dht" ...... if we don't do mti, then will be soln that ad-hoc case will be harder, and comm providers will still say "gotta support this one" sd: hard to see how we do this w/o at least one MTI....... th: if you don't do a mti, then won't get a mtd (deploy).....so last bullet isn't nec, this is really about having a mts (support) of just one.......the choice of selecting just one is often a losing prop, so we are talkking about supporting mult dhts and ques is are we choosing type of dht? and so mebbe what we shud do is support a mult number of similar dhts...... pm: many props are prett open today, but might come lot dhts that are really diff than ones we have today....and so we might be constantly adding new things ....and are you saying we shud track dht design....? th: make this suff well layered such that there is an abs that can be applied as new dhts come along, eg for scale, limiting ourselvs to things of today is prob not a good idea......making prot efft for that abs is a good thing.....sd raises good point, but there is a way around that, so for reaching PS we presume a dht, but don't bake it into the specs bones.......turns out that an assump can be made and we succeed true abs layer we get more flexibility....and then can have temp mti dht for testing purposes...... garcia: ...dht.....what's diffs....? pm/db: eg using diff codecs..... br: pick one, we all impl it, having ONE allows us to have things that work, not having ONE things wont work, we can pick one, write code make it work, we have lots of mti all over in ietf specs, sometimes right or wrong, but we shud pick one today, go on and fix it later, pick one now and get some interop today th: br was speaking on floor as individ..... db: going to hold further ques till end.... pm: ok, so..... slide: DD record types DD == distrib dbase slide: DD: soft state or hard state? e.g.: OSPF is a DD proto w/soft-state, scales to 600 peers BGP is DD proto w/hard state , scales to ?? peers slide: security slide: high level NAT traversal approach? slide: what xport shud the peer prot use? slide: future-proofing can we misx old and new prot versions in one overlay? slide: diagnostics db: questions? ?glasses?: ....if youre going to consider sctp, consider dccp (??) ?dark hair?: ...is there any way to rcmd that use a subset of sip for these peers, but sip is heavy, and might wanna have peers that impl sip subset....is there any way we can rcmd "use these pieces of sip"....? alan johnson(aj): there is a draft that talks about usage scenarios that may ans this ..... svcs being done in p2p way pm: suggesgts a subset of sip rfcs.... sd: do we have to do smthing wrt overlay? jr: if we don't do this right and then aft deply we are so screwed -- real religious on this one (future proof) if we don't we're hosed ----------------------------------------- jr: asp key ideas (slide) draft-jennings-p2psip-asp-00 obj is to look at really hard things we need to do * security frmwk jr: using peers as sip proxies is a bit sec mistake. * nat traversal * extn * usage models * pluggble dht * forwarding layer * mult p2p networks jr: what you won't find in this draft is actual prot payloads.... henry: are there any patents we need to know about? is there any ipr wrt this? jr: not that i aware of chris?: are u able to supp new dumb clients? jr: (stuff in doc) db: clarify "use ICE" jr: there is adaptation of ICE here, it sez this is how to use ICE and what parts, eg subs offer/ans in ICE, and here we say ignore that.....took only things we need.....early ver of ice was meta-prot......we got rid of that in ICE spec.....but use that technq here wrt ICE -------------------------------------------------- pm: draft-matthews-p2psip-hip-hop-00 slide: HIP-HOP proposal pm: 2 parts, (1) breaking up p2p layer into 3 parts, and then (2) a detailed proposal using HIP for distrib xport part. so this doesn't propose soln for stuff we can leverage from other proposals so why hip-hop is right way to go.... special ipv6 addr as opposed to..... opaque bitstring addr socket API some new api (largely) preservs invest in existing sip stack impls endpoint-2-endpoint hop-by-hop NAT trav at HIP layer in each app ?guy ponytail & beard?: ....????..... henry s (hs): any patents? pm: no ?short lean guy?: recompiling....overselling this..... pm: 20% impl @ recent sipit supported ipv6, so w/other appchs need to do even more work ?slg?: related to terena? pm: can't say ?slg?: is this timing issue? mebbe will work out? ?tall lean guy w/glasses?: something about recompiling assn being mistaken jr: theres changes have to be made for other prop might be about same here; i think this is tintribing idea for hip; but have things bkwds: dht (& ice?) apply to hip, have bennies, but personnaly have concerns about details, pers take is ...... pm: disag with your approach; don't unnstan concerns why this isn't suit approach ?chair of hip wg?: we need to educate why hip is applicable here; doesn't force to use ipv6 ----------------------------------------------- ?presenting: draft-baset-p2psip-p2pp-00 ?: s baset? (sb) slide: P2PP * pluggable dht & non-dht prots * overlay maint * replication provide reliability; depends on what kind of devices * nat travs baked-in * simpl & extensible * no dht mash up not prop mash=up of dhts ekr: what is sec story? sb: something about tls & dtls ekr: encourage to flesh out what you actually mean no more ques.... -------------------------------------------- B. Lowekamp (bl) : draft-bryan-p2psip-reload-01 slide: RELOAD * binary TLV messages * fixed routing header makes calc routing is v. efficient * pluggable dht & sec * sec for overlay, resources & peers certs for each individ entity know info you get is always signed by orig entity * attrs use hierarchical extendable types * one2many resource annot w/params for types etc. * nat trav, tunnel w/small num msgs (something about ICE in there) no encumb w/ this draft that we know of. no questions ------------------------------------- J. Hautakorpi (jh): draft-hautakorpi-p2psip-with-hip-00 -p2psip-peer-protocol-?? slide: overview (diagram) layering: LOCSER: SIP method HIP IPv4/6 slide: highlights * bennies - supports mobility - has ice-like nat trav - supports leapOfFaith type security - can bve used with diff peer prots (eg p2pp) * disctinct design choices hs: ipr? jh: none AFAIK ekr: sec? jh: mechs offered in the layers ekr: .....potentially ...msg sec...doesn't addr access control...how you think of (?).... jh: can be done, up to peer protocol, hip is used as-is (?)...... ?slg?: ........ jh: we do it pm: this is just used as ident up to higher level, doenst mean ur running ipv6 can run over ipv4 layer (clarification) jr: ques on mobility -- when u combine sip w/nat, higher layer notions on connectivity u need to do restart w/ice? jh: yes jr: ice restar isn't lightwght, but need to happen jh: --------------------------------------- E. Ivov (ei): draft-marocco-p2psip-xpp-00 draft-marocco-p2psip-xpp-pcan-00 slide: XPP(-PCAN) Goodies XPP... * session based * NAT traversal ICE is only rcmd, not mandated * backed up by an open source impl is at sourceforge * very lightweight * works for any DHT doesn't make any assump abt DHT XPP-PCAN... * trusted neighbors and passive approach * designed after an OS impl no ques... ------------------------------------ db: ok, ended early, so floor open wrt all of the props pm: every draft have good ideas, should incorp them somehow, encouraged by all these props br: does this merging activity need chair help? how should wg do this? pm: there is some debate on how fast we want to do things; likely wont make choce in Vanc unless goes faster br: not looking for full-blown ans in vanc, want to encourage progress pm: learn from ipv6 process? jr: don't wanna repeat that process....(laughing) db: something about fixing something..... br: all props look viable, all cud stand improvement, keep this moving