>From danmcd@Sun.COM Tue Jan 8 12:23:33 2008 Date: Tue, 08 Jan 2008 13:08:17 -0500 From: Dan McDonald Subject: Pass-0 check of -05 of connection latching In-reply-to: <20080107203639.GG22538@Sun.COM> To: Nicolas Williams Cc: Dan McDonald , Julien Laganier Message-id: <20080108180817.GB999@kebe.east.sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> Here are some pass-0 (first breezy read-through) comments: * The whole normative/informative split irks me... it feels like you're trying to assuage the Steve Kents of the world. (Perhaps that is its purpose?) * If this is "a description of how it works today", as mentioned on phone conversations - it's not. The draft points out what SHOULD be there, not what IS. I don't mind this quirk, but I just wanted to make sure it's not claiming to be entirely implemented in running code today. * Perhaps my first deep reading will answer this, but do you cover the unconnected datagram socket case at all? There are potential ways to convey the information latching requires on inbound datagrams and on outbound datagrams in the disconnected socket case, but It's Hard (TM) and would require XNET (aka UNIX98 or later) sockets using cmsg data. I don't know how that would fit into your informative model, never mind your normative one. * Maybe I need to re-read 4301, but I thought the SPD was a non-persistent repository, but you make it sound like it's persistent across boots... again, perhaps my next reading will make things clearer. I will be giving the document a second, deeper, reading later today or tomorrow. I may give it a third one if it's particularly bothersome, or if we arrive at any noteworthy changes. Just consider this a progress check of sorts! :) Dan >From Nicolas.Williams@sun.com Tue Jan 8 14:32:34 2008 Date: Tue, 8 Jan 2008 14:32:33 -0600 From: Nicolas Williams To: Dan McDonald Cc: Julien Laganier Subject: Re: Pass-0 check of -05 of connection latching Message-ID: <20080108203233.GS22538@Sun.COM> References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> <20080108180817.GB999@kebe.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080108180817.GB999@kebe.east.sun.com> On Tue, Jan 08, 2008 at 01:08:17PM -0500, Dan McDonald wrote: > Here are some pass-0 (first breezy read-through) comments: > > * The whole normative/informative split irks me... it feels like > you're trying to assuage the Steve Kents of the world. (Perhaps > that is its purpose?) That's partly it. I'm following the lead of RFC4301: lay out a reference model and any other model that provides equivalent security guarantees or better is OK. A model that might please the Steve Kents of the world is, in the IETF anyways, a big plus. Whether this one is such a model, I don't know -- Steve has indicated that he doesn't care to review this I-D :/ > * If this is "a description of how it works today", as mentioned on > phone conversations - it's not. The draft points out what SHOULD I'm aware. The informative section is meant to be the "how it works today" part. > be there, not what IS. I don't mind this quirk, but I just wanted > to make sure it's not claiming to be entirely implemented in > running code today. I did this primarily because a model that works for hybrid BITS/native implementations seemed desirable. Think of NICS that offload ESP/AH, like RNICs (NICs that implement the RDDP parts of iSER (iSCSI + RDDP) and NFSv4 -- iSCSI requires IPsec). Now put the firmware beyond your reach. And, to top it off, make it so that NIC doesn't tag incoming packets with information about what SAs protected them. How would you implement connection latching? The Solaris approach won't work, but the normative scheme laid out in the I-D does. Now, maybe *all* NICs with ESP/AH offload actually tag incoming packets with the SAs that protected them (and, conversely, allow the OS to tag outgoing packets with what SAs to use to protect them). With the normative model given we just don't have to ask anyone what the heck their NICs do in this regard. To switch to the Solaris model as the normative model would require asking lots of questions of people who we may not even know are building such NICs. > * Perhaps my first deep reading will answer this, but do you cover > the unconnected datagram socket case at all? There are potential > ways to convey the information latching requires on inbound > datagrams and on outbound datagrams in the disconnected socket > case, but It's Hard (TM) and would require XNET (aka UNIX98 or > later) sockets using cmsg data. I don't know how that would fit > into your informative model, never mind your normative one. It covers the connected datagram socket case but not the unconnected datagram case. I believe the only way to deal with the latter is through the informative packet-tagging model. > * Maybe I need to re-read 4301, but I thought the SPD was a > non-persistent repository, but you make it sound like it's > persistent across boots... again, perhaps my next reading will make > things clearer. The PAD (roughly svc:/network/ipsec/ike:default's config file) and SPD (roughly svc:/network/ipsec/policy:default's config file) are persistent. The SADB is dynamic and non-persisting across reboots (though you might think of manually keyed SADB entries as persistent). > I will be giving the document a second, deeper, reading later today or > tomorrow. I may give it a third one if it's particularly bothersome, or if > we arrive at any noteworthy changes. > > Just consider this a progress check of sorts! :) Thanks! Nico -- >From danmcd@sun.com Wed Jan 9 15:18:00 2008 Date: Wed, 09 Jan 2008 16:02:54 -0500 From: Dan McDonald Subject: Pass-1 review of -05 In-reply-to: <20080108203233.GS22538@Sun.COM> To: Nicolas Williams Cc: Dan McDonald , Julien Laganier Message-id: <20080109210254.GD1329@sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> <20080108180817.GB999@kebe.east.sun.com> <20080108203233.GS22538@Sun.COM> I said: > > I will be giving the document a second, deeper, reading later today or > > tomorrow. I may give it a third one if it's particularly bothersome, or > > if we arrive at any noteworthy changes. And here is pass 1 comments on draft-ietf-btns-connection-latching-05.txt. NOTE: Some pass 0 comments may be restated. This is merely because I didn't use different colored pens for marking up the paper copy. :) Dan ===================== (Cut up to and including here.) ===================== OVERALL ------- * Now that I understand the necessity for both normative and informative models, I actually like how both explain two different ways to solve the same problem. I like this document overall, and my comments are mostly centered around clarification and pitfall indication. * Any mention of OpenSolaris is made with two purposes. The first is to clarify to you, Nico, what's currently in OpenSolaris - since I believe you're drawing from us as a prototype connection-latching implementation. The second is to help me think about implementation issues. * The informative (packet-tagging) model isn't EXACTLY how OpenSolaris works today, and there will be several RFEs falling out of this draft, I think. I believe those RFEs should be covered in the context of RFC 430x work in OpenSolaris. * Implementations may store their various bits and pieces in different protection domains. (e.g. Our connection latches are auxiliary state to the conn_t, aka. control-block, but our certificates are in the IKE daemon.) You may need to acknowlege this fact somewhere. Per-section comments -------------------- Sec 2 I'm not very fond of the term "IPsec channel", because it's pg 4 more a "latch instance", but I can't think of a very good reason to rename it, so just consider that a bit of a style criticism you can ignore. pg 4 Latch parameters not in OpenSolaris today: Replay protection indicator Key lengths Peer identity information pg 5 Small descriptions with each state would be helpful. pg 5 You lead with "MUST NOT be sent unprotected" which seems obvious. You should probably stress "MUST match latch parameters" instead. (Applies to inbound and outbound processing bullets.) pg 6 You hint at section 3's "Optional Protection". I'll talk about that more later, but that's gonna be hard to get right, never mind specify. pg 6 OpenSolaris doesn't use PF_KEY mods at all for connection latching. Ours is totally centered on the IP_SEC_OPT socket option. See ipsec(7P) in the OpenSolaris man pages. I don't mind the citation, of course, but that wasn't one of the intended uses of PF_KEY. Sec 2.1 You've encountered what we found operationally in punchin! When pg 9 a NAT is involved all hell breaks loose with mistaken SA sharing. In OpenSolaris, the only way to workaround this is to specify UNIQUE SA policies (which means an SA must be tied to an entire 5-tuple) and have the aggressive breaking of latches by closing connections. pg 9 Speaking of latch breaking, I like the idea of closing the connection in these situations. The question is, what errno gets passed up to the socket? (e.g. ECONNRESET for TCP RST packets). pg 11 Phrasing nit: say "(i.e. the tags don't appear..." instead of "(the tags don't appear...". pg 11 Explain a little more that acquiring an SA means kicking Key Management in the pants to do its thing. Not everyone thinks like PF_KEY coders. :) Sec 3 Today, OpenSolaris allows IP_SEC_OPT to override any non-PASS SPD pg 14 entry for normal users - so long as the IP_SEC_OPT specifies some level of IPsec protection. Privilege is required to BYPASS any SPD entries using what you call "optional protection". pg 14 How does one specify "meets or exceeds" the quality of protection. I believe the answer is "at the discretion of the system policy", but that's hard to implement properly. pg 14 Your last paragraph talks about updates to the SPD. That might make sense in some implementations, but today if I do "ipsecconf -ln" I don't see all of the per-socket exceptions, nor do I plan to. OpenSolaris caches SPD results in the conn_t for connected sockets. They're ALSO latched implicitly. For example, if I have specified: # Telnet needs IPsec protection { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} and then I open an outbound telnet connection, that connection uses ESP with AES and HMAC-SHA1 for its duration - even if I come along halfway through its lifetime and flush the local SPD! >From Nicolas.Williams@sun.com Wed Jan 9 15:44:01 2008 Date: Wed, 9 Jan 2008 15:44:00 -0600 From: Nicolas Williams To: Dan McDonald Cc: Julien Laganier Subject: Re: Pass-1 review of -05 Message-ID: <20080109214400.GG810@Sun.COM> References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> <20080108180817.GB999@kebe.east.sun.com> <20080108203233.GS22538@Sun.COM> <20080109210254.GD1329@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080109210254.GD1329@sun.com> On Wed, Jan 09, 2008 at 04:02:54PM -0500, Dan McDonald wrote: > OVERALL > ------- > > * Now that I understand the necessity for both normative and informative > models, I actually like how both explain two different ways to solve the > same problem. I like this document overall, and my comments are mostly > centered around clarification and pitfall indication. Thanks. And, if I may, *phew*. I like knowing that we're on the right track, and review has been so sorely missing here that I couldn't be quite sure... > * Any mention of OpenSolaris is made with two purposes. The first is to > clarify to you, Nico, what's currently in OpenSolaris - since I believe > you're drawing from us as a prototype connection-latching implementation. > The second is to help me think about implementation issues. I'll include my replies here, cc'ed to Julien, but Julien is free to ignore the OpenSolar-specific bits if he likes. > * The informative (packet-tagging) model isn't EXACTLY how OpenSolaris works > today, and there will be several RFEs falling out of this draft, I think. Yeah, I know. > I believe those RFEs should be covered in the context of RFC 430x work in > OpenSolaris. > > * Implementations may store their various bits and pieces in different > protection domains. (e.g. Our connection latches are auxiliary state to > the conn_t, aka. control-block, but our certificates are in the IKE > daemon.) You may need to acknowlege this fact somewhere. I think that's implied here: o Implementations that have a restartable key management process (or "daemon") MUST arrange for existing latched connections to either be broken and disconnected, or for them to survive the restart of key exchange processes. (This is implied by the above requirements.) IPsec state related to connection latches MUST be torn down when latched connections are torn down, even when the latter is implied, such as at crash/halt/reboot time. But I'll add something a bit more explicit. > Per-section comments > -------------------- > > Sec 2 I'm not very fond of the term "IPsec channel", because it's > pg 4 more a "latch instance", but I can't think of a very good reason to > rename it, so just consider that a bit of a style criticism you can > ignore. Yeah, well, we have the term "channel binding," which presupposes a channel. Connection latching provides an "IPsec channel" in that sense. Terminology is... painful. Different areas of the IETF use very different terminology and one cannot please everyone. The best I could do is have a glossary where every term like this one is explained, including its historical context. Say the word and I'll do it. I think it's too late to change from this term to something else. But since "IPsec channel" and "connection latch" are used fairly interchangeably, I could minimize all uses of "IPsec channel," relegating them to the introduction, say. > pg 4 Latch parameters not in OpenSolaris today: > > Replay protection indicator > > Key lengths > > Peer identity information We need to fix this :) > pg 5 Small descriptions with each state would be helpful. OK. I'll be adding one more state: SUSPENDED, for apps like BGP that want to avoid connection breaks as much as possible (and which expect no breaks). But connection latch breaking should probably be the default behaviour. > pg 5 You lead with "MUST NOT be sent unprotected" which seems obvious. > You should probably stress "MUST match latch parameters" instead. > (Applies to inbound and outbound processing bullets.) OK. > pg 6 You hint at section 3's "Optional Protection". I'll talk about that > more later, but that's gonna be hard to get right, never mind > specify. Earlier I called this "BYPASS OR PROTECT" and it gave Steve Kent, and, by extension, me, *heartburn*. > pg 6 OpenSolaris doesn't use PF_KEY mods at all for connection latching. > Ours is totally centered on the IP_SEC_OPT socket option. See > ipsec(7P) in the OpenSolaris man pages. I don't mind the citation, > of course, but that wasn't one of the intended uses of PF_KEY. I was hinting at kernel-driven ACQUIRE, since creating a latch can ultimately lead to that situation. But I'm happy to remove the comment and the reference, if you like. > Sec 2.1 You've encountered what we found operationally in punchin! When > pg 9 a NAT is involved all hell breaks loose with mistaken SA sharing. > In OpenSolaris, the only way to workaround this is to specify UNIQUE > SA policies (which means an SA must be tied to an entire 5-tuple) and > have the aggressive breaking of latches by closing connections. If I did it's because: a) this was probably in the back of my mind anyways, b) I definitely had IP_SEC_OPT in mind, c) Michael Richardson cares about NATs very much, so he'd have seen to it that this was there. > pg 9 Speaking of latch breaking, I like the idea of closing the connection > in these situations. The question is, what errno gets passed up to > the socket? (e.g. ECONNRESET for TCP RST packets). Yes, ECONNRESET. > pg 11 Phrasing nit: say "(i.e. the tags don't appear..." instead > of "(the tags don't appear...". OK. > pg 11 Explain a little more that acquiring an SA means kicking Key > Management in the pants to do its thing. Not everyone thinks like > PF_KEY coders. :) Heh. First he complains about a reference to PF_KEY, then... :) :) > Sec 3 Today, OpenSolaris allows IP_SEC_OPT to override any non-PASS SPD "PASS"? In RFC4301 parlance that'd be "PROTECT," right? > pg 14 entry for normal users - so long as the IP_SEC_OPT specifies some > level of IPsec protection. Privilege is required to BYPASS any > SPD entries using what you call "optional protection". It was my intent to capture this. Did I? > pg 14 How does one specify "meets or exceeds" the quality of protection. > I believe the answer is "at the discretion of the system policy", but That's pretty much what it means. In practice that's the only thing it can mean, because there's no way to algorithmically compare the strength of cipher suites. (The issue of relative strength comes up *often* in the IETF. This is my answer.) > that's hard to implement properly. Well, no, local/system policy is easy to implement. In the worst (or best) case you act as if there was no such policy, in which case you don't allow any deviation from what's in the SPD. > pg 14 Your last paragraph talks about updates to the SPD. That might make > sense in some implementations, but today if I do "ipsecconf -ln" I > don't see all of the per-socket exceptions, nor do I plan to. I did use the qualifier "logically." I believe that should suffice to allow the behaviour you describe. > OpenSolaris caches SPD results in the conn_t for connected sockets. > They're ALSO latched implicitly. For example, if I have specified: > > # Telnet needs IPsec protection > { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} > > and then I open an outbound telnet connection, that connection uses > ESP with AES and HMAC-SHA1 for its duration - even if I come along > halfway through its lifetime and flush the local SPD! Yes, I know. I should probably describe this too, and even RECOMMEND it. Not probably; I will, if I haven't already. Thanks! Nico -- >From danmcd@sun.com Thu Jan 10 12:54:16 2008 Date: Thu, 10 Jan 2008 13:38:49 -0500 From: Dan McDonald Subject: Re: Pass-1 review of -05 In-reply-to: <20080109214400.GG810@Sun.COM> To: Nicolas Williams Cc: Dan McDonald , Julien Laganier Message-id: <20080110183849.GC781@kebe.east.sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> <20080108180817.GB999@kebe.east.sun.com> <20080108203233.GS22538@Sun.COM> <20080109210254.GD1329@sun.com> <20080109214400.GG810@Sun.COM> Content-Length: 5743 Lines: 148 On Wed, Jan 09, 2008 at 03:44:01PM -0600, Nicolas Williams wrote: > > * Implementations may store their various bits and pieces in different > > protection domains. (e.g. Our connection latches are auxiliary state to > > the conn_t, aka. control-block, but our certificates are in the IKE > > daemon.) You may need to acknowlege this fact somewhere. > > I think that's implied here: > > o Implementations that have a restartable key management process (or > "daemon") MUST arrange for existing latched connections to either > be broken and disconnected, or for them to survive the restart of > key exchange processes. (This is implied by the above > requirements.) IPsec state related to connection latches MUST be > torn down when latched connections are torn down, even when the > latter is implied, such as at crash/halt/reboot time. > > But I'll add something a bit more explicit. You mention nothing about how hard/easy this might be given where various bits of state may or may not be stored. That's what I'm worried about. > > Per-section comments > > -------------------- > > > > Sec 2 I'm not very fond of the term "IPsec channel", because it's > > pg 4 more a "latch instance", but I can't think of a very good reason to > > rename it, so just consider that a bit of a style criticism you can > > ignore. > > Yeah, well, we have the term "channel binding," which presupposes a > channel. Connection latching provides an "IPsec channel" in that sense. > Terminology is... painful. Different areas of the IETF use very > different terminology and one cannot please everyone. The best I could > do is have a glossary where every term like this one is explained, > including its historical context. Say the word and I'll do it. > > I think it's too late to change from this term to something else. > But since "IPsec channel" and "connection latch" are used fairly > interchangeably, I could minimize all uses of "IPsec channel," > relegating them to the introduction, say. It was more of a grouse than an actual constructive comment. I feel bad for including it. > > pg 4 Latch parameters not in OpenSolaris today: > > > > Replay protection indicator > > > > Key lengths > > > > Peer identity information > > We need to fix this :) Like I said... tons of RFEs fall out of this document. > > pg 5 Small descriptions with each state would be helpful. > > OK. I'll be adding one more state: SUSPENDED, for apps like BGP that > want to avoid connection breaks as much as possible (and which expect no > breaks). But connection latch breaking should probably be the default > behaviour. Thanks. > > pg 6 OpenSolaris doesn't use PF_KEY mods at all for connection latching. > > Ours is totally centered on the IP_SEC_OPT socket option. See > > ipsec(7P) in the OpenSolaris man pages. I don't mind the citation, > > of course, but that wasn't one of the intended uses of PF_KEY. > > I was hinting at kernel-driven ACQUIRE, since creating a latch can > ultimately lead to that situation. But I'm happy to remove the comment > and the reference, if you like. Your text made it sound like PF_KEY was the way to implement the connection-latching API, which probably isn't the case. > > pg 9 Speaking of latch breaking, I like the idea of closing the connection > > in these situations. The question is, what errno gets passed up to > > the socket? (e.g. ECONNRESET for TCP RST packets). > > Yes, ECONNRESET. I might argue the choice of errno value, but that it should manifest AS an error of some kind is what I was seeking. Thanks! > > Sec 3 Today, OpenSolaris allows IP_SEC_OPT to override any non-PASS > SPD > > "PASS"? In RFC4301 parlance that'd be "PROTECT," right? non-PASS == PROTECT. Today on OpenSolaris, if I've an SPD: # ESP with AES and HMAC-SHA-1 {} ipsec {encr_algs aes encr_auth_algs sha1} I could set a socket option (even as a normal user) to use AH with HMAC-MD5 without incident (assuming KM succeeded). > > pg 14 entry for normal users - so long as the IP_SEC_OPT specifies some > > level of IPsec protection. Privilege is required to BYPASS any > > SPD entries using what you call "optional protection". > > It was my intent to capture this. Did I? Mostly, except for the behaviors I specified above. > > pg 14 How does one specify "meets or exceeds" the quality of protection. > > I believe the answer is "at the discretion of the system policy", but > > That's pretty much what it means. In practice that's the only thing it > can mean, because there's no way to algorithmically compare the strength > of cipher suites. (The issue of relative strength comes up *often* in > the IETF. This is my answer.) Understood. > > pg 14 Your last paragraph talks about updates to the SPD. That might make > > sense in some implementations, but today if I do "ipsecconf -ln" I > > don't see all of the per-socket exceptions, nor do I plan to. > > I did use the qualifier "logically." I believe that should suffice to > allow the behaviour you describe. Phew! Okay. > > OpenSolaris caches SPD results in the conn_t for connected sockets. > > They're ALSO latched implicitly. For example, if I have specified: > > > > # Telnet needs IPsec protection > > { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} > > > > and then I open an outbound telnet connection, that connection uses > > ESP with AES and HMAC-SHA1 for its duration - even if I come along > > halfway through its lifetime and flush the local SPD! > > Yes, I know. I should probably describe this too, and even RECOMMEND > it. Not probably; I will, if I haven't already. Excellent! Thanks, Dan >From Nicolas.Williams@sun.com Thu Jan 10 15:41:53 2008 Date: Thu, 10 Jan 2008 15:41:53 -0600 From: Nicolas Williams To: Dan McDonald Cc: Julien Laganier Subject: Re: Pass-1 review of -05 Message-ID: <20080110214153.GY810@Sun.COM> References: <200712211008.07706.julien.laganier@gmail.com> <20080107130220.GA1290@sun.com> <20080107203639.GG22538@Sun.COM> <20080108180817.GB999@kebe.east.sun.com> <20080108203233.GS22538@Sun.COM> <20080109210254.GD1329@sun.com> <20080109214400.GG810@Sun.COM> <20080110183849.GC781@kebe.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080110183849.GC781@kebe.east.sun.com> Content-Length: 3529 Lines: 82 On Thu, Jan 10, 2008 at 01:38:49PM -0500, Dan McDonald wrote: > On Wed, Jan 09, 2008 at 03:44:01PM -0600, Nicolas Williams wrote: > > > > > > * Implementations may store their various bits and pieces in different > > > protection domains. (e.g. Our connection latches are auxiliary state to > > > the conn_t, aka. control-block, but our certificates are in the IKE > > > daemon.) You may need to acknowlege this fact somewhere. > > > > I think that's implied here: > > > > o Implementations that have a restartable key management process (or > > "daemon") MUST arrange for existing latched connections to either > > be broken and disconnected, or for them to survive the restart of > > key exchange processes. (This is implied by the above > > requirements.) IPsec state related to connection latches MUST be > > torn down when latched connections are torn down, even when the > > latter is implied, such as at crash/halt/reboot time. > > > > But I'll add something a bit more explicit. > > You mention nothing about how hard/easy this might be given where various > bits of state may or may not be stored. That's what I'm worried about. Well, does it matter? Sure, it may not be easy for *some* implementation designs. So what? The question, for me, is whether this is always so hard that we should go back to the drawing board. I think the answer is no. > > I was hinting at kernel-driven ACQUIRE, since creating a latch can > > ultimately lead to that situation. But I'm happy to remove the comment > > and the reference, if you like. > > Your text made it sound like PF_KEY was the way to implement the > connection-latching API, which probably isn't the case. I've re-read, it says "Both models imply extensions to any PF_KEY-like" protocols that may be used internally ..." ^^^ ^^^^^ In practice the extensions for kernel-driven ACQUIRE were always needed, so I'll just remove this. > > "PASS"? In RFC4301 parlance that'd be "PROTECT," right? > > non-PASS == PROTECT. > > Today on OpenSolaris, if I've an SPD: > > # ESP with AES and HMAC-SHA-1 > {} ipsec {encr_algs aes encr_auth_algs sha1} > > I could set a socket option (even as a normal user) to use AH with HMAC-MD5 > without incident (assuming KM succeeded). Very confusing. RFC4301 uses "BYPASS" to mean "sent/accepted in the clear." Bottom-line: unprivileged apps should be able to request PROTECT (RFC4301 terms) when the policy would BYPASS (RFC4301 terms), but not BYPASS when PROTECT would be required, and neither BYPASS nor PROTECT when DISCARD (drop) would be required. Privileged apps should be able to do whatever their level of privilege allows them. > > > OpenSolaris caches SPD results in the conn_t for connected sockets. > > > They're ALSO latched implicitly. For example, if I have specified: > > > > > > # Telnet needs IPsec protection > > > { rport 23 } ipsec {encr_algs aes encr_auth_algs sha1} > > > > > > and then I open an outbound telnet connection, that connection uses > > > ESP with AES and HMAC-SHA1 for its duration - even if I come along > > > halfway through its lifetime and flush the local SPD! > > > > Yes, I know. I should probably describe this too, and even RECOMMEND > > it. Not probably; I will, if I haven't already. > > Excellent! Of course, to do this I need to figure out what the default latched parameters should be -- easy for everything except the new "break or suspend" option.