[11:56:21] --- LOGGING STARTED
[13:49:16] --- andrewm has joined
[13:57:27] --- guhasaikat has joined
[14:02:33] <andrewm> 1300-1315 - Agenda, joint meeting goals (Chairs)
[14:03:36] <guhasaikat> can't seem to connect to the audio streams host. heard of similar problems from anyone else?
[14:05:53] <guhasaikat> am on audio now. cheers.
[14:06:18] <andrewm> (room has filled up so there will be a bit of noise for a few minutes as the staff remove a wall)
[14:08:21] <guhasaikat> hmmm. this is salon 3 correct (as per web page)? (I seem to in some other audio room. :-p)
[14:08:30] <andrewm> Salon 2
[14:08:51] <andrewm> We're in RG administrivia at present
[14:10:08] <guhasaikat> cool thanks. got the right stream
[14:11:00] <andrewm> Pause to reconfigure the room.
[14:12:56] --- bnsmith has joined
[14:13:04] <andrewm> Tom Henderson is presenting the goals for a joint meeting.
[14:13:44] <andrewm> There are apparent synergies between hip and eme architectures
[14:14:07] <andrewm> hip may support a middlebox-oriented arch
[14:14:32] <andrewm> there are potential naming synergies as well
[14:14:56] <andrewm> There is a need for high-level human-friendly names on top of HIP's names
[14:15:08] <andrewm> That may be eme's URI-based scheme
[14:15:29] <andrewm> NAT traversal is an active issue in both spaces
[14:15:50] <andrewm> NUTSS may benefit from HIP underneath
[14:16:04] <andrewm> Both RGs have similar charters
[14:16:18] <andrewm> How to take experiments to a larger scale?
[14:17:34] <andrewm> Draft reviews next, then discussion on potential synergy and experiment scaling
[14:20:35] <andrewm> Goal of EME: allow hosts to establish connections that respect ACLs of all stakeholders
[14:20:50] <andrewm> plus mobility, anycast etc
[14:20:56] <andrewm> not QoS
[14:21:45] <andrewm> Consequences:
[14:21:56] <andrewm> User friendly names required
[14:22:03] <andrewm> Largely for ACLs
[14:22:53] <andrewm> Also exposing middleboxen to ends
[14:23:39] <andrewm> Lots of vaguely similar work
[14:24:01] <andrewm> The idea here is to look for a clean design, then map onto existing stuff if possible
[14:28:02] --- PasiS has joined
[14:28:11] --- Suz has joined
[14:28:46] --- lars.eggert@googlemail.com has joined
[14:29:05] --- Suz has left
[14:29:32] <andrewm> Reference Architecture slide is up.
[14:30:21] <andrewm> P-box name routing
[14:31:01] <andrewm> Coupling between two signalling modes
[14:32:38] <andrewm> Basic signalling approach
[14:36:38] <andrewm> Discussion over granularity
[14:38:35] <andrewm> Signalling messages slide
[14:39:10] <andrewm> Concept of 'devices'
[14:40:18] <andrewm> Device consists of name, protocol definitions, tokens, and authentication
[14:41:47] <andrewm> Device authentication
[14:45:32] --- jlcjohn has joined
[14:46:13] <andrewm> Series of examples in progress.
[14:50:30] <andrewm> Complex example brings up the MTU as an issue.
[14:51:35] <andrewm> Next steps:
[14:51:41] <andrewm> Is this a good approach
[14:51:59] --- sbrim has joined
[14:51:59] <andrewm> Integration with HIP: good idea? How much?
[14:52:10] * sbrim thanks you for scribing
[14:52:47] <andrewm> Question: is there more detail about the authentication? Does that involve more signalling?
[14:53:02] <andrewm> A: That's not specified yet. It might.
[14:54:15] <andrewm> Michael Richardson: Mentioned SPP, which seems to him to have a very similar architecture
[14:54:25] <sbrim> what is SPP?
[14:54:46] <andrewm> I didn't catch that quite, sorry... about 10 year old draft
[14:54:56] <andrewm> MKR thought it rather validated the approach.
[14:55:11] <andrewm> There is software at http://nutss.net/
[14:55:47] <andrewm> 1345-1425 - HIP RG work on SIP and reachability (40 minutes)
              - P2PSIP prototypes and drafts:
                - Philip Matthews
                - Joakim Koskela
                - Martin Stiemerling
              - Fault tolerance configurations for HIP multihoming
              - Interaction between SIP and HIP

[14:56:41] <andrewm> HIP and P2PSIP
[14:57:06] <andrewm> p2psip is about p2p overlays for multimedia communication
[14:58:13] <andrewm> hiphop is one of 3 hip for p2psip proposals
[14:58:26] <andrewm> there is discussion about unifying already
[14:59:29] <andrewm> hiphop is overlay routing on HITs, as an extended RVS system
[14:59:46] <andrewm> Key based routing a la DHT systems
[15:01:00] <andrewm> Synthetic metric on keys, so you can go to your next closest neighbour by the metric
[15:02:14] <andrewm> No graph calculations involved (i.e. no routing protocol per se)
[15:02:31] <andrewm> Use this to set up HIP associations with hosts behind NATs
[15:06:01] <andrewm> Tim Shepard: How does a new user join? Public RVS?
[15:07:16] --- lars.eggert@googlemail.com has left
[15:07:21] <andrewm> Answer: in essence, yes.
[15:08:06] --- mrichardson has joined
[15:08:20] <mrichardson> now I can join this room. hmm.
[15:08:24] <andrewm> hiphop status
[15:08:30] <sbrim> :sprinkles magic everywhere
[15:08:44] <andrewm> Plan to submit documents to hipwg for Vancouver
[15:08:55] <mrichardson> andrewm is in fixed width font.
[15:09:06] <andrewm> Opinion: this is a compelling use for HIP
[15:09:17] <andrewm> Oh, is my client actually transmitting that?
[15:09:29] <sbrim> Does that mean documents on this particular topic --> HIPWG, or is it an appeal to get more material in HIPWG, or is it announcing impending doom for the RG, or ??
[15:09:37] <mrichardson> so... now that we have HIP for SIP, why do we actually need dtls-keyed SRTP?
[15:09:42] <sbrim> I have no problem with your being fixed font
[15:09:59] <andrewm> I just wasn't aware that that wasn't purely local.
[15:10:00] <mrichardson> I like the fixed-width.
[15:10:27] <andrewm> Encouraging HIP clue to come to p2psip on Thursday
[15:10:38] <mrichardson> I guess I just pick the right font in the toolbar I normally turn off.
[15:10:51] <andrewm> Tim Shepard: Is there code yet?
[15:11:00] <andrewm> A: Not yet, but we're working on it.
[15:11:35] <mrichardson> p2psip on thursday... seems to be: thursday morning, 9-11:30, Red Lacquer room.
[15:12:24] <andrewm> Tim: This seems like a great example for what can be done with HIP
[15:12:50] <andrewm> Next presentation, Joakim Koskela, HIP-based p2psip
[15:13:50] <andrewm> Reporting on an implementation project
[15:14:30] <andrewm> HIIT TrustInet
[15:14:42] <andrewm> about trust models in the network
[15:14:50] <andrewm> HIP provides tools
[15:15:34] <andrewm> Build a DHT on HIP connections
[15:15:40] --- elwynd has joined
[15:16:31] <sbrim> It sounds like in general, people are talking about "how to use HIP for things", as opposed to issues in HIP itself?
[15:16:34] <andrewm> Peers provide all necessary connection services... DHT, RVS etc
[15:18:54] <andrewm> sbrim: yes, which says a lot about the maturity of HIP itself
[15:19:51] <andrewm> Implementation runs on Nokia N800 tablets, and works.
[15:20:20] <andrewm> No NAT traversal yet.
[15:22:27] <andrewm> Open issues:
[15:22:47] <andrewm> Client/Peer protocol is currently minimalistic
[15:23:00] <andrewm> DHT algorithms
[15:23:02] <andrewm> etc
[15:23:19] <andrewm> Strong requirement for improving HIP NAT traversal
[15:24:08] <andrewm> Next presentation: multihoming in HIP
[15:24:15] <andrewm> Relating SHIM6 REAP to HIP
[15:24:26] <andrewm> Marcelo Bagnulo
[15:27:55] <andrewm> Simple multihoming case shows that existing -mm draft is overcomplicated for that case
[15:28:08] <andrewm> Also missing failure detection at present
[15:28:16] <andrewm> REAP is proposed for this.
[15:29:42] <andrewm> Now what about NATed multihoming?
[15:30:21] <andrewm> (can consider IPv6 global + IPv4 NAT a case of this)
[15:30:45] <sbrim> Yow
[15:31:10] <andrewm> REAP (modified) could be used for this.
[15:31:21] <andrewm> But public address discovery is still an open issue
[15:37:03] <andrewm> IPv4 situation: multihomed site, both with NATs
[15:38:03] <andrewm> Comment: isn't REAP a subset of STUN/ICE?
[15:38:35] <andrewm> differences: REAP produces less traffic under some circumstances
[15:38:53] <andrewm> Also REAP can detect unidirectional connectivity
[15:39:08] <andrewm> Suggested ICE has problems with that... or maybe not?
[15:39:55] <andrewm> Discussion time
[15:39:58] --- elwynd has left: Replaced by new connection
[15:39:59] --- elwynd has joined
[15:40:03] <andrewm> Is there synergy between HIP and EME?
[15:40:09] <andrewm> What can the RGs do?
[15:42:01] <andrewm> Me: Yes, I think so, and I recall conversations that seem like EME from a long time past.
[15:42:11] <mrichardson> RGs should have scotch bof. whichever RG has the most people standing on friday morning, wins.
[15:42:58] <andrewm> Tom: EME seems attractive from a deployment perspective. URI based names and policy configuration sounds like it could be built on top of HIP.
[15:43:13] <andrewm> HIP was intended to be middlebox-friendly, but not much work done on that yet.
[15:43:54] <andrewm> One question is, does EME really need HIP underneath?
[15:43:57] <mrichardson> if you run an EME overlay on *top* of HIP, then that means that when NAT environment disappears (future IPv6 only world), you still have that layer there.
[15:44:24] <andrewm> Or if, in the near term, your IPv6 doesn't work, you have a fallback.
[15:44:50] <mrichardson> I was thinking that EME would live under HIP, and that HIP would use EME to make that e2e connections that hip prefers possible, and so the interface above HIP would always remain the same.
[15:45:41] <guhasaikat> IMO: even after NATs disappear, (ipv6) firewalls will still be around. http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-00.txt (ipv6 firewalls draft)
[15:45:56] <andrewm> Paul F: HIP makes it possible for middleboxen to check packets on the way through.
[15:47:05] <mrichardson> that's why I care about the difference between modify and authenticate.
[15:47:42] <andrewm> Bob Briscoe: NUTSS about policy of the form allow/deny,identity but does it extend to access?
[15:47:47] <mrichardson> I am happy (in some cases) to build hop-by-hop encryption with firewalls to permit inspection and auditing, provided that I can still detect changes.
[15:48:24] <sbrim> Interesting ... so the idea is that once the EME mechanisms have been gone through, both name- and address-routed signaling, then during data flow the packets are HIPped and that helps the middleboxes be sure they are in the flow that was authenticated???
[15:48:58] <andrewm> Exactly
[15:49:09] <mrichardson> was that Melinda talking?
[15:49:12] <andrewm> Yes
[15:49:18] <sbrim> what did she say?
[15:49:33] <mrichardson> I don't know. other side of column... audio doesn't carry.
[15:49:36] <andrewm> Basically, the scope of an identity isn't that important
[15:49:41] --- Will Ivancic has joined
[15:49:56] <andrewm> It can be extended later, and as I said, you can issue identities on whatever granularity you want.
[15:50:25] <andrewm> Bob: the scope of an identity could be access to middlebox policy...
[15:50:30] * sbrim sighs at that concept "identity" again. Identifiers I can talk about. I don't know what identity is.
[15:50:50] <andrewm> Sorry... HIP people often conflate them.
[15:51:03] <andrewm> Read them as the same in what I just said..
[15:51:06] <sbrim> yup :-)
[15:51:32] <andrewm> Paul hasn't gone to delegation requests.
[15:52:33] <andrewm> Paul: why not just do ICE for NAT traversal, before doing EME for access control?
[15:52:39] <andrewm> Tom
[15:52:41] <andrewm> :
[15:52:57] <andrewm> RG is looking at clean(ish) slate approaches
[15:53:26] <andrewm> NAT traversal is a hot topic in HIP land. It's the biggest practical problem.
[15:54:13] <andrewm> ICE is, from an implementation perspective, a good way to deal with that problem.
[15:54:51] <andrewm> Paul: If you're stuck with legacy NATs, ICE is the way to go to get through them.
[15:55:57] <andrewm> Tim: NUTSS seems to provide more control over multihoming situations, does it help maintain transport during disconnections?
[15:56:02] <andrewm> Paul: Yes.
[15:56:17] <andrewm> It's even implemented.
[15:56:53] <mrichardson> this library sounds like it lives above TCP?
[15:56:58] <mrichardson> is it in the application?
[15:57:10] <andrewm> Apparently
[15:57:11] <guhasaikat> yes. at the moment.
[15:57:37] <guhasaikat> App - Nutsslib - (ICE - TCP/UDP - IP ...)
[15:57:49] <andrewm> Q: How is NUTTS different from other stuff in this space?
[15:58:22] <andrewm> Melinda: it's explicit, therefore easier to secure, and also integrates on- and off- path signalling to get the job done better.
[15:58:34] <mrichardson> with these multiple TCP sessions.... what does that mean wrt congestion control?
[15:58:37] <andrewm> Removes the need to guess who to talk to.
[15:59:00] <andrewm> On-path discovery of someone behind a NAT isn't doable.
[15:59:12] <andrewm> In general
[15:59:20] --- Will Ivancic has left
[15:59:27] <andrewm> Session close.
[15:59:37] <guhasaikat> @mrichardson: currently, only one TCP is in simultaneous use.
[16:04:47] --- PasiS has left
[16:07:53] --- elwynd has left: Replaced by new connection
[16:07:56] --- elwynd has joined
[16:07:57] --- elwynd has left
[16:09:37] --- andrewm has left
[16:19:51] --- sbrim has left
[16:20:02] --- guhasaikat has left
[16:26:50] --- mrichardson has left
[21:44:06] --- jlcjohn has left