Subject: Re: [BEHAVE] Proposed resolutions for TURN open issues

From: "Alfred E. Heggestad" <[email-masked]>
Date: Sat, 02 Aug 2008 18:06:42 +0100

Hi

please see inline for my comments:

Philip Matthews wrote:
> There was an ad-hoc meeting on TURN  on Wednesday, July 31. During this 
> meeting, all the open issues affecting TURN were discussed and proposals 
> for how to resolve them reached. Jonathan and I then held a phone call 
> to discuss and in a couple of cases made minor tweaks. This e-mail 
> documents the proposed resolutions. Please comment if you are not happy 
> with any of these.
> 
>    1.  Detecting in-use channels.  Do we need a way for a client to
>        determine if a channel is currently bound?  Right now, the only
>        way is to try to bind it to an address.
> 
> This issue was prompted by concerns that the client and server might get 
> out-of-sync over which channels were bound. A concrete example of this 
> concern was when a client retransmitted a ChannelBind msg over UDP. If 
> the first transmission generated a failure response, but the second 
> generated a success response, then the client would believe that the 
> channel was not bound, but the server would believe the channel is bound.
> 
> The proposed resolution to this issue is to not add any way for the 
> client to determine which channels are bound, but to add text explicitly 
> saying that a client should abandon an allocation if it receives an 
> error response to a ChannelBind command. The idea is that any mismatch 
> between the client and the server in this area is very serious, and 
> starting over is the best way to recover.
> 

I dont see any need for detecting in-use channels.

the TURN client is controlling which channels are in use, and the
chances of a ChannelBind error response is very low.

> -- 
> 
>    2.  Public TURN servers.  The spec currently hints (but does not say
>        anything solid) that the way to run a publicly-accessable TURN
>        server is to not require authentication.  But perhaps a better
>        way is to require authentication but have some unspecified method
>        to allow any user to create an account on the server.
> 
> After discussion in the ad-hoc, we propose to say nothing about this. 
> The current text, which does really say anything about this, would 
> remain unchanged. The rationale is that this is a protocol document, not 
> an operational guidance document.
> 

Fully agree

> -- 
> 
>    3.  IPv6.  Currently, TURN supports IPv4-to-IPv4 relaying, and IPv6-
>        to-IPv6 relaying, but does not support IPv4-to-IPv6 relaying.  To
>        ensure this, a server requires that the family of the relayed
>        address match that of the 5-tuple as seen by the server.
>        However, some people would like to see a different rule.
> 
> The proposed resolution is to move the specification of IPv6-to-IPv6, 
> IPv4-to-IPv6, and IPv6-to-IPv4 relaying to draft-ietf-behave-turn-ipv6. 
> The base TURN specification would handle only IPv4-to-IPv4 relaying. The 
> base spec would say that the server address and all relayed addresses 
> must be IPv4 addresses.
> 
> This proposal ensures that client can know in advance what family (v4 or 
> v6) the relayed-transport-address returned by the server will always be 
> of. Some people had objected to the scheme in TURN-09 because the client 
> might send the Allocate request over IPv6, but unbeknownst to the 
> client, the request might pass through a NAT64 and arrive at the server 
> at an IPv4 address. If this happened, the client would get back an IPv4 
> relayed-transport-address when it really wanted an IPv6 
> relayed-transport-address. This proposal addresses their concern, while 
> also moving all the complexity around IPv6 and IPv4 <-> IPv6 to 
> draft-ietf-behave-turn-ipv6, where we have more time to study it and get 
> it right.
> 

Agreed.

> -- 
> 
>    4.  ALTERNATE-SERVER and Anycast.  The details of ALTERNATE-SERVER
>        support are still under discussion.  In particular, some people
>        would like to use ALTERNATE-SERVER to support anycast discovery
>        of a TURN server.
> 
> The proposed resolution is as follows:
> a) The TURN spec would allow the use of ALTERNATE-SERVER in replies to 
> Allocate requests. Furthermore, the text would override the STUN spec 
> and allow the use of ALTERNATE-SERVER in unauthenticated Allocate error 
> responses. If the client receives such a response, then the client 
> SHOULD retry the Allocate transaction with the new address. However, the 
> client MUST check that the realm value received back from the new server 
> is as expected and must use the same username and password as it would 
> have with the original server. In practice, this means that the client 
> must have known in advance what realm, username and password to use with 
> the original server, and uses these same values with the alternate 
> server. With this check, the client can ensure that the original and 
> alternate server are part of the same authentication group.
> b) The spec would NOT go into detail on how this mechanism can be used 
> to do anycast discovery. This would be left to another document.
> 
> In summary, the spec would provide the basic pieces required, but would 
> not go into details on how to use those pieces.
> 

I dont have any opinion about this..

> -- 
> 
>    5.  Authenticated Permission Refresh.  Currently, permissions can be
>        refreshed by unauthenticated Send indications and ChannelData
>        messages.  Some have suggested that this is a security issue.
> 
> The discussion of this issue at the BEHAVE meeting on Tuesday was 
> inconclusive. At the ad-hoc, there was further discussion and it was 
> realized that the attack described in the slides presented at the BEHAVE 
> meeting was easier to perform that we realized earlier. Given this 
> realization, the people at the ad-hoc meeting agreed on the following 
> (options 3 and 4 combined from the slides):
> a) In addition to a Send indication, TURN will support a Send 
> request/response transaction.
> b) Permissions will no longer be installed or refreshed by Send 
> indications or ChannelData msgs. Instead, permissions will be installed 
> or refreshed by ChannelBind transactions (as in turn-09) and by the new 
> Send request/response transaction. Since both of these are 
> request/response, they can be authenticated.
> c) The semantics of the new Send request/response is very similar to the 
> existing Send indication: it would take the same attributes, etc. 
> Specifically, it would have two forms: one with and one without the DATA 
> attribute; the 'without' form would only install or refresh permissions, 
> while the 'with' form would also send data.
> d) In addition, the client would check that Data messages are being 
> received from peer with which it thinks it has a permission. If the 
> client believes there is no permission, the client would discard the data.
> 

I will strongly suggest that any protocol changes to solve this, is
carefully reviewed by experts in this working group. I have been running
the current permission/channel mechanism (defined in turn-07/08/09)
for a while now, and it shows that it is very elegant and clean and robust.
I have not seen any problems with it in deployment.

I am very worried that if we change the turn-spec to add Send Request/Response,
we will indirectly add new problems that we did not think of.

for each TURN allocation, both the client and the server must maintain a list
of channels in use. The same thing would then also apply for Permissions, as
both client and server must maintain a list of permissions (per alloation).
if we can live with the increased security of checking permissions in the
TURN client (SHOULD-strength?), then I would be voting for this solution.

> 
> -- 
> 
>    6.  PMTUD for non-preserving allocations.  Some people would like a
>        way to do PMTUD even if the allocation is non-preserving, and
>        have suggested that a way for the client to indicate to the
>        server (in a Send indication) that the DF bit should be set when
>        sending to the peer might allow this.
> 
> There was hot discussion of this issue at the ad-hoc. Finally, it was 
> agreed that the mechanism suggested by Cullen would be added to the TURN 
> specification, to whit:
> a) A new attribute would be defined for use in a Send indication. If 
> this attribute is present, then the server would set the DF bit when 
> sending the UDP datagram to the peer.
> 

if this is really required, I would suggest moving the attribute/bit
to the allocate request instead. setting the DF-bit is normally done
when opening a socket (setsockopt IP_MTU_DISCOVER)

as a side note, it would be nice to have more fine-grained control
with how the allocation/server should behave. I mean instead of having
a bit-flag saying non-preserving/preserving, we could add more bits
which describe each feature for that allocation.

the client would request a feature by setting a bit to 1, the server
would include in the response which features it supports (0==disabled,
1==enabled).

> -- 
> 
>    7.  Security.  The security consideration section is out-of-date with
>        the changes to the rest of the draft, and it has been suggested
>        that TURN might require TLS to provide proper security.  Updating
>        the security consideration section will answer this question.
> 
> The above changes fix all known security holes. Never-the-less, the 
> authors plan to rewrite the security considerations section ASAP, which 
> would involve taking another hard look at TURN security.
> 

[...]

/alfred

> Comments?
> 
> - Philip
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Fri, 8 Aug 2008 16:08:40 -0400

On Thu, 31-Jul-08, at 17:38 , Benny Prijono wrote:

> On Thu, Jul 31, 2008 at 3:03 AM, Philip Matthews <[email-masked] 
> > wrote:
> There was an ad-hoc meeting on TURN  on Wednesday, July 31. During  
> this meeting, all the open issues affecting TURN were discussed and  
> proposals for how to resolve them reached. Jonathan and I then held  
> a phone call to discuss and in a couple of cases made minor tweaks.  
> This e-mail documents the proposed resolutions. Please comment if  
> you are not happy with any of these.
>
> This issue was prompted by concerns that the client and server might  
> get out-of-sync over which channels were bound. A concrete example  
> of this concern was when a client retransmitted a ChannelBind msg  
> over UDP. If the first transmission generated a failure response,  
> but the second generated a success response, then the client would  
> believe that the channel was not bound, but the server would believe  
> the channel is bound.
>
>
> I thought that (as per the last discussion on this list), any STUN  
> servers (TURN included) MUST retransmit the last error response upon  
> receiving request retransmissions, so this shouldn't be an issue,  
> should it?

The current version of the STUN spec (draft-ietf-behave-rfc3489bis-18)  
lists this as a SHOULD.

However, I believe you are right -- if the server remembers and  
retransmits error responses, then there is no problem.

> client to determine which channels are bound, but to add text  
> explicitly saying that a client should abandon an allocation if it  
> receives an error response to a ChannelBind command. The idea is  
> that any mismatch between the client and the server in this area is  
> very serious, and starting over is the best way to recover.
>
>
> I don't think I would like the text. First of all, not all error  
> responses means out of sync (for example, 438/Stale Nonce). Second,  
> I feel that it should be left to client to decide what to do when  
> such mismatch happens (which shouldn't happen in the first place  
> because of error retransmission requirement above).
>
> So the solution does not solve the question. And personally I don't  
> think this is a question that needs to be solved either, since  
> client totally controls the channel numbers, and out-of-sync can't  
> happen if server retransmits error responses.

How about the following text? This is an attempt to give guidance  
while leaving the final decision of what to do up to the implementor.

10.3.  Receiving a ChannelBind Response

    When the client receives a ChannelBind success response, it updates
    its data structures to record that the channel binding is now  
active.

    If the client receives a ChannelBind failure response that indicates
    that the channel information is out-of-sync between the client and
    the server (e.g., an unexpected 400 "Bad Request" response), then it
    is RECOMMENDED that the client immediately delete the allocation and
    start afresh with a new allocation.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Fri, 8 Aug 2008 16:35:19 -0400

Thanks for your comments. Responses inline.
- Philip

On Sat, 2-Aug-08, at 13:06 , Alfred E. Heggestad wrote:
>> This issue was prompted by concerns that the client and server  
>> might get out-of-sync over which channels were bound. A concrete  
>> example of this concern was when a client retransmitted a  
>> ChannelBind msg over UDP. If the first transmission generated a  
>> failure response, but the second generated a success response, then  
>> the client would believe that the channel was not bound, but the  
>> server would believe the channel is bound.

OK. See my suggested text in the message to Benny Prijono sent a few  
minutes ago.

