[e2e] Port numbers, SRV records or...?

[Joe Touch]

We may be converging, so I'll focus on the port issues per se:

Keith Moore wrote:
...
>>>>> The destination host knows which protocol is being used, the source
>>>>>  host presumably also knows (it has some reason for choosing that
>>>>> port, whether it's because it's a well-known port or a SRV record or
>>>>> configuration data or whatever), and I wonder whether anyone else
>>>>> needs to know.
>>>> That's only for well-known ports;
>>> no, it's true regardless of how the initiator chose which destination
>>> port to use.
>> So I use the string "APPLESAUCE" - what protocol does that mean, please?
> 
> I think we're sort of in agreement here.  It doesn't matter why or how
> a port is chosen - basically it shouldn't mean anything to anyone
> except the destination.   You're arguing that the same would be true of
> a selector string in a TCP option.   I can't say that you're wrong in
> how they could be used  - but I'm concerned by your wanting to define
> the selector string as a protocol name when there are (a) good reasons
> to not expose this to the network (even for legitimate apps that have
> no reasons to call themselves applesauce) and (b) good reasons to run
> multiple instances of the same protocol (presumably with the same
> protocol name) on the same host.  

Numbers and strings are equally exposed. If you want privacy at that
layer, encrypt.

As to running multiple instances of the same protocol on the same host,
that's harder - the key question is "how do you know which one you want
to talk to".

If the answer is "it depends on the protocol" (e.g., server instance in
HTTP, NFS subset, etc.), that ID belongs in the HTTP/NFS/etc stream, not
in the TCP header - and not demuxed there.

Is there an ID you can think of that is necessary at the TCP layer that
differentiates instance of a protocol?

>> The portnames ID argues primarily for another ID for the protocol
>> separate from the port. The use of strings is my personal preference,
>> but not required.
> 
> I guess I think it's more straightforward to just extend the size of
> the port number space.

My ID shows how to do this in a fairly backward-compatible way.
Increasing portspace size has benefits, but isn't as viable. It also
continues to mix port and protocol in the same number space.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060809/061f18e4/signature.bin