[anonsec] Connection Latching draft review (draft-ietf-btns-connection-latching-04.txt)

[Black_David at emc.com ()]

This message is an attempt to kill two review "birds" with
one email "stone" - I meant to review the connection latching
draft some time ago, and in addition, this is a transport
directorate review of the connection latching draft.

For the latter purpose, the following paragraph applies:

- I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents.
These comments were written primarily for the transport
area directors, but are copied to the document's authors
for their information and to allow them to address any
issues raised.

The result is a mix of transport and security comments in
this email - the transport ADs should pay particular
attention to the service-orientation and NAT comments. In
general, this is a good draft, and I think it should go
forward.

-- Service Orientation

The introduction considerably undersells the architectural
impact of this draft. IPsec architecture has been based on
inclusion of a logical firewall. This results in the
configuration of security services being somewhat
disconnected from the higher level protocols and
applications that benefit from those services by the use of
the SPD to configure the logical firewall (see Sections 3
and 3.1 of RFC 4301).

This disconnection has been an important feature of IPsec,
as it has enabled consistent application of security
policy to all traffic crossing an IPsec boundary (e.g.,
to/from a specific network node, to/from an otherwise
unprotected [untrusted] network at a network node), but
it has made use of IPsec by higher layer applications and
protocols more difficult because application usage
requests for IPsec have to be expressed in terms of a
firewall-like configuration through an API of some form,
and conflicts are possible.

The connection latching draft is aimed at precisely this
gap between effective application usage and the logical
firewall architecture of IPsec; in essence, the draft is
defining the functional service interface through which
higher layer applications and protocols should be
obtaining IPsec services for themselves instead of setting
up SPD (and possibly PAD) entries directly. This change
from logical firewall orientation to service orientation is
(IMHO) an important step towards making IPsec effectively
usable for protocols such as iSCSI and NFSv4, and should
be explained in the Introduction of this draft.

-- NATs

p.5 says:

o Implementations that provide such programming interfaces
SHOULD make available to applications any available
NAT-related information about the peer: whether it is
behind a NAT and, if it is, the inner and outer tunnel
addresses of the peer.

Is that serious? I don't think inflicting NAT awareness on
additional protocols and applications is a good idea unless
it's absolutely necessary (i.e., protocol/app won't work through
a NAT that it doesn't know about). In general, IPsec NAT
traversal ought to work transparently with respect to
connection latching, and (IMHO), this transparency should
be the preferred approach whenever feasible.

-- Key Manager/Key Management

The draft talks about a key manager. It should state what
functions the key manager is performing with respect to the
IPsec architecture (RFC 4301). While IKEv2 would clearly
be inside the key manager, where is responsibility for the
SPD and PAD placed and/or how is that responsibility divided?

While not exactly key management, how does connection latch
state lifetime relate to the lifetime of the IKE_SA for the
latched SA? This is the infamous "dangling SAs" issue
applied to connection latch state. I think that connection
latch state does not survive termination without replacement
of the IKE_SA (e.g., key management entity containing
IKE/IKEv2 implementation crashes), but ought to survive
replacement of the IKE_SA. In any case, this topic needs to
be covered.

-- Nits

idnits 2.05.03 found a bunch of nits, mostly in the references.

tmp/draft-ietf-btns-connection-latching-04.txt:

Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:

------------------------------------------------------------------------
----

No issues found here.

Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:

------------------------------------------------------------------------
----

== No 'Intended status' indicated for this document; assuming Proposed
Standard


Checking nits according to http://www.ietf.org/ID-Checklist.html:

------------------------------------------------------------------------
----

No issues found here.

Miscellaneous warnings:

------------------------------------------------------------------------
----

== The copyright year in the IETF Trust Copyright Line does not match
the
current year


Checking references for intended status: Proposed Standard

------------------------------------------------------------------------
----

(See RFC 3967 for information about using normative references to
lower-maturity documents in RFCs)

== Unused Reference: 'I-D.bellovin-useipsec' is defined on line 632,
but no
explicit reference was found in the text

== Unused Reference: 'RFC4322' is defined on line 642, but no explicit
reference was found in the text

-- Possible downref: Normative reference to a draft: ref.
'I-D.ietf-btns-abstract-api' (No intended status found in state
file of
draft-ietf-btns-abstract-api)

== Outdated reference: A later version (-06) exists of
draft-ietf-btns-core-05

== Outdated reference: A later version (-06) exists of
draft-ietf-btns-prob-and-applic-05

** Downref: Normative reference to an Informational draft:
draft-ietf-btns-prob-and-applic (ref.
'I-D.ietf-btns-prob-and-applic')

** Downref: Normative reference to an Informational RFC: RFC 2367

== Outdated reference: A later version (-07) exists of
draft-bellovin-useipsec-06

== Outdated reference: draft-williams-on-channel-binding has been
published
as RFC 5056

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
[phone] FAX: [phone]
black_david at emc.com Mobile: [phone]
----------------------------------------------------

[Nicolas Williams]

Post by Black_David at emc.com ()
This message is an attempt to kill two review "birds" with
one email "stone" - I meant to review the connection latching
draft some time ago, and in addition, this is a transport
directorate review of the connection latching draft.

Thank you.

Post by Black_David at emc.com ()
-- Service Orientation
The introduction considerably undersells the architectural
impact of this draft. [...]

I agree, ...

Post by Black_David at emc.com ()
The connection latching draft is aimed at precisely this
gap between effective application usage and the logical
firewall architecture of IPsec; in essence, the draft is
defining the functional service interface through which
higher layer applications and protocols should be
obtaining IPsec services for themselves instead of setting
up SPD (and possibly PAD) entries directly. This change
from logical firewall orientation to service orientation is
(IMHO) an important step towards making IPsec effectively
usable for protocols such as iSCSI and NFSv4, and should
be explained in the Introduction of this draft.

... but connection latching is one of a multi-prong approach to closing
that gap. The other main prong is IPsec APIs. A third, optional prong,
is channel binding.

I fear that to correct this undersell while the IPsec APIs documents are
not complete might be to oversell the architectural impact of this
document.

Comments?

Post by Black_David at emc.com ()
-- NATs
o Implementations that provide such programming interfaces
SHOULD make available to applications any available
NAT-related information about the peer: whether it is
behind a NAT and, if it is, the inner and outer tunnel
addresses of the peer.
Is that serious? I don't think inflicting NAT awareness on
additional protocols and applications is a good idea unless
it's absolutely necessary (i.e., protocol/app won't work through
a NAT that it doesn't know about). In general, IPsec NAT
traversal ought to work transparently with respect to
connection latching, and (IMHO), this transparency should
be the preferred approach whenever feasible.

Well, does it hurt to have this? I suppose this could be a MAY, if
implementors object (or it could be downgraded to MAY or removed
altogether when in the progression to Standard).

I don't feel too strongly about it, but I also don't feel too strongly
about discouraging the use of NATs (face it: NATs are here to stay, at
least in the IPv4 world).

Post by Black_David at emc.com ()
-- Key Manager/Key Management
The draft talks about a key manager. It should state what
functions the key manager is performing with respect to the
IPsec architecture (RFC 4301). While IKEv2 would clearly
be inside the key manager, where is responsibility for the
SPD and PAD placed and/or how is that responsibility divided?

RFC4301 does not speak of a key manager, but does speak of key
management -- see section 4.5. I'll clarify in the I-D, and here: the
key manager is the part of the implementation that manages the SAD. The
KE protocols (IKEv2, KINK, ...) are associated with the key manager, but
what really matters here is the component of the system through which
all SAD updates are done.

Post by Black_David at emc.com ()
While not exactly key management, how does connection latch
state lifetime relate to the lifetime of the IKE_SA for the
latched SA?

It doesn't.

Post by Black_David at emc.com ()
This is the infamous "dangling SAs" issue
applied to connection latch state.

What is this infamous issue?

Post by Black_David at emc.com ()
I think that connection
latch state does not survive termination without replacement
of the IKE_SA (e.g., key management entity containing
IKE/IKEv2 implementation crashes), but ought to survive
replacement of the IKE_SA. In any case, this topic needs to
be covered.

It is absolutely desirable that connection latch state survive IKE_SA
and even child SA expiration.

The document does describe latch termination, but -05 will do so in much
more detail.

Basically a latch terminates when the ULP requests it (which may be when
the application requests it, or when an RST is received protected by a
suitable SA) and, in the normative model, whenever the key manager adds
an SA to the SAD which conflicts with the latch.

