Subject: WG Last Call draft-ietf-ipsec-dpd-01.txt

From: Barbara Fraser <[email-masked]>
Date: Mon, 03 Feb 2003 07:41:38 -0800

This is a working group last call for comments for the 
draft-ietf-ipsec-dpd-01.txt draft, for progression to Informational 
RFC.  This last call will expire in one week on Februrary 10.

thanks,
Barb and Ted

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 3 Feb 2003 11:08:24 -0800

At 7:41 AM -0800 2/3/03, Barbara Fraser wrote:
>RFC.

Why is this meant to be an Informational RFC? It is an actual 
protocol. It should be on standards track.

If the reason for making this an Informational RFC is because it 
changes IKEv1, will we also be able to get XAUTH and MODECFG (two 
actual protocols that are widely deployed) published as Informational 
RFCs as well?

--Paul Hoffman, Director
--VPN Consortium

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Mon, 3 Feb 2003 16:47:57 -0700

The draft has a number of non-ascii characters.  

There was once a good statement on the mailing list about why
keep-alives were important, but this draft doesn't have such a thing.
What important advantage accrues from keep-alives?  They allow state
to be removed more aggressively and efficiently than methods without
keep-alives?  Alos, there is mention of a "mitigation" of the need for
timers, but one still needs them, it seems.

There should be some context about where the SPI and associated
parameters come from.  It's a little difficult to grok these things
exist until one gets to the message formats.  There's a statement
early on that there will be comparison between methods based on IPSec
SA's and IKE SA's, but the promise is not kept, as nearly as I can see.

There's a statement that "unencrypted" data must be rejected.  How does
one make a determination that the data has been encrypted?  From a security
viewpoint, it seems more important that a message authentication code be
validated than that encryption be applied.

There is no mention of what should be done if the peer doesn't
respond.  Is the RUTHERE sent again?  How fast, how many times before
making a deadness decision?  Suppose A decides B is dead, but B does
not agree.  A will start a new "session" and choose a new sequence
number.  B might continue using the previous "session".  If A refuses
to respond, B might eventually conclude that A is dead and start a new
session.  How do they resynchronize?

Suppose B decides to optimize by pre-computing its responses and sends them
prior to A's requests, using a timer.  Is there any harm?

There's an obscure covert channel introduced by this mechanism.  If A
sends IPSec traffic to B and E corrupts that traffic, B will consider
A unresponsive and send a keep-alive.  That lets E distinguish between
successful and unsuccessful corruption.

Security considerations should address how long a session can be used
with the sequence number scheme.  What it be feasible, for example, to
have a one millisecond "worry interval"?

Hilarie

---

From: "Geoffrey Huang" <[email-masked]>
Date: Tue, 4 Feb 2003 22:05:37 -0800

> The draft has a number of non-ascii characters.

I will fix.

> What important advantage accrues from keep-alives?  They allow state

Advantage of keepalives over...?  There isn't a comparison between
keepalives and every other scheme to resynchronize lost state for several
reasons: 1) I don't know ever other scheme 2) I tried to focus on comparing
DPD to keepalives/heartbeats.

> timers, but one still needs them, it seems.

True - one still needs timers, but it's "mitigation" and not "elimination."
The introduction sums up this mitigation - DPD does not need "to send
messages at regular intervals."

> exist until one gets to the message formats.  There's a statement

Do you mean section 5.3?  The SPI isn't referenced until the message
format's presented anyhow...

> SA's and IKE SA's, but the promise is not kept, as nearly as I can see.

The comparison that got elided is this: Hello messages sent out per IPSec SA
can get you finer granularity, but at the cost of maintaining more state.
If you allow the liveness of an IKE SA to imply liveness of all IPSec SAs
through the IKE peer, then you get coarser granularity, but you have to
maintain less state.  I can either add this blurb, or remove the claim about
the comparison.

> validated than that encryption be applied.

...the same way you'd determine any other notify is unencrypted ;-).

> making a deadness decision?  Suppose A decides B is dead, but B does

Yep, you should retransmit.  The number of retransmissions isn't important,
but you're right, I'll add text to this effect.

> prior to A's requests, using a timer.  Is there any harm?

No, since any inbound traffic to A from B serves as proof of liveliness of
B.  As the text mentions, however, each entity defines its own "worry
metric" at which point it considers the liveliness of its peer in doubt.

> successful and unsuccessful corruption.

Successful and unsuccessful corruption of the IPSec traffic?  That would
require E to understand the transmission scheme of B's DPD implementation,
and it would assume that B sends R-U-THERE messages whenever it hasn't heard
from A.

> have a one millisecond "worry interval"?

No, I suppose it wouldn't be feasible to have a 1 ms worry interval.  The
examples in the document suggest something on the order of 10 seconds.

Thanks for the comments.

-g