Subject: [Tsvwg] Re: Comments to draft-ietf-tsvwg-udp-guidelines-03.txt

From: Lars Eggert <[email-masked]>
Date: Wed, 10 Oct 2007 09:50:40 -0500

Hi, Tero,

thanks for the feedback!

On 2007-10-10, at 8:50, ext Tero Kivinen wrote:
> In section 3.6 Programming Guidelines you mention:
>
>    Many operating systems also allow a UDP socket to be connected,  
> i.e.,
>    allow to bind a UDP socket to a specific pair of addresses and  
> ports.
>    This is similar to the corresponding TCP sockets API functionality.
>    However, for UDP, this is only a local operation that serves to
>    simplify the local send/receive functions and to filter the traffic
>    for the specified addresses and ports.  Binding a UDP socket  
> does not
>    establish a connection - UDP does not notify the remote end when a
>    local UDP socket is bound.
>
> I was thinking that it might be good idea to give one reason why you
> do want to do that binding, i.e. to get ICMP error messages associated
> with your UDP packets to your application. If you do the binding of
> local and remote addresses then operating systems usually deliver ICMP
> error messages like host or port unreachable. Those might be
> especially useful for one way connections, i.e. to detect that the
> other end node has disappeared and the router before it is sending
> host unreachable messages to you, so you can stop sending packets to
> it.

If I recall correctly, binding only gets you inbound ICMP messages on  
some stacks. But yes, that may be worth pointing out.

In any event, Gorry and me have been chatting about what to do with  
the "programming guidelines" section. We've gotten other good  
suggestions about what to add here, but that'd make it very long, and  
the purpose of the RFC isn't to be a guidebook on sockets  
programming. Instead of lengthening it, we may instead make it  
shorter, and basically say "if you know the TCP sockets API, there  
are some pitfalls you need to be aware of", together with a small  
number of examples and a pointer to a sockets programming book. But  
we haven't made a decision about what to do yet.

> Also in section 4. Security Considerations you say
>
>    One option of securing UDP communications is with IPsec [RFC4301],
>    which provides authentication [RFC4302] and encryption [RFC4303]  
> for
>    flows of IP packets.  Applications use the Internet Key Exchange
>    (IKE) [RFC4306] to configure IPsec for their sessions.   
> Depending on
>    how IPsec is configured for a flow, it can authenticate or encrypt
>    the UDP headers as well as UDP payloads....
>
> IPsec will always protect UDP headers. There is no way to configure
> IPsec so it does not protect UDP headers. It does not necessarely
> protect IP headers (i.e. when using transport mode with ESP), but it
> will protect UDP headers. So UDP header is always either encrypted, or
> authenticated or both.

Right, and the last sentence in the quote above tries to express  
this. If that isn't clear, we may rephrase that a bit based on your  
previous paragraph.

> Note also that ESP (RFC4303) can also provide authentication in
> addition or instead of encryption, and AH (RFC4302) support in RFC4301
> IPsec architecture is MAY. For authentication ESP with no encryption
> but with authentication is often better option than AH, as ESP will
> also work through NATs (i.e. section 3.5 problem).

Good point, we'll clarify this.

Thanks,
Lars

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 11 Oct 2007 14:19:11 +0100

We will revise this section based on feedback. We'll be seeking to make 
the section concise and helpful, not definitive. So it's useful to 
understand what people think are the key issues - and also to see 
recommendations of the best cook-books to make good applications.

Tero Kivinen wrote:
> Lars Eggert writes:
> Yes, it might not be implemented on all stacks. 
> 
Is it possible to clarify which stacks this concerns?

<snip>

Gorry

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 10 Oct 2007 16:50:05 +0300

Many operating systems also allow a UDP socket to be connected, i.e.,
   allow to bind a UDP socket to a specific pair of addresses and ports.
   This is similar to the corresponding TCP sockets API functionality.
   However, for UDP, this is only a local operation that serves to
   simplify the local send/receive functions and to filter the traffic
   for the specified addresses and ports.  Binding a UDP socket does not
   establish a connection - UDP does not notify the remote end when a
   local UDP socket is bound.

   One option of securing UDP communications is with IPsec [RFC4301],
   which provides authentication [RFC4302] and encryption [RFC4303] for
   flows of IP packets.  Applications use the Internet Key Exchange
   (IKE) [RFC4306] to configure IPsec for their sessions.  Depending on
   how IPsec is configured for a flow, it can authenticate or encrypt
   the UDP headers as well as UDP payloads....

IPsec will always protect UDP headers. There is no way to configure
IPsec so it does not protect UDP headers. It does not necessarely
protect IP headers (i.e. when using transport mode with ESP),From [email-masked] Thu Oct 11 09:33:42 2007
Date: Wed, 10 Oct 2007 16:50:05 +0300
From: Tero Kivinen <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: [Tsvwg] Comments to draft-ietf-tsvwg-udp-guidelines-03.txt

   Many operating systems also allow a UDP socket to be connected, i.e.,
   allow to bind a UDP socket to a specific pair of addresses and ports.
   This is similar to the corresponding TCP sockets API functionality.
   However, for UDP, this is only a local operation that serves to
   simplify the local send/receive functions and to filter the traffic
   for the specified addresses and ports.  Binding a UDP socket does not
   establish a connection - UDP does not notify the remote end when a
   local UDP socket is bound.

   One option of securing UDP communications is with IPsec [RFC4301],
   which provides authentication [RFC4302] and encryption [RFC4303] for
   flows of IP packets.  Applications use the Internet Key Exchange
   (IKE) [RFC4306] to configure IPsec for their sessions.  Depending on
   how IPsec is configured for a flow, it can authenticate or encrypt
   the UDP headers as well as UDP payloads....

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Oct 2007 16:05:04 +0300

>  but it

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Oct 2007 16:05:04 +0300

> we haven't made a decision about what to do yet.

I do not think it is worthwile to make it very long (if it gets longer
than 2 pages then I think it is too long), but it is good idea to
point out few things just like you do now. I.e. not include details,
but point out some things you need to know or to find out, before
starting to write code.
-- 
[email-masked]

> we haven't made a decision about what to do yet.

I do not think it is worthwile to make it very long (if it gets longer
than 2 pages then I think it is too long), but it is good idea to
point out few things just like you do now. I.e. not include details,
but point out some things you need to know or to find out, before
starting to write code.
-- 
[email-masked]

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 11 Oct 2007 16:47:13 +0300

> host unreachable messages to you, so you can stop sending packets to

It's not that simple... if there is a temporary routing failure, you may get 
an ICMP error. Does that mean the entire flow should fail permanently?
I don't know. I have that problem in the VLC media player RTP output. I did 
consider dropping the flow at the first ICMP error. But then, I suspect dudes 
would start complaining how it breaks their (somewhat broken) setup. Not too 
sure what to do here. Waiting for multiple consecutive errors does not help 
either, as ICMP errors are usually paced, so you seldom get two of them in a 
row.

And then, there are quite a bunch of other pitfalls with UDP. My all time 
favorite is the 0-bytes receive, meaning an empty UDP packet rather than 
terminated connection. Interestingly, the DCCP API is very ambiguous on that, 
as it has both connection closure and empty packets... but that would be 
another topic.

And the common mistake of using SO_REUSEADDR on *unicast* UDP sockets.

...

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 12 Oct 2007 16:44:50 -0700

Rémi Denis-Courmont wrote:

> > I was thinking that it might be good idea to give one reason why
> > you do want to do that binding, i.e. to get ICMP error messages
> > associated with your UDP packets to your application. If you do
> > the binding of local and remote addresses then operating systems
> > usually deliver ICMP error messages like host or port unreachable.
> > Those might be especially useful for one way connections, i.e. to
> > detect that the other end node has disappeared and the router
> > before it is sending host unreachable messages to you, so you can
> > stop sending packets to it.
> 
> It's not that simple... if there is a temporary routing failure,
> you may get an ICMP error.  Does that mean the entire flow should
> fail permanently?  I don't know.  I have that problem in the VLC
> media player RTP output. I did consider dropping the flow at the
> first ICMP error.  But then, I suspect dudes would start
> complaining how it breaks their (somewhat broken) setup.  Not too
> sure what to do here. Waiting for multiple consecutive errors does
> not help either, as ICMP errors are usually paced, so you seldom
> get two of them in a row.

It might help if a UDP application handled ICMP 'hard' and 'soft' 
errors differently, as described for TCP in draft-ietf-tcpm-icmp-attacks.

draft-ietf-tsvwg-udp-guidelines might consider such a recommendation.

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 15 Oct 2007 10:43:51 +0300

