[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



There does exist a balacing act between manageability and security, but
IPSec was meant to be as secure as possible.  I beleive that most
customers will want to hide the port numbers along with the identities
of the protected systems, ie. hide as much as possible.

By adding ports to the ESP header, you would also have to add yet
another field for the protocol being protected as well, since the next
protocol field in ESP might be pointing to another ESP/AH or IPComp
header.  This is five extra bytes (protocol + source/dest port) that
most people in the working group would not be happy with.

>-----Original Message-----
>From:	Greg Minshall [SMTP:minshall@fiberlane.com]
>Sent:	Thursday, March 26, 1998 2:26 PM
>To:	iesg@ns.ietf.org
>Cc:	ipsec@tis.com; ietf@ns.ietf.org
>Subject:	Re: Last Call: Security Architecture for the Internet Protocol to
>Proposed Standard
>
>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
>
>
>
>
>