>> After discussion in the ad-hoc, we propose to say nothing about  
>> this. The current text, which does really say anything about this,  
>> would remain unchanged. The rationale is that this is a protocol  
>> document, not an operational guidance document.
>
> Fully agree
>
>
>> -- 
>> The proposed resolution is to move the specification of IPv6-to- 
>> IPv6, IPv4-to-IPv6, and IPv6-to-IPv4 relaying to draft-ietf-behave- 
>> turn-ipv6. The base TURN specification would handle only IPv4-to- 
>> IPv4 relaying. The base spec would say that the server address and  
>> all relayed addresses must be IPv4 addresses.
>> This proposal ensures that client can know in advance what family  
>> (v4 or v6) the relayed-transport-address returned by the server  
>> will always be of. Some people had objected to the scheme in  
>> TURN-09 because the client might send the Allocate request over  
>> IPv6, but unbeknownst to the client, the request might pass through  
>> a NAT64 and arrive at the server at an IPv4 address. If this  
>> happened, the client would get back an IPv4 relayed-transport- 
>> address when it really wanted an IPv6 relayed-transport-address.  
>> This proposal addresses their concern, while also moving all the  
>> complexity around IPv6 and IPv4 <-> IPv6 to draft-ietf-behave-turn- 
>> ipv6, where we have more time to study it and get it right.
>
> Agreed.
>
>
>> -- 
>> a) The TURN spec would allow the use of ALTERNATE-SERVER in replies  
>> to Allocate requests. Furthermore, the text would override the STUN  
>> spec and allow the use of ALTERNATE-SERVER in unauthenticated  
>> Allocate error responses. If the client receives such a response,  
>> then the client SHOULD retry the Allocate transaction with the new  
>> address. However, the client MUST check that the realm value  
>> received back from the new server is as expected and must use the  
>> same username and password as it would have with the original  
>> server. In practice, this means that the client must have known in  
>> advance what realm, username and password to use with the original  
>> server, and uses these same values with the alternate server. With  
>> this check, the client can ensure that the original and alternate  
>> server are part of the same authentication group.
>> b) The spec would NOT go into detail on how this mechanism can be  
>> used to do anycast discovery. This would be left to another document.
>> In summary, the spec would provide the basic pieces required, but  
>> would not go into details on how to use those pieces.
>
>> inconclusive. At the ad-hoc, there was further discussion and it  
>> was realized that the attack described in the slides presented at  
>> the BEHAVE meeting was easier to perform that we realized earlier.  
>> Given this realization, the people at the ad-hoc meeting agreed on  
>> the following (options 3 and 4 combined from the slides):
>> indications or ChannelData msgs. Instead, permissions will be  
>> installed or refreshed by ChannelBind transactions (as in turn-09)  
>> and by the new Send request/response transaction. Since both of  
>> these are request/response, they can be authenticated.
>> c) The semantics of the new Send request/response is very similar  
>> to the existing Send indication: it would take the same attributes,  
>> etc. Specifically, it would have two forms: one with and one  
>> without the DATA attribute; the 'without' form would only install  
>> or refresh permissions, while the 'with' form would also send data.

This was a hotly debated point at the BEHAVE meeting and it took quite  
a while to come to a consensus. But yes, any change is worrisome.

> TURN client (SHOULD-strength?), then I would be voting for this  

Could you explain your last sentence in more detail? I am not sure  
what you are referring to.

>> There was hot discussion of this issue at the ad-hoc. Finally, it  
>> was agreed that the mechanism suggested by Cullen would be added to  
>> the TURN specification, to whit:
>> a) A new attribute would be defined for use in a Send indication.  
>> If this attribute is present, then the server would set the DF bit  
>> when sending the UDP datagram to the peer.
>

Cullen Jennings, who was the person who pushed strongly for this  
feature, would like to set the DF bit on some packets but not others.

> would include in the response which features it supports (0==disabled,

If I understand you correctly, then you would like to be able to  
request the features associated with a preserving allocation  
individually rather than get them all together. However, all the  
specification on preserving allocations has been moved out of the base  
TURN spec to a new (as yet unpublished) document. Let's have this  
discussion once that document is ready.

>> authors plan to rewrite the security considerations section ASAP,  
>> which would involve taking another hard look at TURN security.
>
> [...]
>
>
> /alfred
>
>> Comments?
>> - Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 08 Aug 2008 17:08:47 -0700

[...]

>>> agreed that the mechanism suggested by Cullen would be added to the
>>> TURN specification, to whit:

I also support this feature.

-- 
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: Philip Matthews <[email-masked]>
Date: Fri, 8 Aug 2008 21:10:58 -0400

> I also support this feature.

After thinking about this feature a bit, and taking Alfred's comment  
into account, it seems to me that there might be a platform where this  
feature cannot be implemented with an unprivileged user-space  
implementation. For example, a quick web search on how to do this for  
MacOS seemed to indicate that there might be a problem. Without  
getting into a discussion of which platforms can and cannot do it, it  
seems wise to me to treat this as a feature which an implementation  
might not be willing or able to support.

Hence I have the following proposal for how to define this feature:

1) TURN would define a new attribute, call it SET-DF. The attribute  
would have a value length of 0. The attribute would be in the  
comprehension-required range.

2) A client MAY include the SET-DF option in an Allocate request.  
Including this option means that the client is requesting an  
allocation that supports this feature.

