Subject: Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-09.txt

From: Joerg Ott <[email-masked]>
Date: Mon, 13 Aug 2018 22:36:19 +0200

[Now including the DTN WG list]

Hi everybody,

I am guilty of having had less than adequate time lately to look at the
detailed evolution of this draft.  I did a detailed review that yielded
a number of comments.

As a meta note up front: I am not super-happy that the document more
than doubled in size, while the functionality did not grow that much
(luckily).  There seem to be lots of precautions taken for future-
proofing, while some of those could be addressed by another rev.
I specifically also went back to v3 to compare the changes.

I am also puzzled about the generous choice of field sizes given that
the bundle protocol itself uses encodings that aim at wire efficiency.

I don't wanna bring up everything at once but here are a few bits that
I really think need to be fixed.  So let me keep the discussion focused
for now (we can look at nits later on):

1. Section 4.3 seems to suggest on p21 (a node may adapt its operation
    to an older version of the protocol) the two endpoints might choose
    using different protocols versions, which is surely problematic.
    The outcome of this negotiation must be unambiguous.

2. Section 4.4 discusses TLS but this isn't enough.  TLS has lots of
    parameters, TLS clients may and servers must have certificates.
    All this interaction needs to be spelled out.  What about the APN
    to be used for TLS connection setup.  And, of course, we should use
    TLS 1.3.

3. Splitting XFER_INIT from XFER_SEGMENT is not useful.  Nodes would not
    want to wait for a reply but use pipelining.  Hence, creating a
    SEGMENT must follow INIT dependency appears unnecessarily complex
    in terms of state space.

    Simple suggestion: Just keep session transfer but, if the S bit is
    set, include the total bundle length field and the bundle transfer
    id.  You achieve the same, save a few bytes, and the sender won't
    wait transmitting anyway.  And one possible error condition goes
    away.

    The only reason LENGTH was a separate message before is that we
    needed/wanted to be backwards compatible to earlier versions of the
    draft and could not grow the header of the DATA_SEGMENT message.

4. Section 5.1.1 Keep alive has lost its function.  According to the
    current text, a keep-alive should be transmitted when the timer
    expires.  Fine, but this too late because the other entity will
    time out the connection.  The earlier guidance was that the session
    timeout occurs if no data was received for _twice_ the keep alive
    interval.  But this part seems to have gone.  The text would need
    to be explicit about when to schedule sending keep-alive messages
    and when to time out.

5. The extension items (both for setup and transfer) are generously
    dimensioned but not a single one is defined.  I would say that
    8 bits parameter space and 16 bits length should be sufficient.
    It is also useful to define the encoding only in one place since
    the two are largely identical.

6. Echoing the SESS_TERM message as an ACK is a good idea.  Should
    we include a nonce here to make sure that an ACK is different from
    an independently issued SESS_TERM?

7. Session termination in section 6.1 got more complicated.  The text
    now alllows sending even more segments, whereas the v3 spec
    essentially said that no data must follow afterwards.  If I receive
    a SESS_TERM, I should be sure that I can release data processing
    resources.

8. Why not always have the reason code and define one to be unpsecified
    in SESS_TERM rather than having two-stage processing?

Major editorial:

We have too many terms and definitions.  Why are we discussing a TCPCL
entity with a complex figure 2, when there is nowhere inside the
document any need visible for discussing more than a single TCPCL
connection at a time.  This is rather confusing.

We have many state diagrams (fundamentally a good idea) but they are
hard to follow and sometimes very simple.  They are also not referred
to in the mandatory text.  Maybe we can have fewer states and a
stronger relation between text and diagrams?  Btw, not all acronyms are
defined here.

"CAN_TLS" is not the best name.

Cheers,
Jörg

---

From: Rick Taylor <[email-masked]>
Date: Tue, 21 Aug 2018 12:55:05 +0000

Hi Joerg,

Thanks for the detailed review.

