Re: [saag] Fwd: draft-bonica-tcp-auth

[Stephen Kent <kent at bbn.com>]

At 9:57 AM -0400 4/20/06, Russ Housley wrote:
> We had a presentation at the IETF 65 SAAG session about this
> document.  What should we say to the TCPM folks?
>
> Russ

I have several concerns with the current proposal:

	1. Parts of this proposal seem to focus on inter-router 
communication, specifically in support of BGP, but it should be a 
clearer re the scope of applicability. Alternatively, is this 
intended as a generic layer 4 integrity and key management mechanism? 
I would have a lot of additional concerns if it were proposed in the 
latter context, rather than as just a replacement for the TCP MD5 
checksum option.

	2. The notion of time-based key changeover seems a bit 
complex when one looks at the details. In the BGP border router 
context there may be substantial clock skew between peers, as an ISP 
operator noted when this presentation was made in the RPSEC WG. In 
anticipation of this sort of problem, the proposal allows setting the 
changeover to the equivalent of "forever," which then defeats the 
purpose of the mechanism. During the RPSEC WG discussion of the 
proposal, Ron suggested typical key change intervals might be monthly 
or semi-monthly, but an ISP operator scoffed at that suggestion, 
indicating that anything more frequent than an annual change would be 
too much work.  This disparity between the protocol designer's notion 
of how the system would be managed, and that of a prospective user is 
worrisome, and relevant to my next concern.

	3. On the RPSEC mailing list there was a discussion of 
whether this sort of replacement for the MD5 option was the right 
path, or whether IPsec should be used. (ESP with NULL encryption 
would offer equivalent security functionality for BGP sessions.) 
After several message exchanges it appears that the primary reason 
for not using IPsec is that current router IPsec implementations are 
designed to protect subscriber traffic (with the router acting as a 
security gateway), and this makes it hard to configure them to 
protect router management traffic, e.g., BGP sessions.

	Other concerns about using IPsec centered on the question of 
how to perform key management, e.g., using certs or PSKs.  It was 
agreed that use of certs would clearly be better, but there are 
concerns over getting certs issued to routers for inter-AS use. (The 
PKI work in SIDR might offer a solution to this problem, but it is 
not a very near term solution.)  If one uses PSKs for authentication 
(via IKE), then its seems appropriate to ask how the two mechanisms 
compare in operational terms. IKE generates a new key for each SA and 
transitions traffic from one SA to its re-keyed successor without 
interruption, achieving the same goal as this proposal. A BGP TCP 
session protected via IPsec would be disrupted only if the PSK used 
to authenticate two peers was changed at one peer but not the other 
AND the SA timed out and needed to be re-keyed while the two ends 
were not in sync re the PSKs. An SA can have a long lifetime, 
especially given the relatively low traffic volumes associated with a 
BGP session, which helps minimize the likelihood that the PSKs are 
out of sync AND an SA needs to be re-keyed.

	This is why it is important to ask what is the likely 
frequency of key change for this purpose. Because PSKs for IKE are 
not used to protect traffic, unlike the keys in this proposal, they 
should be changed based primarily on physical, procedural, and 
personnel security concerns, rather than on cryptanalytic concerns. 
That may make annual changes seem more reasonable for PSKs than for 
the keys used for traffic protection in the proposed mechanism.


	4. There is a companion I-D that was generated slightly later 
than the proposal we're discussing 
(draft-weis-tcp-auth-auto-ks-00.txt). It gets closer to IKE-style key 
management for the proposed TCP integrity option. I think it should 
not be treated separately, but rather needs to be considered as part 
of a unified proposal. Only then can we make a fair comparison 
between IPsec and this proposal.

Steve