Subject: [BEHAVE] (mostly non) open issues

From: "Rohan Mahy" <[email-masked]>
Date: Sun, 27 Jan 2008 22:54:27 -0800

Hi,

I think most of the so-called open issues in TURN-06 are not really open
issues. My recollection follows for the ones I think are not open, and my
opinion for items #4 and #8 which I consider the only real open issue on the
list:

17.1. Open Issues

   1.   Bandwidth: What should we do with the BANDWIDTH attribute, which
        is currently ill-specified?  Should we remove it?  Or should we
        try to come up with a good specification, perhaps using ideas
        from RSVP?

I recall that we agreed that it is a hint.

   2.   Permission Policy: What should the permission policy be?
        Address-restricted, as is currently specified in the document?
        Or address-and-port-restricted, as many firewalls implement
        today?  Or should we leave this open to the implementor, under
        the assumption that the IT administrator will only allow clients
        to contact those servers that implement whatever permission
        policy the IT administrator can accept?

We definitely agreed that the permission policy is address-restricted.

   3.   Port Adjacency: The spec currently allows a client to request
        that the server allocate a port and also reserve the next higher
        port number for a possible future allocation (on a different
        5-tuple).  However, the exact behavior of the server in this
        case is ill-specified.  For example, must the next-higher-port
        be available for the allocation of the lower port number to
        succeed?  How long is the next-higher-port reserved? 30 seconds?
        For the lifetime of the lower-numbered-port's allocation?  Or
        should we just ditch this feature, since it is difficult to
        implement, it is at odds with port randomization, and paired
        port numbers applications don't work well with NATs anyway?

We agreed to keep this at the adhoc. The server is asked to come up with ANY
even port with the next higher port available.  The client was never allowed
to ask for a pair of ports with a specific port number (the syntax actually
prevents this).

IMO, the server is reserving the next port as a courtesy, so the amount of
time the server wants to wait is up to the server.

   4.   Demuxing ChannelData messages: How does a client or server demux
        STUN-formatted messages from ChannelData messages?  Does it use
        the first two bits (as currently specified) or just one bit?
        And how many channels do we need anyway?  Some people are
        questioning the need for any more than 200 channels.  If we
        don't need many channels, then the demux algorithm might become
        simpler.

OPEN ISSUE:
Unfortunately I have to agree that this is an open issue, but only because
we are not using the 4-octet framing for every message as we had consensus
to do in TURN -05. My opinion is that we should go back to TURN framing for
all TURN messages.

   5.   Deallocating Channels: Do we need a mechanism for deallocating
        channels?  Some have argued for this feature, because a TURN
        server administrator will want a way to recover resources for
        channels no longer in active use.  If yes, then what is the
        mechanism?  For example, should a channel binding expire when
        the corresponding permission expires?

I recall that we came to consensus that this was not necessary.  If the
client is really concerned, it can open a new allocation and transition its
active peers to the new address.

   6.   Permissions and Channel Allocations: Should allocating a channel
        for a peer automatically install a permission for that peer's IP
        address?

We agreed long ago, and repeated agreeing that sending data (in a Send or
within a channel) or sending a Send indication with no DATA attribute
creates a permission.

   7.   Permission and Allocation Lifetimes: What should the default
        permission lifetime be?  Should there be a minumum value?
        Should there be a way for the client to modify the permission
        lifetime?  Should there be a way for the client to learn the
        current permission lifetime?  And what is the relationship of
        the permission lifetime to the allocation lifetime?  Does it
        make sense for the allocation lifetime to be less than the
        permission lifetime?

We agreed a long time ago that 30 seconds for a UDP permission was
appropriate and consistent with NATs.

   8.   Preserving bits in the IP header: What bits (if any) should be
        preserved in the IP header when a packet is relayed by the
        server?  The bits under consideration are currently the Don't
        Fragment (DF) bit, the Explicit Congestion Notification (ECN)
        bits, and the DiffServ (DS) bits.

OPEN ISSUE:  IMO, this is an implementation issue.  The server can try to
preserve some of these bits, but is not obligated to do so.  The client
cannot count on any of these bits being passed along.  If this is not good
enough in practice, we can add an extension that provides this type of
transparency.

   9.   Exceeding the Path MTU Size: TURN adds an overhead of 4 bytes
        (ChannelData msg) or 36 bytes (Send or Data Indication), thus
        potentially exceeding the path MTU between the client and
        server.  This could either cause IP fragmentation, or cause the
        packet to be dropped if the DF bit is set.  Who handles this
        problem?  Does TURN need to handle this, or is this left up to
        the application to handle?

We agreed back when we added the framing that this was a non-issue for the
protocol.

   10.  Allowed PEER-ADDRESS values: Should there be any restrictions on
        the IP address the client can specify in the PEER-ADDRESS
        attribute?  Are multicast addresses allowed?  What about
        0.0.0.0?  Any other restrictions?

I think server implementations are capable of taking care of this
themselves.  I don't think we need to specify this in the protocol.  I
certainly don't think this is an open issue, since I don't it is an issue.

   11.  Discarding UDP datagrams: If the server discards a received UDP
        datagram on the relayed transport address (because there is no
        corresponding permission), then does the server send an ICMP
        response?  If so, what error code does it use?  (What does RFC
        4787 say about the corresponding situation in NATs?  I believe
        many NATs silently discard these packets by default, or have a
        "stealth mode" that enables this behavior.)

We agreed and the draft has said for a very long time "silently discards"

   12.  Authentication: Is the use of STUN's Long-Term Authentication
        Mechanism by a TURN server mandatory?  The document currently
        implicitly assumes "yes", but what about someone who wants to
        operate a public TURN server?

I believe we had consensus that even/especially public STUN servers MUST use
long-term authentication.

   13.  Re-using the 5-tuple: If an allocation expires, is there any
        reason a client should not be able to immediately create a new
        allocation using the same 5-tuple?

Yes, there is a good reason.  The protocol does not allow requesting a
specific requested ip address and port unless asking for the second port in
a pair of ports.

   14.  Password change: Is it possible to change the password for the
        Long-Term Authentication mechanism during the lifetime of an
        allocation?  If so, how is it done?

IMO: Up to the implementation.

   15.  IPv6: TURN probably works fine in an all IPv6 environment, but
        there are a number of mixed IPv4/IPv6 cases that are ill-
        specified.  As an example, the server needs to check that the
        PEER-ADDRESS in a Send Indication is of the same address family
        as the relayed transport address.  Should we carefully work
        through all these cases and make sure we have caught them all,
        or should we just state that this document covers the IPv4 case
        only, and punt the specification of IPv6 and mixed IPv4/IPv6
        operation to draft-ietf-behave-turn-ipv6?  Does the current
        interest in resurecting IPv4-to-IPv6 NATs have any impact on
        TURN?

We agreed that this will be handled in a separate document.

thanks,
-rohan
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave