[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
At least two things get affected on intermediate routers
due to presence of IPsec traffic going through.
1. Fine grained Statistic counting
2. Traffic Inspection on packet per packet basis
First issue can be partially resolved by having protocol
support logically equivalent to:
Host A negotiates a SA destined to Host B with Router R.
Tricky logic, but can be technically achieved with modification
of current ISAKMP. While this might open a new sort of attacks
(I don't care), the router R can further differentiate IPsec traffic
by SPI value found in there.
Note that fine grained SAs must be used to handle different
priorities/precise statistics for traffic going through router R.
Second issue can be resolved only under an assumption that host A and B
will reveal information to R that is equivalent to having the case:
SA: A to B = AH(A->B, application data))
SA: A to R = ESP(A->R, AH(A->B, application data))
SA: R to B = ESP(R->B, AH(B->A, application data))
SA: B to A = AH(B->A, application data))
SA: B to R = ESP(B->R, AH(B->A, application data))
SA: R to a = ESP(R->A, AH(B->A, application data))
Nothing prevents to have this done based on current specs though
nothing is in the specs to simplify such a policy management.
---
Alexei
---
-----Original Message-----
From: Roy Pereira <rpereira@TimeStep.com>
To: 'Greg Minshall' <minshall@fiberlane.com>
Cc: 'ipsec@tis.com' <ipsec@tis.com>
Date: 27 марта 1998 г. 0:41
Subject: 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
:>
:>
:>
:>
:>
:
Follow-Ups: