Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp-clayer-04

Simon Perreault <> Tue, 15 January 2013 09:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 421CF21F8AB8 for <>; Tue, 15 Jan 2013 01:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.658
X-Spam-Status: No, score=0.658 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_22=0.6, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bxT-L+4vbDUx for <>; Tue, 15 Jan 2013 01:40:13 -0800 (PST)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id BA5A921F8A94 for <>; Tue, 15 Jan 2013 01:40:13 -0800 (PST)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f454:37f3:6ead:1220]) by (Postfix) with ESMTPSA id E500140372; Tue, 15 Jan 2013 04:40:12 -0500 (EST)
Message-ID: <>
Date: Tue, 15 Jan 2013 10:40:59 +0100
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Elwyn Davies <>
References: <1358181196.28723.7028.camel@mightyatom> <> <1358189815.28723.7270.camel@mightyatom>
In-Reply-To: <1358189815.28723.7270.camel@mightyatom>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp-clayer-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Jan 2013 09:40:14 -0000

Le 2013-01-14 19:56, Elwyn Davies a écrit :
> c) Encode the reason in the flags bits. 3 reasons and another bit left
> incase we think of some other reasons?  Bit naughty but not a big issue.

Works for me.

> The initial delay SHOULD be at least 1 second but SHOULD be configurable
> and will be application and network type dependent.

Works for me.

> There is a DoS opportunity here in that s6.1 says we have to send the
> contact header (and implicitly complete the TCP setup).  OTOH, there is
> (to the best of my knowledge) no way to tell OS'es to ignore incoming
> SYNs from a particular address for a while.  Probably the best one can
> do is to hold off sending the contact header for a while.

Well, there is a range of things one can do:

a) Once accept() returns, close() the socket if the remote address is evil.

b) Instead of closing, keep the socket open but delay sending the 
contact header.

c) Send a SHUTDOWN as soon as possible.

d) Send a SHUTDOWN after a delay.

e) Combinations of the above...

I think everything is fine and it is up to the implementation to decide 
exactly what to do. It is especially important that it be considered 
legal to just close a TCP connection without sending a contact header. 
So how about simply adding text saying that a server MAY do this kind of 
thing for security purposes?

> One additional thing I had meant to say and forgot:
> The only mention of the ability to use a single TCP connection for
> bidirectional communication (in the sense of sending bundles from A to B
> and B to A on a single TCP connection is in a cryptic reference in s3:
>>     When acknowledgments are enabled, then for each data segment that is
>>     received, the receiving node sends an ACK_SEGMENT code followed by an
>>     SDNV containing the cumulative length of the bundle that has been
>>     received.  Note that in the case of concurrent bidirectional
>>     transmission, then ack segments may be interleaved with data
>>     segments.
> I would add an explanation of this to s3.. maybe a new subsection:
> 3.1.  Bidirectional Use of TCP Connection
> Since each message type used in the TCPCL protocol in association with
> sending a bundle is only sent in a specific direction (DATA_SEGMENT and
> LENGTH from bundle sender to receiver, ACK_SEGMENT and REFUSE_BUNDLE
> from receiver to sender) with the remaining messages (KEEPALIVE and
> SHUTDOWN) being associated with the connection rather than a particular
> bundle, a single TCP connection can be used bidirectionally to send
> bundles concurrently from either end to the other.
> Note that in the case of concurrent bidirectional transmission, ack
> segments may be interleaved with data segments.
> (and remove this sentence from prior occurrence in s3.)

Agreed. This is important.