Post by Black_David at emc.com ()
-- Nits
----
== No 'Intended status' indicated for this document; assuming Proposed
Standard

Thanks. I'll fix this.

Post by Black_David at emc.com ()
== The copyright year in the IETF Trust Copyright Line does not match
the
current year

It matches the year in which it was submitted. -05 will be submitted in
2008, so its IETF Trust Copyright notice will say "2008."

Post by Black_David at emc.com ()
(See RFC 3967 for information about using normative references to
lower-maturity documents in RFCs)
== Unused Reference: 'I-D.bellovin-useipsec' is defined on line 632,
but no
explicit reference was found in the text

If I correct the "undersell" then there will definitely be a mention of
bellovin-useipsec!

Post by Black_David at emc.com ()
== Unused Reference: 'RFC4322' is defined on line 642, but no explicit
reference was found in the text

Suggestions?

Post by Black_David at emc.com ()
-- Possible downref: Normative reference to a draft: ref.
'I-D.ietf-btns-abstract-api' (No intended status found in state
file of
draft-ietf-btns-abstract-api)

That should probably be informative, yes.

Post by Black_David at emc.com ()
== Outdated reference: A later version (-06) exists of
draft-ietf-btns-core-05
== Outdated reference: A later version (-06) exists of
draft-ietf-btns-prob-and-applic-05
draft-ietf-btns-prob-and-applic (ref.
'I-D.ietf-btns-prob-and-applic')
** Downref: Normative reference to an Informational RFC: RFC 2367
== Outdated reference: A later version (-07) exists of
draft-bellovin-useipsec-06
== Outdated reference: draft-williams-on-channel-binding has been
published
as RFC 5056

Will fix.

Thanks!

Nico
--

[Black_David at emc.com ()]

Nico,

Post by Nicolas Williams

Post by Black_David at emc.com ()
-- Service Orientation
The introduction considerably undersells the architectural
impact of this draft. [...]

I agree, ...
... but connection latching is one of a multi-prong approach to closing
that gap. The other main prong is IPsec APIs. A third, optional prong,
is channel binding.

Describing this overall multi-prong structure and connection
latching's role in it would be a "good thing" to do in the
introduction and should position the connection latching draft
correctly.

Post by Nicolas Williams

Post by Black_David at emc.com ()
-- NATs
o Implementations that provide such programming interfaces
SHOULD make available to applications any available
NAT-related information about the peer: whether it is
behind a NAT and, if it is, the inner and outer tunnel
addresses of the peer.
Is that serious? I don't think inflicting NAT awareness on
additional protocols and applications is a good idea unless
it's absolutely necessary (i.e., protocol/app won't work through
a NAT that it doesn't know about). In general, IPsec NAT
traversal ought to work transparently with respect to
connection latching, and (IMHO), this transparency should
be the preferred approach whenever feasible.

Well, does it hurt to have this? I suppose this could be a MAY, if
implementors object (or it could be downgraded to MAY or removed
altogether when in the progression to Standard).
I don't feel too strongly about it, but I also don't feel too strongly
about discouraging the use of NATs (face it: NATs are here to stay, at
least in the IPv4 world).

This isn't about discouraging use of NATs; I completely agree
that NATs are a fact of life for IPv4. This is about avoiding
encouragement of NAT-specific code in protocols and applications
that don't need it (i.e., work just fine with IPsec NAT traversal).

Think of the goal as "damage containment" - it does hurt to
encourage unnecessary attempts to deal with NATs. It may be ok
to have the interface if the interface adds value to what apps
already have to do to cope with NATs, but there should be a
rationale for the added value.

Post by Nicolas Williams

Post by Black_David at emc.com ()
-- Key Manager/Key Management

[... snip ...]

Post by Nicolas Williams

Post by Black_David at emc.com ()
This is the infamous "dangling SAs" issue
applied to connection latch state.

What is this infamous issue?

Does a CHILD_SA survive termination of the IKE_SA used to create
the CHILD_SA?

[... snip ...]

Post by Nicolas Williams
It is absolutely desirable that connection latch state survive IKE_SA
and even child SA expiration.
The document does describe latch termination, but -05 will do
so in much more detail.
Basically a latch terminates when the ULP requests it (which may be when
the application requests it, or when an RST is received protected by a
suitable SA) and, in the normative model, whenever the key manager adds
an SA to the SAD which conflicts with the latch.

I think that's ok, just write it up in -05, and explain why the
disconnection from the IKE_SA lifetime/fate is important. I
was making intelligent guesses in the absence of detail, and I
guessed wrong :-).

Thanks,
--David

Post by Nicolas Williams
-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams at sun.com]
Sent: Tuesday, January 08, 2008 4:19 PM
To: Black, David
Cc: anonsec at postel.org; tsv-dir at ietf.org
Subject: Re: [anonsec] Connection Latching draft review
(draft-ietf-btns-connection-latching-04.txt)

Post by Black_David at emc.com ()
This message is an attempt to kill two review "birds" with
one email "stone" - I meant to review the connection latching
draft some time ago, and in addition, this is a transport
directorate review of the connection latching draft.

Thank you.

Post by Black_David at emc.com ()
-- Service Orientation
The introduction considerably undersells the architectural
impact of this draft. [...]

I agree, ...

Post by Black_David at emc.com ()
The connection latching draft is aimed at precisely this
gap between effective application usage and the logical
firewall architecture of IPsec; in essence, the draft is
defining the functional service interface through which
higher layer applications and protocols should be
obtaining IPsec services for themselves instead of setting
up SPD (and possibly PAD) entries directly. This change
from logical firewall orientation to service orientation is
(IMHO) an important step towards making IPsec effectively
usable for protocols such as iSCSI and NFSv4, and should
be explained in the Introduction of this draft.

... but connection latching is one of a multi-prong approach
to closing
that gap. The other main prong is IPsec APIs. A third,
optional prong,
is channel binding.
I fear that to correct this undersell while the IPsec APIs
documents are
not complete might be to oversell the architectural impact of this
document.
Comments?

Post by Black_David at emc.com ()
-- NATs
o Implementations that provide such programming interfaces
SHOULD make available to applications any available
NAT-related information about the peer: whether it is
behind a NAT and, if it is, the inner and outer tunnel
addresses of the peer.
Is that serious? I don't think inflicting NAT awareness on
additional protocols and applications is a good idea unless
it's absolutely necessary (i.e., protocol/app won't work through
a NAT that it doesn't know about). In general, IPsec NAT
traversal ought to work transparently with respect to
connection latching, and (IMHO), this transparency should
be the preferred approach whenever feasible.

Well, does it hurt to have this? I suppose this could be a MAY, if
implementors object (or it could be downgraded to MAY or removed
altogether when in the progression to Standard).
I don't feel too strongly about it, but I also don't feel too strongly
about discouraging the use of NATs (face it: NATs are here to stay, at
least in the IPv4 world).

Post by Black_David at emc.com ()
-- Key Manager/Key Management
The draft talks about a key manager. It should state what
functions the key manager is performing with respect to the
IPsec architecture (RFC 4301). While IKEv2 would clearly
be inside the key manager, where is responsibility for the
SPD and PAD placed and/or how is that responsibility divided?

RFC4301 does not speak of a key manager, but does speak of key
management -- see section 4.5. I'll clarify in the I-D, and here: the
key manager is the part of the implementation that manages
the SAD. The
KE protocols (IKEv2, KINK, ...) are associated with the key
manager, but
what really matters here is the component of the system through which
all SAD updates are done.

Post by Black_David at emc.com ()
While not exactly key management, how does connection latch
state lifetime relate to the lifetime of the IKE_SA for the
latched SA?

It doesn't.

Post by Black_David at emc.com ()
This is the infamous "dangling SAs" issue
applied to connection latch state.

What is this infamous issue?

Post by Black_David at emc.com ()
I think that connection
latch state does not survive termination without replacement
of the IKE_SA (e.g., key management entity containing
IKE/IKEv2 implementation crashes), but ought to survive
replacement of the IKE_SA. In any case, this topic needs to
be covered.

It is absolutely desirable that connection latch state survive IKE_SA
and even child SA expiration.
The document does describe latch termination, but -05 will do
so in much
more detail.
Basically a latch terminates when the ULP requests it (which
may be when
the application requests it, or when an RST is received protected by a
suitable SA) and, in the normative model, whenever the key
manager adds
an SA to the SAD which conflicts with the latch.

