headers
Cullen Jennings | 1 Feb 2008 07:10
Picon
Favicon
Gravatar

Re: TURN Issue: Preserving bits in the IP header


that is very cool - thank you for writing that. Any thoughts on being  
able to read any of these bits?

On Jan 29, 2008, at 1:06 PM, Stephane Bortzmeyer wrote:

> On Tue, Jan 08, 2008 at 12:23:16PM +0200,
> Rémi Denis-Courmont <remi.denis-courmont <at> nokia.com> wrote
> a message of 33 lines which said:
>
>> As far as I know the Winsock (Windows), Linux and BSD socket API
>> implementations, none of them provide per-packet TOS and ECN bit
>> specification.
>
> To ease the current survey of implementations, I wrote the attached
> small program, that you can run on your system (tested on many Unix,
> VMS - if someone wants to run a TURN server on VMS - and Windows XP),
> to see what bits in the IP header an ordinary application can *set*
> (wether it can *gets* them is another issue).
>
> To compile:
>
> make
>
> To run:
>
> make test
>
> If you are root, I suggest to run it with and without root privileges,
> the results may be different (for instance on Linux).
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stephane Bortzmeyer | 1 Feb 2008 11:55
Picon

Re: Summary of TURN open-issues call on Monday, 28 Jan 2008

On Mon, Jan 28, 2008 at 05:06:11PM -0500,
 Philip Matthews <philip_matthews <at> magma.ca> wrote 
 a message of 125 lines which said:

> *) Preserving bits in the IP header. When relaying packets, how
> should various IP header bits be set?

My personal opinion, based on the tests I ran on various machines, is
that:

TURN is a "last resort" solution, anyway, for the case where users are
stuck behind badly behaving NATs. We all know it is not the best
solution but its main feature is that it always works, whatever the
behaviour of the NATs. So, having more things (such as preservation of
IP options) is nice but should not be mandatory, it is most important
to have TURN servers available than to have them preserve every IP
option.

So, I favor something like "TURN servers MAY preserve the options set
in the IP header".

Other things to keep in mind (and that's why i suggest MAY and not
SHOULD):

* being a TURN server will not be fun, it takes a lot of resources. We
should not ask them more.

* IP options such as DSCP are very rarely used, anyway.

* we can always design later an extension which will ask for strict
(Continue reading)

Permalink | Reply | 1 comment |
headers
Spencer Dawkins | 1 Feb 2008 15:59
Favicon

Re: Summary of TURN open-issues call on Monday, 28 Jan 2008

From: "Stephane Bortzmeyer" <bortzmeyer <at> nic.fr>

> On Mon, Jan 28, 2008 at 05:06:11PM -0500,
> Philip Matthews <philip_matthews <at> magma.ca> wrote
> a message of 125 lines which said:
>
>> *) Preserving bits in the IP header. When relaying packets, how
>> should various IP header bits be set?
>
> My personal opinion, based on the tests I ran on various machines, is
> that:
>
> TURN is a "last resort" solution, anyway, for the case where users are
> stuck behind badly behaving NATs. We all know it is not the best
> solution but its main feature is that it always works, whatever the
> behaviour of the NATs. So, having more things (such as preservation of
> IP options) is nice but should not be mandatory, it is most important
> to have TURN servers available than to have them preserve every IP
> option.

I guess a related question is whether TURN servers would refuse clients if 
the client asks for IP option preservation and the TURN server doesn't do 
that - I'm guessing "no", but does anyone think the answer is "yes"?

Spencer
Permalink | Reply | 0 comments |
headers
Philip Matthews | 1 Feb 2008 19:41
Picon

Re: TURN Issue: Preserving bits in the IP header


