Re: DCCP & port randomization

On Jan 31, 2010, at 1:51 AM, Fernando Gont wrote:

>> Similar to TCP, DCCP is also connection-oriented and has a LISTEN  
>> state
>> for server sockets. I also believe that implementations use the  
>> socket
>> API for opening server DCCP sockets in a similar way that TCP does,  
>> so
>> many issues are probably similar. But there is a relevant difference:
>> DCCP service codes are intended to allow more flexible allocation  
>> of the
>> ports, or even sharing a port by multiple applications.
>
> Is that mandated by the specs? IIRC, when I reviewed Gorry's
> dccp-service-codes I-D (now RFC5595), it was still open what to do  
> with
> services codes.

Yes, I think RFC5595 says that sharing a port for multiple SCs at a  
server should be possible, and it also proposes an algorithm on how to  
pick a dynamic port based on service code.

- Pasi

Re: DCCP and IETF-77

Hi,

It seems there is not much demand for having a DCCP meeting in  
Anaheim, so Tom and I have decided not to schedule a meeting this time.

There are two drafts that are in progress. One on UDP encapsulation,  
that will be named draft-ietf-dccp-udpencap-00, and there are also  
plans to re-activate draft-ietf-dccp-user-guide. My understanding is  
that these are practically already revised, but there are problems in  
getting them through the submission tools. I hope these problems can  
be solved ASAP.

We are planning to request a time slot from TSVWG to discuss the UDP  
encapsulation draft there.

- Pasi

draft-ietf-dccp-udpencap-00

Hi All,

I've submitted draft-ietf-dccp-udpencap-00 to the I-D editor.  While
we're waiting for it to arrive in the archive, it can be viewed at
http://www.phelan-4.com/dccp/draft-ietf-dccp-udpencap-00.txt.  You can
see a diff with the previous (individual) version at
http://tools.ietf.org//rfcdiff?url1=http://www.phelan-4.com/dccp/draft-i
etf-dccp-udpencap-00.txt&url2=http://www.ietf.org/id/draft-phelan-dccp-n
atencap-03.txt.

This version incorporates changes that were discussed on the mailing
list in December or so last year.  Important changes are:

 o  Partial checksum -- this was completely modified to use a UDP-Lite
type operation.  For DCCP-NAT, the UDP Length field is redefined to mean
the extent of the packet that is covered by the UDP checksum.  This,
while still a kludge, is cleaner than the previous mechanism, and
provides protection for the UDP header that the previous mechanism
didn't.

 o  SDP simplification -- I mostly followed Colin's suggestions for
simplifying the SDP, but not completely.  Colin, please check this out.

 o  ECN -- there is a new section on ECN support in reaction to Gorry's
comments in this area.  Gorry, please check this out.

 o  PMTUD -- there is a new section on PMTUD.  Basically it just says do
what RFC4340 says to do.

Tom P.

Re: DCCP & port randomization

Hello, folks,

I'm trying to finish a rev of the port-randomization I-D. The only
remaining bit is the DCCP-specific text. It'd be great if any you could
help me with closing these remaining bits...

Comments in-line...

