Subject: [tcpm] feedback on tcp-auth-02

From: Joe Touch <[email-masked]>
Date: Fri, 02 Dec 2005 14:00:21 -0800

Hi, Ron (et al.),

As promised, here's some detailed feedback on your draft. I hope it's
useful, albeit a little later than I expected...

Joe

- ------

First, I think there are three reasons network administrators don't use
TCP/MD5, and all need to be considered:

	1) key management

	2) performance

	3) flaws in the current protocol
		- not an HMAC
		- lack of a key ID (for key rollover/rekeying)
		- lack of an algorithm ID (for alternate algorithms)

#2 is a bit of a red-herring; all hash algorithms are similar in
performance (differing by a factor of 2-3, which is not much).

#1 is a BIG issue; this doc ought to include a key management protocol.
Originally, I was thinking it might leverage IKE to do key distribution,
but now I believe that the fate sharing of SYN+DiffieHellman makes more
sense. Otherwise it's a burden on the app to coordinate sockets with
IKE. DiffieHellman (authenticated, and perhaps not [as per BTNS]) is
requied; the key must be per-session.

Doing the DH requires specifying that protocol - perhaps using the
reserved bit to indicate DH request, DH reply, etc., and whether this is
a new keying or rekeying.

#3 are easier to fix, and you've taken steps along most of those lines.

IMO, it's simpler to just use a key ID and do rekeying by request (use
one of the flags to trigger it, and allow rekeying messages to be
exchanged with null data segments).

More specific comments:

Sec 2, first paragraph: refer to TCP, not BGP (TCP sessions for BGP).
The intent was to secure BGP sessions, but it's TCP that gets secured.

Sec 2, end: I don't agree that rekeying sync is the largest deterrent to
use; the largest appears to be CPU load, and that's not addressed here.
As per my other post, I don't think it can be addressed; most algorithms
are basically the same performance-wise.

Sec 3: why not allow multiple active keys? that would allow parallelism
in hardware (which might actually impact performance).

Throughout: omit references to "routers". BGP sessions are host-host;
the router is acting as an 1122-style host for those connections, even
though the information is used to configure the router.

Near end Sec 4: while I agree that the source should receive responses
for bad key'd data, the recipient MIGHT (it might be useful to know
you're being attacked, e.g.)

End Sec 4: If the extension is not required during the SYN, you're going
to need another handshake protocol to establish the diffie-hellman, and
to decide at what point to allow new data through. IMO, this is just a
lot of extra work; I'd just as soon assume that the DH happens during
the SYN. Note - I'm assuming a DH to establish a per-session key,
something this doc doesn't address, though.

Page 6: reserved bits:
	MUST set to zero in current implementations
	MUST ignore on receipt in current implementations

	(otherwise you'll never be able to use them in the future!)

Refer to the possible use of the TCP "NOP" option for alignment.

Table 1: omit non-HMAC algorithms, IMO

Sec 5.1: clock sync seems like an antiquated key management scheme; it
would be more useful to use IKE-style management, which is not
timer-based. If timer-based is required, it will be useful to give a
detailed explanation as to why (i.e., why you're diverging from
'conventional' key rollover).

Question about keychains - at what point do they get cleared out? If the
other side reboots and loses the session keys, it can never generate a
RST that is accepted. IMO, a viable solution would be to allow new SYN
Diffie-Hellman exchanges, which if authenticated (with the
authentication key, not the session key), would cause the current
keychain to be flushed.

Sec 5.4: if you have too many options, which ones take precedence? Or
should the option configuration request be denied? this needs to be
explained and defined.

Sec 5.5: "at minimum...80 octets, as this" is sufficient. You don't need
to use both "minimum" and "or less" in the same sentence ;-)

I would NOT allow the use of a single key for multiple sessions; this is
a TCP protocol, and everything should be per-connection. Which is why
per-session keys via DH is preferred, IMO.

Sec 7: I see two considerations:
	1) option KIND
	2) algorithm types (for use in DH negotation)
		which might be copied from IKE
- ----

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm