[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSP and TCP/UDP ports
IPSP and TCP/UDP ports
IPSEC'ers
Below is a retransmission of a ongoing discussion on port numbers and IPSP.
p.l.
--------------------------------------
Date: 14 Jan 93 10:59:12 -0800
From: Jim Zmuda <zmuda@mls1.hac.com>
To: Paul_Lambert-P15452 <Paul_Lambert@poncho.phx.sectel.mot.com>
Subject: Some things to add to Internet NLSP profile
Paul,
One of the things that we have found lacking with the NLSP spec is the fact
that encapsulating the entire TCP/IP header means that TCP port numbers are
no
longer available in the clear at routers. And many routers (CISCO), as well
as network monitors, read the TCP port numbers to do things like
protocol-based routing. E.G. let TELNET and RLOGIN packets take priority
over FTP packets.
Jim Zmuda
--------------------------------------
Date: 19 Jan 1993 16:31:09 -0700 (MST)
To: Jim Zmuda
From: Paul Lambert
Reply to: RE>Some things to add to Inter
Jim,
You have a good point that we really need to examine. I wonder what IPv7
plans to do about network priority?
It would seem most appropriate to place traffic priority information into a
network protocol. We could kludge ipsec to include some form of priority
indicator, but this seems ugly. Your example implies only two levels of
priority. How many categories of traffic priority would be useful in the
future?
p.l.
.. maybe we should continue this discussion on the ipsec list and try to get
some discussion going there....
--------------------------------------
Date: Wed, 20 Jan 93 08:21:45 PST
From: zmuda@mls1.hac.com (Jim Zmuda)
To: Paul_Lambert@poncho.phx.sectel.mot.com
Subject: Re: Some things to add to In
Paul,
The point of bringing this up was that although there is currently no useful
priority scheme at the network layer, the router manufacturers (I'm thinking
in particular of Cisco - with a 70% marketshare) didn't let that stop them.
They just programmed their routers to peer into the layer four headers
(meaning most of the time TCP or UDP) to look for the TCP port numbers being
used, and relying on the association between well-known port numbers and
protocols, use that information to make informed decisions about how to
route
a particular packet. In addition, many network monitors and diagnostic
devices utilize the TCP port numbers to trace traffic (e.g. problems with
NFS requests and responses not matching up).
Thus, even though from a purists point of view this kind of information
has no business being looked at by a router, it is in fact being looked at.
And since the NLSP/IPSP envelope will neatly wrap that data up in its
cryptographic envelope, that information will no longer be available to a
router. What I was suggesting was that we add a new field to the clear
header to carry generic "upper layer addressing information" in the clear.
This way, it would still be possible for routers to make protocol type based
routing decisions, and it would still be possible for network diagnostics
tools to
perform traces on network traffic by upper level protocol type.
An impure approach, but one which tries to not break things that work now.
Always a good idea when trying to sell someone security as a "useful
feature".
Interestingly, as I point out in my last note, the sort of information
needed
in this additional field in the clear header is just the sort of thing which
a Transport Layer security protocol like TLSP would have in its hands. On
the other hand this information would have to be added to the TCP/UDP to IP
interface calls, or pulled out of the TCP header by NLSP itself. Nasty, but
doable.
Anyway, these things are only needed because the current IP doesn't have
enough info for routers and diagnostics devices to do the full job they are
doing
now. (I'm not sure IP ever will have all this information.) Admittedly,
they (
especially the routers) are violating layering principles, but these guys
make
money by selling features. It is incumbent upon us to figure out a way to
let them continue to provide their feature-rich performance. Otherwise
customers who have these routers will be pissed.
I agree this belongs on the IPSEC discussion. I will recast for that.
Jim Zmuda
_________
Date: 20 Jan 1993 11:55:08 -0700 (MST)
From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert)
Subject: Re: >Some things to add to I
To: zmuda@mls1.HAC.COM (Jim Zmuda)
Reply to: RE>>Some things to add to In
Jim,
I totally agree with the basic requirement that you have identified to be
able to indicate some form of routing information in the clear header.
However, upper layer address information may not be adequate. This would
require a router to understand the attributes of all present and upper layer
protocols.
I can think of two additional ways this requirement could:
* include a new field to indicate the traffic priority and other attributes
* define conventions for the SAID to carry traffic attributes
The latter approach will need to be worked independent of solutions for the
priority issue. Multicast/broadcast assignment of SAIDs requires a
convention to ensure unique assignment of identifiers. For example, all
SAIDs with the MSB set would be globally administered rather then locally
selected.
p.l.
--------------------------------------
Date: 1/21/93 2:40 PM
To: Paul Lambert
From: Jim Zmuda
Received: from phx.sectel.mot.com by poncho.phx.sectel.mot.com (SMTP\QM
1.1.3)
id AA2810472041; Thu, 21 Jan 1993 14:40:41 MST
Received: from pobox.mot.com by phx.sectel.mot.com (4.1/SMI-4.1)
id AA26661; Thu, 21 Jan 93 08:07:48 MST
Received: from motgate.mot.com by pobox.mot.com with SMTP
(5.65c/IDA-1.4.4/MOT-2.6 for <Paul_Lambert@poncho.phx.sectel.mot.com>)
id AA25301; Thu, 21 Jan 1993 09:08:02 -0600
Received: from hac2arpa (hac2arpa.hac.com) by motgate.mot.com with SMTP
(5.65c/IDA-1.4.4/MOT-2.6 for <Paul_Lambert@poncho.phx.sectel.mot.com>)
id AA26293; Thu, 21 Jan 1993 09:08:00 -0600
Received: from mls1.HAC.COM ([147.19.8.25]) by hac2arpa (4.1/SMI-DDN)
id AA11844; Thu, 21 Jan 93 07:07:40 PST
Received: by mls1.HAC.COM (4.1/SMI-4.0)
id AA01260; Thu, 21 Jan 93 07:07:00 PST
Date: Thu, 21 Jan 93 07:07:00 PST
From: zmuda@mls1.hac.com (Jim Zmuda)
Message-Id: <9301211507.AA01260@mls1.HAC.COM>
To: Paul_Lambert@poncho.phx.sectel.mot.com
Subject: Re: >Some things to add to I
Paul,
I disagree. The issue is not whether or not routers should be asked to do
these things (i.e. upper layer addresses) . The fact is that they are
already
doing them!
What I'm trying to point out is that we had better not break these existing
routers when we add the security protocol.
Of course, I'm thinking about adding security devices to end-systems, and
trying to identify all the problems you might face using these end-system
security devices in conjunction with the existing infrastructure of ordinary
vanilla (non-secure) routers. Perhaps you are thinking that all routers
will
be secure routers? That wasn't the case I was concerned with. Although,
even
that case runs up against this problem eventually, like whenever you
interface
to the black network, and thus traverse black network routers.
I don't know, maybe the correct answer to this question is: "Sorry that
doesn't
work!" But it seems to me that there is a little hack that could be used to
fix this problem so that such vanilla routers could still do their
layer-violating protocol-based routing.
Or am I missing the point that you are trying to make entirely, and you are
telling me that all future routers will need to use to make similar
decisions
to those they are making today by peeking at the TCP/UDP port numbers is
some
additional Priority parameters that are going to be defined by IPv7? Or by
us? Or as part of the SA? That might work, if one modifies all those
Transport protocols to map their port numbers to the proper priority to use
for the communications. But the nice thing about the current Cisco approach
is
that it works today with the current TCP implementations and you can alter
priorities based on protocol type (derived from port number) in a
centralized
manner. (You do it at the routers, not at the end-systems.)
Also, I bet this won't satisfy the router people and their customers,
because
they will always want access to some specific piece of information in the
upper
layer protocol header that helps distinguish one kind of traffic from
another.
And thus, having an additional field in the IPSP clear header would allow
you
to carry this kind of info where the routers can see it.
Finally, this approach doesn't help the people who are building the network
diagnostic tools, which have a legitimate need to look into the TCP/UDP
headers for any and all information. Here, adding a field to the IPSP clear
header in which port number or perhaps even other information (I can't think
of any) could be carried would be useful.
Jim Zmuda
_____
Date: 21 Jan 1993
From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert)
Subject: Re: >Some things to add to I
To: zmuda@mls1.HAC.COM (Jim Zmuda)
Jim,
Yes, I think you were missing my point somewhat. I was agreeing with your
basic premise, but attempting to extent the issue a little bit and offer
alternate solutions.
First, I am not against little hacks to fix real problems.
Second, simply placing port numbers in a new field in the clear header will
not transparently work in existing routers unless the formats are identical.
This would mean that the complete network and transport headers would have
to match existing protocols. These are the formats that current routers are
using to make routing and priority decisions. The router parsing will have
to be configured to look at our new protocol unless we make the IPSP clear
header look like TCP or UDP.
Assuming that we are creating a new protocol with a new clear header format
(maybe we could digress later on SP3/SP4 like headers and TCP port numbers),
the fields used to make priority decisions could be based on:
1) The TCP/UDP port number could be duplicated in a new field in the IPSP
clear header. This does lead to some interesting scenarios when the port
number in the clear header is not the same as the cryptographically
protected port number. This is really what started me thinking about this
issue in terms of the priority information implicitly carried by the port
number.
2) A new field in the IPSP clear header that can be used to indicate the
transmission requirements of the information (priority, protocol type, and
perhaps other attributes). Note that here I am using protocol type loosely
and assume that many port numbers would map to the same type of transmission
requirements.
3) The IPSP Security Association Identifier (SAID) field could be selected
to meet conventions that would allow the optional inclusion of priority or
port information.
Once again, I do agree with your proposal when it is re-interpreted as a
requirement in IPSP to optionally provide information in the clear to
identify the type of protocol being encapsulated. This information could be
used by routers to support routing decisions based on the traffics
attributes implied by the protocol type information. I am hedging a little
on your initial proposal to carry this information as a direct mapping of
the TCP/UDP port number.
Paul