Key Change Strategies for TCP-MD5
draft-bellovin-keyroll2385-04

[Ballot discuss]
> There is a problem if the unchanged machine is a "silent host" -- a
> host that has nothing to say, and hence does not transmit.  The best
> way to avoid this is for an upgraded machine to try a variety of keys
> in event of repeated unacknowledged packets, as discussed earlier.

I re-read the relevant parts of the draft and was
considering removing my Discuss entirely, since the
text in Section 2.2 covers most of what I wanted to
say. But I would still suggest changing the

  The best way to avoid this is for an upgraded machine
  to try a variety of keys in event of repeated unacknowledged
  packets, as discussed earlier.

to

  The best way to avoid this is for an upgraded machine
  to try a variety of keys in event of repeated unacknowledged
  packets, and to probe for new unused keys under silent
  periods, as discussed in Section 2.2.

[Ballot comment]
A minor point: First paragraph of section 2.1:

  A receiver has a list of valid keys.  Each key has a (conceptual)
  timestamp associated with it.  When a segment arrives, each key is
  tried in turn.  The segment is discarded if and only if it cannot be
  validated by any key in the list.

In my reading of the document, the timestamp doesn't actually do anything wrt receiving the packet, but does have an effect on sending the packet, in that the timestamp is the earliest time that you will use the key in sending a packet, but you will use any of the configured keys in checking received packets. I think that this could be stated a bit more explicitly up front, and it seems odd that if the timestamp is only used for sending, it is described in the receiving section. One option would be to move this section ahead of the 2.1 heading, so that it becomes part of section 2, and then update it to clearly make this point. This might then make the beginning of section 2 (up to the 2.1 heading) to read:

  2.  The Algorithm

  A receiver has a list of valid keys that may be used for both
  transmission and reception.  Each key has a (conceptual) timestamp
  associated with it which specifies the earliest time that it can
  be used for transmission. 

  Separate algorithms are necessary for transmission and reception.
  Reception is easier; we explain it first.

  2.1.  Reception

  When a segment arrives, each key is tried in turn (without regard
  for the timestamp).  The segment is discarded if and only if it
  cannot be validated by any key in the list.

  In principle,...


A very minor nit: second paragraph of section 2.1, last sentence says:

  On the other hand, validating that a received segment is putatively
  legal, by checking its sequence number against the advertised window,
  can help avoid denial of service attacks.

I think here that the word "avoid" should be "minimize the impact of", since strictly speaking this strategy doesn't completely avoid DOS attacks, it just allows you to discard some invalid packets with a relatively quick method (check sequence number) rather than a slower method (check the authentication).

[Ballot discuss]
> There is a problem if the unchanged machine is a "silent host" -- a
> host that has nothing to say, and hence does not transmit.  The best
> way to avoid this is for an upgraded machine to try a variety of keys
> in event of repeated unacknowledged packets, as discussed earlier.

The machine cannot be silent, if it is expected to
have a persistent TCP session with its peer, such
as is the case with BGP use of TCP MD5. There will
be ACKs.

Or are you referring to a situation where the two
hosts are not communicating at all, and will bring
up TCP only on a per-need basis? If yes, the draft
probably needs to talk about delaying any key
change actions until there has been communication.

[Ballot comment]
No IANA considerations. Author suggests:

        There are no IANA actions required.  The TCP-MD5
        option number is defined in [RFC2385], and is currently
        listed by IANA.

[Ballot comment]
It is not clear to me what the following text in Section 3 means:

'Any monitoring mechanism can be used; most likely, it will be a combination of a MIB entry and a command-line display.'

I assume that by MIB entry the author means a MIB object or entry in a table in a standard MIB module. What command-line has to do here? Or does he mean that the current practice or recommendation for monitoring involves some mix of management interfaces out of which MIB objects accessed by SNMP and CLI are more obvious?

It would be good to clarify this part of the text.