> On Fri, 1-Feb-08, at 05:55 , Stephane Bortzmeyer wrote:
>> On Mon, Jan 28, 2008 at 05:06:11PM -0500,
>>  Philip Matthews <philip_matthews <at> magma.ca> wrote
>>  a message of 125 lines which said:
>>
>>> *) Preserving bits in the IP header. When relaying packets, how
>>> should various IP header bits be set?
>>
>> My personal opinion, based on the tests I ran on various machines, is
>> that:
>>
>> TURN is a "last resort" solution, anyway, for the case where users  
>> are
>> stuck behind badly behaving NATs. We all know it is not the best
>> solution but its main feature is that it always works, whatever the
>> behaviour of the NATs. So, having more things (such as  
>> preservation of
>> IP options) is nice but should not be mandatory, it is most important
>> to have TURN servers available than to have them preserve every IP
>> option.
>>
>> So, I favor something like "TURN servers MAY preserve the options set
>> in the IP header".
>>

What if we come up with something that can be fairly easily done by a  
unprivileged user-land process?
Do you still think MAY is important?
(Continue reading)

Permalink | Reply | 12 comments |
headers
Dan Wing | 3 Feb 2008 19:44
Picon
Favicon

new and adjusted milestones

BEHAVE has a three new milestones:

  * DCCP, July 2008
    This is a BCP document describing NAT operation for DCCP.
    At this time, the most likely candidate document appears to
    be draft-denis-behave-nat-dccp-00.

  * SCTP, December 2008
    This is a BCP document describing NAT operation for SCTP,
    including SCTP multi-homing across NATs.  At this time, the
    most likely candidate document appears to be 
    draft-stewart-behave-sctpnat-03; discussion of SCTP
    multihoming is in draft-xie-behave-sctp-nat-cons-03.

  * STUN test vectors, January 2008
    This is the WG-adopted document 
    draft-ietf-behave-stun-test-vectors-00.

the dates for TURN, TURN-v6, and TURN-TCP were slipped.  (TURN is actually
missing from the milestones right now; I am getting that corrected).

-d
Permalink | Reply | 0 comments |
headers
Dan Wing | 4 Feb 2008 17:17
Picon
Favicon

WGLC: draft-ietf-behave-stun-test-vectors-00

I am starting a two-week working group last call on
draft-ietf-behave-stun-test-vectors-00.txt, ending February 18:

http://tools.ietf.org/html/draft-ietf-behave-stun-test-vectors-00

Abstract:

   This document includes test vectors for the MESSAGE-INTEGRITY and
   FINGERPRINT attributes of the STUN protocol.

This document is being published as an Informational document.

-d
Permalink | Reply | 2 comments |
headers
Philip Matthews | 5 Feb 2008 13:49
Picon

Re: WGLC: draft-ietf-behave-stun-test-vectors-00

Since the document is so short, I have simply reproduced it below
interspersed with some comments.

- Philip

>
>
> Behavior Engineering for Hindrance                     R. Denis- 
> Courmont
> Avoidance                                                           
> Nokia
> Internet-Draft                                         December 17,  
> 2007
> Intended status: Informational
> Expires: June 19, 2008
>
>
>                          Test vectors for STUN
>                  draft-ietf-behave-stun-test-vectors-00
>
[SNIP]

>
> 1.  Introduction
>
>    The Session Traversal Utilities for NAT
>    (STUN)[I-D.ietf-behave-rfc3489bis] protocol defines two different
>    hashes that may be included in messages exchanged by peers
>    implementing that protocol:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marc Petit-Huguenin | 5 Feb 2008 19:05
Picon
Favicon

DF bit in TURN

To understand the problems with the bits to preserve in the IP header
when tunneling through TURN, I tried to implement something that use the
DF bit.  My idea was that two endpoints exchanging video over
RTP/UDP/IPv4 would certainly benefit of using RFC 1191 and RFC 4821 to
find the PMTU in each direction and use it to adjust the maximum size of
the RTP packets that can be sent.  I am assuming that both endpoints are
using ICE, so they both contain a STUN client and a STUN server for the
connectivity checks.  It is then easy to implement PMTU discovery by
using something like a Echo transactions with the PADDING attribute[1]
as probes.

 From the point of view of the endpoint using TURN there is two cases,
