Subject: [tram] I-D Action: draft-ietf-tram-turnbis-06.txt

From: [email-masked]
Date: Fri, 11 Sep 2015 15:25:34 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the TURN Revised and Modernized Working Group of the IETF.

        Title           : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
        Authors         : Tirumaleswar Reddy
                          Alan Johnston
                          Philip Matthews
                          Jonathan Rosenberg
	Filename        : draft-ietf-tram-turnbis-06.txt
	Pages           : 80
	Date            : 2015-09-11

Abstract:
   If a host is located behind a NAT, then in certain situations it can
   be impossible for that host to communicate directly with other hosts
   (peers).  In these situations, it is necessary for the host to use
   the services of an intermediate node that acts as a communication
   relay.  This specification defines a protocol, called TURN (Traversal
   Using Relays around NAT), that allows the host to control the
   operation of the relay and to exchange packets with its peers using
   the relay.  TURN differs from some other relay control protocols in
   that it allows a client to communicate with multiple peers using a
   single relay address.

   The TURN protocol was designed to be used as part of the ICE
   (Interactive Connectivity Establishment) approach to NAT traversal,
   though it also can be used without ICE.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tram-turnbis-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 11 Sep 2015 22:28:33 +0000

This revision updates PMTUD and adds support for receiving ICMP from peer.

-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Friday, September 11, 2015 3:26 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-06.txt
> 
> 
>         Title           : Traversal Using Relays around NAT (TURN): Relay Extensions
> to Session Traversal Utilities for NAT (STUN)
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Sep 2015 08:34:52 -0400

> This revision updates PMTUD and adds support for receiving ICMP from peer.

Thanks for this update. Here are a few comments...

> 10.5.  Receiving an ICMP Packet
> 
>    When the server receives an ICMP packet at a currently allocated
>    relayed transport address,

You can't receive an ICMP packet "at a currently allocated relayed
transport address".

Suggestion: s/at a currently allocated relayed transport address//, with
additional text below.

>    the server verifies that the type is
>    either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either 1, 2, or
>    3 for an ICMPv6 [RFC4443] packet.  It also verifies that the IP
>    packet in the ICMP packet payload contain an UDP header.  If either

s/contain/contains/

>    of these conditions fail, then the ICMP packet is silently dropped.

>    The server looks up the allocation associated with the relayed
>    transport address.

Replace this sentence with: "The server looks up the allocation whose
relayed transport address corresponds to the encapsulated packet's
source IP address and UDP port. If no such allocation exists, the packet
is silently dropped."

>    The server then checks to see whether the set of
>    permissions for the allocation allows the relaying of the ICMP packet
>    as described in Section 8.

Section 8 would imply checking the outer packet's source, which is
wrong. It is very likely that ICMP packets are generated by intermediate
routers. The router must ignore the outer source and must instead check
the encapsulated packet's destination.

Reword for clarity: "For ICMP packets, the source IP address MUST NOT be
checked against the permissions list as it would be for UDP packets.
Instead, the server extracts the destination IP address from the
encapsulated IP header.  The server then compares this address with the
IP address associated with each permission in the list of permissions
for the allocation.  If no match is found, relaying is not permitted,
and the server silently discards the ICMP packet.  Note that only
addresses are compared and port numbers are not considered."

>    If relaying is permitted then the server forms and sends a SendError
>    indication.  The SendError indication MUST contain both an XOR-PEER-
>    ADDRESS and an ICMP attribute.  The ICMP attribute is set to the
>    value of the type and code fields from the ICMP packet, and the XOR-
>    PEER-ADDRESS attribute is set to the destination IP address in the IP
>    header and to the destination port in the UDP header.  Both are found
>    in the ICMP packet payload.  The SendError indication is then sent on
>    the 5-tuple associated with the allocation.

Two things:

- The "SendError" method can be confused with a "Send Indication error
response" (i.e., a message with the Send method and class 0b11). I
suggest renaming to avoid confusion.

- Is it really necessary to define a new method? I'm thinking that the
Data method could be reused: just make it transport an ICMP attribute
instead of a DATA attribute. It would not affect backwards compatibility
since older clients will drop Data messages that don't contain a DATA
attribute (per section 10.4).

Simon

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 14 Sep 2015 14:24:36 +0000

> On Sep 11, 2015, at 6:28 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 

You add the SendError as a new indication to be sent unilaterally, with no backward-compatibility features. Do we know that existing clients won’t choke on receiving an unknown indication type?

I suggest a new attribute on the Allocate message and response, SUPPORT-SEND-ERROR or the like, so support for SendError can be negotiated.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 18 Sep 2015 01:00:48 +0000

> From: tram [mailto:[email-masked]] On Behalf Of Jonathan Lennox
> Sent: Monday, September 14, 2015 7:55 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]
> Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-06.txt
> 
> 
> You add the SendError as a new indication to be sent unilaterally, with no
> backward-compatibility features. Do we know that existing clients won’t
> choke on receiving an unknown indication type? 

Based on the comments from Simon, the plan is to use Data indication to send the ICMP attribute and remove SendError.

-Tiru
> 
> I suggest a new attribute on the Allocate message and response, SUPPORT-
> SEND-ERROR or the like, so support for SendError can be negotiated.
> 
> >
> > -Tiru
> >
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 18 Sep 2015 14:17:35 +0000

> On Sep 17, 2015, at 9:00 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 

That’s fine, but the same consideration applies.  Do we know that existing clients do okay receiving a data indication without a data attribute?

Do you see harm in negotiating whether ICMP reports are supported?

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 18 Sep 2015 15:30:39 +0000

> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Friday, September 18, 2015 7:48 PM
> >> You add the SendError as a new indication to be sent unilaterally,
> >> with no backward-compatibility features. Do we know that existing
> >> clients won’t choke on receiving an unknown indication type?
> >
> > Based on the comments from Simon, the plan is to use Data indication to
> send the ICMP attribute and remove SendError.
> 
> That’s fine, but the same consideration applies.  Do we know that existing
> clients do okay receiving a data indication without a data attribute ?

Yes, https://tools.ietf.org/html/rfc5766#section-10.4 TURN client ignores Data indication without Data attribute.

-Tiru
> >> I suggest a new attribute on the Allocate message and response,
> >> SUPPORT- SEND-ERROR or the like, so support for SendError can be
> negotiated.
> >>
> >>>
> >>> -Tiru
> >>>
> >>>>  If a host is located behind a NAT, then in certain situations it
> >>>> can  be impossible for that host to communicate directly with other
> >>>> hosts  (peers).  In these situations, it is necessary for the host
> >>>> to use  the services of an intermediate node that acts as a
> >>>> communication  relay.  This specification defines a protocol,
> >>>> called TURN (Traversal  Using Relays around NAT), that allows the
> >>>> host to control the  operation of the relay and to exchange packets
> >>>> with its peers using  the relay.  TURN differs from some other
> >>>> relay control protocols in  that it allows a client to communicate
> >>>> with multiple peers using a  single relay address.
> >>>>