Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard

[Bill Sommerfeld <sommerfeld at orchard.arlington.ma.us>]

Since often things seem to turn on the volume (or mass) of commentary,
I think I'll weigh in here..

A number of folks have argued for adding various layers of
"transparency" to the ipsec, for a variety of reasons:
	1) management wiretapping.
	2) differential handling based on protocol.
	3) protocol spoofing for long-latency networks.

None of these seem to justify this, and there are alternate means of
accomplishing these..

1) Wiretapping is exactly what this set of protocols was intended to
prevent (duh!)...  conceivably, facilities for wiretapping traffic (a
la RMON), both before encryption and after decryption, could be built
into end systems, and enabled only when suitable cryptographic
authorization is presented by the management station.. however, I
can't imagine situations where I would want to turn that on in
production systems..

2) The proposed mechanism (putting a copy of port numbers outside the
crypto) is essentially a "new" mechanism, requiring new handling in
routers, and could just as well be replaced by code which sets the
appropriate TOS/precedence bits.  Also, if fine-grained (e.g.,
connection-oriented) keying is in use, different flows could be
distinguished by the SPI (which, for ESP, is conveniently the same
size and in the same place as the port pair..)

3) IMHO, protocol spoofing (e.g., forging TCP acks in the middle of
the network) is simply evil....

					- Bill