[e2e] Port numbers in the network layer?

[John Day]

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 
better isolation.

One of the implications of Watson's work is that port-id and 
connection-endpoint-ids should be distinct. This has a number of 
benefits.

>
>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...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130426/e3d7dab8/attachment.html