FW: [dccp] Re: wildcard service code?

[vladimir.moltchanov at nokia.com]

>-----Original Message-----
>From: Moltchanov Vladimir (Nokia-NRC/Helsinki) 
>Sent: 23 November, 2005 09:33
>To: 'ext Eddie Kohler'
>Subject: RE: [dccp] Re: wildcard service code?
>
>Hello, all.
>
>As it was mentioned already, its not a big deal to add a line 
>in the code to set this service code. However, it IS different 
>from TCP or UDP style and that's not good, since many will hit 
>this corner at least once before it will become a general 
>knowledge. Then the question: which service code to use? 
>
>
>(quote)
>Each DCCP-Request contains a 32-bit Service Code, which identifies
>    the application-level service to which the client application is
>    trying to connect.  Service Codes should correspond to application
>    services and protocols.  For example, there might be a Service Code
>    for SIP control connections and one for RTP audio connections.
>    Middleboxes, such as firewalls, can use the Service Code 
>to identify
>    the application running on a nonstandard port (assuming the DCCP
>    header has not been encrypted).
>(/quote)
>
>I understand, that service codes are not personal (like 
>application codes in Symbian OS, for example) but a dupplicate 
>of a protocol port on a different level. I am quite sceptical 
>about automatic firewall tunneling by using this approach, 
>cause I can already see a spyware app sending an RTP request 
>on a non-standard port. So, there still should be some sort of 
>management of ports that could be non-standard for a certain 
>services on a FW. So there is no mandatory need for an 
>application that doesn't intend to go via specific firewall to 
>use a specific service numeber, then. 
>
>So, why not to have a default "private use" number that is set 
>automatically by default OR, since those service numbers are 
>not DCCP-only, to apply and to reserve a DCCP_GENERAL_SERVICE 
>number which would be the default one?
>
>B.R.
>Vladimir.
>
>
>>-----Original Message-----
>>From: dccp-bounces at ietf.org [mailto:dccp-bounces at ietf.org] On 
>Behalf Of 
>>ext Eddie Kohler
>>Sent: 22 November, 2005 22:04
>>To: Yoshifumi Nishida
>>Cc: dccp at ietf.org
>>Subject: [dccp] Re: wildcard service code?
>>
>>Hi,
>>
>>As we discussed previously, my preferred implementation would 
>have been 
>>to stick the Service Code in the sockaddr.  Then there wouldn't be an 
>>extra step to frustrate users.  You vetoed that, I forget why, but I 
>>wasn't convinced by your arguments.
>>
>>The lack of a Service Code wildcard is intentional.  As we discussed, 
>>we will not add a wildcard service code, since this would open a huge 
>>hole in the service code mechanism.  It would be better to remove 
>>Service Codes entirely, which we will not do.
>>
>>We would prefer that every application writer apply for, and use, an 
>>application-specific Service Code as soon as possible; so the current 
>>default, which encourages that behavior, is fine.  Although I would 
>>discourage this, the document does not prevent the Linux 
>implementation 
>>from starting up with Service Code 0; we say that Service Code 0 MUST 
>>NOT be *allocated*, not that it must not be used.
>
>
>
>
>>
>>Eddie
>>
>>
>>On Nov 22, 2005, at 11:05 AM, Yoshifumi Nishida wrote:
>>
>>>
>>> Eddie,
>>>
>>> Sorry, This might be too late to bring this up, but I have
>>one comment
>>> on service code. If I could have a little chance, I would
>>like to put
>>> this on the table and see what other people think.
>>>
>>> In section 8.1.2 of the draft-ietf-dccp-spec-12.txt, it says:
>>>
>>>   Service Code 0 represents the absence of a meaningful Service
>>>   Code, and MUST NOT be allocated.
>>>
>>> To comply with this, the linux implementation sets service
>>code to -1
>>> as the initial value and a program will get EPROTO if it
>>doesn't set a
>>> proper service code with setsockopt().
>>>
>>> (see: http://linux-net.osdl.org/index.php/DCCP#FAQ)
>>>
>>> It seems to me that this might cause a little confusion to some 
>>> application programmers.
>>>
>>> But, if we could have service code 0 as a wildcard service
>>code which
>>> indicates that the application doesn't care about the
>>service code and
>>> accepts any value of service code, we don't have to set a
>>service code
>>> if we don't need to use it.
>>> Or, if we could use service code 0 as the absence of a meaningful 
>>> service and use it as the initial value, we can get similar effect.
>>>
>>> I think we had better avoid mandatory use of setsockopt if it's 
>>> possible and a wildcard service code may be uselful in some 
>>> situations.
>>>
>>> Thanks,
>>> --
>>> Yoshifumi Nishida
>>> nishida at csl.sony.co.jp
>>> Sony Computer Science Laboratories, Inc.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>