Subject: Re: [P2PSIP] proposal for reload congestion control, fragmentation, and retransmission

From: <[email-masked]>
Date: Wed, 04 Mar 2009 06:39:52 -0700

Eric,

> -------- Original Message --------
> Subject: Re: [P2PSIP] proposal for reload congestion control,
> fragmentation, and retransmission
> From: Eric Rescorla  
> 
> [Note: please figure out how to send plaintext email. HTML is
> not convenient for me]
> 
> At Tue, 03 Mar 2009 04:30:57 -0700,
> > > This framing is also going to be used with TLS, so you do need<br>
> > >  the length there. I'd rather have a consistent framing than<br>
> > > save 3 bytes.<br>
> > 
> 
> > My thought section 5.2.2 is for unreliable link (UDP/DTLS) only.
> 
> Editorial error. It was our intent that everything be framed.

It would be helpful if a section of the draft present a complete logical
view of all frames and protocol layers.

> > I assume the TLS record layer is sufficient for TCP.
> 
> TLS does not preserve write boundaries.
> 
> 
> > Even if framing
> > is used for TCP, wouldn't it be using rfc4571 as suggested by
> > draft-ietf-mmusic-ice-tcp-07? Please clarify.
> 
> No, that's at the wrong layer--below TLS rather than above.
> 
> -Ekr

Okay, the FramedMessage is encrypted by TLS/DTLS. Then why mention
demultiplexing with STUN. I don't believe STUN is send inside the
TLS/DTLS layload. According to ICE, STUN should be at the outer most
layer inside the TCP/UDP frame, so there are only two protocols being
multiplexed inside the TCP/UDP frame: STUN and TLS/DTLS. Please confirm.

Thanks

--Michael

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 04 Mar 2009 07:25:06 -0800

At Wed, 04 Mar 2009 06:39:52 -0700,
<[email-masked]> wrote:
> Okay, the FramedMessage is encrypted by TLS/DTLS.

Naturally.

> Then why mention

Right. Thinko by one of the authors.

-Ekr