3) If the server cannot create an allocation that supports the  
feature, the Allocate request is rejected with a 420 Unknown  
Attributes and the UNKNOWN-ATTRIBUTES attribute would list this  
attribute. [Note that in this case, the SET-DF attribute may not  
really be unknown, but simply cannot be supported.]

4) If the server accepts the Allocate request, then the client MAY use  
the SET-DF attribute in a Send request or a Send indication. If the  
attribute is included, then the server sets the DF bit in the  
corresponding UDP datagram towards the peer. If the attribute is not  
included, the server does not set the DF bit.

5) Using the SET-DF attribute in a Send request or Send indication on  
an allocation that does not support it causes the Send request to be  
rejected and the Send indication to be silently ignored (= standard  
behavior for a unknown comprehension-required attribute).

An alternative to this would be to drop points (2) and (3), and say  
that the server rejects a Send request if it cannot	 support the SET- 
DF attribute. This is a bit simpler, but delays the point at which the  
client discovers that the attribute is not supported.

Comments?

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 09 Aug 2008 05:43:57 -0700

Philip Matthews wrote:
> MacOS seemed to indicate that there might be a problem. Without getting
> into a discussion of which platforms can and cannot do it, it seems wise
> to me to treat this as a feature which an implementation might not be
> willing or able to support.
> 
> Including this option means that the client is requesting an allocation
> that supports this feature.
> 
> 3) If the server cannot create an allocation that supports the feature,
> the Allocate request is rejected with a 420 Unknown Attributes and the
> UNKNOWN-ATTRIBUTES attribute would list this attribute. [Note that in
> this case, the SET-DF attribute may not really be unknown, but simply
> cannot be supported.]
> 
> 5) Using the SET-DF attribute in a Send request or Send indication on an
> allocation that does not support it causes the Send request to be
> An alternative to this would be to drop points (2) and (3), and say that
> the server rejects a Send request if it cannot     support the SET-DF
> attribute. This is a bit simpler, but delays the point at which the

Here's an alternate proposal:

- Use bit 3 in REQUESTED-PROPS for the support of the DF bit.  This is
consistent with the usage of REQUESTED-PROPS to query/request allocation
properties.

- Redefine the reserved first 8 bits of PEER-ADDRESS to use bit 7 to
carry the DF bit.  It can then be used in a Send indication/transaction
and even in a ChannelBind transaction if one wants DF bit set in all
packets.

---

From: Simon Perreault <[email-masked]>
Date: Sat, 9 Aug 2008 08:59:17 -0400

> client discovers that the attribute is not supported.

I prefer this alternative. KISS. Logically, setting the DF bit is not an 
allocation attribute so it looks like a hack to save one round trip. Not a 
good enough reason IMHO.

BTW, instead of SET-DF perhaps DONT-FRAGMENT would be more appropriate.

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 10 Aug 2008 18:08:04 -0700

I prefer the simpler version without the steps 2-4 for a few reasons

1) it is simpler

2) it is what we agreed to in the meeting

3) it is more likely to actually get implemented

4) a client that cases can send a 0 length send request with this to  
see if it gets an error or not as soon as it likes

Cullen <with my individual hat on>

On Aug 8, 2008, at 6:10 PM, Philip Matthews wrote:

> into account, it seems to me that there might be a platform where  
> this feature cannot be implemented with an unprivileged user-space  
> implementation. For example, a quick web search on how to do this  
> for MacOS seemed to indicate that there might be a problem. Without  
> getting into a discussion of which platforms can and cannot do it,  
> it seems wise to me to treat this as a feature which an  
> implementation might not be willing or able to support.
>
> 4) If the server accepts the Allocate request, then the client MAY  
> use the SET-DF attribute in a Send request or a Send indication. If  
> the attribute is included, then the server sets the DF bit in the  
> 5) Using the SET-DF attribute in a Send request or Send indication  
> on an allocation that does not support it causes the Send request to  
> be rejected and the Send indication to be silently ignored (=  
> standard behavior for a unknown comprehension-required attribute).
>
> DF attribute. This is a bit simpler, but delays the point at which  
> the client discovers that the attribute is not supported.
>
> Comments?
>
> - Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 11 Aug 2008 10:08:30 +0300

> client discovers that the attribute is not supported.

