[e2e] Port numbers in the network layer?
jeanjour at comcast.net
Fri Apr 26 15:30:24 PDT 2013
At 9:32 PM +0200 4/25/13, Detlef Bosau wrote:
>Am 25.04.2013 14:52, schrieb John Day:
>>Re: [e2e] Port numbers in the network layer?
>>The question is why is a protocol-id field required in some
>>protocols and not others.
>>If it is to identify the protocol in the layer above, then how many
>>thousand SCTP instances can I identify on top of a single IP
>>instance. If it identifies the protocol, then that should be
>>possible. Obviously it isn't what it is intended for.
>So, what is, concisely, the problem and your proposed solution?
Problem? What problem? No one suggested there was a problem.
The question was about the distinction between protocol-id fields and
port-ids. I explained the difference and what the function of the
protocol-id field was as opposed to the purpose of source and
destination port-ids. It is the case that the protocol-id field does
have the rather disturbing property of requiring an (N)-protocol to
have information about (N+1)-protocols, while port-ids provide
One of the implications of Watson's work is that port-id and
connection-endpoint-ids should be distinct. This has a number of
>Up to know, each individual TCP connection is uniquely identified by
>an address quadruple (node 1, port 1, node 2, port2).
>Why doesn't this work?
For what value of "work"? ;-)
The current practice in TCP has certain security problems. These
stem from the fact that port-ids and connection-endpoint ids are
conflated and the use of well-known ports. The TCP server must rely
on source port to distinguish connections to a well-known port. This
is a number it did not generate and can be spoofed and hence creates
a security vulnerability.
>And which solution works better?
Taking the lessons from delta-t noted above and eliminating the need
for well-known ports avoids a number of security vulnerabilities.
see G. Boddapati, L. Chitkushev, J. Day, and I. Matta "Assessing the
Security of a Clean-Slate Internet Architecture," Seventh Workshop on
Secure Network Protocols (NPSec) October 30th, 2012.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest