Subject: Re: [dtn] draft-ietf-dtn-tcpclv4-02 comments

From: Victoria Pritchard <[email-masked]>
Date: Thu, 18 Jan 2018 00:00:26 +0000

Hi Brian,

Sorry for the delay in getting back to you, I've been trying to find a
chunk of time to go through draft 05.

I have some responses inline, and I have a review of draft 05 I will send
separately.

Kind regards,
Victoria.

On 15 December 2017 at 01:40, Brian Sipos <[email-masked]> wrote:

> I'll include my responses in-line below to hopefully make reading
> easier. Any changes discussed here will be part of a to-be-submitted
> -05 draft revision.
>
> On Tue, 2017-11-28 at 00:04 +0000, Victoria Pritchard wrote:
> > Hi Brian, everyone,
> >
> > Sorry for the delay, as I promised this a few days after the DTN
> > meeting in Singapore. Here's my comments on the TCPCLv4 draft,
> > covering my main issues with the draft and questions about the
> > protocol....it's based on version 2 of the draft - you may have
> > addressed some of these points already...
> >
> > In general I think there's a lot of detailed explanation in the
> > overview sections which I think would be better moved into the more
> > specific sections later. There is some crossover in later sections
> > too. Having info in different places ends up causing confusion as
> > they can seem to contradict each other. For example, I think there’s
> > a lot of scattered info about shutdown and closing of
> > sessions/connections. Also in Section 3, as a general overview, you
> > don’t need that much information – it could be simplified a lot by
> > taking out the MUSTs and MAYs, and leave the detail on exactly how
> > each feature works in the relevant sections later in the draft.
> >
> I've moved actual requirements out of section 3 main part and into
> message definition sections.
>

I think there is still more that can be done here to make this more of an
overview without getting into too much detail.

>
> > In Section 3 you might also want to mention TLS, signals to/from
> > other processes, the fact a shutdown can include a reason.
> >
> After earlier comments, the TLS negotation has been moved into
> subsection under section 3.
>

I only meant to include a quick mention of TLS, since this is an overview
section but it doesn't mention it.

>
> > There are a few places where this draft mentions activities I don’t
> > think are the responsibility of a CL, or if they are, doesn't give
> > enough information. Should be clear about the scope of TCPCL,
> > discussing in the early part of the draft, and being clear
> > throughout. Particularly regarding bundle fragmentation, routing,
> > mapping endpoint ID to IP address, and reporting failures. For
> > example, Section 3 mentions “routing and forwarding messages” and
> > fragmentation (also in 4.1). Section 4 mentions “find an alternate
> > route”. And also be clear about interactions with other processes.
> >
> Some of this text has been removed in the last draft. I'm leaving in
> the informative statements about routing and fragmentation for now. I
> agree that they are not explained in this spec but also this spec is
> intended to be used in context of BPbis itself, not really stand-alone.
>
>
I still think it should be clearer what is and is not the responsibility of
TCPCL and what interactions this means there are between TCPCL and a higher
layer.

> > I had a lot of questions around acknowledgements….If all the acks are
> > received for a particular transfer, do we tell BP that the bundle was
> > delivered? If not, do we tell BP the transfer failed? How long do we
> > wait for acknowledgements? What action is taken for unacknowledged
> > packets? Why ack every single segment? Could we get into a situation
> > where we started sending a second bundle with a new transfer ID but
> > then realised part of the first one was not received? The draft says
> > you can't interleave data from different bundles...
> >
> I am going to add some statements about segment and transfer timeout,
> but I will leave the actual timeout durations up to the implementation
> for now. I'm not sure the protocol can specify how much round-trip time
> and possible processing delay can be expected in any particular use
> case.
> Another response below deals with segment size choice.
>
>
I did not see text in draft 05 that answered my questions.

> > The draft mentions that a transfer can be interrupted and resumed (to
> > avoid re-sending the already transmitted part), but doesn't describe
> > how it is resumed. Does the BP just give a smaller bundle the next
> > time, omitting any part it knew was already received (does it get
> > told how much was received)? What I took from reading the 5th
> > paragraph in section 3 completely changed when I read the rest of the
> > draft. Might be good to include possible ways the transfer might be
> > interrupted to help explain this.
> >
> I've removed the discussion about reactive fragmentation and bundle
> transfer resumption (as much as I've seen). If there are any remaining
> statements then these need to be removed. In BPbis there is no longer
> the concept of a CL-supplied transfer fragment information.
>

Section 3.1 still mentions reactive fragmentation (final paragraph on Page
6). Also Table 6.

>
> > It wasn't clear to me if the TCPCL session should end when the
> > bundles given by BP have all been sent, or if it should be maintained
> > with keepalives in case further bundles need to be sent at a later
> > time. Both ways are described in different places.
> >
> I've added some specific language to Section 3 to mention that it is an
> implementation decision whether or not to keep a session up
> indefinitely if no transfers are pending.
>
>
That's great, thanks.

> > The draft isn’t always clear about the meaning of idle, and the
> > details surrounding keepalives. Under Section 4.1 Keepalive, from the
> > description, it's not clear if this is the dead timer or the send
> > interval - "longest allowable interval" makes it sound like if a
> > keepalive is not received in this time then the session would be
> > considered down. I think elsewhere it says 2 x keepalive interval? So
> > assuming this should be the maximum time between sending keepalives,
> > the description should be updated. Also, since this is the "longest
> > allowable interval", would you ever send keepalives more frequently
> > than this, and why? Being really picky, saying this is the longest
> > allowable interval between keepalives would mean you had to send a
> > keepalive even if other messages were being sent, but elsewhere it
> > says the keepalive is only sent if the session is idle, so this
> > definition is incorrect. Is it worth just removing "longest
> > allowable"? Also in 5.2.1, keepalives sound optional - "SHOULD send a
> > KEEPALIVE message", and "MAY terminate the session". Is that
> > intentional? The word "allowable" was used earlier which sounds more
> > like a must. If no keepalive/other message is received, is "Idle
> > Timeout" the correct error code? Would think idle timeout should
> > relate to bundle transmission, i.e. having no bundles to transfer so
> > the session is idle apart from keepalives. The missing keepalives
> > would be a session failure though, not an idle timeout. Section 6.2
> > describes “idle” as I would expect. Would like to see all this
> > information collected in one section so that it is clear.
> >
> I have removed the "longest allowable" phrasing to avoid confusion.
> I've also added term definitions for Idle and Lively to distinguish
> between the two meanings. I hope this language is clear, and any
> specific disagreements in the text should be reconciled.
>
>
I noticed that Lively is only used in the definitions, and liveliness only
mentioned in one other place. I dont know if lively is required, but the
meaning of idle is definitely clearer now.

> > I'm unclear about the EID that gets sent in the contact header.
> > Information on this is scattered through the draft. It looks like
> > some other process outside TCPCL may find it useful? How do you
> > determine which EID to include? Would you ever want to include
> > multiple EIDs? I would expect this to be described in Section 4.1
> > (Contact Header).
> >
> Unfortunately for me, the EID behavior is inherited from TCPCLv3 and
> I've not changed the semantics of this in any way. I would be perfectly
> fine with removing the mandatory EID in favor of either an TCPCL
> extension and/or a separate neighbor discovery mechanism.
>
>
Happy with the text that says this is used to assist in routing and
forwarding. Not sure if my other questions about EID are worth considering?

> > I wondered why TLS is optional...Also think TLS should be moved to
> > before the existing Section 5.1, since it would happen immediately
> > after the contact header exchange. With it being an AND, one side can
> > just say it doesn’t want to use TLS, to force a non-TLS session.
> > Should the flag instead indicate the peer will only accept a TLS
> > session? If you make it an OR, then if either side requests TLS, do
> > not begin a session without it? Or make it default to use, since the
> > contact header must be re-exchanged anyway to ensure no man-in-the-
> > middle. Could a man-in-the-middle not change the TLS indicator in the
> > unsecured contact header? In Section 7, it says “When TCPCL session
> > security is mandatory," ...but it's not mandatory, because if either
> > side indicates it is not using TLS, the session does not use TLS.
> > Also, in the RFC referenced, it says that a STARTTLS capability could
> > be removed from the unsecured message, so should the security
> > considerations here mention if a man-in-the-middle attacker could
> > force a non-TLS session? Also the text about the unsecured contact
> > header might fit nicely with the rest of the TLS text - or at least a
> > mention of it and a reference to the security considerations where it
> > is described?
> >
> This was a well-negotiated topic in earlier IETFs and the current
> behavior was the most agreeable to those in the discussions. In the
> last draft (-04) I did move TLS discussion into Section 3 (it was only
> in later section before because it used to be a message type, now it's
> just a contact negotiation behavior).
> Regarding your comment on USE_TLS logic (AND vs OR) each peer is
> allowed to use its local security policy to refuse a session (SHUTDOWN
> immediately after contact header exchange) for any reason. It can
> mandate that only secured sessions are acceptable just as well as only
> unsecured sessions are acceptable. This is not a protocol negotiation,
> its a peer policy decision.
> Regarding the man-in-the-middle and USE_TLS, I don't think that there
> is anything that can be done about this kind of attack. If this is
> something that is an expected network behavior then I think a lower
> level security such as IPsec or IP tunneling would be necessary.
>
> In section 7 I rephrased this to say "When TCPCL session security
> mandated by a TCPCL peer, that peer SHALL transmit ..." the point here
> is that if a peer may set USE_TLS flag but may still allow non-secured
> sessions (so the secured session is a want not a need).
>
>
I like that there is more text in draft 05 about policy, thank you. This
wasn't clear when I read the earlier draft.

> A message rejection includes the header of the rejected message, but
> > the header is only made up of the type field....is that enough to be
> > useful? What does TCPCL do upon receiving a message rejection? Also
> > how would you choose to use the unknown and unsupported reason codes?
> > Are these effectively the same thing?
> >
> The only reason for the MSG_REJECT is for troubleshooting application-
> layer connectivity. A well-behaved session should never see these
> messages in either direction.
> The distinction between "Type Unknown" and "Unsupported" is that
> "Unsupported" means that there was some problem with the semantics of
> the decoded message, where "Type Unknown" means the entire message is
> unintelligible to the receiver.
>
> > How is segment size chosen? And why or when would it vary?
> >
> The segment size is effectively the acknowledgment window of the
> transmitter. Similar to above, to me the acknowledgment is more for
> detecting failed/unreliable connections than for the ideal case. If you
> have a perfectly functioning network, you can very well leave the
> segment MRU at the maximum value, which means one transfer consists of
> one segment and one acknowledgment (no matter the size). Smaller MRUs
> could be also be used for controlling memory use in more constrained
> environments (a maximum-size MRU means the peer is willing to allocate
> a possibly enormous amount of memory to receive an enormous single-
> segment message). An implementation that streams received data directly
> to bulk storage (e.g. filesystem) may be less constrained in this
> regard.
>
> > In Section 4.1, regarding Transfer MRU, if we learn the maximum
> > bundle size here in the contact header, can this be used in bundle
> > fragmentation before we get to a point where we get a refuse message
> > back with the code "No resources" indicating fragmentation is needed?
> >
> Absolutely, at the higher-up BP layer there is no point in even
> attempting to send a transfer larger than the Transfer MRU because it
> will necessarily be refused.
>

OK, so if TCPCL is given a bundle to send and it is larger than the
Transfer MRU, will TCPCL refuse to send it, and signal to BP that it will
not send it because it is too large? This is not defined in the draft. If
so, do we still need this reason code?

Or will TCPCL begin to send it and eventually get the refuse message back?

>
> > How are the extensions to be defined? In extra drafts? Informally as
> > experiments?
> >
> The current spec leaves two categories of extensions: the lower-
> numbered types are required to be approved specs while the higher-
> numbered types can be user-, site-, or network-specific.
>

Would like to see a note to explain this in the draft where header
extensions are described. I know if you look hard enough, it does say
something similar in Section 8.3.

> >
> >
> > Also, let me know if you want all my fussy comments on typos and
> > wording etc...
> >
> I'm going to publish a revised draft (-05) soon, so comments on typos
> etc. are welcome on that revision.
>

Will email my 05 review separately.

> > Kind regards,
> > Victoria.