[06:55:46] --- phragon has become available
[06:55:51] --- phragon has left
[08:21:03] --- sakai has become available
[08:23:01] --- sakai has left
[08:37:43] --- brabson has become available
[08:37:47] --- brabson has left
[08:44:10] --- sakai has become available
[08:50:10] --- sakai has left
[08:52:49] --- sakai has become available
[08:59:50] --- gih has become available
[09:01:07] --- warlord has become available
[09:02:08] --- brabson has become available
[09:02:31] --- jaltman has become available
[09:04:56] --- lisaDusseault has become available
[09:05:19] --- lisaDusseault has left: Replaced by new connection
[09:05:20] --- lisaDusseault has become available
[09:05:45] --- lisaDusseault has left: Replaced by new connection
[09:05:45] --- lisaDusseault has become available
[09:05:46] --- lisaDusseault has left
[09:05:54] --- jhutz has become available
[09:10:53] --- lisaDusseault has become available
[09:14:59] <gih> the story so far...Introduction using the duality of ip addresses as the motivator. Mobility and multi-homing are consequent challenges - well known space covered many times in the past - IRTF NSRG work cited. Noted intersection with mobility, multi-homing, security and id/locator split activity. - opportunistic host-to-host IPSEC ESP - end host mobility across v4 and v6 - end host multi-address mult-homing - v4 / v6 app interoperability new layer between IP and transport using crypto host identifiers host identifiers are their public keys, represented as "host-id tage" sockets are bound to <host-id,port> host identity translates host identity to transport identifiers (addresses) Implementation approach using DNS with host-id response (Host Identity Tag) to pass HIT to the client that looks like an IP addr. The socket API calls a connect using HIT to the IPsec security policy database This the requests a hip daemon handshake to install the security assns in each host. This then allows the security assn to create an ESP protected TCP session. Received packets undergo a similar mapping from ipaddr to HIT. protocol exchange then illustrated
[09:29:13] --- dinakar has become available
[09:48:13] --- yone has become available
[09:48:26] --- yone has left
[09:49:09] --- randy has become available
[09:59:59] --- mrose has become available
[10:02:50] <gih> Moore: HIP solves none of the claimed problems! Ans: facilitates, not solves Bound: differentiate technology vs implementation. Is this a proto standard, and what are you trying to do with such a standard? Ans: this is a proposal for expr status outcomes with info rfcs as arch description to capture current thinking of HIP. Its not quite mature enough for an Internet std (opinions differ). Implementation options in the documentation are intended to be moved to appendices. Nordmark: claimed IPR? Ans: as far as is known there may be IPRs in the puzzle, but shouldn't be any. IPSEC may have some. Fleischman: talked to Bob Moskowitz - reported that Bob's activity had no claimed IPR from him. Sommerfield: not adequate for free and clear Wasserman: lack of knowledge of IPR is not proff - we will find out as we go Metgzer: rare to see a proto wg deliberately going for expr Narten: all wg documents are covered under a must disclose rule Bellovin: requirements are standards track. Not particularly as applied to experimental Ward: need to invetigate IPR a little further and options to wg will be presented at that point, and then the wg would look at adoption ekr: how does this play with IPSEC? host app wants an IPSEC SA. Does it use HIP or IPSEC over HIP? ?: you do have the option of running IKE over HIPSEC. ?: HIP server does not have return routeability test. Certification missing. not sure how it helps with mobility. We appear to want channels to be protected and renumber the tunnel ends. The IKEv2 mobility bof appears to be more promising Nikkander: IPSEC is not the 'core' of this proposal - the essential concept is the host-to-host identity interaction. You could use DNS, or DNSSEC. The current approach is opportunistic encryption without authentication of the representation assertions. Certificates have been deliberately left out. ?: but renumbering hosts for tunnels is then an issue Kent: solution looking for a set of problems.Implementations out there without certain understanding of the problem space. Nikkander: the problem is the identifier / locator split. This is a potential answer without full knowledge of the space Kent: its more than just this problem. We don't understand the constraint space. Nikkander: this is a charter discussion topic [demo] Moore: A more wonderful demo please! work: architecture draft info to rfc to base protocol spec closing on completion, with some open issues left proposal for esp extensions (BEET mode) (bound end-to-end tunnel mode) translates inner to outer addresses on output draft on multi-addressing with proposed soln needing to be re-worked and packet formates to be updates and QoS properties DNS interactions -no drafts yet. need a methid to store HIs or HITs NAT traversal - no drafts yt, but need to be aligned with multi-addressing. Possible: let NATs leans SPIs from HIP messages, setting SPI-based NAT (rather than just using UDP tunnels) rendezvous and proxy server spec required for simultaneous mobility.
[10:04:28] --- perry has become available
[10:06:47] --- falk has become available
[10:10:06] --- mrose has left
[10:10:21] --- mrose has become available
[10:16:05] --- brabson has left: Replaced by new connection
[10:16:08] --- gih has left: Disconnected
[10:16:13] --- sakai has left
[10:17:15] --- falk has left: Replaced by new connection
[10:18:42] --- gih has become available
[10:18:47] --- brabson has become available
[10:21:16] --- sakai has become available
[10:21:22] --- lisaDusseault has left: Replaced by new connection
[10:24:43] --- randy has left: Disconnected
[10:30:50] --- hta has become available
[10:34:32] --- dinakar has left: Disconnected
[10:34:44] --- sakai has left
[10:34:46] --- hta has left: Disconnected
[10:35:33] --- gih has left: Disconnected
[10:36:21] --- sakai has become available
[10:38:25] --- hta has become available
[10:38:46] --- hta has left
[10:38:50] --- hta has become available
[10:38:52] --- hta has left
[10:39:00] --- hta has become available
[10:39:43] <hta> one good thing about running an experiment in the IETF is that there is a known set of rules for IPR.....
[10:40:22] <perry> The IETF doesn't do enough experiments, IMHO.
[10:40:55] <perry> We have this false idea that you come up with a final architecture fully formed by thinking enough.
[10:41:04] <perry> in fact, in the real world it is always iterative refinement.
[10:41:07] --- mark.ellison has become available
[10:41:15] --- falk has become available
[10:42:16] --- leslie has become available
[10:45:41] --- randy has become available
[10:45:44] <jhutz> yes, of course it is. but there's a difference between "experiments" and engineering. The latter really should start with a specified problem; otherwise you're just playing
[10:45:56] --- gih has become available
[10:47:14] <perry> playing is how most things actually get figured out.
[10:47:27] <perry> my favorite essay on this was by Sussman on how scheme was really designed
[10:47:47] <perry> and the answer was, it did not burst forth fully formed. iterative playing built it.
[10:48:13] <perry> BTW, IPv4 was constructed much the same way
[10:48:24] <warlord> Which is amusing considering how scheme uses recusion and tries NOT to use iteration...
[10:48:26] <perry> the early designs were very different, and much playing was done.
[10:48:35] <warlord> "Experimental"
[10:48:37] <perry> warlord: hehehehe
[10:49:02] <jhutz> of course it didn't; nothing does. I'm not saying engineering isn't iterative refinement. But it's iterative refinement with a goal; you have some idea what you're working toward, and know how to tell if you've achieved it.
[10:50:25] <warlord> We're having the HIP discussion in AppsArea
[10:50:46] <jaltman> I thought the IRTF was meant for architectural experiments
[10:51:54] <perry> The IRTF hasn't been as successful at that as we would like.
[10:51:56] <warlord> IRTF is a research area for when you dont know HOW to solve a problem.
[10:52:12] <warlord> with HIP we know how to solve the problem, just not which approach works best.
[10:52:45] <jhutz> The IRTF is an appropriate place for cool technology in search of a solution, or even not bothering to search for a solutioin.
[10:52:50] <perry> I'm not convinced HIP is that fully formed, but it is at the point where they have running code. There are still big holes.
[10:53:00] <jhutz> The IETF is an appropriate place for actually trying to solve problems.
[10:53:03] <perry> But for years I heard people say "show me EIDs working" and here, they've shown us EIDs working.
[10:53:17] <perry> So we at the very least shouldn't cut them off at the knees for doing what we all demanded for years.
[10:54:25] <jhutz> they should decide whether they're doing research or trying to develop a standards-track protocol. They don't seem to know.
[10:55:08] <jhutz> If they think they're trying to do research, they should go to the IRTF.
[10:55:13] <perry> okay, put it another way: if they succeed, we have protocol documents we can use as a basis for future work. if they fail, nothing harmful has happened.
[10:55:49] <warlord> jhutz: i dont think they are trying to do research. I think they want to make a standar.d
[10:55:52] <jhutz> If they're trying to develop a standard, they should admit that, indicate what the standard is _for_, and accept that you don't come to the IETF with a complete spec and say "please standardize this"
[10:56:10] <perry> you do come to the IETF with a spec pretty often.
[10:56:16] <perry> remember, the IETF did not design TCP. :)
[10:56:29] <perry> and much successful stuff like ssh and http was not designed here initially.
[10:56:38] <gih> if you dont come to the IETF with a spec for stdization, why do you come?
[10:56:57] <perry> for the cookies.
[10:57:03] <jhutz> Note that the ssh that we're about to publish as a proposed standard looks nothing like sshv1
[10:57:05] <gih> sorry - forgot!
[10:57:10] <jhutz> ==perry
[10:57:21] <perry> sure, but tatu came to ietf with a fully formed protocol. we then fixed problems in it.
[10:57:55] <gih> standardization is not a ruibber stamp - standardization may (or may not) make changes to a spec. But you come to the ietf to standardize a specification!
[10:58:07] <jhutz> but seriously, when you come to the ietf with a spec, you have to expect the IETF to make changes.
[10:58:11] <perry> of course
[10:58:14] <perry> but they want changes
[10:58:21] <gih> yes - and I don't see cement around HIP
[11:00:10] <jhutz> are steve or russ in this room?
[11:00:43] <warlord> russ is in msec.
[11:09:22] <perry> we are bogging down in process here
[11:11:52] <jaltman> the app area is proposing another HIP meeting on wednesday
[11:12:27] --- brabson has left
[11:12:32] --- gih has left
[11:12:50] <mrose> hardie: we'll try to setup a weds 1530-1730 slot...
[11:13:07] --- perry has left: Logged out
[11:13:08] --- perry has become available
[11:13:08] --- perry has left: Logged out
[11:13:08] <mrose> oops
[11:13:34] <jhutz> we just finished. folks interested should pay attention to the mailing list; there is a URL to the archives contained in the proposed HIP charter (see the BOF agenda)
[11:13:43] <jhutz> http://honor.trusecure.com/pipermail/hipsec
[11:13:49] <jhutz> I also sent that to the 'appsarea' conference
[11:19:50] --- sakai has left
[11:19:55] --- mark.ellison has left
[11:20:12] --- warlord has left
[11:21:00] --- falk has left: Disconnected
[11:22:04] --- hta has left: Disconnected
[11:23:15] --- leslie has left
[11:29:05] --- jaltman has left: Disconnected
[11:30:30] --- mrose has left
[11:38:37] --- jhutz has left: Logged out
[11:38:39] --- jhutz has become available
[11:38:39] --- jhutz has left: Logged out
[13:01:24] --- randy has left: Disconnected
[14:52:52] --- hardie has become available
[14:53:10] --- hardie has left