Subject: RE: [Tsvwg] Looking for feedback on DTLS

From: "Amit Jain" <[email-masked]>
Date: Wed, 5 Jan 2005 18:55:58 -0800

Thanks for your replies. My thoughts inline:

>> I think another approach worth considering may be to introduce a thin
>> layer inside record layer which takes care of fragmentation,
>> reliability, in-order delivery to record layer. In this approach:

>Yes. We considered this approach.  However, we were concerned about
>designing a generic reliability layer. Designing reliable transport
>protocols is difficult, as evidenced by the fact that we're still
>working on TCP after 20+ years. Our feeling was that as the only real
>requirement was to make the handshake reliable it was best to tie the
>reliability into the handshake process and thus avoid the complexity
>and rathole potential of trying to design something more
>general. Moreover, there is experience with this kind of state machine
>from IKE and other similar protocols.

As you described, we need a very simple reliability mechanism for
handshake signaling, I think moving this simple reliable mechanism to
record layer will make it further simple in terms of implementation. It
may also make it more efficient in terms of buffer requirements for
retransmissions and the bytes needed to retransmit in case of packet
loss since we can track the reliability per UDP datagram instead of a
flight of handshake messages. 

I did not mean that we need to have a reliable layer as extensive as TCP
in record layer.

>> 2: Records are fragmented and is converted to UDP datagram. 
>>  
>> These UDP data-grams are then transmitted reliably to other end in
the
>> handshake phase using a very thin layer (built into record layer). It
>> may be analogous to a simple reliable variant of UDP (something like
>> TFTP). Here the reliability is tracked for each UDP datagram and only
>> the missing UDP datagram is re-transmitted.
>>
>> This may provide following advantages:
>>  
>> 1: Handshake layer will be similar to the TLS. There won't be any
change
>> needed in the implementation of state machine and the specification
of
>> handshake messages.
>That's sort of correct, except that the handshake state machine
>will need to do signalling to the record layer about when it wants
>reliability. It's also important to note that the DTLS handshake
>reliability layer lives mostly at the level of the DTLS handshake
>wrapper. The handshake payloads themselves don't change.

My thought on this is that there is already a content type field in the
record layer. It probably can be used for providing different types of
services to different content types. I agree that it has additional
complexity.

One thought which comes at this point is that do we also need to make
alert reliable? What if the close notify alert gets lost? Will it affect
the protection against truncation attack? When do we stop reusing the
DTLS session information? Or how do we differentiate an abrupt closure
from a graceful closure?

Having reliability in record layer can make it possible for the alerts
to be transmitted reliably.

>> 3: Having a thin reliability layer in Record layer will allow greater
>> flexibility and extensibility. Reliability layer can be replaced with
>> other reliability mechanism like DCCP in future for providing
>> reliability/congestion control.

>Well, DCCP wouldn't do the job here since it ONLY provides congestion
>control and not reliability. DTLS will of course run fine over DCCP.
>It just doesn't make the problem any easier. Michael Tuexen and I
>are currently talking about the interaction of DTLS and SCTP, but
>I don't think that's a universal solution.

My bad here. Short on knowledge on DCCP =). But the point I wanted to
convey here was that it is the record layer which interfaces with the
transport, so any kind of transport adaptation should possibly be in
record layer. Of course it is the first thought which comes to anybody
when thinking about adapting TLS to different transports and it needs to
be evaluated based on all other design criteria.

Thanks for your replies.
-amit

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: EKR <[email-masked]>
Date: Wed, 05 Jan 2005 20:41:49 -0800

"Amit Jain" <[email-masked]> writes:
> record layer will make it further simple in terms of implementation.
I doubt the difference will be significant. As noted in the original
DTLS paper, the incremental effort involved was quite small. And,
of course, the reliability mechanism for DTLS has already been
designed and tested.

> It
As I indicated in my responses to Murali Bashyam, the amount of
overhead involved here is really quite small. In any case, the
performance difference isn't a result of where the reliability
layer is, it's a result of whether you have explicit ACKs as
oppposed to the implicit ACK of receiving the next message
from the peer that DTLS currently uses. We decided not to add
them in DTLS for complexity reasons (see S 4.4 of the paper for
discussion).

> I did not mean that we need to have a reliable layer as extensive as TCP
OK. But one of the hazards of doing a generic layer that includes
coverage of the data records is that it's hard to know where to
stop.

> services to different content types. I agree that it has additional
Yes. It also requires some substantial layer traversal to make it
work--in TLS and DTLS, the record layer is more-or-less agnostic
about what data its carrying.

> alert reliable?

We don't believe so, no.

> What if the close notify alert gets lost?  Will it affect

In general, in an environment where the data is unreliable, it's
not clear what the meaning of a connection closure is, so I would
tend to expect this to happen at the application layer in general.
In any case, TLS 1.1 relaxes the requirement not to resume if
you don't see a close_notify.

> record layer.

Yep. It's certainly a reasonable first thought, but I think at the
end of the day it's the wrong way to go.

-Ekr