Post by Black_David at emc.com ()
-- Nits
----
== No 'Intended status' indicated for this document;

assuming Proposed

Post by Black_David at emc.com ()
Standard

Thanks. I'll fix this.

Post by Black_David at emc.com ()
== The copyright year in the IETF Trust Copyright Line

does not match

Post by Black_David at emc.com ()
the
current year

It matches the year in which it was submitted. -05 will be
submitted in
2008, so its IETF Trust Copyright notice will say "2008."

Post by Black_David at emc.com ()
(See RFC 3967 for information about using normative

references to

Post by Black_David at emc.com ()
lower-maturity documents in RFCs)
== Unused Reference: 'I-D.bellovin-useipsec' is defined

on line 632,

Post by Black_David at emc.com ()
but no
explicit reference was found in the text

If I correct the "undersell" then there will definitely be a
mention of
bellovin-useipsec!

Post by Black_David at emc.com ()
== Unused Reference: 'RFC4322' is defined on line 642,

but no explicit

Post by Black_David at emc.com ()
reference was found in the text

Suggestions?

Post by Black_David at emc.com ()
-- Possible downref: Normative reference to a draft: ref.
'I-D.ietf-btns-abstract-api' (No intended status

found in state

Post by Black_David at emc.com ()
file of
draft-ietf-btns-abstract-api)

That should probably be informative, yes.

Post by Black_David at emc.com ()
== Outdated reference: A later version (-06) exists of
draft-ietf-btns-core-05
== Outdated reference: A later version (-06) exists of
draft-ietf-btns-prob-and-applic-05
draft-ietf-btns-prob-and-applic (ref.
'I-D.ietf-btns-prob-and-applic')
** Downref: Normative reference to an Informational RFC: RFC 2367
== Outdated reference: A later version (-07) exists of
draft-bellovin-useipsec-06
== Outdated reference: draft-williams-on-channel-binding has been
published
as RFC 5056

Will fix.
Thanks!
Nico
--

[Nicolas Williams]

Post by Nicolas Williams

Post by Nicolas Williams

Post by Black_David at emc.com ()
The introduction considerably undersells the architectural
impact of this draft. [...]

I agree, ...
... but connection latching is one of a multi-prong approach to

closing

Post by Nicolas Williams
that gap. The other main prong is IPsec APIs. A third, optional

prong,

Post by Nicolas Williams
is channel binding.

Describing this overall multi-prong structure and connection
latching's role in it would be a "good thing" to do in the
introduction and should position the connection latching draft
correctly.

OK, I will do so.

Post by Nicolas Williams

Post by Nicolas Williams

Post by Black_David at emc.com ()
-- NATs

Well, does it hurt to have this? I suppose this could be a MAY, if
implementors object (or it could be downgraded to MAY or removed
altogether when in the progression to Standard).
I don't feel too strongly about it, but I also don't feel too strongly
about discouraging the use of NATs (face it: NATs are here to stay, at
least in the IPv4 world).

This isn't about discouraging use of NATs; I completely agree
that NATs are a fact of life for IPv4. This is about avoiding
encouragement of NAT-specific code in protocols and applications
that don't need it (i.e., work just fine with IPsec NAT traversal).

I think this text doesn't do that at all. Why would application
developers bother to ask about NAT-related information when they already
know that their app works with IPsec NAT traversal?

Post by Nicolas Williams
Think of the goal as "damage containment" - it does hurt to
encourage unnecessary attempts to deal with NATs. It may be ok
to have the interface if the interface adds value to what apps
already have to do to cope with NATs, but there should be a
rationale for the added value.

But also, and more to the point, as long as we accept the existence of
NATs we might as well accept the existence of protocols which need help
to traverse them, and then we should accept some of the responsibility for
helping them.

I'd reverse your question and ask how making this information available
to the application developer encourages the development of new
applications that need help in order to traverse NATs.

Post by Nicolas Williams

Post by Nicolas Williams

Post by Black_David at emc.com ()
-- Key Manager/Key Management

[... snip ...]

Post by Nicolas Williams

Post by Black_David at emc.com ()
This is the infamous "dangling SAs" issue
applied to connection latch state.

What is this infamous issue?

Does a CHILD_SA survive termination of the IKE_SA used to create
the CHILD_SA?

Right, that problem is irrelevant to connection latching as specified.
That said, that problem is relevant to the construction of IPsec channel
bindings. But that's a topic for a different I-D.

Thanks,

Nico
--

[Black_David at emc.com ()]

Nico,

Post by Nicolas Williams

Post by Black_David at emc.com ()

Post by Nicolas Williams

Post by Black_David at emc.com ()
-- NATs

Well, does it hurt to have this? I suppose this could be a MAY, if
implementors object (or it could be downgraded to MAY or removed
altogether when in the progression to Standard).
I don't feel too strongly about it, but I also don't feel too strongly
about discouraging the use of NATs (face it: NATs are here to stay, at
least in the IPv4 world).

This isn't about discouraging use of NATs; I completely agree
that NATs are a fact of life for IPv4. This is about avoiding
encouragement of NAT-specific code in protocols and applications
that don't need it (i.e., work just fine with IPsec NAT traversal).

I think this text doesn't do that at all. Why would application
developers bother to ask about NAT-related information when
they already know that their app works with IPsec NAT traversal?

Because there's a "SHOULD" in the standard written by people who
may have more of a clue about NATs.

Post by Nicolas Williams

Post by Black_David at emc.com ()
Think of the goal as "damage containment" - it does hurt to
encourage unnecessary attempts to deal with NATs. It may be ok
to have the interface if the interface adds value to what apps
already have to do to cope with NATs, but there should be a
rationale for the added value.

But also, and more to the point, as long as we accept the existence of
NATs we might as well accept the existence of protocols which need help
to traverse them, and then we should accept some of the responsibility for
helping them.
I'd reverse your question and ask how making this information

available

Post by Nicolas Williams
to the application developer encourages the development of new
applications that need help in order to traverse NATs.

I hereby renew my membership in the "if in doubt, leave it out"
design camp ;-). In any case, I'm ok with making the requirement
a MAY, at least for now.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
[phone] FAX: [phone]
black_david at emc.com Mobile: [phone]
----------------------------------------------------

[Nicolas Williams]

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). I still
have some TODOs, but I wanted to submit a new version sooner, rather
than later.

I've made few changes to the design of connection latching, but several
significant and substantive changes to the document.

Design changes:

- removed LARVAL state (it was imaginary)
- added requirement for API option for conflict resolution: wait for
the conflict to go away or break the latch
- added SUSPENDED state corresponding to "wait for the conflict to go
away" (see above)

Text changes:

- moved connection latch state into its own sub-section and greatly
expanded it, including state transition details
- I've not yet written a state diagram
- added more text about the normative/informative model split
- added text to the introduction about the significance of this work
- added text on simultaneous latching (corresponding to TCP
simultaneous opens)
- added more text on connection latching in BITS and SG

Thank you, David, and thank you, Dan, for your helpful comments!

In particular, given that Dan and connection latching go back a long
time (at least ten years) and that Dan had much to do with the Solaris
implementation of connection latching, I now feel quite certain that
this document is on track as far as the technical details are concerned.

Nico
--

[Nicolas Williams]

Post by Nicolas Williams
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 --------------

Post by Nicolas Williams
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

Post by Nicolas Williams
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>

Post by Nicolas Williams
* 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 :/

Post by Nicolas Williams
* 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.

Post by Nicolas Williams
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.

Post by Nicolas Williams
* 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.

Post by Nicolas Williams
* 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).

Post by Nicolas Williams
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
--

Post by Nicolas Williams
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>

Post by Nicolas Williams

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!

Post by Nicolas Williams
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>

Post by Nicolas Williams
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...

Post by Nicolas Williams
* 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.

Post by Nicolas Williams
* 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.

Post by Nicolas Williams
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.

Post by Nicolas Williams
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.

Post by Nicolas Williams
Replay protection indicator
Key lengths
Peer identity information

We need to fix this :)

Post by Nicolas Williams
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.

Post by Nicolas Williams
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.

Post by Nicolas Williams
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*.

Post by Nicolas Williams
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.

Post by Nicolas Williams
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.

Post by Nicolas Williams
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.

Post by Nicolas Williams
pg 11 Phrasing nit: say "(i.e. the tags don't appear..." instead
of "(the tags don't appear...".

