[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dccp] Re: wildcard service code?

Hi Vladimir, all,

Thanks to everybody for discussing this issue!  I think it is important.

Hopefully Mark Handley will speak up, since he originated Service Codes and cares about them the most.

Re: spyware applications: You're right. Middleboxes should not trust Service Codes for security decisions! (Hope you didn't get that impression.) We do not think Service Codes are secure. We do believe that we could build better middleboxes, firewalls, trace analyzers, and so forth if connections declared what application they were intending to contact. Think of a NAT, for example; a NAT that changed payload could work for connections using nonstandard ports, if it knew which app was running on which port.

But if most connections on the Internet have the default Service Code, we will never know how much Service Codes could have helped. This is why I'm pushing back.

Again, there's always Service Code 0, which "represents the absence of a meaningful Service Code". This should be the default, if you desperately want a default. A Linux- or DCCP-specific default Service Code would be strictly worse than 0.

More generally, while I want it to be easy to port applications from UDP to DCCP, a handful of differences seem fine, especially when they are as easily resolved as the Service Code. #define SOCK_DGRAM SOCK_DCCP will lead to a working application, but not an optimal application. For instance, Section 14 says that "fragmentation SHOULD NOT be the default", meaning that DCCP should by default refuse to send any datagram that would lead to a packet larger than the MTU. Although an implementer might ignore this advice, that would be a shame, since it will lead to worse-performing applications in the end.

Eddie


On Nov 22, 2005, at 11:35 PM, vladimir.moltchanov at nokia.com wrote: 
-----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.