Re: [AVTCORE] RTP and UDP checksum=0

[Philip Zimmermann <[e-mail]>]

I think it should use the checksum field.  It is generally a bad idea for one layer to neglect its usual built-in error-checking duties because it assumes another layer will handle it.

Let me draw an analogy from the crypto world, we don't use weak 56-bit DES as our PGP keys because we assume that the email message will pass through a strong SSL tunnel, so why bother to work so hard to protect the message with strong keys in PGP?  We see to our own layer's security, without getting lazy and letting another layer handle it.  What if the other layer is not used?  What if the email is not passing through SSL?  Oops.

Every layer should try to look after its own obligations to protect packets.  If UDP was originally designed to carry checksums, we should generate them all the time in the UDP layer.

Just my two cents.




On Apr 18, 2011, at 1:02 AM, Magnus Westerlund wrote:

> Dan Wing skrev 2011-04-15 17:26:
>> Observation:  tunneled packets have two elements actively 
>> deciding checksum=0 is okay.  Those elements are the 
>> tunnel encap and tunnel decap.
>> 
>> Question: Should non-tunneled UDP flows, *established with 
>> explicit signaling*, also be allowed to decide that checksum=0 
>> is okay?  For example, an RTP-over-UDP flow established 
>> with RTSP or SIP signaling.  Some RTP traffic includes its
>> own checksum at the application layer (e.g., SRTP authentication)
>> and gains little or no benefit to a UDP checksum.  Near as I
>> can discern, SIP-signaled flows meet all of the constraints
>> discussed in 
>> http://tools.ietf.org/html/draft-ietf-6man-udpzero-02#section-5.1
> 
> Dan,
> 
> I agree that SRTP would be safe to use without checksum also in v6.
> However, using non-secured RTP without checksums are "a very bad idea"
> (TM).
> 
> Also, if you are an end-point generating RTP flows then the UDP checksum
> overhead is generally not that big of an issue compared to all media
> processing. I think the only node that where this could make any
> significant difference are in a transport translator, which only relays
> an incoming packets to a number of other unicast addresses.
> 
> I do however, see a need for a number of additional mechanisms, at least
> signalling if one wants do do this for RTP with SRTP integrity
> protection enabled. SIP/SDP signalling and maybe also an additional ICE
> STUN check to verify the capability prior to using it to avoid loss due
> to middleboxes that doesn't handle zero UDP checksum with v6.
> 
> My general fear is that the usage of zero checksum for IPv6 is done
> without thinking and that it is similar in behavior to IPv4 which it
> clearly is not, but I guess that is difficult to ensure. Soo frankly, is
> it really worth it for RTP?
> 
> I guess what you say comes down to if we should ensure that the text is
> generalized enough that it doesn't only apply to tunnel applications. To
> me the new specification text before the bullet list appears ok. If only
> give tunnels as an example. The bullet list also appears ok from a
> non-tunnel application perspective. So it is likely only the title and
> some of the introduction text that needs to be ensured that it doesn't
> only speak of tunneling.
> 
> I think the authors should ensure this as it appears to be minor
> modifications and clearly we didn't mean this to only be applicable to
> one type of applications, but all that meets the considerations.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

------------------------------------------------
Philip R Zimmermann    [e-mail]
(spelled with 2 n's)   http://philzimmermann.com
tel [phone]    http://zfone.com