Re: [rtcweb] draft-jesup-rtcweb-data-00 posted

[Randell Jesup <[e-mail]>]

On 10/25/2011 4:02 AM, Hadriel Kaplan wrote:
>
> Hi Randell,
> What do you think about the following additional requirements:
>
> Req. 7: Data streams MUST provide fragmentation at a layer above UDP, such
 > that IP-layer fragmentation does not occur no matter how large a 
message/buffer
 > the Javascript application passes down to the Browser to be sent out.
>
> Req. 8: The data stream transport protocol MUST NOT encode IP addresses
> inside its protocol fields; doing so reveals potentially private information,
 > and leads to failure if the address is depended upon.
>
> Req. 9: The data stream protocol SHOULD support unbounded-length "messages"
> (i.e., a virtual socket stream) at the application layer, for such things as
> image-file-transfer; or else it MUST support at least a maximum
 > application-layer message size of 4GB.
>
> Req. 10: The data stream packet format/encoding MUST be such that it is
 > impossible for a malicious Javascript to generate an application message
 > crafted such that it could be interpreted as a native protocol over UDP -
 > such as UPnP, RTP, SNMP, STUN, etc.

Thanks, those look useful.  I'm not sure if Req 8 should be reworded to 
be more explicit (local IP address?)  For Req 7, I think that when 
applied to unreliable data channels, entire fragmented messages must be 
delivered or none of the fragments delivered to the application.

> I believe SCTP can do 7+8+9 the above if its options are chosen right, and of course TCP can.

Yes, I believe so - for Req 9, SOCK_STREAM can be used to provide a 
TCP-like interface to SCTP.

Do any of the above only apply to reliable data channels, in particular 
Req 9?

> And I'm guessing DTLS will satisfy 10 above, as would websockets-style masking.

Yes.


-- 
Randell Jesup
[e-mail]