As you are one of the authors, are you suggesting that the author team
no longer considers the document ready for publication, and that the
team wish to abort the WG Last Call to give you all time to address
your comments?

If so, can I impress upon you the urgency of getting at least one
Convergence Layer document onto the Standards Track as soon as possible
- TCP-CL being the current best candidate.

To the WG: If someone has another interoperable Convergence Layer
protocol that they wish to submit to the working group, it would be
very welcome.  TCP-CL is not the 'One CL to rule them All' just what
was seen as a simple first CL to publish alongside BPbis and BPSec. If
another CL document was to appear in such a state that it could be
quickly adopted and peer-reviewed then the TCP-CL authors would have
more time to address any perceived short-comings in the draft, and the
publication of BPbis would not be further delayed. 

Sorry for the top-post.

Cheers,

Rick

On Mon, 2018-08-13 at 22:36 +0200, Joerg Ott wrote:
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: "R. Atkinson" <[email-masked]>
Date: Tue, 21 Aug 2018 13:36:48 -0400

My comments below are all non-blocking from a process perspective.

That noted, there do seem to be practical issues that should be 
addressed before this document goes to RFC.  

> On Aug 13, 2018, at 16:36, Joerg Ott <[email-masked]> wrote:
> 

This seems like a significant interoperability problem that
ought to be resolved prior to publication as an RFC.

>   to be used for TLS connection setup.  And, of course, we should use

Q: Might a compromise be to spell out at least one deployable “profile”
     of TLS for use with this specification, while not precluding folks using
     some other set of TLS parameters if they choose ??

Concur about TLS 1.3.  In fact, I doubt very much the Security Area will
approve any TLS version less than 1.3 — given known/published issues
with previous versions of TLS.

>   to be explicit about when to schedule sending keep-alive messages

This sounds like a serious interoperability issue that ought to be resolved
prior to publication.

>   an independently issued SESS_TERM?

I concur that a nonce would be good to add here.

>   a SESS_TERM, I should be sure that I can release data processing

This also seems like a problem worth fixing.

>   in SESS_TERM rather than having two-stage processing?

No opinion about the specific issue.  In general, it ought to simplify implementation
and improve interoperability to always have a reason code.  

I would not want to use anything that isn’t specified in an applicable IANA
Registry, but I might specify one in that Registry that means “some other reason”.

Yours,

Ran

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 21 Aug 2018 19:42:48 +0000

I'm on vacation through Friday, but next week - if necessary - I could write a quick I-D for the Simplified TCP convergence-layer adapter that is available as an option in ION.  It is not as capable as TCLPL, but it's less complex while still being more reliable than UDP.

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Rick Taylor
Sent: Tuesday, August 21, 2018 5:55 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-09.txt

Hi Joerg,

As you are one of the authors, are you suggesting that the author team no longer considers the document ready for publication, and that the team wish to abort the WG Last Call to give you all time to address your comments?

If so, can I impress upon you the urgency of getting at least one Convergence Layer document onto the Standards Track as soon as possible
- TCP-CL being the current best candidate.

To the WG: If someone has another interoperable Convergence Layer protocol that they wish to submit to the working group, it would be very welcome.  TCP-CL is not the 'One CL to rule them All' just what was seen as a simple first CL to publish alongside BPbis and BPSec. If another CL document was to appear in such a state that it could be quickly adopted and peer-reviewed then the TCP-CL authors would have more time to address any perceived short-comings in the draft, and the publication of BPbis would not be further delayed. 

Sorry for the top-post.

Cheers,

Rick

On Mon, 2018-08-13 at 22:36 +0200, Joerg Ott wrote:
> I am guilty of having had less than adequate time lately to look at 
> the detailed evolution of this draft.  I did a detailed review that 
> yielded a number of comments.
> 
> I really think need to be fixed.  So let me keep the discussion 
> focused for now (we can look at nits later on):
> 
> stronger relation between text and diagrams?  Btw, not all acronyms 
> are defined here.
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Aug 2018 23:54:14 +0100

