From Paul_Lambert@poncho.phx.sectel.mot.com Fri Jan 22 03:23:42 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06086 (5.65c/IDA-1.4.4 for ); Fri, 22 Jan 1993 12:20:15 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA14051 (InterLock SMTP Gateway 1.1 for ); Fri, 22 Jan 1993 12:18:08 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA04861; Fri, 22 Jan 1993 11:18:29 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA29985; Fri, 22 Jan 1993 11:18:24 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA28566; Fri, 22 Jan 93 10:17:54 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA31480; Fri, 22 Jan 1993 10:27:01 MST Message-Id: <00112.2810543221.31480@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Fri, 22 Jan 1993 10:23:42 MST Subject: 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 To: Paul_Lambert-P15452 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 ) 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 ) 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