Key Change Strategies for TCP-MD5
Note: This ballot was opened for revision 04 and is now closed.
(Russ Housley) Yes
Magnus Westerlund Yes
(Jari Arkko) (was Discuss) No Objection
(Ross Callon) No Objection
Comment (2006-11-16 for -)
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).
(Brian Carpenter) No Objection
Comment (2006-11-15 for -)
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.
(Bill Fenner) No Objection
(Ted Hardie) No Objection
(Cullen Jennings) No Objection
(David Kessens) No Objection
(Dan Romascanu) No Objection
Comment (2006-11-14 for -)
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.