Subject: RTP and UDP checksum=0

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Apr 2011 08:26:40 -0700

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

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Apr 2011 10:02:23 +0200

> 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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Philip Zimmermann <[email-masked]>
Date: Mon, 18 Apr 2011 01:52:18 -0700

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:

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

------------------------------------------------
Philip R Zimmermann    [email-masked]
(spelled with 2 n's)   http://philzimmermann.com
tel +1 831 425-7524    http://zfone.com