Hiya,

Just saw this going by...

> with previous versions of TLS.

Best thing to do is cite BCP195. That's currently RFC7525 and has
loadsa recommendations for how to use TLS1.2 nicely. At some stage
it'll get updated to add TLS1.3, but the BCP195 citation will
still work then (so cite it as BCP195 and not as RFC7525).

The only TLS1.3 issue worth thought in this WG is the 0rtt one.
If a DTN draft cites TLS1.3 (RFC8446) then the WG will need to figure
out whether or not BP/TLS1.3 with 0rtt is ok or not, and if so when.
I can imagine that might actually be a bit of an involved discussion
(pro-0rtt: in DTNs reducing RTTs mostly wins, against-0rtt: in DTNs
replay attacks against different not-tightly-coordinated-BPAs seem
potentially pretty bad).

My take would be to just refer to BCP195 only and punt on 0rtt 'till
there's folks really wanna use BP/TLS1.3 and figure it out then.

Cheers,
S.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 21 Aug 2018 22:17:53 -0500

Speaking as an interested bystander ...

> still work then (so cite it as BCP195 and not as RFC7525).

I encourage the working group to do the right thing, but I hope Stephen's
answer here is the right thing to do.

I have more confidence in pointing to the BCP that the SEC community should
keep up to date to say "do TLS this way", than in a working group outside
SEC trying to track what the SEC community thinks the right answer with TLS
is, as it changes over time.

But do the right thing, of course.

Spencer

---

From: "R. Atkinson" <[email-masked]>
Date: Wed, 22 Aug 2018 07:38:03 -0400

> On Aug 21, 2018, at 18:54, Stephen Farrell <[email-masked]> wrote:
> 
> Best thing to do is cite BCP195.  
>  
> That's currently RFC7525 and has loadsa recommendations for how to use
> TLS1.2 nicely. At some stage it'll get updated to add TLS1.3, but the BCP195
> citation will still work then (so cite it as BCP195 and not as RFC7525).

I concur.  

That approach ought to be acceptable to the Security Area.

Further, that is a procedurally elegant solution as it means that this DTN 
document  won’t need to be updated as TLS evolves, but instead this DTN 
document will remain current even as TLS evolves.

Yours,

Ran

---

From: "Dr. Ronny L. Bull" <[email-masked]>
Date: Wed, 22 Aug 2018 08:06:58 -0400

Excellent point regarding the ease of future document maintenance by
referencing BCP195.  I agree that this is the best way to approach this.

Ronny

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 22 Aug 2018 13:52:11 +0000 (UTC)

> your comments?

I do believe he is.

> - TCP-CL being the current best candidate

Urgency?

An experimental TCP convergence layer was published in RFC 7242
in January 2014. That was based on Demmer's -00 draft of October 2006.
So, over seven years to get out the door.

This one's only had a couple of years since the Siphos -00 draft.
We wouldn't want to rush things, especially given that there's already
a TCP convergence layer RFC.

My concern is that this is being looked at from a progress-a-standard-
to-workgroup-deadlines perspective, rather than the perspective of
asking if it's any good. Any sense of urgency here is entirely
artificial. Quality, not speed.

(I also think that debating which current fashionable security
standard to reference is entirely a waste of time; they don't
last...)

L.

I am not super happy about DTN. 

Lloyd Wood
http://sat-net.com/L.Wood/dtn

________________________________
From: Rick Taylor <[email-masked]>
To: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Tuesday, 21 August 2018, 22:57
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-09.txt

Hi Joerg,

Sorry for the top-post.

Cheers,

Rick

On Mon, 2018-08-13 at 22:36 +0200, Joerg Ott wrote:
> the
>     we include a nonce here to make sure that an ACK is different
>    from an independently issued SESS_TERM?
> 
>     essentially said that no data must follow afterwards.  If I

