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

["Geoffrey Huang" <ghuang@cisco.com>]

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

I will fix.

> 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

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.

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

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

> 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

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

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

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.

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

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

> 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

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

> 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?

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.

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

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.

> 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"?

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

> Hilarie
>