[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dccp] Re: DCCP Service Names/Codes and security
In message <200310280207.h9S27Dp0095873@coyote.icir.org>, Eddie Kohler writes:
>Hi Steve, all,
>
>One of Steve's comments from last IETF's DCCP expert review (for which
>THANK YOU AGAIN, it was great) confuses me. It had to do with the security
>implications of DCCP's Service Name field, since renamed to Service Code.
>I wonder if someone could clarify?
>
>Background: Service Code is a 4-byte number, sent on a DCCP-Request (the
>active open), that identifies the service the client expects to be running
>on the server port. If the client's specified Service Code doesn't match
>the server port's internal Service Code, then the connection fails. For
>instance, if the server app listening on port 80 is running service "FTP",
>and the client's DCCP-Request sent to port 80 expected service "HTTP", then
>the connection fails. Service Code 0 is used for wildcards on both Request
>and listening port.
>
>Here are some things that Service Code does *not* do:
>* Service Code does *not* replace Destination Port.
>* Service Code does *not* necessarily allow multiple services to run on the
> same Destination Port. We intended there to be at most one Service Code
> per Port, although the document isn't crystal clear here.
>
>Now here's your comment.
>
> - The service name bother me - this could be dangerous it presents 2
> things with the same meaning: port + name. Once you have two ways
> of doing it, you need two checks, or they can exploited. An example
> is an Operating system that treat low-numbered ports as privileged -
> but midboxes don't do quite same thing (e.g. they open based on
> service name)- can this be exploited? appropriate actions need to
> be defined.
>
>I'm confused because the Service Code *doesn't* mean the same thing as the
>port. The port is explicitly the primary lookup. If I were writing a
>midbox I'd totally do it with port first, using Service Code as a secondary
>check.
>
>Is that all you meant by "appropriate actions" -- adding some text, perhaps
>in the Middlebox Considerations section, like:
>
> Since well-known ports are well understood in TCP and UDP, and ports
> remain DCCP's main way to differentiate among services active on an
> endpoint, middleboxes should use well-known DCCP ports as their main
> policy enforcement mechanism. The Service Code values on DCCP-Requests
> should be used for supplementary checks.
>
Then I'm confused about the purpose of the Service Code. I had thought
it was to permit middle boxes to work in a port number-independent
fashion, so that NATs could change port numbers.
--Steve Bellovin, http://www.research.att.com/~smb
_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info: https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html