[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
Greg,
I'm not sure what the correct procedure is for addressing IESG last call
comments, so I am sending this to the same lists as you.
I don't believe it would be difficult to create a "header", much like AH,
that would be filled in with the UDP/TCP port information (and any other
information that is encrypted, but found useful for network management
purposes). This header could be included in the scope of AH authentication
data, so it couldn't be changed by an intruder (unless AH wasn't present).
However, I don't think the receiver should replace the port information
protected by an ESP header by the port information carried in the clear. I
suggest the following slight modification to that rule. If the management
header is present and protected by AH, the ports in the management header
and ESP protected data must match. Otherwise, the packet is presented for
normal IPsec processing. If network administrators are burdened by the lack
of port information in packets, they can always configure their networks to
discard packets that do not have a protected management header.
The advantage of this approach is it allows the management header
definition and IPsec promotion to proposed standard to proceed
independently. The only change necessary to IPsec is to add the management
header to the list of "immutable" fields over which AH authentication codes
are computed, once it is defined.
Dan Nessett
At 7:26 PM +0000 3/26/98, Greg Minshall wrote:
>Dear IESG,
>I have one serious concern about the IP Security Architecture, which is the
>fact that IPSEC packets encrypt the TCP/UDP port numbers in packets.
>I think this is a significant issue in a number of areas related to
>operating
>and managing the internet (and smaller intranets). For example, these days
>we
>are able to measure traffic growth by application type ("how much of the
>traffic is HTTP traffic and how is that changing over time?" is typical of
>the
>questions we ask there). When debugging problems, correlating packets
>observed with known application behaviours ("oh, yes, that must be from a
>buggy version of TN3270") is often useful. We occasionally would like to
>give
>different classes of service to different application types.
>While it is quite possible that the removal of port numbers from the
>cleartext
>payload will *not* adversely affect the operating of the internet, i worry
>that it may impact things negatively.
>If i were to summarize what i would like to see done, it would be to
>provide
>room in the cleartext portion of the IPSEC header for "32 bits of source
>and
>destination port numbers (or their equivalent) in protocols that have the
>concept of port numbers", along with "advice to implementors" that the
>ultimate receiver should use these bits, if not zero, to replace the port
>numbers carried within the encrypted payload. (Applications worried about
>port-based traffic analysis would be able to use zeroes in the cleartext
>header.)
>This issue was raised (several years ago) within the IPSEC working group.
>After a reasonable discussion, the working group decided to leave the port
>numbers encrypted. I think that from the IPSEC working group's point of
>view,
>this makes sense (maximum security). I am hoping that from the point of
>view
>of the entire IETF, we may be able to decide that managing the network is
>important enough to move the port numbers into the clear.
>Thanks very much for your consideration in this matter,
>Greg Minshall