[anonsec] Dan's comments (Re: Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt))
Nicolas Williams
Nicolas.Williams at sun.com
Thu Jan 10 15:16:10 PST 2008
On Thu, Jan 10, 2008 at 04:32:47PM -0600, Nicolas Williams wrote:
> I've uploaded a new version, -05, that addresses most of your comments,
> as well as most of Dan McDonald's comments (made off-list; I'll forward
> those exchanges to the list, with Dan's permission, shortly).
Attached are Dan's comments and my replies.
Nico
--
-------------- next part --------------
>From danmcd at Sun.COM Tue Jan 8 12:23:33 2008
Date: Tue, 08 Jan 2008 13:08:17 -0500
From: Dan McDonald <danmcd at Sun.COM>
Subject: Pass-0 check of -05 of connection latching
In-reply-to: <20080107203639.GG22538 at Sun.COM>
To: Nicolas Williams <Nicolas.Williams at Sun.COM>
Cc: Dan McDonald <danmcd at Sun.COM>, Julien Laganier <julien.laganier at gmail.com>
Message-id: <20080108180817.GB999 at 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 at gmail.com>
<20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at 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 at sun.com Tue Jan 8 14:32:34 2008
Date: Tue, 8 Jan 2008 14:32:33 -0600
From: Nicolas Williams <Nicolas.Williams at sun.com>
To: Dan McDonald <danmcd at Sun.COM>
Cc: Julien Laganier <julien.laganier at gmail.com>
Subject: Re: Pass-0 check of -05 of connection latching
Message-ID: <20080108203233.GS22538 at Sun.COM>
References: <200712211008.07706.julien.laganier at gmail.com> <20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at Sun.COM> <20080108180817.GB999 at kebe.east.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080108180817.GB999 at 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 at sun.com Wed Jan 9 15:18:00 2008
Date: Wed, 09 Jan 2008 16:02:54 -0500
From: Dan McDonald <danmcd at sun.com>
Subject: Pass-1 review of -05
In-reply-to: <20080108203233.GS22538 at Sun.COM>
To: Nicolas Williams <Nicolas.Williams at Sun.COM>
Cc: Dan McDonald <danmcd at sun.com>, Julien Laganier <julien.laganier at gmail.com>
Message-id: <20080109210254.GD1329 at 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 at gmail.com>
<20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at Sun.COM>
<20080108180817.GB999 at kebe.east.sun.com> <20080108203233.GS22538 at 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 at sun.com Wed Jan 9 15:44:01 2008
Date: Wed, 9 Jan 2008 15:44:00 -0600
From: Nicolas Williams <Nicolas.Williams at sun.com>
To: Dan McDonald <danmcd at sun.com>
Cc: Julien Laganier <julien.laganier at gmail.com>
Subject: Re: Pass-1 review of -05
Message-ID: <20080109214400.GG810 at Sun.COM>
References: <200712211008.07706.julien.laganier at gmail.com> <20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at Sun.COM> <20080108180817.GB999 at kebe.east.sun.com> <20080108203233.GS22538 at Sun.COM> <20080109210254.GD1329 at sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080109210254.GD1329 at 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 at sun.com Thu Jan 10 12:54:16 2008
Date: Thu, 10 Jan 2008 13:38:49 -0500
From: Dan McDonald <danmcd at sun.com>
Subject: Re: Pass-1 review of -05
In-reply-to: <20080109214400.GG810 at Sun.COM>
To: Nicolas Williams <Nicolas.Williams at Sun.COM>
Cc: Dan McDonald <danmcd at sun.com>, Julien Laganier <julien.laganier at gmail.com>
Message-id: <20080110183849.GC781 at 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 at gmail.com>
<20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at Sun.COM>
<20080108180817.GB999 at kebe.east.sun.com> <20080108203233.GS22538 at Sun.COM>
<20080109210254.GD1329 at sun.com> <20080109214400.GG810 at Sun.COM>
Content-Length: 5743
Lines: 148
On Wed, Jan 09, 2008 at 03:44:01PM -0600, Nicolas Williams wrote:
<mucho snippage deleted!>
> > * 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 at sun.com Thu Jan 10 15:41:53 2008
Date: Thu, 10 Jan 2008 15:41:53 -0600
From: Nicolas Williams <Nicolas.Williams at sun.com>
To: Dan McDonald <danmcd at sun.com>
Cc: Julien Laganier <julien.laganier at gmail.com>
Subject: Re: Pass-1 review of -05
Message-ID: <20080110214153.GY810 at Sun.COM>
References: <200712211008.07706.julien.laganier at gmail.com> <20080107130220.GA1290 at sun.com> <20080107203639.GG22538 at Sun.COM> <20080108180817.GB999 at kebe.east.sun.com> <20080108203233.GS22538 at Sun.COM> <20080109210254.GD1329 at sun.com> <20080109214400.GG810 at Sun.COM> <20080110183849.GC781 at kebe.east.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080110183849.GC781 at 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:
>
> <mucho snippage deleted!>
>
> > > * 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.
More information about the ANONSEC
mailing list