IETF77 TSV Area Open Meeting Transport Area Open Meeting IETF-77, Anaheim, CA, USA Chairs: Magnus Westerlund Lars Eggert David Harrington ietfdbh@comcast.net (incoming) Minutes taken by John Leslie http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/ietf77-ch3-wed-afnoon.mp3 time: 01:00, MP3 offset: 25:00 Agenda: State of the Area 15 minutes Understanding Apple's Back to My Mac Service Stuart Cheshire 15 minutes Adobe's Real-Time Media Flow Protocol (RTMFP) Matthew Kaufman 45 minutes Discussion on the continued IETF maintenance of RSVP & IntServ Lars Eggert & Magnus Westerlund 45 minutes -- State of the Area Lars: Four agenda items... We invited Stuart Cheshire to do technical presentation on Apple?s Back to My Mac Service We invited Matthew Kaufman to do technical presentation on Adobe's Real-Time Media Flow Protocol (RTMFP) Magnus nad Lars will step down for fourth, to be moderated by Fred Baker & Scott Bradner... how we're going to maintain RSVP & IntServ due to less review than we want... some overlap vs routing area...? State of BoFs, PPSP already chartered; worked out IESG issues and scheduled a session. ConEx second BoF, two sessions, interest strong in Hiroshima, but other area ADs weren't there; two 1-hour sessions should give everyone an opportunity to attend.? Winding down two WGs, ROHC closed ; very successful; NSIS WG shutting down; Lars will take over from Magnus. DCCP has 1 remaining item, and they will be done. Apologies for lacking usual chart of amount published? More than usual amount of publications because Magnus pushed to finish as much as possible. Office hours happened this morning (announced on mailing-list)? Any questions ? (none) 1318 (35:00) "Back to My Mac" Stuart: Lixia asked me to present, based on _her_ students' work? lots of discussion of mobile IP, locator/ID separation, etc. Apple has this Back to My Mac product that does these things. Lixia?s students went through the open source code to document it, and I?m presenting. Apple wants customers to communicate between machines, various locations ? work, home, cafes, perhaps through NATs, recognizing security issues; negotiate NAT-PMP (port mapping protocol), tunnel everything over UDP . Application developers are not necessarily security experts. Your mac at home is offering services (file access, printing), Works from home, but harder from a caf? someplace. Uses UDP port 4500 on your machine (maybe NATted); configures a non-routable IPv6 address, has keys and credentials to prove its identity; Use IPv6 because it has unique addresses. IPv4 with NATs are not unique addresses. Chose IPv6 for pragmatic reasons, not religious reasons. Configure IPsec with Cocoon; wrapping all packets in IPsec, so even if application doesn?t protect the data, we do to prevent Apple being embarrassed by security problems. Need a place to store the data. Use dynamic DNS. every MobileMe customer gets unique domain. DNS updates sent machine is turned on. DNS use TCP/TLS, three standard DNS records... PTR, SRV, TXT Also Autotunnel service via SRV record. says how to get packets to the machine. Every Mac has a Kerberos server, providing single sign on. Client wants to connect... DNS/TCP updates wrapped in TLS to prevent eavesdropping. PTR query says machine has service AFP/TCP (Apple filing protocol) SRV says service available at port TXT with additional info, such as icon. From name to programmatic to open connection. Look at SRV, TXT, AAAA We block; don?t return AAAA to client yet. If client doesn?t have ULA, then Configure ULA. Configure security credentials Then return AAAA. Client opens connections; more magic happens. IPsec policies cause Racoon ISAKMP exchange NAT gateway Have tunnel IPv6 with IPsec UDP, goes through NATs The inner IPv6 address is constant ? persistent identifier Can shut lid, go somewhere, wake with different NAT, ?and recreate tunnel through changed IPv4 address? Inner TCP connection is not broken. Sort of a locator/ID split. Carsen Bowman: interesting stuff. Lots of personal/social VPNs, different tunneling, etc... Lively community; will we interesting to see standards in this area. Greg Lebovitz: missed something, how do you do incoming? How did home gateway permit ISAKMP exchange. Stuart: most gateways support one of two standards; UPnP or NAT-PMP Greg: if gateway doesn?t support one of these, this won?t work? Stuart: correct. A major DSL vendor doesn?t support the necessary standards that would permit Back to My Mac to work. doesn't allow incoming connections at all Tim Shepherd: maybe you're behind corporate IPv4 NAT, with routable IPv6, does this work over IPv6 on the outside. Stuart: architecture does, not released yet. native IPv6 pretty rare right now, but designed for it . If machine has native IPv6, we intend to use that. Tim: .Use has to have a Mac subscription? Stuart: paid service $99 per year Tim:? Similar to other ID/locators schemes. Did you consider use any of the standards efforts? Stuart: I had dropped out of IETF activity, wasn?t aware of what was going on. After we designed this and showed to Steve, a VP promised a short delivery date to Steve, so there was a mad scramble to get it done, We looked at what IPv6 range to use, looked at IANA IPv6 ranges, HIP didn't appear in IANA list. I didn't know about it Michael Tuxson: must I use a specific API on the server? can I ping the machine? Stuart: Any MAC acts as the server, not big iron server. any software with open listen; 100% use Bonjour, apps have been using Bonjour for years. Need API to advertise service. Bonjour available on Windows and Linux machines as well. iTunes for Windows uses Bonjour. 1340 (58:00) RTMFP Matthew Kaufman: Long presentation about what and how; show of hands for technology. This technology is proprietary, but presenting on request from IETF Management doesn?t like us presenting, but IETF invitations make it happen. We designed a new transport protocol: Hard to get investors for transport protocols with no users. Designed secure MFP. forklift upgrade; successfully deployed it (MFP) Acquired by Adobe. RTMFP released in Flash 10.0. about 95% deployment of Flash to people who browse the web. RTMFP is proprietary. Some things I can share (may have IPR, disclosed)? Cannot share bit-level packet formats or crypto information. We wanted to securely deliver media flows, "better" than existing choices. This predates DCCP and DTLS. Might have used if they were available and easy to combine. Some assumptions... Internet usually lossless, in order unless doing load balancing. Is possibly congested (signal for congestion is loss), ?loss is bursty, and congestion is close to users. All paths are asymmetric, lots of security issues, filled with "NAT devices"; end to end is gone but not forgotten. Computers getting faster, moving data is slow, moving things in and out of cache is slow. must run with user privileges, mobility-like issues: no raw sockets; no ECN, network availability as people move. It happens all the time. fewer round trips is better, shorter packets are good; must encrypt; must not consume state, must assume you don?t know your public address, and want to do P2P ...? Connectivity philosophy: should "just work", even from peers, as quickly as possible, even from cold start, need fast connection setup; cannot spend lots of repeated work at establishing connections. prefer combined signaling & data? to reduce redundant negotiations. Easy to take a protocol designed with signaling and media, and break it into two. Difficult to take a protocol designed for just signaling and add media. Layering both good and bad: some issues cannot be stopped we build "sessions" between two endpoints, secure setup in two Round trip times IP address mobility; congestion controlled; single congestion domain one or more media flows in each direction; named with metadata; prioritized, in or out of order delivery, buffer management for higher level apps. Presenter Skipping ahead on the slides to address design ... parallel open, initiator Hello to all candidates, can prirotize if desired first responder wins; free load balancing. NAT hole-punching... On the same LAN quick responders. GregL: the candidates came from DNS resolution? Matthew: can use known candidates, but typically start with redirector, not actually a peer; Flash server you know ? Endpoint discriminator can help Redirection can provide candidates. Can send messages to a node that can forward message using persistent connection. NAT hole punching is built in; not separate protocol. Address mobility: we don?t use address/port tuples to identify sessions. We use session identifier, incoming may be mobility or DoS? IP mobility is often somebody unplugging and plugging it in. We probe new address before moving the stream. Congestion control is interesting. Share congestion state across all flows in a session. Dynamic Congestion Management, A sets bit in the header in real time traffic when talking to B, to identify realtime traffic. B sets a bit to indicate ?I am receiving realtiem traffic? in packet sgoing to all other connections. Close to 50% chance that loss is on B?s uplink. Changes back off more on likely-congested flow. Can tie flows together, such as media nad control streams. Variable length unsigned INTs, so never wrap sequence numbers (at least 64 bits). Congestion control: we think it is important. Prioritization requires congestion control. If you are going to prioritize different streams, you need congestion control. "popular" application needs to do it; we tried equation-based rate control, it didn't work very well; slides discuss this. we do burst avoidance? by requiring hearing back from the other end. Security: always on; manage how to exchange what you need to exchange, but not specific cryptography. very important encryption issues of IP addresses and NATs; explicit Session ID scrambled to look like noise, annoys deep packet inspection guys. Let crypto system encrypt network-level info and provide integrity checks; we ignore padding on end. timestamp not opaque; protect against session replay, when crypto uses same forwards and back. TagLengthValue chunks (inspired by SCTP)? Initiator Hello, endpoint discriminator tag is opaque except to sender Responder Hello; this tag identifies flow when candidate responds. echos tag, cookie, responder "cert" (opaque, may have public key) . Identifies endpoint. Don?t want two sessions between the same endpoints because you want to share congestion info. Canonical Endpoint Discriminator (CEPD) Initiator . A cert can be turned into a CEPD. Sessions are bi-direction; and need to worry about glare case ? prevent opening both directions simultaneously. Use crypto to decide which one wins. Initial Keying Responder , Initial Keying User Data: API for flows gives you per-write framing Metadata sent with flow, until user data acknowledged: opaque to protocol Can do this starting with Partial Reliability, and receiver can tell. [quick overview of features listed on slides] 1416 questions?? Tim Shepard: interesting... what should we do with a proprietary protocol ? would like standards Lars: we should be interested in major deployments outside the IETF Matthew: would like to see as open published protocol. Currently perceived business advantage. Al Morton: please do Partial Reliability again (slide 54) Matthew: each write may be partial or fully reliable; partial may be sent but abandoned; in-order delivery by "forward sequence number" ; don?t force priority for whole flow. If fragmented, we drop the rest of the fragments at the sender. Al: no forward error correction? Matthew: we believe FEC on the Internet is bad . It?s good on native IP multicast, but bad otherwise. We largely believe Bram Cohen?s attitude on this. 1421 (1:38:00) Fred, Scott, & Bruce Davies http://www.ietf.org/proceedings/10mar/slides/tsvarea-2.pdf Fred: question we want to answer: should IETF keep working on RSVP as an IP QoS protocol? Bruce: critical issues... terminology, RSVP-TE (traffic engineering), RSVP-QoS RSVP-TE I sgoing fine in CCAMP; not about that. Today is about QoS usages of RSVP (aka RSVP-QoS) Lou: there's QoS in RSVP-TE , so this is misleading. Bruce: agreed, terminology being debated; no time to re-edit slides... five concerns (see slide)? My term (RSVP-QoS) applies to IntServ and Diffserv, so these are also in scope. 1. Is there deployment? (yes, a number of implementers and deployers) 2. Is there community to do the work? 3. Does RSVP-QoS have show-stopper technical issues? (yes, router alert, scalability) 4. What relationship between RSVP-QoS and TSVP-TE? (some duplicate effort) 5. What about NSIS? NSIS "has not displaced RSVP" Lars: NSIS will swim/sink on it's own merits. NSIS is orthogonal to the RSVP question. RSVP should rise/fall on its own merits. Bruce: Implementations... lots of them, six well-known vendor names Deployment: solves several real problems, reserve resources along a path, high QoS expectations; six companies publicly stating they're deploying it (some still in evaluations)? Support within IETF: 10 authors, 5 companies on recent drafts Lars: looking for warm bodies in meetings that do the work and review the drafts, with view to standardizing. That has been lacking. Maybe the community is fine with a small number of people developing and reviewing standards. It is hard to run a consensus-based effort without contributors. ScottB: takes more people to review than to implement Lars: reviews are the starting point. Does it stay in TSVWG or get its own WG? Bruce: Lars' prodding has helped, believe we can get more cycles . Community support isn?t what Lars would wish, but it is more than none. Need cycles to review drafts. Fred: 118 authors for OSPF, 146 for RSVP Lars: since I became AD, community of reviewers has been small. It may have been larger earlier. Francois: example, a fellow is very active, just not on list. He works off-list contributing to the specs. Lars: If you think one person makes a difference, that might reflect a problem. I agree more folks are working on it than might be obvious. Spencer Dawkins: reviewing really does matter; cases in 1990s where things just didn't interoperate. Need a community of reviewers. Lou Berger: Need not only reviews for comleteness and quality. There are two groups extending RSVP, but many ar ein MPLS world, not RSVP for IP flows. We should tap those resources to review specs for RSVP for IP flows. Those TE groups are not the right people to develop new extensions, just to review to keep TE and flows in sync. Lars: review leading to decision whether to accept has been missing; not happy with "not much interest, but let's adopt it" Bruce: believe we can get people to participate on list, even if they don?t show up at meetings. There are no show-stopper issues that should make RSVP go away. Router Alert: does create applicability Scalability: we've done a number of demos? Ken Calder: folks disagree that Router Alert is solved. Some think that is a deal-breaker. Bob Briscoe: willing to do reviews; RSVP of interest to group keying. Bruce: PCN WG is another potential user; they could make use of RSVP. My opiion is that there is plenty of applicability and a large amount of interest, but not necessarily in the IETF. I think ti should continue doing the work in the IETF. Summary: plenty of applicability, better done in IETF, relationship to RSVP-TE needs attention? 1428 Lou: RSVP taking elsewhere would be bad; don't forget MPLS; code point assignment needs IETF involvement. how to deal with extension useful for all three case (ccamp, rsvp-te, and rsvp flows) Matthew: write a draft, present to all WGs Ross Callon: as individual, I agree with your presentation; I agree the work should be don ein the IETF. re DoS, would like to see issues addressed in appropriate documents relative to specific environments -- many issues are simple enough do deal with. ??: what if a WG developed an object in one environment that caused problems for operators and vendors? I have an object in mind that associates two objects. ?. Lars: The question is too detailed, the question on the table is do we have enough community support to review whether we should accept new proposals for RSVP or not? Scott: time running out? 1254 (2:10:00) Sanjay Mehta RSVP Support in Mediabase? video-on-demand SP IPTV managed video delivery, service providers looking for how to provide premium content, now over-provisioning, looking for bandwidth reservation for premium content (as opposed to free); RSVP gaining traction for this; "optional reservation" during rollout; 4000 streams test; looks fully scalable; easy to implement; deployment across France starting ?? (Chinese University?): is this intended for network reservation? why this complexity Bruce: intent to run on hosts and routers Bob Briscoe: RSVP community may have shrunk because there are perceptions of scalability problems, working on scalability issues in INT area; RSVP needs to be there. Work the IETF is doing could rejuvenate community. Lars: please answer how we grow community to review adoption of proposals Sanjay: we do have an interest in contributing as reviewers. Ken Colberg: practically speaking, this didn?t work. Adrian Farrell: It worries me that Lars?s question isn?t getting solid answer. What?s happening to date, developing in TSV, not spotted elsewhere, review is limited, late, and concentrating on effects on RSVP-TE to protect RSVP-TE without interest in plain RSVP. Maybe TSV should develop requirements for TSVWG, and then do the work in the Routing area so the code points etc are in sync. Scott: not sure requirements are actually developed in TSVWG Fred: show of hands of people willing to vet ideas coming into the WG, whether to accept, I count 12 hands GregL: as IAB member, I need to know: how many came because of this topic (about 20 hands); if this were a BoF from scratch? Lars: got to close, please send email Scott: thank you to those who did show up; I believe the level of interest is well on the way...