Subject: Re: [dtn] BP/TCP and TLS extension

From: Joerg Ott <[email-masked]>
Date: Mon, 12 Sep 2016 15:04:24 +0200

Hi Brian,

thanks much for taking up the effort on furthering TCPCL.  As mentioned
during the last IETF, I got some comments but I dropped the item over
the summer break.  So, finally, here comes a review of the draft.

My meta theme is still making this as simple a possible.  After all,
what we just try to do is mapping bundles to a byte stream.

I believe some more work is needed for TLS inclusion.  And I am
wondering if this document could serve as a framework for all kinds
of reliable streams-based transports.

For now, I have included a detailed review with many comments.

Jörg

On 07.09.16 20:43, Brian Sipos wrote:
> Sorry to bug you, but if you want to provide any comments to the TCPCL
> draft please let me know prior to the upcoming DTNWG interim meeting on
> 28 Sept.
>
> Thank you!
>
> ------------------------------------------------------------------------
> *From:* Joerg Ott <[email-masked]>
> *Sent:* Tuesday, July 26, 2016 12:39:28 PM
> *To:* Brian Sipos; [email-masked]
> *Subject:* Re: [dtn] BP/TCP and TLS extension
>
> I tried but it seems I will only be able to get back to you with
> a detailed review after my vacation in three weeks and a bit.
>
> Jörg
>
> On 20.07.16 14:49, Brian Sipos wrote:
>> Joerg and Simon,
>>
>> If you are not already aware there was a presentation on proposed
>> changes (and reasons for) at
>> <https://www.ietf.org/proceedings/96/slides/slides-96-dtn-2.pdf> along
>> with the actual draft at
>> <https://tools.ietf.org/html/draft-sipos-dtn-tcpclv4-01>. The main
>> intent is to keep as much as possible while allowing for new behaviors.
>> Any comments are certainly welcome, since I'm sure you have more
>> experience with the original behavior.
>>
>> Thank you,
>>
>> Brian S.
>>
>> ------------------------------------------------------------------------
>> *From:* Joerg Ott <[email-masked]>
>> *Sent:* Monday, July 18, 2016 5:45:32 AM
>> *To:* Brian Sipos
>> *Cc:* Michael Demmer; [email-masked]
>> *Subject:* Re: [dtn] BP/TCP and TLS extension
>>
>> Hi Brian,
>>
>> thanks much for taking up the work revising and advancing this spec.
>> There are clearly things worthwhile doing and we are happy to discuss
>> and  help advancing those.  We had a number of ideas we didn't implement
>> to keep things simple, but there are conceivable useful additions.
>> Let's see what we can and should do here.
>>
>> I am still working in this field, Mike has moved on (I believe), not
>> sure about Simon.  But I am including them in CC in case they aren't
>> actively monitoring the DTN WG list.
>>
>> I have one principle point as well (with the disclaimer that I don't
>> really need extra credits for my day job): it's been good practice
>> in the IETF that if you revise document, you keep the original authors
>> as you move on and add yourself.  After all, a substantial part of the
>> text was still written by them.  So, maybe let's follow this procedure
>> here as well.
>>
>> Cheers,
>> Jörg
>>
>>
>> On 13.04.16 16:07, Brian Sipos wrote:
>>> All,
>>>
>>> I have been looking into using the BP/TCP transport of RFC 7242, which
>>> mentions that the protocol is compatible with TLS:
>>>
>>>     "Nothing in TCPCL prevents the use of the Transport Layer Security
>>> (TLS) protocol [RFC5246] to secure a connection."
>>>
>>> but does not specify how to actually use TLS to secure a connection or
>>> to disambiguate between TLS-capable and -incapable nodes.
>>>
>>>
>>> I have a need to use TLS for transport-level mutual authentication for
>>> my application of BP, and would prefer to use the existing methods as
>>> much as possible.
>>>
>>> How would the WG feel about adding a STARTTLS-type message code to the
>>> IANA registry
>>> <http://www.iana.org/assignments/bundle/bundle.xhtml#tcpcl-message> with
>>> an associated SHUTDOWN code for negotiation failure?
>>>
>>>
>>> This new message would have behavior consistent with RFC 2595
>>> (POP3/IMAP/etc.) use of STARTTLS, so it would be node policy whether or
>>> not to actually require TLS operation. If TLS is required but cannot be
>>> negotiated (either because not supported, cannot agree, etc.), a node
>>> would simply close the connection with the appropriate shutdown code.
>>>
>>> My other option is to either use same or different TCP port number and
>>> suffer the consequences (same as HTTP vs. HTTPS disambiguation) if there
>>> was ever a need to interoperate, which I would rather avoid.
>>>
>>>
>>> Thanks for any comments.
>>>
>>>
>>>
>>> _______________________________________________
>>> dtn mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dtn
>>>