> draft-ietf-tsvwg-udp-guidelines might consider such a recommendation.

Good point. But that is based on the premise that there is a connection 
establishment and then an established connection. Something UDP and UDP-Lite 
don't have, and "UDP/IP" stacks don't know of (I expect the ICMP soft errors 
to be hidden/digested by the TCP/IP stack from TCP-using applications).

Oh well, one more reason to implement RTCP when using RTP, I guess.

-- 
Rémi Denis-Courmont

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Oct 2007 12:21:11 -0700

>    local UDP socket is bound.

Also to set per-socket options that affect either UDP or IP layers, such
as enabling/disabling UDP checksum, IP source route, etc.

Those typically cannot be sent via a SEND or RECEIVE call alone.

> with your UDP packets to your application.

RFC1122 talks about this, and suggests a pending RECEIVE (sec 4.1.3.3)
as a mechanism as well.

> If you do the binding of

RFC1122 sec 4.1.5 does not require this at the socket layer; it simply
requires that UDP pass the ICMP info to the application. I.e., the "you"
in "you stop sending packets" is the application - not the socket, AFAICT.

> IPsec so it does not protect UDP headers.

If a key is shared among flows between multiple hosts or multiple ports
on a host, it provides a different kind of protection than if it is
specific to a single host pair and port pair. I think that might be
useful to include as clarification, i.e., that IPsec always protects the
headers from tampering, but not from spoofing within a key group.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Oct 2007 12:26:14 -0700

> an ICMP error. Does that mean the entire flow should fail permanently?

See RFC1122 sec 3.2.2.1. Those would be dest unreachables, and MUST be
interpreted as hints only for the reason you describe. Host/port
unreachables are sent by the endpoint and are treated differently.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Oct 2007 12:27:47 -0700

Dan Wing wrote:
...
> errors differently, as described for TCP in draft-ietf-tcpm-icmp-attacks.

That doc describes ways to handle 'hard' and 'soft' differently
depending on whether a stateful connection has been established or not.

UDP doesn't have a stateful connection, so context-dependent responses
to hard and soft ICMPs seems inappropriate.

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Oct 2007 12:38:26 -0700

> to hard and soft ICMPs seems inappropriate.

I agree UDP doesn't have stateful connection, and I agree that handling
hard/soft ICMP errors doesn't make sense for UDP in the general case.
However, I said 'UDP application', and some UDP applications mimic
TCP's connection (via acknowledgement messages and retransmissions).
NFS, once it has established a 'connection' (for example in the middle
of transferring a file) is a reasonable example of an application 
that could benefit from handling ICMP hard/soft differently rather
than handling all ICMP 'soft' errors as if they were important.

-d

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Oct 2007 12:59:35 -0700

> than handling all ICMP 'soft' errors as if they were important.

That would be specifying application layer behavior, and is outside the
scope of this WG, AFAICT.

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Oct 2007 13:06:25 -0700

> That would be specifying application layer behavior, and is 
> outside the scope of this WG, AFAICT.

draft-ietf-tsvwg-udp-guidelines-03.txt is called "UDP Usage 
Guidelines for Application Designers", so it seems in scope for
that working group document, even if out of scope for other
TSVWG activity.

-d

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Oct 2007 13:08:57 -0700

> that working group document, even if out of scope for other

Fair enough. I agree with your summary above, and it would be useful to add.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 16 Oct 2007 21:38:15 +0100

> Fair enough. I agree with your summary above, and it would be useful to add.

It seems you're concluding that if you want to do things in a good way, 
then this "stateful" reliable upper-layer protocol using UDP should 
handle ICMP errors like TCP, SCTP, DCCP, ...

Gorry

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Oct 2007 13:55:34 -0700

Gorry Fairhurst wrote:
>>>> That would be specifying application layer behavior, and is outside
>>>> the scope of this WG, AFAICT.

In general, I would think that upper layers should react similarly to
ICMP errors - stateful or otherwise, UNLESS they have a specific reason
to do otherwise. I think that's useful to note.

Joe

---

From: Gregory Woodhouse <[email-masked]>
Date: Tue, 16 Oct 2007 16:48:34 -0700

> that working group document, even if out of scope for other

That is my understanding of the purpose of this document.

There's a fine line between optimization
and not being stupid. -- R. Kent Dybvig