>    receive a SESS_TERM, I should be sure that I can release
>    data processing resources.> 
> 8. Why not always have the reason code and define one to be

>    unpsecified in SESS_TERM rather than having two-stage
>    processing?> 
> 
> Major editorial:
>

---

From: Rick Taylor <[email-masked]>
Date: Wed, 22 Aug 2018 14:44:25 +0000

> > team wish to abort the WG Last Call to give you all time to address

We are waiting to hear the opinions of the authors, but I get the
feeling he is as well.

> > - TCP-CL being the current best candidate

The urgency is all related to the belief that the other primary
documents of the WG must wait for at least one CL before making
standards track.  It was the rough consensus of the working group that
an RFC 7242 uplift would be a simple task, and therefore not cause a
log jam.  However, it has taken considerably more time and effort than
originally predicted.

In the meantime, the chairs will be seeking clarification from the ADs
and IESG on whether the initial assumption of a CL being required still
holds given the current situation.

> a TCP convergence layer RFC.

The current TCP-CL draft is effectively 7242bis.  However, the bar is
set much higher for a Standards Track document than an Experimental
document.

> artificial. Quality, not speed.

I agree quality is more important than progress in theory, but in
practice no/slow progress in one standards body results in alternate
progress in other standards bodies, which is not per-se a bad thing,
but does have an increased risk of diverging standards.

> standard to reference is entirely a waste of time; they don't

The discussion is not about fashion, it's about reducing the amount of
paperwork churn involved in tracking an evolving standard.  Given the
work involved in document uplift, any tactics to avoid administrivia in
the WG is valid discussion.

Rick

> I am not super happy about DTN. 

If we were all super happy, we wouldn't be trying to improve it.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 23 Aug 2018 00:47:37 +0000 (UTC)

Rick,

> It was the rough consensus of the working group
> that an RFC 7242 uplift would be a simple task,
> and therefore not cause a log jam.

Well, RFC 7242 did take over seven years to do,
so seven years to redo is not unreasonable.
But, as you point out, standards track is a
higher bar than experimental, so it's quite
reasonable to expect that it will take longer.

So, over over seven years. (Even though
running over TCP is pretty much what any
bundle implementation has been doing from
the start, because TCP's reliable delivery makes
bundle delivery easy, and difficult transport
and reliability issues can be dismissed. The
TCP convergence layer is complicating
a relatively simple layering thing.)

> holds given the current situation.

I fear we're heading into a scenario like BEEP,
where TCP carriage is all that the IETF defines,
and doing anything else was given up on as too hard.
(RFC 3080/3081)But hey, BEEP went standards track! Mission accomplished!

> in practice no/slow progress in one standards body results in
> alternate progress in other standards bodies, which is not per-se
> a bad thing, but does have an increased risk of diverging standards.

are you saying this TCP convergence layer work will be done somewhere
else?

Lloyd Wood

________________________________
From: Rick Taylor <[email-masked]>
To: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Thursday, 23 August 2018, 0:44
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-09.txt

On Wed, 2018-08-22 at 13:52 +0000, Lloyd Wood wrote:
> > As you are one of the authors, are you suggesting that the author
> > team no longer considers the document ready for publication,
> > and that the team wish to abort the WG Last Call to give you
> > all time to address your comments?
> 
> I do believe he is.

Rick

---

From: Brian Sipos <[email-masked]>
Date: Thu, 30 Aug 2018 13:01:34 +0000

Joerg,

I have seen your issues but have not had time to address them individually. I am planning on doing so in the near future, but I do agree that all of your issues need to be addressed (either by response to mailing list or to edit to draft).

________________________________
From: Joerg Ott <[email-masked]>
Sent: Monday, August 13, 2018 4:36:19 PM
To: Brian Sipos; Simon Perreault; [email-masked]
Cc: Marc Blanchet; [email-masked]
Subject: Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-09.txt

Hi everybody,

Major editorial:

Cheers,
Jörg