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

[Elwyn Davies <[e-mail]>]

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