[02:12:16] --- mrichardson has left
[09:06:51] --- mrichardson has joined
[09:06:57] --- mrichardson has left
[09:07:07] --- mrichardson has joined
[10:14:00] --- LOGGING STARTED
[10:16:47] --- mrichardson has joined
[10:19:28] --- mrichardson has left: Logged out
[10:19:36] --- mrichardson has joined
[12:59:30] --- LOGGING STARTED
[13:01:22] --- dennis_f has joined
[13:01:22] --- dennis_f has left: Lost connection
[13:01:23] --- dennis_f has joined
[13:01:30] --- dennis_f has left
[13:03:30] --- LOGGING STARTED
[15:31:08] --- Thierry has joined
[15:31:59] --- Thierry has left
[15:36:42] --- mrichardson has joined
[15:36:47] --- Thierry has joined
[15:37:53] --- Thierry has left
[15:39:09] --- Thierry has joined
[16:01:00] --- Thierry has left
[16:13:49] --- jimsch1 has joined
[16:19:21] <mrichardson> hi.
[16:20:48] --- pguenther has joined
[16:21:07] <mrichardson> plea for notetakers.
[16:21:12] <mrichardson> welcome.
[16:21:32] <mrichardson> audio feed: http://videolab.uoregon.edu/events/ietf/
[16:22:42] --- jhutz has joined
[16:23:12] <mrichardson> WG background summary of three different groups of people: off-path, channel-bindings,SSH leap-of-faith.
[16:24:46] --- raeburn has joined
[16:25:53] --- rstory has joined
[16:27:00] <jhutz> joe touch is giving an update on problem statement
[16:27:15] --- dennis_f has joined
[16:27:33] <mrichardson> sec1 - removed redndant text.
[16:27:43] <mrichardson> sec2 -- added net layer motivation
[16:27:49] <mrichardson> sec3 - overview
[16:27:55] <mrichardson> sec4 - remove moves
[16:28:03] <mrichardson> sec5- security considerations
[16:28:04] --- yjs has joined
[16:28:21] <mrichardson> sec4 - remove modes
[16:28:38] <mrichardson> 15 issues posted in dec.
[16:28:58] <jhutz> Joe's slides online at http://www3.ietf.org/proceedings/06mar/slides/btns-1.pdf
[16:30:02] --- dumdidum has joined
[16:30:10] <jhutz> Steve Kent : First of those two [reasons for #3] good; other not so much.
[16:30:41] <jhutz> Joe: That [no API] is just a reason we mentioned; we agree that alone would not be sufficient.
[16:31:56] <jhutz> 4 issues not addressed in as much detail as we wanted...
[16:32:06] <mrichardson> not addressed: #8; AS for SAB and CBB.
[16:32:26] <jhutz> #8: AS sort of merges things together for SAB and CBB. He [sam] suggested separating out. We're not sure...
[16:32:33] <mrichardson> #9: IKE vs CBB strength.
[16:33:35] <jhutz> #14 leap of faith.
[16:33:39] <jhutz> need to discuss this further.
[16:33:55] --- dennis_f has left: Lost connection
[16:33:55] --- yjs has left: Lost connection
[16:34:04] --- sharonchisholm has joined
[16:34:14] <jhutz> If someone could help clarify exactly what LOF is, that would help.
[16:34:26] --- hartmans has joined
[16:34:27] <jhutz> Again, looking for suggestions of actual text to insert in the document.
[16:35:24] --- nico has joined
[16:35:35] <jhutz> Next steps... seeking another round of feedback. Would like the next version to be the one people examine w/ fine toothed comb, get lots of detail stuff in. Not necessarily last-call.
[16:35:46] <jhutz> lha: Who is going to volunteer to read this and give feedback?
[16:35:52] <jhutz> Sam, Michael
[16:36:00] <jhutz> who else? different people would be good
[16:36:03] --- kivinen has joined
[16:36:06] <jhutz> or should I just pick people and nag?
[16:36:11] <jhutz> ... no answer ...
[16:36:16] <jhutz> lha: will pick people and nag
[16:36:26] <jhutz> pekka: would like to get some cross-area review
[16:36:37] <jhutz> please let us know if you have suggestions of people in other areas we can ask
[16:36:42] <jhutz> ... waiting for nico's slides ...
[16:39:13] <jhutz> Nico's slides are up. Will be on the web page soon.
[16:39:21] <jhutz> PAD and BTNS extensions...
[16:39:43] <jhutz> nico:...
[16:40:00] <jhutz> btns nodes have some credential. authenticate as usual. authorized by a PAD entry.
[16:40:26] <jhutz> Last PAD entry should use a (newly-defined) wildcard matching extension to match BTNS peers.
[16:40:53] <jhutz> Nico's slides online at http://www3.ietf.org/proceedings/06mar/slides/btns-2.pdf
[16:41:25] <jhutz> ... SPD's should have a "BTNS OK" flag
[16:41:49] <jhutz> [NB: last bullet on slide is a typo; should say "SPD extension" not "BTNS extension"]
[16:42:06] <jhutz> <speaker>: Where does PUBLICKEY ID type appear?
[16:42:09] <jhutz> Nico: Not on the wire
[16:42:19] <jhutz> <speaker>: Does it say where?
[16:42:23] <jhutz> Nico: Local matter.
[16:42:27] <mrichardson> speaker is Stephen Kent.
[16:43:09] <jhutz> [thanks, but then I lost the gist of his argument]
[16:43:58] --- Thierry has joined
[16:44:08] --- dumdidum has left: Replaced by new connection
[16:44:19] <jhutz> Nico: scope of these ID's is local; not specified in draft
[16:44:49] <jhutz> Sam: Why do the semanics not need to be specified?
[16:45:13] <jhutz> Nico: They're never used on the wire
[16:45:25] <jhutz> Sam: No use of ID's in 4301 on the wire either
[16:45:57] <jhutz> Nico: It would be useful to know in what way you think it's insufficiently specified.
[16:46:07] <jhutz> Steve Kent: I think that's asking the question the wrong way.
[16:46:26] <jhutz> It's preferable you explain to people what are implications of what you're describing.
[16:46:45] <jhutz> How can people expect compliant implementations to behave?
[16:46:54] <jhutz> If I want to build this, where do I need to add hooks
[16:47:10] <jhutz> Nico: OK; I thought you were asking for more.
[16:47:17] <jhutz> Example [see slide]
[16:47:43] --- dumdidum has joined
[16:48:59] --- jimsch1 has left
[16:49:54] <jhutz> Nico polling people to see who read the document
[16:50:01] <jhutz> Michael Richardson:
[16:50:17] <jhutz> ... I think the document is quite short; uses some pretty specifc language
[16:50:31] <jhutz> ... problem is that to understand what it says, you have to read 4301 several times over.
[16:50:39] <jhutz> Nico: It took that to write it
[16:50:55] <jhutz> Michael: I read it and can't disagree with anything that's there; it all looks great, but I can't
[16:51:06] <jhutz> eval against large volume of 4301.
[16:51:13] <jhutz> If you wrote more text, we'd probably argue with you more.
[16:51:30] <jhutz> Question is, is the text there sufficient for an implementor to get it.
[16:51:41] <jhutz> I think it is, but I think I already know what it's supposed to say, so am not a good judge.
[16:51:53] <jhutz> Joe Touch: My impression was it was written like a patch to 4301.
[16:51:59] <jhutz> would be great if we were computers.
[16:52:13] <jhutz> would be good to provide enough of a summary of other things, then point off into it as needed
[16:52:23] <jhutz> The danger there is for the summary to be wrong.
[16:52:32] <jhutz> Nico: Make it non-normative.
[16:52:38] <jhutz> Joe: Needs a background section.
[16:52:55] <jhutz> Steve Kent: I didn't read this version, but remember making comments like this on the last version.
[16:52:58] <jhutz> It's too terse.
[16:53:07] <jhutz> You need to explain what it needs to do, why it does it.
[16:53:20] <jhutz> s/why/why they sholuld believe/
[16:53:26] <jhutz> ...
[16:53:40] <jhutz> sec cons needs to show why your method doesn't undermine the access control model
[16:54:08] <jhutz> Steve: When I read the last version, one of the comments was it might be too terse.
[16:54:14] <jhutz> That doesn't make it easy for implementors.
[16:54:28] <jhutz> Nico: Sure. At this point, aiming for review from people familiar with 4301
[16:55:18] <jhutz> <who is this?> quick question for sam/chairs
[16:55:30] <jhutz> nico pointed out you could use either self-signed certs or raw rsa keys
[16:55:44] <jhutz> is there a plan to specify which is required, both, ???
[16:56:04] <sharonchisholm> He has a blue dot if that helps ...
[16:56:06] <jhutz> [chair points at bullet point for this isse]
[16:56:30] <jhutz> sam hartman: In section 2, you have second modification to IPsec model is you create a new PAD entry
[16:56:41] <jhutz> ... intended to fall at the end of the PAD, for BTNS
[16:56:49] <jhutz> ... matches peers you haven't seen before
[16:56:59] <jhutz> ... but didn't say ID's are coerced to type publickey after matching this thing
[16:57:12] <jhutz> [naw, half the speakers have dots]
[16:57:22] <jhutz> ... we've already done PAD matching; where will I use the ID again?
[16:57:39] <jhutz> Nico: You might use it to create new SPD entries matched by ID, or new PAD entries matched by ID, or in channel bindings
[16:58:07] <jhutz> Sam: In draft today, I don't see a modification to the ipsec processing model that allows that coercion to do anything.
[16:58:23] <jhutz> nico: The only thing this draft does with those ID's is allow matching of SPD's by ID.
[16:58:29] <jhutz> Sam: But I'd have to create them
[16:58:33] <jhutz> Nico: Yes, but it's out of scope
[16:58:42] <jhutz> Sam: You need to say that.
[16:58:55] <jhutz> Sam: You need to say impls must search SPD for entries of type publickey
[16:59:05] <jhutz> Nico: I see what you're saying. I think sec cons may say something about LOF out of scope
[16:59:14] <jhutz> Sam: But impl behavior is in scope; needs to be done
[16:59:42] <jhutz> nico: To allow creation of SPD's that reference speciifc DNS peers... must make these ID's available, be able to create PAD entries matching specific ID's
[16:59:51] <jhutz> sam: Need to go through some of the implications
[17:00:12] <jhutz> ... if a BTNS PAD entry can assert an IPaddr, that can appear in an SPD. You need to indicate that works, or forbid it.
[17:00:20] <jhutz> ... and expand on similar kinds of things
[17:00:30] <jhutz> Sam: Sanity check: Goal of your spec is to do N things:
[17:00:54] <jhutz> 1) Need to provide enough impl imperatives that two impls are guaranteed to be interoperable
[17:01:17] <jhutz> 2) Need to provide enough impl advice that probability of significant # of impls making the same error is low
[17:01:35] <jhutz> Sam: Not sure if you've done (1), definitely haven't done (2).
[17:01:53] <jhutz> Michael: Sam's point is, if we all get it wrong, we'll interop but be getting it wrong.
[17:02:28] <jhutz> Reduce chance we'll all make the same trivial mistake/security bug, instead we make "hard" bugs and fail to interop
[17:02:37] <jhutz> Nico: Maybe I could get an implementor as a co-editor?
[17:02:37] --- tanupoo has joined
[17:02:43] <jhutz> [ Michael volunteers ]
[17:03:18] <jhutz> Nico's updated slides at http://www3.ietf.org/proceedings/06mar/slides/btns-2.pdf
[17:03:24] <jhutz> Connection latching:
[17:03:29] <jhutz> [see slides]
[17:06:25] <jhutz> Michael Richardson: I think it's important this get written down somewhere.
[17:06:33] <jhutz> Not sure this is the only way to do it, but not arguing that point.
[17:06:47] <jhutz> Real question is not how does it happen in the stack, but what are the semantics for interaction with other peers.
[17:07:08] <jhutz> Why do we care in this WG?
[17:07:18] <jhutz> My opinion is that w/o connection latching, we can't make BTNS work through a NAT.
[17:07:27] <jhutz> If we want it to work through a NAT, we have to have conn latching.
[17:07:39] <jhutz> Nico: Haven't thought about it.
[17:07:52] <jhutz> Michael: Unclear if CL is the only way to make channel binding work right.
[17:08:09] <jhutz> You can probably do it through proper provisioning/config, but CL is more convenient.
[17:08:24] <jhutz> But no way I can write SPD entries for each 192.168.x.y behind different people's NAT's.
[17:08:34] <jhutz> Nico: This isn't intended to provide impl advice.
[17:08:44] <jhutz> Michael: You have a design spec here
[17:09:01] <jhutz> Nico: The slide is written that way; the draft talks about who needs to provide what to whom when.
[17:09:09] <jhutz> Doesn't talk about impl details.
[17:09:23] <jhutz> ... As for what it does - protects you against reconfiguration.
[17:09:31] <jhutz> Against things we discussed on the list
[17:09:37] <jhutz> Provides a channel you can bind to.
[17:09:58] <jhutz> Michael: <missed this; you fill it in>
[17:10:08] <jhutz> Nico: Might be worth discussing this more on the list...
[17:10:24] <jhutz> Sam Hartman: Question for Michael about NAT's you seem to think exist on the internet
[17:10:26] <jhutz> <laughter>
[17:10:41] <jhutz> Sam: (BTW, Nico, need to nail down things like whether we support tunnel mode)
[17:10:54] <jhutz> ... So, in transport mode, I don't understand the NAT problem.
[17:11:13] <jhutz> Michael: I asked some time ago, are we going to do transport or tunnel.
[17:11:32] <jhutz> A number of people said they wanted transport; I preferred /32-/32 tunnels, but indifferent
[17:11:49] <jhutz> If we're going to use tunnel mode w/NAT traversal, we'd have to figure out what IP addr to use inside the tunnel.
[17:12:06] <jhutz> Don't know what we'd conclude, but...
[17:12:07] <jhutz> ...
[17:12:37] <jhutz> If we're going for transport mode, you get the original IP when the packet left the box (behind the NAT), and in some logical sense, you restore that address to the header.
[17:13:08] <jhutz> When the (hopefully non-natted peer) gets that packet <missed this>
[17:13:18] <jhutz> Sam: Why do you want that behavior? Why not keep the outer address?
[17:13:53] <jhutz> Michael: Suppose we have a conn from my browser (192.168.1.1:1024) to your server (routable 80)
[17:14:11] <jhutz> On the outside, you see 63.x.y.z:40000. Are you going to restore the port number?
[17:14:22] <jhutz> Why we need CL: All the peers behind all the NAT's have the same IP address.
[17:14:32] <jhutz> Once we restore the addrs, well, it looks really wierd.
[17:14:54] <jhutz> CL gets rid of this problem because we have the IPsec SA # as an additional index
[17:15:05] <jhutz> Sam: For channel bindings, not a big deal.
[17:15:13] <jhutz> For CL, you've made significant changes.
[17:15:25] <jhutz> Michael: I claim my changes are invisible outside my host, so out of scope:
[17:15:44] <jhutz> Sam: Agree on first part, but not second. All sorts of things invisible outside the host are specified.
[17:16:07] <jhutz> Michael: I"ve argued against that for 10 years. It constrains things unnecessarily
[17:16:18] <jhutz> Sam: I hear you. It is not the job of this WG to change that consensus.
[17:16:42] <jhutz> Nico: You're saying you want to dispatch not only on the 5-tuple, but also on the latch?
[17:16:52] <jhutz> Michael: Point to PCB from latched SA
[17:16:58] <jhutz> Nico: SA's don't necessarily match one flow
[17:17:11] <jhutz> Michael: Yes; essentially adding another selector to the protocol control block
[17:17:14] --- dennis_f has joined
[17:17:14] --- dennis_f has left: Lost connection
[17:17:22] <hartmans> O, so we're changing TCP as well as 4301?
[17:17:22] <jhutz> ... SA+SPD entry has to survive rekeys, etc; makes it complicated.
[17:17:41] <jhutz> But have to - have to disambiguate all the 192.168.1.1's _and_ figure out how to send the replies
[17:17:56] <jhutz> One suggestion: NAT again between the IPsec and higher layers
[17:18:30] <jhutz> Steve Kent: Michael, if your impl externally looks like what 4301 requires, there's not a problem
[17:18:37] <jhutz> ... but I also don't understand what your concern is.
[17:18:49] <jhutz> ... descriptions in 4301 for modelling SPD is there so we have a management interface that
[17:18:56] <jhutz> provides minimal functionality for users.
[17:19:08] <jhutz> If we didn't do that, you could claim to do IPsec but no one could figure out how to make it work.
[17:19:14] <hartmans> Can I get the chairs to rule the discussion of the purpose and design goals of IPsec out of scope?
[17:19:23] <jhutz> Of course, you're free to rule it out of scope.
[17:19:30] <jhutz> [sam, maybe, but neither is reading here]
[17:19:59] <hartmans> I don't want to do that. I was hoping they were reading here.
[17:20:13] <jhutz> lha: I think we decided in paris we need tunnel mode
[17:20:33] --- sharonchisholm has left
[17:21:21] <jhutz> ["you're free..." wasn't a reply to you sam; I was quoting someone
[17:21:47] <jhutz> Pekka, from the floor: I admit I don't follow all the details, but especially given how Michael described an impl might work,
[17:22:02] <jhutz> ... there is some similarity to what might come up tomorrow in mobike wrt optimizing tunneling.
[17:22:17] <jhutz> ... by rewriting IP header instead of encapsulating, provided you can reverse at the other end.
[17:22:30] <jhutz> ... Here, if you have full info about what the latch does, you could do something similar,
[17:22:36] <jhutz> ... but it doesn't solve the sec problem.
[17:22:42] <jhutz> Sam: I don't know the answer, but....
[17:22:46] <jhutz> I think this is a charter bug...
[17:22:56] <jhutz> To what extent do we (BTNS) care about mobility?
[17:23:23] <jhutz> Pekka: I don't have any answer either, but MHO is that we want these things to be really usable in the current IPv4 net.
[17:23:30] <jhutz> Many of the mobility and NAT issues are similar
[17:23:47] <jhutz> Michael: I could be mistaken, but I believe that most of the time mobike will be used in a tunnel mode,
[17:24:01] <jhutz> ... where the end roaming thing will actually have an address it can use on the inside of the tunnel.
[17:24:13] <jhutz> ... When the packet arrives, the address it will see is the assigned addr on the inside of the tunnel.
[17:24:22] <jhutz> ... Doesn't matter how much stuff got rewritten on the outside.
[17:24:39] <jhutz> ... I think that mobike and BTNS should be sufficiently orthogonal that we don't have overlap of spec concern
[17:24:48] <jhutz> pekka: mobike will be tunnel; <...>
[17:24:55] --- dennis_f has joined
[17:25:12] <jhutz> [correction; this is tero]
[17:26:12] <jhutz> Nico: Michael, if there is interest in solving the NAT problem, you could contribute text to this draft or write a separate one
[17:26:18] <jhutz> ...
[17:26:39] --- dumdidum has left: Replaced by new connection
[17:26:45] <jhutz> Pekka: Returning to Sam's question. My feeling is that if we do BTNS without thinking about mobike,
[17:26:49] <jhutz> there will be <xxx>.
[17:27:08] <jhutz> Need to be careful not to create dangerous combinations which break security because of interactions between btns and mobike
[17:27:22] <jhutz> ... probably could be done after the base work is done. impl guidelines, etc.
[17:27:34] <jhutz> Nico: CL is about making sure you don't accidentally send your packet flows to a different peer
[17:27:38] <mrichardson> maybe, at least to prove that there are no such situations
[17:27:43] <jhutz> ... as a result of reconfig that might result from mobility.
[17:27:55] <jhutz> ... If I understand, you're saying btns needs CL
[17:27:59] <jhutz> Chair: Any other questions?
[17:28:13] <jhutz> ... Who should I nag to read Nico's doc?
[17:28:19] <jhutz> Sam: People from tcpm
[17:28:30] <jhutz> David Black: me
[17:28:37] <jhutz> Chair: anyone else?
[17:28:55] <jhutz> Chair (lha): Have some old but still open issues
[17:29:13] --- dumdidum has joined
[17:29:17] <jhutz> Love's slides at http://www3.ietf.org/proceedings/06mar/slides/btns-0.pdf
[17:29:32] <jhutz> #1 - exact details of SPD/PAD extensions
[17:29:40] <jhutz> #2 - do we need IKE extensions?
[17:30:01] <jhutz> #1, #2 are part of Nico's doc. Questions is, is Nico's doc enough for this?
[17:30:10] <jhutz> Pekka: Simple milestone question. Basically, are these done?
[17:30:13] --- dumdidum has left
[17:30:16] <jhutz> Or does someone feel there is something missing?
[17:30:30] <jhutz> Michael: I think we concluded there needs to be more text
[17:30:57] --- dumdidum has joined
[17:31:07] <jhutz> Love: But what we're asking is is the basic idea OK; does/will it handle these items
[17:31:13] <jhutz> Michael: I think so
[17:31:33] <jhutz> Nico: One comment was we need an informational section describing 4301+BTNS; few people can apply the "patch"
[17:31:46] <jhutz> ... was a request for more sec cons expaining what this does/doesn't do, how it doesn't break things
[17:32:02] <jhutz> Pekka: From the process POC, sounds like we can close these items and move discussion to Nico's document.
[17:32:32] --- Jeffrey Altman has joined
[17:32:35] <jhutz> Micheal: Wrt #2: We do not require any IKE extensions. Depending on answer to #4 [bare keys vs self-signed certs]
[17:32:48] <jhutz> we may need to detail cert payload, but not really an extension.
[17:33:04] <jhutz> I would like to see us write an IKE notify that expresses the fact a peer believes it is in BTNS mode.
[17:33:13] <jhutz> Exists for auditing and debugging; non-critical extension.
[17:33:22] <jhutz> Compliant implementation would not need any IKE extensions.
[17:33:32] <jhutz> Pekka: Are you volunteering to write that?
[17:33:39] <jhutz> Michael: I think I am already coauthor on that doc.
[17:33:47] <jhutz> Pekka: Sounds like we're done with #1,2
[17:33:56] <jhutz> What about #3 - auto detection of BTNS ?
[17:34:12] <jhutz> Michael: Thought it was explicitly out of scope per problem statement.
[17:34:19] <jhutz> Determining if other end is BTNS-capable is out of scope.
[17:34:41] <jhutz> David: I think this is out of scope - auto-detection of BTNS is just a special-case of auto-detecting
[17:34:53] <jhutz> whether the other end is going to like the cert you're about to send. No good way to do that in IKE
[17:35:00] <jhutz> either; we're not justified in holding BTNS to a higher standard.
[17:35:12] <jhutz> Michael: Are we still at #3? I think it's out of scope.
[17:35:27] <jhutz> Pekka: Sounds like we're done with #3. On to #4; bare-keys vs self-signed certs.
[17:35:42] <jhutz> Michael: I vote for self-signed certs as MUST implement. If what you have is a self-signed cert, you
[17:35:56] <jhutz> can easily pull out a bare key. If what you have is a bare key, making a self-signed cert is hard.
[17:36:19] <jhutz> OTOH, I think it would be acceptable for an impl to send a bare key and, if it has one, a self-signed cert, and, if it has one, a huge cert chain. :-)
[17:36:32] <jhutz> ... but if you're claiming to do BTNS, you must have the first (bare key).
[17:36:42] <jhutz> Sam Hartman: Is there a way fo sending a bare key in a cert payload?
[17:36:49] <jhutz> Nico: Yes; not sure it's required.
[17:37:03] <jhutz> Michael: I know now to do it; the spec is not entirely clear on what the format is.
[17:37:13] <jhutz> I don't think it will take long to agree what it is; we just haven't written it down.
[17:37:28] <jhutz> <XXX>: Written down in IKEv2 clarifications, in IKEv2bis.
[17:37:43] <jhutz> Pekka: Michael told us his opinion. Anyone else?
[17:37:54] <jhutz> OK; let's hum
[17:38:01] <jhutz> In favor: <some>
[17:38:05] <jhutz> Against: <silence>
[17:38:21] --- sharonchisholm has joined
[17:38:33] <jhutz> Nico: Question for Sam... was proposal to drop ??? motivated by this?
[17:38:46] <jhutz> If you send a bare RSA key, will there be non-BTNS peers that don't support that?
[17:38:56] <jhutz> Sam: Nico, you haven't read Joe's draft; this is not that; will explain later.
[17:39:06] <jhutz> Pekka: Room consensus was to use bare keys as MUST; need to take to list.
[17:39:09] <jhutz> Done with open issues.
[17:39:21] <jhutz> Other issues on the table...
[17:39:25] <jhutz> API document
[17:39:39] --- dumdidum has left: Replaced by new connection
[17:41:47] <jhutz> <ack; missed a bunch here>
[17:41:59] <jhutz> Pekka: Sounds to me like we may not need any more documents.
[17:42:05] <jhutz> Nico: Leap of Faith
[17:42:16] <jhutz> David: Someone needs to volunteer to write it.
[17:42:23] <jhutz> Michael: Argument why we don't need more docs.
[17:42:28] <jhutz> CL has to describe it.
[17:42:41] <jhutz> If you're doing UDP with an unconnected socket, CL happens in your app.
[17:42:53] <jhutz> Guess it's the same for SCTP in unconnected mode.
[17:43:11] <jhutz> Sam: Please carefully consider this issue. I don't remember specific text of charter.
[17:43:22] <jhutz> ... charter is what guides here; I don't want you to go outside your charter.
[17:43:57] <jhutz> We don't have a recommendation for interfaces for vendors to provide to do things like manipulate SPD's.
[17:44:26] <jhutz> Recommendations for...
[17:44:34] <jhutz> ... where ipsec protection barrier goes
[17:45:01] <jhutz> ... how to think about how to model ipsec such that multiple apps using ipsec as lower-layer security (btns or otherwise) can coexist.
[17:45:20] <jhutz> ... I can't ask people to use 4301 when they come and say "I want to use IPsec to secure my protocol".
[17:45:50] <jhutz> Tried to get OSPF to do it, and the result was more documentation is required before I'm willing to try to force people to do that
[17:46:01] <jhutz> IMHO things in BTNS charter are close to this.
[17:46:26] <jhutz> Steve Kent: the problem here is frequently the WG may go to AD's and say "I want to use IPsec to secure my protocol"
[17:46:44] <jhutz> ... thinking IPsec is like TLS; provides a channel but no access control.
[17:47:04] <jhutz> Use IPsec not to secure a protocol, but as part of security of a system.
[17:47:20] <jhutz> Have to figure out what they're trying to accomplish.
[17:47:27] <jhutz> Sam: That's not what they want.
[17:47:33] <jhutz> Steve: Can't always get what you want
[17:47:49] <jhutz> Sam: I think we can give it to them; the output of this WG provides flexibility so IPsec can be used to meet those.
[17:48:16] <jhutz> ...
[17:48:32] <jhutz> Problem is either system is not easy to deploy, or multiple deployments can coexist in single system.
[17:49:05] <jhutz> Steve: <missed this>
[17:49:15] <jhutz> Nico: Sam, did I understand you want specific API's, not abstract ones?
[17:49:25] <jhutz> Sam: Things I would find useful as a protocol designer...
[17:49:41] <jhutz> - recommendation to implementors that they have a standardized way of thinking about SPD's so
[17:50:08] <jhutz> ... I (OSPF, iSCSI, etc) can add the access control rules for my app to the SPD in a way that coexists with other apps in the environment.
[17:50:13] <jhutz> - A model for XXX
[17:50:24] <jhutz> - A model for how to think about the protection barrier
[17:50:38] <jhutz> - A model for how to think about SPD... Able to say "traffic out interface X must be secured".
[17:50:55] <jhutz> - Lots of OS's let you open a socket and assert a security policy like traffic over that socket must be protected.
[17:51:09] <jhutz> defining stuff in that space would be useful. Not API's but generic interfaces.
[17:51:17] <jhutz> Nico: wrt CL, I think that's in that draft.
[17:51:28] <jhutz> WRT management of SPD's, not. But that could be a different doc.
[17:51:58] <jhutz> David Black: Second Sam's comment. Filling in the details would be quite useful.
[17:52:29] <jhutz> ... We've been through the adventure of adapting 2401 to deal with ISCSI.
[17:52:37] <jhutz> ... definitely room for improvement in this area.
[17:52:53] <jhutz> Given one of the goals of this WG is to produce a mode to support upper-level protocols,
[17:53:00] <jhutz> filling in these gaps seems reasonable.
[17:53:19] <jhutz> Love: There seems to be some interest.
[17:53:28] <jhutz> Nico's document partway there, not all the way.
[17:53:54] <jhutz> <who?>: Read Nico's document; tempting to say do API in same document
[17:54:00] <jhutz> Love: Are you volunteering to coauthor?
[17:54:15] <jhutz> <xxx> Not really; not familiar with channel bindings, CL, but will review.
[17:54:23] <jhutz> Michael: Sam, I think this is outside our mandate.
[17:54:29] <jhutz> Suggest it deserves a new WG.
[17:54:35] <jhutz> It might be in the transport area.
[17:55:00] <jhutz> This was a work item of IPSP, which was killed after not going anywhere.
[17:55:23] <jhutz> Tragedy of the commons wrt detailed sockets API. Everyone wants a universal one; hard to do it.
[17:55:45] <jhutz> This is a big job; I'd like to see it done right, and in an new WG.
[17:55:47] --- dumdidum has joined
[17:55:57] <jhutz> Sam: I looked at the charter; effectively we picked up that item from IPSP.
[17:56:11] <jhutz> ... Maybe we can go back and look at that discussion.
[17:56:17] <jhutz> Here's where the break-point is....
[17:56:30] <jhutz> Describing what interfaces impls should provide is within our mandate.
[17:56:41] <jhutz> Describing how to use those intfs to secure higher-layer protocols is not.
[17:57:05] <jhutz> ... read draft-bellovin-useipsec-04.txt
[17:57:14] <jhutz> ... Steve describes some gaps; we're supposed to fill them in.
[17:57:28] <jhutz> Love: So, you're saying we should describe an interface, and hope it's useful?
[17:57:46] --- sharonchisholm has left
[17:58:01] <jhutz> Sam: It would be more clever to do it in conjunction with someone who's doing Steve's draft for some protocol
[17:58:13] <jhutz> Love: ... and you have a list of people for me to talk to?
[17:58:17] <jhutz> sam: Uh, no.
[17:58:36] <jhutz> If you don't want to do this right now, don't. I'm saying this is something that would be useful to me as an AD.
[17:58:50] <jhutz> ... If there aren't enough people, creating a new WG won't help.
[17:58:59] <jhutz> I don't want to form a WG for the sake of forming a WG.
[17:59:08] <jhutz> Nico: Sam, could you write requirements for what you want?
[17:59:19] <jhutz> Sam: I could give a presentation on problems I'd like to see solved.
[17:59:24] <jhutz> David, would you help me get that right?
[17:59:48] <jhutz> David: I can help insure my perspective is represented. Can't insure you get it right. :-)
[18:00:00] <jhutz> Love: I think we'll let this hang until the next meeting
[18:00:05] <jhutz> Sam: Do you want such a presentation?
[18:00:06] <jhutz> Love: yes?
[18:00:24] <jhutz> Love: Next steps...
[18:00:37] <jhutz> - Respin problem statement/applic statement and take to WGLC
[18:01:10] <jhutz> <who?> Can't speak for Joe, but... want to make sure we cover everything.
[18:01:17] <jhutz> Maybe next one can go to last call; maybe after.
[18:01:24] <jhutz> Pekka: Date for the next one?
[18:01:38] <jhutz> <who?>: Give me a week to think about it. Before next meeting.
[18:01:52] <jhutz> Pekka: May would be nice. Would like to WGLC before next meeting.
[18:01:59] <jhutz> <who?>: May would be doable.
[18:02:04] <jhutz> Pekka: So, beginning of may?
[18:02:08] <jhutz> David: You're good
[18:02:11] <jhutz> Love: End of May?
[18:02:14] <jhutz> ...
[18:02:23] <jhutz> Love: Nico needs to address comments, flesh out document.
[18:02:32] <jhutz> ... I like document because it's short; that's just me.
[18:02:47] <jhutz> Love: And first IPsec interfaces draft probably not until after next meeting.
[18:02:56] <jhutz> Proposed milestones.... [see slides]
[18:03:08] --- dumdidum has left: Replaced by new connection
[18:03:32] --- dumdidum has joined
[18:04:20] <jhutz> jhutz: So, you've pushing everything out 5 months?
[18:04:21] --- kivinen has left
[18:04:22] <jhutz> pekka: yes
[18:04:29] <jhutz> love: anyone not signed blue sheets?
[18:04:31] <jhutz> meeting ended.
[18:04:49] --- raeburn has left
[18:04:57] --- Jeffrey Altman has left
[18:06:15] --- tanupoo has left: Replaced by new connection
[18:06:49] --- hartmans has left
[18:06:57] <mrichardson> 15:55 speaker was Kent.
[18:08:13] --- dennis_f has left
[18:09:05] --- FDupont has joined
[18:09:33] --- FDupont has left
[18:09:57] --- jhutz has left: Logged out
[18:15:03] --- nico has left
[18:16:44] --- pguenther has left
[18:22:09] --- dumdidum has left
[18:40:49] --- Thierry has left
[18:47:23] --- rstory has left
[19:02:07] --- yushun has joined
[19:03:48] --- yushun has left
[19:23:54] --- mrichardson has left
[21:04:51] --- mrichardson has joined
[21:40:46] --- mrichardson has left: Logged out