What happens if SET-DF is *absent* and the OS does not support NOT setting the 
DF bit (from userland)? I recall BSDs, including OSX being in such situation.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Benny Prijono" <[email-masked]>
Date: Mon, 11 Aug 2008 12:50:14 +0100

On Fri, Aug 8, 2008 at 9:08 PM, Philip Matthews <[email-masked]>wrote:

>
> How about the following text? This is an attempt to give guidance while
> leaving the final decision of what to do up to the implementor.
>
>    its data structures to record that the channel binding is now active.
>
I guess I'm okay with that. But we really want to handle out-of-sync
situation, can't we just add a new error code for this (e.g. 4xx Channel In
Use)?

This way the situation is more explicit, and client can also (ab)use it to
check if a specified channel is currently in use (i.e. by sending
ChannelBind and see if it receives 4xx Channel In Use response).

Cheers
 Benny

---

From: Philip Matthews <[email-masked]>
Date: Tue, 12 Aug 2008 21:56:35 -0400

On Sat, 9-Aug-08, at 08:43 , Marc Petit-Huguenin wrote:
>> this
>> getting
>> feature,
>> use
>> on an
>> that

Perhaps I didn't make things clear in an earlier message.
Jonathan and I had a phone discussion about REQUESTED-PROPS. He argued  
(as Simon Perreault also argued) that using REQUESTED-PROPS as a set  
of bit flags meant that TURN had two different ways to define  
extensions (one by defining a new attribute and one using REQUESTED- 
PROPS) and he did not like this at all. He pushed very strongly for  
removing this use of REQUESTED-PROPS. Eventually, I agreed reluctantly  
to go along with this and remove this use REQUESTED-PROPS as part of  
the removal of Preserving allocations.
If the working group disagrees, we can put back in the use of  
REQUESTED-PROPS as a way to define new features, but for now it is out.

> and even in a ChannelBind transaction if one wants DF bit set in all

We could do this (I had originally proposed something like this some  
time ago), but others objected saying that using a new attribute was  
cleaner and saving bytes was not important since the SET-DF attribute  
would only be used on certain special packets. Hence my proposal.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Fri, 15 Aug 2008 14:18:16 -0400

On Mon, 11-Aug-08, at 07:50 , Benny Prijono wrote:

> On Fri, Aug 8, 2008 at 9:08 PM, Philip Matthews <[email-masked] 
> > wrote:
>
> situation, can't we just add a new error code for this (e.g. 4xx  
> Channel In Use)?
>
> This way the situation is more explicit, and client can also (ab)use  
> it to check if a specified channel is currently in use (i.e. by  
> sending ChannelBind and see if it receives 4xx Channel In Use  
> response).

The problem with this approach to determining if a channel N is in use  
is, if it was not in use, then this approach will bind it to some  
address and that binding will take 10 minutes to expire. That is why I  
added an open issue to TURN-09 about adding a mechanism to determine  
if a channel was bound. But the sense of the ad-hoc meeting in Dublin  
was to avoid adding anything in this area and to just add some words  
about what to do if a ChannelBind fails.

---

From: Philip Matthews <[email-masked]>
Date: Fri, 15 Aug 2008 14:51:38 -0400

> the client discovers that the attribute is not supported.

I have seen two requests for the simpler alternative described in the  
last paragraph, and no requests for my more complex proposal. Since I  
really don't care either way, I will go with the simpler proposal.

> DF bit (from userland)? I recall BSDs, including OSX being in such  

The original request was for a way to do some sort of Path MTU  
discovery when the server operated entirely in userland. Always  
setting the DF bit doesn't interfere with this, it just means the the  
Path MTU is smaller than it might otherwise be.

To be precise, if the SET-DF (or DONT-FRAGMENT, as Simon suggests)  
attribute is not present, then I propose the text say that the server  
SHOULD clear the DF bit, with a note that clearing the DF bit may not  
be possible in some situations.

- Philip

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 19 Aug 2008 08:11:23 -0600

> be possible in some situations.

Uh, what sitituations is it not possible to clear the DF bit?

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 19 Aug 2008 17:18:44 +0300

> Uh, what sitituations is it not possible to clear the DF bit?

AFAIK, on a *BSD kernel (including MacOS X), all UDP datagrams have the DF bit 
_not_ set.