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

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.

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.

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,... <continue with existing text here>


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