Subject: Re: [Tsvwg] Comments on draft-ietf-tsvwg-udp-guidelines-06

From: Lars Eggert <[email-masked]>
Date: Tue, 13 May 2008 10:25:02 +0300

Hi, Pasi,

On 2008-4-21, at 17:48, ext [email-masked] wrote:
> In general, the document is clear and well written.

thanks!

> Couple of
> additional suggestions follow:
>
> Two topics which could be useful to mention in Section 3.5
> (middlebox traversal guidelines):
>
> - Typically, TCP needs keep-alives much less frequently than UDP.
> Sending frequent keep-alive messages can, depending on the underlying
> technology, consume significant amounts of energy, which can be a
> problem especially for battery-powered devices. In this kind of
> situation, if an application needs to maintain connectivity for long
> periods with little traffic (e.g., VoIP phone that's just waiting
> for an incoming call), TCP could be more suitable than UDP.
>
> - Techniques such as ICE allow two hosts behind different middleboxes
> to establish direct communication in some circumstances. Reputedly,  
> the
> real-world success rate is much higher for UDP than for TCP, and this
> alone may be a reason for using UDP in some situations.

Although I agree with both of your observations, I'm not convinced  
that this is the document for them.

This BCP-to-be is supposed to discuss how to use UDP and what the  
tradeoffs are. We are maybe in need of another BCP - in case someone  
out there is looking for an authoring opportunity - that discusses  
what transport protocol (TCP, UDP, SCTP, DCCP, roll-your-own) is  
appropriate for a given application. Your two suggestions would be  
spot-on for that that document, because they discuss what's good about  
using UDP and what's good about using something else.

But I'm not vehemently opposed to adding one or both of your  
suggestions if others think that's a good idea. I'm mostly mildly  
pushing back in order to keep the document focused. (It's already a  
lot longer than I thought it could ever become...)

> Section 4 says "Many other options for authenticating or encrypting
> UDP payloads exist.  These include IETF security frameworks such as
> GSS-API [RFC2743], SASL [RFC4422] and EAP [RFC3748], which are
> designed to provide security services for network protocols."
>
> EAP doesn't provide any kind of security services for UDP payloads
> (although it could be used together with a mechanism that does
> provide such services), and SASL runs over reliable bidirectional
> streams (like TCP), not datagrams. Also, it might be useful to mention
> CMS here.

You're the security expert - send me text :-) Seriously though, what  
the security considerations are currently saying is what I as a non- 
expert could come up with followed by suggestions by a sec-dir  
reviewer on how to fix the most serious issues. I'm more than happy to  
reword this in ways that will make the section be more accurate, but I  
need some editing help.

Lars

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 14 May 2008 11:18:43 +0300

Lars Eggert wrote:

> > streams (like TCP), not datagrams. Also, it might be useful to
> > mention CMS here.
> 
> reviewer on how to fix the most serious issues. I'm more than happy
> to reword this in ways that will make the section be more accurate,
> but I need some editing help.

Suggested replacement for this paragraph:

   Many other options for authenticating or encrypting UDP payloads
   exist.  For example, the GSS-API security framework [RFC2743] or
   Cryptographic Message Syntax (CMS) [RFC3852] could be used to
   protect UDP payloads. The IETF standard for securing RTP [RFC3550]
   realtime communication sessions over UDP is SRTP [RFC3711].  In
   some applications, a better solution is to protect larger
   standalone objects, such as files or messages, instead of
   individual UDP payloads. In these situations, CMS [RFC3852], 
   S/MIME [RFC3851] or OpenPGP [RFC4880] could be used. In addition, 
   there are many non-IETF protocols in this area.

(On the other hand, the exact text here isn't that important, since
we're not specifying anything new here, only giving pointers
for further reading.)

Best regards,
Pasi

---

From: Lars Eggert <[email-masked]>
Date: Wed, 14 May 2008 11:34:10 +0300

Change made - thanks!