[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,
(call the protocol police, 3 alarm layer violation in progress ... :-))
The 32 bit hack probably will not be enough. Folks have proposed the use of
SNOOPing protocols that need to look at the TCP seq numbers passing by to
enhance the performance of TCP on wireless/mobile links.
I would suggest a separate ESP transform instead of mucking up the IPSEC
architecture in general. IP proto issues arise ...
While I am not fond of the idea of this form of "management" I agree that
many people have become dependant on the use of port numbers for managing
their networks (firewalls, filters, etc.)
cheers, peter
> -----Original Message-----
> From: Greg Minshall [SMTP:minshall@fiberlane.com]
> Sent: Thursday, March 26, 1998 11:26 AM
> 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
>
>
Follow-Ups: