Subject: Re: [BEHAVE] I-D Action:draft-petithuguenin-behave-stun-pmtud-00.txt

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 07 Jul 2008 16:52:09 -0700

This is a very preliminary I-D that describe a way to discover the PMTU
with a STUN extension.

Comments and questions welcome.

Thanks.

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)
> 	Author(s)       : M. Petit-Huguenin
> 	Filename        : draft-petithuguenin-behave-stun-pmtud-00.txt
> 	Pages           : 8
> 	Date            : 2008-07-07
> 
> This document describes a Session Traversal Utilities for NAT (STUN)
> usage for discovering the Path MTU between a client and a server.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-petithuguenin-behave-stun-pmtud-00.txt

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Jul 2008 17:51:58 -0700

> This is a very preliminary I-D that describe a way to 
> discover the PMTU with a STUN extension.
> 

Thanks.  This seems like a nice approach to learning the on-path MTU which is
important for applications sending large UDP packets (e.g., video).

Questions:

* Implicit with the new PADDING-RECEIVED attribute is that a partial STUN
packet will be received.  But would that ever really occur?  I mean, I would
expect that if some intermediate router fragmented the packet, and one of the
fragments was lost, the destination host's IP stack would fail IP reassembly
and simply discard the packet.

* Section 3.1, "Sending a Probe Request", says:

   No authentication method is used.

I assume, though, that when using ICE between two endpoints that support
petithuguenin-behave-stun-pmtud, ICE's normal username/password and
MESSAGE-INTEGRITY authentication can be used?

* Instead of modifying the STUN retransmission algorithm (where at the third
re-transmission the DF bit is cleared), have you considered instead kicking
off an a new STUN transaction?  The difficulty I see with modifying the
retransmission algorithm is you could have a situation where the last DF=1
packet really did arrive at the server, but because the next re-transmission
has DF=0, the client assumes it was the DF=0 packet that arrived at the
server:

                     client                            server
                       |                                  |
  1.  transaction=1234, DF=1-------> X (dropped)          |
  2.  transaction=1234, DF=1-------> X (dropped)          |
  3.  transaction=1234, DF=1---------(delayed)----------->|
  4.  transaction=1234, DF=0-------> X (dropped)          |  
  5.                   |<-STUN response, padding-received-|

A similar situation could occur if the server's response is delayed.

-d

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 07 Jul 2008 18:50:15 -0700

> important for applications sending large UDP packets (e.g., video).

Even relatively small packets.  With rfc3489bis now limiting IPv4 UDP
packets to 576 bytes, my TURN-ified implementation of good old TFTP
stopped to work.

> and simply discard the packet.

No, the idea is that all packets are sent with the DF bit set so the
packets are never fragmented.  The PADDING attribute is removed for the
third and next retransmissions so we are sure that the packet will reach
the destination.  This is why there is a PADDING-RECEIVED on the
response, so we know if the packet received was with or without the
PADDING.  This is equivalent to detecting the fragmentation, but in a
way that works with both IPv4 and IPv6.

> MESSAGE-INTEGRITY authentication can be used?

Yes, I think that the authentication thing needs more work (The whole
I-D was rushed before the cut-off).  Reusing the credentials in this
case would work.  My problem was with TURN - the credentials can only be
used in the direction TURN client to TURN server.

>   5.                   |<-STUN response, padding-received-|

There is multiple possible designs (I agree that modifying the
retransmission algorithm is ugly).  I played with the idea of using a
Probe Indication, and a Report transaction sent at the same time but
there was some timing issues.  RFC 4821 is really not easy to map to an
actual UDP protocol.  For example I have, I think, a good mapping with
the Probe Success and Probe Failure Results, but I am not sure how to
implement the other Probe Results.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Jul 2008 19:31:11 -0700

> > Thanks.  This seems like a nice approach to learning the 
> > on-path MTU which is important for applications sending large 
> > UDP packets (e.g., video).
> 

Thank you -- I had misunderstood.  That violates one of of the tenets
of STUN, which is that retransmissions are identical.  From 
draft-ietf-behave-rfc3489bis-16:

   Resends of the same request reuse the same
   transaction ID, but the client MUST choose a new transaction ID for
   new transactions unless the new request is bit-wise identical to the
   previous request and sent from the same transport address to the same
   IP address. 