PMTU discovery from this endpoint to the other endpoint, and PMTU
discovery from the other endpoint to this endpoint.

It is assumed that both the TURN client and the TURN server know the
PMTU inside the tunnel in each other direction, i.e. for TCP or TLS it
would be something like 65535 minus various headers and for UDP it can
be discovered by the same algorithm than described above.

The simplest case is PMTU discovery from the endpoint behind the TURN
tunnel to the other endpoint.  The STUN client behind the TURN client
sends a probe, the TURN server relays it to the other endpoint (peer)
after setting the DF bit.  If a router on the path between the TURN
server and the peer drops the packet because it would be fragmented,
then the RFC 4821 algorithm will work.  If a router sends back an ICMP
Packet Too Big then it will be dropped by the TURN server, and the RFC
4821 algorithm will also work.  There can be two improvements that can
be done in the TURN protocol to help; firstly to add a way for the TURN
client to set the value of the DF bit that will be used to forward the
(Continue reading)

Permalink | Reply | 3 comments |
headers
Rémi Denis-Courmont | 5 Feb 2008 14:09
Picon

Re: WGLC: draft-ietf-behave-stun-test-vectors-00

Le Tuesday 05 February 2008 14:49:41 ext Philip Matthews, vous avez écrit :
> >    All included vectors are represented as a series of hexadecimal
> >    values in network byte order.  Each pair of hexadecimal digits
> >    represents one byte.
> >
> >    Messages follow the ICE Connectivity Checks use case of STUN, (see
> >    [I-D.ietf-mmusic-ice]).  They include both FINGERPRINT and MESSAGE-
> >    INTEGRITY attributes.
>
> You might want to say a bit more about the implications of the statement
> that these messages follow the ICE use case.

Well - the reason why this document uses ICE connectivity checks is simply 
that I wanted packets with all of the following attributes:
 - MESSAGE-INTEGRITY to check SHA-1 summing,
 - FINGERPRINT to check CRC32 summing,
 - XOR-MAPPED-ADDRESS to check XOR'ing,
 - any text field with "undefined" padding (namely USERNAME).

All four of these have actually proven to be buggy in some of the 
Work-In-Progress STUN stacks around here (including mine). Had STUN Binding 
Discovery *customarily* used all of these, I would have gone for it instead.

I don't mind adding more verbose descriptions (as long as it does not screw up 
the schematics layout :P). Then again, I didn't intend this document to be of 
much use to someone who does not even know the STUN message and attribute 
header formats - so the question is, should it or should it not?

--

-- 
Rémi Denis-Courmont
(Continue reading)

Permalink | Reply | 0 comments |
headers
Derek MacDonald | 5 Feb 2008 23:37
Favicon

Re: TURN Issue #5: Port Range

I really don't think we need *any* text about the fact that ports the
TURN server uses can't be used by another app. It's so obvious that
people will think the txt must have some deeper meaning and waste time
trying to find that meaning.

-Derek

On Jan 18, 2008 9:05 AM, Philip Matthews <philip_matthews <at> magma.ca> wrote:
> A number of people have now told me, either publicly or privately,
> that they would be happy with the text if I simply removed the
> discussion on firewalls. So here is my revised text:
>
>     The server SHOULD only allocate ports from the range 49152 - 65535
>     (the Dynamic and/or Private Port range [Port-Numbers]), unless the
>     TURN server application knows, through some means not specified
> here,
>     that other applications running on the same host as the TURN server
>     application will not be impacted by allocating ports outside this
>     range.  This condition can often be satisfied by running the TURN
>     server application on a dedicated machine and/or by arranging that
>     any other applications on the machine allocate ports before the TURN
>     server application starts.  In any case, the TURN server SHOULD NOT
>     allocate ports in the range 0 - 1023 (the Well-Known Port range) to
>     discourage clients from using TURN to run standard services.
>
> Comments?
>
> - Philip
>
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane