Mobility with Traversal Using Relays around NAT (TURN)
draft-ietf-tram-turn-mobility-09

[Ballot discuss]

Apologies if these discuss points are off-base, I was pressed
for time when reviewing this:-(

(1) section 6 correctly says that encryption and integrity
protection are needed to prevent attacks, but the wording
seems ambiguous. Does the MUST here mean that a) TURN servers
MUST use strong crypto whenever they send tickets or b) if a
TURN server does not use strong crypto then tickets can be
abused? I hope it's the former, but in any case I think you
need to clearly say.

(2) I guess the use of (D)TLS is fairly clear here. But I'm
less clear that things are ok for the other cases when the
ticket is (I guess?) visible to a network attacker. Don't you
need to say that in those other cases the server MUST NOT
honour the ticket unless the authentication mechanisms have
worked out ok?

[Ballot comment]
* Section 3

In the figure (without number/title) why is there an Allocate failure in the second message? I could not find the associated text.

* Section 3.2.1

The section on sending a Refresh when the IP address does not change needs a little bit more tightening. Given that the server would reject the request with a mobility ticket in this case, it would be good to put in an explicit restriction to not add the mobility ticket in the following statement

OLD:
If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it will send a Refresh Request as described in Section 7.1 of [RFC5766]

NEW:
If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it MUST send a Refresh Request as described in Section 7.1 of [RFC5766] and MUST NOT include a MOBILITY-TICKET attribute.

[Ballot comment]
Is the following scenario worth to be discussed in the doc?

A client receives a MOBILITY-TICKET from the server but when it tries to send a Refresh Request the server ignors the ticket and sets up a new association (maybe because the server seemlessly migrated to a machine that does not support/understand MOBILITY-TICKETs or because of policy reasons) and therefore also does not send a new MOBILITY-TICKET back. I guess in this case the client would probably still want to communication with the destination server and just start a new transport connection, right?

[Ballot comment]
Hi, I have a few minor comments and (mostly) questions:

- General: I wonder if this should consider the potential for allocation flapping, e.g. if a client is sitting on the border between two wireless networks. Is this an issue, and is their any reasonable guidance that could be offered?

- 3.1.2, 2nd paragraph:
I'm curious why the server disallows this mechanism would explicitly reject a request with the MOBILITY-TICKET attribute rather than ignoring it as if it didn't understand it? Is there an advantage in letting the client know that the server undertands the extension but chooses not to use it, verses simply not understanding it?

- 3.1.4: If the client receives "Mobility Forbidden", is it allowed (or encouraged) to retry without mobility?

- 3.2.2:

I'm (also) curious why the server rejects a refresh request with the original 5-tuple and the mobility ticket.

Also, during the transition window (before it gets a Send Indication or ChannelData message on the new allocation), am I correct to assume that the server forwards inbound data _only_ to the old client address? That is, not both? If so, I think that could use some reinforcement.

- 5.1: Does MICE here refer to the draft in it's current state, or an earlier version? (assuming there is any material difference.)

Editorial:

-1, 2nd paragraph: "the TURN client has to request for a new
  allocation"
s/request for a new/request a new
-- "new relayed candidate address would have to be tricked"
s/tricked/trickled

[Ballot comment]
= Section 3 =

The diagram needs a caption and some explanation. Why does the first Allocate request result in a 401 error? This is not discussed anywhere in the document.

= Appendix A =

In the data structure there is a "state" field but the text below it refers to an "encrypted_state" field.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tram-turn-mobility-03.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the STUN Attributes subregistry of the Session Traversal Utilities for NAT (STUN) Parameters registry located at:

https://www.iana.org/assignments/stun-parameters/

a single new attribute is to be registered in the 0x8000-0xBFFF range as follows:

Value: [ TBD-at-registration ]
Name: MOBILITY-TICKET
Reference: [ RFC-to-be ]

IANA notes that the authors suggest the value 0x8030 for this registration.

Second, in the STUN Error Codes subregistry also in the Session Traversal Utilities for NAT (STUN) Parameters registry located at:

https://www.iana.org/assignments/stun-parameters/

a new error code is to be registered as follows:

Value: [ TBD-at-registration ]
Name: Mobility Forbidden
Reference: [ RFC-to-be ]

IANA notes that the authors suggest the value 405 for this registration.

IANA understands that the two actions above are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: tram-chairs@ietf.org, "Simon Perreault" , sperreault@jive.com, spencerdawkins.ietf@gmail.com, draft-ietf-tram-turn-mobility@ietf.org, tram@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Mobility with TURN) to Proposed Standard


The IESG has received a request from the TURN Revised and Modernized WG
(tram) to consider the following document:
- 'Mobility with TURN'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-08-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  It is desirable to minimize traffic disruption caused by changing IP
  address during a mobility event.  One mechanism to minimize
  disruption is to expose a shorter network path to the mobility event
  so only the local network elements are aware of the changed IP
  address but the remote peer is unaware of the changed IP address.

  This draft provides such an IP address mobility solution using
  Traversal Using Relays around NAT (TURN).  This is achieved by
  allowing a client to retain an allocation on the TURN server when the
  IP address of the client changes.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Document shepherd: Simon Perreault
Responsible Area Director: Spencer Dawkins

The intent of this document is to define a mechanism for TURN allocations to
survive a client IP address change. A new "mobility ticket" attribute allows the
client to migrate to a new IP address using a make-before-break approach.

The requested publication type is Proposed Standard because new TURN attributes
and behaviour are defined.


2. Review and Consensus

The draft was discussed actively in the MMUSIC working group, under the name
MICE, before it was refocused and transferred to TRAM. Once in TRAM there were
few iterations: the WG was roughly happy with the document as it was. A few good
reviews were done by core WG members which resulted in small changes.

Interest in this document has been medium. The mechanism for TURN makes sense
but there are a number of other layers in a SIP/WebRTC stack at which IP address
mobility could be implemented, e.g., trickle ICE, re-INVITE, etc. At this moment
there is no single agreed-upon "how IP address mobility shall be accomplished"
vision and implementations have not yet picked a clear winner. Since the draft
was first proposed in MMUSIC a sort of "wait and see" response had been slowing
progress.  Today it seems like there won't be a clear decision and the consensus
is that publishing the TURN mechanism is what makes most sense at this point.


3. Intellectual Property

Each author has stated that their direct, personal knowledge of any IPR related
to this document has already been disclosed, in conformance with BCPs 78 and 79.
There was no IPR disclosure.


4. Other Points

This document makes two IANA registrations in existing registries. Both are
clear and require IETF Review.