The wording might be backwards, but the wording does require resends with 
the same transaction-id to be identical.  Otherwise we run into another 
issue, which is how the server is supposed to respond with the same 
response within 40 seconds when the two messages are different (one
containing a big PADDING, and another not containing PADDING).

> used in the direction TURN client to TURN server.

Ok.

> implement the other Probe Results.

The model you have seems like it should works well - I do think the
second probe (with the smaller packet) needs to be a separate STUN
transaction, though.

You can stop the STUN state machine early (and stop retransmissions),
if that was your intent of eliminating the PADDING at the 3rd 
retransmission.  Some applications may have different needs or
timing requirements to learn the path MTU.

-d

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 08 Jul 2008 08:12:47 -0700

> containing a big PADDING, and another not containing PADDING).
[...]
> timing requirements to learn the path MTU.

OK, so here's the Probe/Report design:

The PADDING attribute is to be used only with a Probe Indication (or a
Binding Indication).  A Report Request is sent after the sending of the
Probe Indication.  The server responds with a Report Response that
contains the list of all transaction identifiers received in the last 40
seconds (basically the transactions identifiers that had to be kept
anyway).  With a maximum size of 576 bytes, a Report response packet can
contain up to 131 transaction identifiers.

This design should be more flexible and does not mess with the
retransmission algorithm.  OTOH it will be a little bit more complex to
implement, as the client will have to analyze the list of transaction
identifiers received.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Jul 2008 08:57:37 -0700

...
> The PADDING attribute is to be used only with a Probe Indication (or
> a Binding Indication).  A Report Request is sent after the sending
> of the Probe Indication.  The server responds with a Report Response
> that contains the list of all transaction identifiers received in
> the last 40 seconds (basically the transactions identifiers that had
> to be kept anyway).  With a maximum size of 576 bytes, a Report
> response packet can contain up to 131 transaction identifiers.
>
> retransmission algorithm.  OTOH it will be a little bit more complex
> to implement, as the client will have to analyze the list of
> transaction identifiers received.

That design has some interesting properties -- it lets anything be as careful
as it wants.  But if there are a bunch of latent packets (from previous probes
on that same UDP port in the last 2*MSL) or an attacker that is sending
(unauthenticated) probe packets, the Report Response packet could need to be
really big (because there would be a lot of transaction-id's to report).  That
response packet, itself, might be so big that it would get fragmented?

I think modifying your -00 design so that retransmissions are always exactly
like the original packet would be sufficient.  You can add something to the
effect of:  'When sending a certain sized probe, it is RECOMMENDED to assume
there is an ICMP black hole after only 3 missing STUN responses (rather than a
full STUN transaction timeout), and cease retransmitting that STUN
transaction.'  ICE has similar text already (from ice-19):

      *  If an In-Progress pair in the check list is for the same
         component as a nominated pair, the agent SHOULD cease
         retransmissions for its check if its pair priority is lower
         than the lowest priority nominated pair for that component

So a STUN library already needs to have the ability to short-cut its STUN
retransmissions (if the STUN library meets that SHOULD).

-d

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 08 Jul 2008 09:20:24 -0700

> response packet, itself, might be so big that it would get fragmented?

No, because the maximum number of transactions identifiers carried would
be limited by the packet size guaranteed to not be fragmented, i.e.
(576-(20+8+20+4))/4=131 transaction id for IPv4 and
(1280-(40+8+20+4))/4=302 for IPv6.

> retransmissions (if the STUN library meets that SHOULD).

Yes, this works but the alternate design presented above have some nice
properties that would permit (I think) to improve the compliance with
RFC 4821 and implement more efficient algorithms.  For example the
client can send multiple Probe indications with different PADDING size
(with the right pacing between the probes), then send a Report request
to receive the list of probes that made it to the server.

I think I'll put the two designs in the next iteration of the spec:

1. Probe transaction with shortened retransmission (without the
PADDING-RECEIVED attribute on the reponse as it is now useless).

2. Probe indication and Report transaction.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Jul 2008 09:26:24 -0700

> (1280-(40+8+20+4))/4=302 for IPv6.

So your draft would recommend discarding the oldest transaction-ids if there
are too many to fit into the response packet.  Ok.

> 2. Probe indication and Report transaction.

I do like the indication/report mechanism, especially if you recommended
how an application (or underlying OS or underlying STUN stack) might
quickly do PMTUD (using a table of common MTUs like RFC1191 recommends
for TCP) and how it might more thoroughly do PMTUD (more probes to
handle packet loss and handle odd-sized MTUs).

-d