Name Based Sockets - BoF Minutes taken by Andrew McGregor, andrewmcgr@gmail.com **Logistics: * Meeting materials: https://datatracker.ietf.org/meeting/79/materials.html * Mailing list subscription: https://www.ietf.org/mailman/listinfo/nbs * Jabber for remote participation during the session: xmpp:nbs@jabber.ietf.org?join * Audio live feed" http://videolab.uoregon.edu/events/ietf/ietf793.m3u ** Draft Agenda (Version 20101105-00) MONDAY, November 8, 2010 0900-1130 Morning Session I Garden Ballroom 3 Chairs: Martin Stiemerling (martin.stiemerling@neclab.eu) Christian Vogt (christian.vogt@ericsson.com) **Draft Agenda** * Chair's introduction (10 mins) - Agenda bashing - Scope and purpose of BoF - Blue sheets - Minute takers/Jabber scribes * General Overview - Christian Vogt (10 mins.) * Name-based APIs - Dave Thaler * Connect-by-name in OS X - Stuart Cheshire * Technical overview - Javier Ubillos (20 mins.) http://tools.ietf.org/pdf/draft-ubillos-name-based-sockets Jabber question: Do the IP extension headers go through middleboxes? In v6, no problem. In v4, we're looking at teredo-like tunnelling mechanisms, and other options. (clarifying discussion on the concept of 'feature' mentioned in slides: this means a stack-internal feature, and is not exposed) DNS caching: Running on Zero - Saleem Bhatti Thomas Eckert: How does frequent access to records become practical at zero TTL? We picked a set of machines that are frequently used by local machines. Aaron Falk: This is a very server-centric analysis. Did you analyse client-centric behaviour? I had a discussion with Stuart Cheshire about this, and 1 second seems better than zero, to avoid multiple lookups for one page. Dave Thaler: Did you actually try to change the RHS of the records, to see if you really do get the new value? A few recursive resolvers cache 30s anyway. Yes, we tested this, and did see the new values. Dave: Did you try using a recursive resolver on the way? We were using the authoritative servers directly. Dave: What was the workload? We were looking at the general site workload, and so the experiment was to see what the load on the DNS servers became. - Presentation of existing experiments/prototypes - Zhongxing Ming (5 mins.) http://tools.ietf.org/html/draft-xu-name-shim6 - Referrals - Brian Carpenter (10 mins.) http://tools.ietf.org/html/draft-carpenter-referral-ps-01 Lars Eggert: When you say address, you mean address+port? It's even worse? The address space of the internet now includes ports as well, yes. * API related - A Common API for Transparent Hybrid Multicast – Thomas C. Schmidt (5 mins.) http://tools.ietf.org/html/draft-waehlisch-sam-common-api-04 Eric Nordmark: In this example, how do you resolve the cnn part? Out of scope for this presentation, but it can be in DNS. Tomas Eckert: * How to continue with NBS: Scope & Where to do the work Scope (rest of time) - Comments and discussion on name-based sockets - Clarification of questions (see also below) Interest? Demand? Feasibility? Side effects? Commitments? Tom ?: I didn't hear one portable API here... Eric Nordmark: Same point... Dave Thaler: What's the platform independant API? Well, there's a bunch of them depending on where you look... w3c does Javascript, C is Austin Group (posix), etc etc. Thomas Eckert: Austin Group aren't the functionality experts though... Dave Thaler: It is the job of the IETF to define an abstract API, as in a list of fields and values without syntax. The concrete API isn't so useful to do in the IETF, especially since the most developers aren't using any particular concrete. Thomas: How do we get this converged? Which sets of functionalities go into the abstract API working group? Yari Arkko: Dave, you argued there are other orgs that own API definitions, and that an abstract API should be done here. To what extent will the other orgs use this, or have they already done this? Is there work to be done here? Dave: I don't believe we need new APIs, because they exist already. However, what about a session layer... does that cause application changes? If apps want to know the cost properties of the network, does that change APIs, and if so, maybe the API groups want to do names at the same time. Eric: If you look at the IPv6 socket API, that was a concrete API, but that made sure you could describe the behaviour. For example, if I call accept(), has the name been validated at that point. If we don't have a concrete API, that makes it hard to work on this. Dave: Multicast source filters was done in parallel, ipv6 sockets was thrown over the fence. Parallel review works better, because f.e. you don't get type-safety issues like getsockopt or ioctl. Liam Casey: How much work has been done on feasibility of a secure protocol. Javier: The current implementation does nothing. But one idea was to do a forward lookup and check for matching addresses. If a feature activates, f.e. shim6, then they can do extra validation. Liam: I was more wondering how confident you are of feasibility of a secure solution. Javier: I'm looking at lightweight, rather than fully secure, at this point. Andrew: Something HIP-like or using HIP directly could be used for a secure mode. Eric: If you don't do validation, you have an aliasing and DoS problem. We have HIP already, so how much are we willing to give up in RTTs and calculation to achieve name security. Thomas: How necessary is it to have a real name at the responder? What about a stringified IP address? Eric: Dave: several cases, one where you can't improve because you have legacy compatibility. If I'm writing a server, and it's accepting inbound connections, it needs a name that can be unique, but doesn't have to be resolvable. x: We can have a safe mode option, that requires remote support etc. and supplies confirmed binding. But allowing backward compatibility, that's important too. Regarding session layer, that is not the job of name-based sockets, rather name-based sockets is there to enable those features (shim6, hip) Lars: Is there demand? If we did this, who would care? Eric: I think the benefit of a concrete name-based socket API is clear enough that it should see adoption. Jari: Lars is spot on, that's the key issue. That depends on what exactly the scope is. Personally, I'm sceptical about the protocol, but the API is interesting. However, what exactly is to be done? Thomas: To me, the interesting thing is the capabilities that the API delivers, that is the ability to insert extra functionality underneath the API. Yuri: What I don't see here is discussion of, will I get new features out of the API? I don't see how the API helps... Dave: 3 questions: Do we need to something about APIs? Something about behaviour under APIs? Something about protocols? Eric: If we want to put an API in here that provides when it's implemented on only one end, but can grow into an agility solution etc, we need to put enough work in to cover the details of the latter. The relationship to security needs figured out, and comes out of the behavioural details. Lars: Need partial benefit from partial deployment. Randall Stewart: There are APIs out there already... we don't need a new socket API, it's much better to have it above the kernel, but below the app; push the socket goo into a library. I don't think it's a good idea to push it into the OS. Lars: sendfile() became part of the TCP API, it took an extremely long time to be adopted.