Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp-clayer-04
Elwyn Davies <elwynd@folly.org.uk> Tue, 15 January 2013 10:28 UTC
Return-Path: <elwynd@folly.org.uk>
X-Original-To: dtn-interest@ietfa.amsl.com
Delivered-To: dtn-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEE621F872E for <dtn-interest@ietfa.amsl.com>; Tue, 15 Jan 2013 02:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.193
X-Spam-Level:
X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_QP_LONG_LINE=1.396, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E58Hb05dS1iT for <dtn-interest@ietfa.amsl.com>; Tue, 15 Jan 2013 02:28:43 -0800 (PST)
Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id 582F621F86F0 for <dtn-interest@irtf.org>; Tue, 15 Jan 2013 02:28:43 -0800 (PST)
Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtp (Exim 4.72) (envelope-from <elwynd@folly.org.uk>) id 1Tv3l2-0005Ys-5d; Tue, 15 Jan 2013 10:28:40 +0000
From: Elwyn Davies <elwynd@folly.org.uk>
To: Simon Perreault <simon.perreault@viagenie.ca>
In-Reply-To: <50F5242B.80709@viagenie.ca>
References: <1358181196.28723.7028.camel@mightyatom> <50F43E17.2080707@viagenie.ca> <1358189815.28723.7270.camel@mightyatom> <50F5242B.80709@viagenie.ca>
Content-Type: text/plain; charset="ISO-8859-1"
Organization: Folly Consulting
Date: Tue, 15 Jan 2013 10:27:11 +0000
Message-Id: <1358245631.28723.8228.camel@mightyatom>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.3
Content-Transfer-Encoding: quoted-printable
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp-clayer-04
X-BeenThere: dtn-interest@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <dtn-interest.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-interest>
List-Post: <mailto:dtn-interest@irtf.org>
List-Help: <mailto:dtn-interest-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jan 2013 10:28:44 -0000
Hi, Simon. On Tue, 2013-01-15 at 10:40 +0100, Simon Perreault wrote: > 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. OK, I'll ping the dtn-users mailing list just to make sure nobody has serious objections to this plan. > > > The initial delay SHOULD be at least 1 second but SHOULD be configurable > > and will be application and network type dependent. > > Works for me. OK > > > 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? Fair enoungh. Will have to: - Modify the last sentence of the following in s6.1: > A connection shutdown MAY occur immediately after TCP connection > establishment or reception of a contact header (and prior to any > further data exchange). This may, for example, be used to notify > that the node is currently not capable of or willing to communicate. > However, a node MUST always send the contact header to its peer > first. > - Add a comment to the security considerations. > > 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. Good. Look forward to new version. Regards, Elwyn > > Thanks, > Simon
- [dtn-interest] Review of draft-irtf-dtnrg-tcp-cla… Elwyn Davies
- Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp… Simon Perreault
- Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp… Elwyn Davies
- Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp… Simon Perreault
- Re: [dtn-interest] Review of draft-irtf-dtnrg-tcp… Elwyn Davies