OK.

Post by Nicolas Williams
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... :) :)

Post by Nicolas Williams
Sec 3 Today, OpenSolaris allows IP_SEC_OPT to override any non-PASS SPD

"PASS"? In RFC4301 parlance that'd be "PROTECT," right?

Post by Nicolas Williams
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?

Post by Nicolas Williams
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.)

Post by Nicolas Williams
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.

Post by Nicolas Williams
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.

Post by Nicolas Williams
OpenSolaris caches SPD results in the conn_t for connected sockets.
# 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
--

Post by Nicolas Williams
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!>

Post by Nicolas Williams

* 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.

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.

Post by Nicolas Williams

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.

Post by Nicolas Williams

Replay protection indicator
Key lengths
Peer identity information

We need to fix this :)

Like I said... tons of RFEs fall out of this document.

Post by Nicolas Williams

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.

Post by Nicolas Williams

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.

Post by Nicolas Williams

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!

Post by Nicolas Williams

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).

Post by Nicolas Williams

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.

Post by Nicolas Williams

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.

Post by Nicolas Williams

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.

Post by Nicolas Williams

OpenSolaris caches SPD results in the conn_t for connected sockets.
# 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

Post by Nicolas Williams
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

Post by Nicolas Williams
<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.

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.

Post by Nicolas Williams

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.

Post by Nicolas Williams

"PASS"? In RFC4301 parlance that'd be "PROTECT," right?

non-PASS == PROTECT.
# 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.

Post by Nicolas Williams

OpenSolaris caches SPD results in the conn_t for connected sockets.
# 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.

[Stephen Kent]

Nico & Dan,

the SPD has always been a persistent database. the newly added PAD
also is persistent. It's the SAD that is transient, i.e., need not
have any entries unless SAs have been created, and those entries
vanish when the SAs they represent vanish. The notion of dynamic
modification of the SPD is a relatively new concept, not part of the
original design, but not ruled out by it. Also note that the
de-correlated SPD model introduced in 4301 works very well for a
persistent database, but could be costly to maintain if the SPD is
frequently updated.

Steve has indicated that he is tired of reviewing BTNS documents that
often are hard to read and that too often are revised with only
slight improvement. The BTNS problem statement is the most recent
example, where comments from two years ago were not acted upon.

Steve

[Nicolas Williams]

Post by Stephen Kent
Nico & Dan,
the SPD has always been a persistent database. the newly added PAD
also is persistent. It's the SAD that is transient, i.e., need not

Had I gotten this wrong? No. Dan may not be totally up to speed with
RFC4301 terminology, but I wouldn't dismiss what he has to say on
account of that.

Post by Stephen Kent
have any entries unless SAs have been created, and those entries
vanish when the SAs they represent vanish. The notion of dynamic
modification of the SPD is a relatively new concept, not part of the
original design, but not ruled out by it. Also note that the
de-correlated SPD model introduced in 4301 works very well for a
persistent database, but could be costly to maintain if the SPD is
frequently updated.

Are you asking that the connection latching I-D address how to perform
dynamic updates of a de-correlated SPD?

[Stephen Kent]

Post by Nicolas Williams

Post by Stephen Kent
Nico & Dan,
the SPD has always been a persistent database. the newly added PAD
also is persistent. It's the SAD that is transient, i.e., need not

Had I gotten this wrong? No. Dan may not be totally up to speed with
RFC4301 terminology, but I wouldn't dismiss what he has to say on
account of that.

since, as I said, the SPD has ALWAYS been defined as persistent, this
misunderstanding is not attributable to a lack of familiarity with
4301.

Post by Nicolas Williams

Post by Stephen Kent
have any entries unless SAs have been created, and those entries
vanish when the SAs they represent vanish. The notion of dynamic
modification of the SPD is a relatively new concept, not part of the
original design, but not ruled out by it. Also note that the
de-correlated SPD model introduced in 4301 works very well for a
persistent database, but could be costly to maintain if the SPD is
frequently updated.

Are you asking that the connection latching I-D address how to perform
dynamic updates of a de-correlated SPD?

no. I was just noting the most recent (2 years old) text supporting
the fact that the SPD was not nominally viewed as dynamic.

Steve