>> So the question in this regard wrt DCCP would be: if there's a process
>> "listening" for incoming connections (on, say "any IP address, port X"),
>> and an attacker on the same host is allowed to bind() a more-specific
>> socket (say, "IP address, port number X" or "IP address, port number X,
>> service code Y") to steal an incoming connection request?
>>
> I think this could be possible for DCCP - but one also needs to be aware
> of the role of service codes here. Two or more server apps could use a
> different DCCP Service Code value and also be bound to the same server
> port(s). See also section 3.3.1 of RFC 5595.

Question: If I understand the DCCP text, port-numbers are kinda a first
level of demultiplexing. Once you demultiplex an incoming based on the
DCCP destination port, you demultiplex it according to the service code.
Is this correct?

Now, assuming the above is correct:
Say an app binds {IP: INADDR_ANY, Port: X, SC: Y}.
Is it possible for another socket to bind() {IP: Z, Port: X, SC: Y}?
Does the spec prevent this? (e.g., is the first socket required to
setsockopt() something like SO_REUSE_PORT for the socket layer to allow
a another socket to re-bind() the same Port and SC?

Re: DCCP & port randomization

Fernando Gont wrote:
> Hello, folks,
> 
> I'm trying to finish a rev of the port-randomization I-D. The only
> remaining bit is the DCCP-specific text. It'd be great if any you could
> help me with closing these remaining bits...
> 
> Comments in-line...
> 
> 
>>> So the question in this regard wrt DCCP would be: if there's a process
>>> "listening" for incoming connections (on, say "any IP address, port X"),
>>> and an attacker on the same host is allowed to bind() a more-specific
>>> socket (say, "IP address, port number X" or "IP address, port number X,
>>> service code Y") to steal an incoming connection request?
>>>
>> I think this could be possible for DCCP - but one also needs to be aware
>> of the role of service codes here. Two or more server apps could use a
>> different DCCP Service Code value and also be bound to the same server
>> port(s). See also section 3.3.1 of RFC 5595.
> 
> Question: If I understand the DCCP text, port-numbers are kinda a first
> level of demultiplexing. Once you demultiplex an incoming based on the
> DCCP destination port, you demultiplex it according to the service code.
> Is this correct?

for the most part

> Now, assuming the above is correct:
> Say an app binds {IP: INADDR_ANY, Port: X, SC: Y}.

Re: DCCP & port randomization

I agree with Eddie's note that the API and user guidelines have not been 
specified for DCCP - this is probably one reason for the small number of 
responses.

I also agree that the difference between server and client functions in 
DCCP make port randomization less important/undesirable for the DCCP server.

I looked at the new text in rev -06 looks like it may be appropriate. I 
note that you used "should not" rather than "SHOULD NOT" - was that 
intentional, and if so, why.

Gorry

I've looked at the new

Fernando Gont wrote:
> Hello, folks,
> 
> I'm trying to finish a rev of the port-randomization I-D. The only
> remaining bit is the DCCP-specific text. It'd be great if any you could
> help me with closing these remaining bits...
> 
> Comments in-line...
> 
> 
>>> So the question in this regard wrt DCCP would be: if there's a process
>>> "listening" for incoming connections (on, say "any IP address, port X"),
>>> and an attacker on the same host is allowed to bind() a more-specific
>>> socket (say, "IP address, port number X" or "IP address, port number X,
>>> service code Y") to steal an incoming connection request?

Re: DCCP & port randomization

Re: DCCP & port randomization

I think the current text looks appropriate.

I'll leave the AD and others to comment on whether they think we should 
make this an RFC 2119 recommendation.

Gorry

On 17/02/2010 19:07, Fernando Gont wrote:
> On Wed, Feb 17, 2010 at 10:52 AM, Gorry Fairhurst <gorry <at> erg.abdn.ac.uk
> <mailto:gorry <at> erg.abdn.ac.uk>> wrote:
>
>     I looked at the new text in rev -06 looks like it may be appropriate.
>
>
> Sorry... does the current text look okay?
>
>
>     I note that you used "should not" rather than "SHOULD NOT" - was
>     that intentional, and if so, why.
>
>
> I guess I just added a clarification for DCCP but didn't mean to add a
> "new" req. In retrospective, one my argue that I should s/should
> not/SHOULD NOT/ both for DCCP and for TCP (and probably for SCTP, too).
>
> Thoughts? Comments?
>
> --
> Fernando Gont
> e-mail: fernando <at> gont.com.ar <mailto:fernando <at> gont.com.ar> ||
> fgont <at> acm.org <mailto:fgont <at> acm.org>
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Fwd: I-D Action:draft-ietf-dccp-udpencap-00.txt

Hi,

Thanks, Tom, for submitting the the draft. Everyone, please take a  
look at this version and send comments.

Checksum calculation was discussed on the list last November to quite  
some extent. What do people think, is the current version (i.e.,  
applying UDP length for partial checksum calculation logic, always  
include UDP/DCCP header) acceptable?

In addition, to perform some primitive issue tracking, I think the  
following points were raised earlier on the mailing list, but  
according to my reading are not addressed yet:

* make a note this mode is not valid for IPv6
   -- Gorry / 2009-11-20
   (PS: I'm not sure if "this mode" referred to checksums, or the draft
   overall, and not sure I understand what "not valid" means. Hopefully
   UDP encapsulation is not necessary with IPv6, but technically it
   could be done, right?)

* worth considering a straight UDP encapsulation that does not adjust
   the position and order of the fields.
   -- Gorry / 2009-11-20

* essential that any encapsulation draft also notes the drawbacks of
   this mode, and hence advocates native transport were possible
   (e.g. No currently defined support for ECN, No currently defined
   support for shared PMTUD, Restricted support for partial coverage)
   -- Gorry / 2009-11-20

(please shout if there was something in the past discussion I missed)

Tom (& others), do you have opinions about the points above?

- Pasi

Begin forwarded message:

> From: Internet-Drafts <at> ietf.org
> Date: February 11, 2010 9:15:02 AM PST
> To: i-d-announce <at> ietf.org
> Cc: dccp <at> ietf.org
> Subject: [dccp] I-D Action:draft-ietf-dccp-udpencap-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Datagram Congestion Control  
> Protocol Working Group of the IETF.
>
>
> 	Title           : Datagram Congestion Control Protocol (DCCP)  
> Encapsulation for NAT Traversal (DCCP-NAT)
> 	Author(s)       : T. Phelan
> 	Filename        : draft-ietf-dccp-udpencap-00.txt
> 	Pages           : 11
> 	Date            : 2010-02-11
>
> This document specifies an alternative encapsulation of the Datagram
> Congestion Control Protocol (DCCP), referred to as DCCP-NAT.  This
> encapsulation will allow DCCP to be carried through the current
> generation of Network Address Translation (NAT) middleboxes without
> modification of those middleboxes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dccp-udpencap-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

Re: I-D Action:draft-ietf-dccp-udpencap-00.txt

Hi Tom,

Here are some personal (no hats on) comments on the draft:

Have the benefits vs. disadvantages of defining a different DCCP
header for UDP encapsulation been discussed earlier? The current
method saves some redundant header space, but may add to
implementation complexity in the DCCP side. I can't say if this is a
significant concern, but I wonder if it is a problem that DCCP-UDP
supports different set of features than native DCCP, such as not
supporting the short sequence numbers?

Section 3.3.1: I'm not very fond of the idea of fiddling with the
UDP length field to implement partial checksum logic, and would rather
leave the UDP protocol untouched. I guess my take on the checksum
calculation would be just to do something simple, even if it would
mean that partial checksums were not supported with UDP encapsulation.

Section 3.5: I think the draft needs to say more than this about Path
MTU discovery, starting from reminding about the basic fact that use
of UDP reduces the MTU available to DCCP. Also, I'm not sure how/if
PMTU discovery would work in this case. The ICMP Packet Too Big
would be routed to UDP, and UDP would need to pass this
information over to DCCP somehow (which could be a problem if UDP is
in the OS and DCCP is in the user space)

And couple of nits:

Section 3 says "The basic approach here is to insert a UDP ([RFC0768])
"shim" layer between the IP header and a DCCP packet" -- Is this
really a "shim" layer? It adds a full protocol header between IP and
DCCP, as visible on the wire?

How about changing the name of DCCP-NAT to DCCP-UDP? This is not  
explicitly a NAT
interaction mechanism, even though NATs are the major motivation.

- Pasi