BEHAVE Agenda, IETF 66
Tuesday, July 11, 2006, 13:00-15:00
Chair: Dan Wing, dwing@cisco.com 

Notes: Spencer Dawkins, spencer@mcsr-labs.org

Corrections and clarifications (from audio recording): Philip Matthews, philip_matthews@magma.ca

- Agenda and Status -- chair, 10 minutes 

No agenda bashing.

Cullen Jennings has stepped down as WG chair (thank you for years of service).

Looking at future milestones, need an application behavior document. The ICE spec gives an example of application behavior, but we need to generalize that. The only document that is published so far is draft-ford-behave-app-02, and that is probably what we are going to consider adopting as a working group item. Please look at that document.

Multicast document went to WGLC several months ago, but conflicted with magma-igmp-proxy document (with a lot of overlap). Will normatively reference MAGMA document, and add a statement that multicast will probably be traveling only in the outside-->inside direction, so need to send packets to keep the NAT binding alive as long as the host wants to receive multicast packets. Cullen will continue shepherding this document.

-  STUNbis,
draft-ietf-behave-rfc3489bis-04, http://www.jdrosen.net/papers/draft-ietf-behave-rfc3489bis-04.txt
Jonathan Rosenberg,

Though I just had to do a few simple changes, but it took me many, many days to revise to the point where I thought the draft was clear and concise. Was submitted late (this morning). 

Changed the name of protocol to "UNDERNEATH NAT", since we're sending Binding Requests over TCP now.

If attribute length is not multiple of 4, then add padding to make multiple of 4, and attribute length field reflects length prior to  padding. (Text notes explicitly where padding is required)

Added FINGERPRINT attribute for demux. Motivation - Adam was downloading big image through some NAT that had some "application-independent ALG" that looks for IP addresses and rewrites them - this caused his image to be corrupted. This got me thinking that error rates we think of as small might not be small enough, so I wanted to add an extra check that the packet is really STUN, especially as we are now muxing STUN a lot with other protocols. Adding SHA-1 with 160-bit fingerprint to make sure that we know for sure that the traffic is STUN. This is in addition to the already existing ways of demuxing, and is mean as an extra demux check, and is not intended to be used for message integrity.  Questions/comments?

Philip Matthews - You didn't mention the first two bits of the message being 0. Is this still there?

Jonathan - Yes, but I think I forget to mention it in the document. Please send me an e-mail reminding me.

Adam Roach - if you're trying to be fast, don't use crypto, SHA-1 is slow. 

Jonathan - I see what you are saying - we would need to compute this every time we send a STUN message. Ok, this could be a CRC also, we just need "good enough" collision avoidance. 

Eric Rescorla - what false positive probability would you tolerate? Something greater than 1 in 2^32, right? 

Jonathan - Would like to send 8 hours of high-def movie with no errors. 

Eric - But UDP checksums aren't as good as what you're talking about now.  You're trying to get more accurate than the bit error rate for the link.

Cullen Jennings - but we lose TCP connection when we have this problem.

Eric - However, Jonathan is trying to get higher accuracy that the TCP checksum gives. So my point is that this doesn't make any sense.

Cullen Jennings - I agree. I think Jonathan's estimates of what the requirements are are way greater than what they actually are.

Jonathan - (In response to EKR's comment) So how are people achieving highly reliable transmission today?

Eric - They are not using TCP. Either your physical layer must be much better, or you need to use a better TCP checksum. If you have a network with any reasonable amount of noise, then TCP will not protect you to better than 1 to 10 million.

Bruce Lowecamp- The issue isn't just bit errors, it's framing in TCP. If you assume your Lord of the Rings video is just random noise, then if your magic cookie happens to match, then you will mistake a packet containing movie data for a STUN packet and thus kill the framing on your TCP connection. 

Jonathan - Yes, this is what I am worried about.

Bruce - So you can just use  another CRC instead, which effectively extends the magic cookie.

Jonathan - In a perfect network with a perfect link layer, using just the magic cookie to detect STUN packets will give you an error rate of 1 in 2^32, which doesn't seem good enough. 

Philip Matthews - But we don't need to protect against random matches anywhere in the packet. If we are doing framing, we just have to make sure that we don't mistake a  STUN header for the video header.

Jonathan - I don't want to make any assumptions about the headers of the other protocol.

Matt Mathis - TCP undetected error rate of 1 in 2^32 is after any errors that have been caught by lower  layers, so performance is better than you think.

Greg Daley - I have been looking at this recently. If you have STUN and some other protocol sending independently, then you are in trouble. However, if STUN is in charge of sending all the packets on the path, and escapes data packets that would cause problems by framing them inside a STUN Send Indication or  STUN Data Indication, then you don't have the problem any more - it's just like SLIP.

Jonathan - we did this for TURN. Isn't this a big change to look at all the data and escape in this way?

Greg - but you have to do that anyway.

Jonathan - Let me think about this. This would require moving STUN Send Indication into the base STUN specification.

Eric - Anything over 64-bits isn't required. If you make sure the checksums are independent, then you can sum the lengths of the two checksums to get something close to the effective length of the combined check. I also suggest using something which is not a CRC but is something different.

Jonathan - I need to think about the math here. Will go to the list for this.

SRV processing matches Dallas proposal, with usage = stun or stun-pass

TLS procedures fully spelled out. No longer specific for  shared secrets, but can be used for other things.

Authentication mechanism now in one place and consistent (none, short-term secret, long-term secret).

Adam had good point on the list about HMAC key construction, added this to the document.

Got rid of XOR-ONLY, and legacy RFC3489 attributes. However, there is an open issue associated with this: What about IANA registration for these?  Right now, they are deleted from the IANA registration in the back of the document, but we don't want people to reuse these values. So we have three choices: (1) This  document can register them as historic, (2) If we get around to writing a diagnostics document, that  document registers them with the appropriate usage, (3) if we never create the  diagnostics document, then  we can write a two-page document that registers them as historic. So the big question is: Are we going to produce a diagnostics document?

Dan Wing (Chair) - Let's defer this discussion until we discuss the diagnostics document.

BINDING-LIFETIME changed to REFRESH-INTERVAL, added motivation: server can tell client to backoff and send binding refreshes less often because the server is getting overloaded.

Can now use a long-term shared secret to get a short-term password (if you want to)

Cut-and-paste error for ALTERNATIVE-SERVER was fixed..

Are we going to do the diagnostics document? If so, should do IANA there.

Also added motivation of REFRESH-INTERVAL for overlap handling and easy config for binding keepalive usage.

Updated IAB UNSAF Considerations and Security Considerations. They are now the security considerations for mapped addresses, and considerations for other usages will have to  covered  where those usages are covered. 

Changed nonce error code to 438 to avoid TURN overlap.

Binding discovery now uses SIP AOR domain name as the default STUN domain name (if you don't have configured STUN domain name).

Indications can be authenticated using short-term credentials (if desired).

Indications can fail on ICMP errors causing SRV failover.

Defined TCP transaction failure.

Big Intro section cleanup.

That's it  for changes in the document. Lots of cleanup. Only two big functional changes: attribute length and fingerprint. 

Open issues...

Open Issue #1: Where do we put keepalive usage, here or SIP OUTBOUND? Propose "here", because could be used with non-SIP applications. Need to define the things other protocols that want to use this usage need to say. This document will give a list of questions that any protocol that wants to use binding keepalive needs to answer.

Rohan agrees.  Any other comments? No? Ok.

Open Issue #2: Where is connectivity check defined? Propose doing this in the ICE specification, because (for example) username construction and validation in this usage are very specific to the ICE protocol. This will help ICE clarity.

I see Philip agrees, and one other person agrees. Any other comments?  No. Ok, I will make that change.

ICE has a sections on sending and receiving STUN requests and responses -- those sections will incorporate the remaining STUN usage text from 3489bis and become the definition of the ICE connectivity check.

Philip - How much are you moving into ICE?

Jonathan - Just the usage section. About 1.5 pages. Usages do not define new protocol mechanisms, they just describe how they are used.

Philip - Could you be more precise about API for other applications? STUN transaction state machine is in STUN draft, and ICE needs to trigger transitions on this state machine. Would be nice if there was a more explicit interface for this interaction.

Jonathan - I understand what you are saying. However, I though it  was pretty clear and I will try to make it even clearer as I do the revision.

Jonathan will start a thread on FINGERPRINT, otherwise this document is done, right? Would be good to get reviews of next draft - when would it be available? Bruce Lowecamp and Philip Matthews and Brian Stockerton to review 05.

-  TURN, draft-ietf-behave-turn-01 -- Rohan Mahy, 30 minutes 

Had editor's token this round.

Added lightweight TCP framing to this version of the draft, so you can tell when you are receiving data and when you are receiving STUN traffic over the TCP connection.  I assumed this needs to run on the same port as regular STUN, but Jonathan assumed we would demux on port. This is a requirements question and we need to pick something. . I don't care, Jonathan might, but do others? If no one else cares, will swap the text. 

Philip Matthews - I would like to be able to run a TURN server on a P2PSIP peer which is behind a nice NAT, and I don't want to have to have two pinholes through the  firewall: one for STUN and one for TURN.

Rohan - So you want to be able to do this in a case where you are not using SRV and you want to be able to do STUN and TURN on the same port.

Greg Daley - I want to make sure there's only one encapsulation, regardless of whether we use Set-Active-Destination or whether we use the connection-oriented transport wrappers for STUN-TCP. 

Rohan - It is currently type and length. So n eed a type for muxing.

Jonathan - Whole point of framing is that I know what is coming over the wire,  but now I have to hack support in with a higher-level protocol.  Is "TCP with lightweight framing" the transport protocol? Rohan - I have a proposal: If you discover the server using SRV records, then use only this framing. If you discover the server through other mechanisms, then I can add text to  describe how to tell what  framing is being used. i

Jonathan - STUN is almost completely subsumed by TURN. If you're going to do STUN, you don't need TURN. 

Rohan - if you wanted to run TCP and TCP-framing on the same port, you can do that, but we're not describing how.

Cullen - this is because we want to switch back to control packets, right? Not just about ports. We're doing insane things to limit RTP length but then saying that adding an additional type field to distinguish packets does matter. We need to get our story straight.

Jonathan - You are bring up an entirely different issue: How efficient is the framing protocol. But the question here is are we always using the framing protocol or are we sometimes using the framing protocol and sometime not.

Rohan - (To Cullen) The reason for doing this is for compatibility with implementations that send ordinary STUN over TCP requests.

Greg - But there are no such applications because we do not yet have STUN over TCP. There are no backwards compatibility issues, so please just do this right.

Philip - If STUN is a subset of TURN, that solves my problem. 

Rohan -So we will always use this with TCP?

Lars - TCP framing very contentious in TCP-M, since TCP is free to resegment. Have you thought of all this? If so, I'm happy - have you?

Rohan - no, this is stream-style, that's not a problem.

So we seem to be leaning towards always using TCP framing? Does anyone object? No one in the room.

Mistakenly removed Connect Request; will be added back. Needed when TURN server is used for policy reasons (instead of traversal reasons) -- e.g., my UA can only connect to one specific TURN server. 

Connection Status Indication is needed for forking case - I have a TCP connection to a TURN server, which then has multiple connections to other UAs; if one of those multiple connections dies, I need a way to be informed of that. Always sent reliably now. 

Only relay from the TURN server to the peer over TCP if the connection from the TURN server to the TURN client is reliable. That is, if connection between TURN client and  TURN server is TCP or TLS over TCP, connection between TURN server and peer can be either TCP or UDP; if the connection is UDP, the connection to the peer can only be UDP.

Now allowed to refresh allocation from different source address. Convenient if I did a bunch of allocations and then my NAT reboots and I have a different address; I can send an allocate to the same server and get the traffic to come back to me.

Rewrote overview.

Motivated odd-even port alignment options. A TURN client doesn't have to use these, they are just there if you want to use them.

Used XOR-MAPPED throughout, instead of MAPPED-ADDRESS.

Used REMOTE-ADDRESS instead of DESTINATION-ADDRESS for consistency in a number of different messages.

I added two additional indications. If you are forking and you are receiving data from one fork, there was no way to squelch data that you were receiving from one of these forks. So added an explicit CloseBinding request to allow you to close one of the forks - is this useful?  Also added explicit OpenBinding for completeness.

Francois Audet - can you CloseBinding all the bindings EXCEPT the one you want to keep? If I have 20 bindings open, and I want to close all but one, do I have to send 19 CloseBinding request?

Rohan - You must send 19 CloseBinding requests, but you can send them all at once.

Philip Matthews - According to the  examples in the ICE specification, TURN has address-dependent filtering behavior. However, when I looked in the TURN draft a few weeks ago, I didn't see anywhere that this was explicitly stated. Is it address-dependent or address-and-port-dependent filtering? 

Jonathan - The term isn't called out but I think the rules are there. 

Dan Wing - This should be made explicit in the document. And if it was address-and-port-dependent mapping, then it would not work well with symmetric NATs. 

Philip - Back to my question: If we have a control channel, it would be nice to be able to turn filtering off and on. If we had this ability, then CloseBinding would be interesting, because we would accept bindings from anyone for a while, then close it down to just a connection to a specific peer.

Rohan - Please wait a couple of slides

Does anyone want a CloseBinding? 3 - 4 hands go up. 

Cullen - From what I heard, it sounded like what we actually want is CloseAllBindingsButX

Rohan - Perhaps. It is easy to do both.

Jonathan - What is the use-case for this primitive? In normal operation, I don't see where this would be useful. The only case I can see is if a malicious endpoint is sending you packets via a TURN address which it  saw in an Invite.

Rohan - I think this is also useful for forked early media. Note that I don't like forked early media, but I have seen it happen.

Jonathan - This is turning into a redesign of PRACK UPDATE.

Cullen - Since there doesn't seem to be a compelling use-case for this, and since this is something that could clearly be added later, perhaps we should leave it until a compelling use-case arises.

Rohan - For CloseBinding, let's wait until we get to the door discussion. However, I have heard no one interested in OpenBinding, so I am planning to remove it. Does anyone care? No. Ok, we have consensus on that, at  least.

SetActiveDestination request has a race condition: over UDP, if I issue a SetActiveDestination and then I later issue SetActiveDestination for another destination, then if packets get re-ordered I might not know which packets were received from which destination. Currently, there is both a client-side and a server-side state machine to avoid this race condition. However, an alternative proposal is to eliminate server state machine in favor of client-enforced timer. If client messes up, only client suffers. However, there is a requirements question: Do we want to be able to swap back and forth between forks, or do we want to just swap to a new fork and get rid of the old fork? The alternative proposal does not allow swapping back and forth, but the current mechanism does. I also came up with a third proposal: sending SetActiveDestination with no REMOTE-ADDRESS means "I don't want there to be an active destination right now". Could then send SetActiveDestination with no REMOTE-ADDRESS, wait, then send SetActiveDestination with new active address.  Does anybody care?

Derek MacDonald - Not that I care, but I had put a timer in my client anyhow with the current mechanism, so if you get rid of it on the server side it doesn't really matter to me.

Jonathan - Previous version of draft had the more general solution. I admit  that was ugly, but I don't see a a compelling reason to change it.

Anyone planning to implement a server? Seeing about 15 people who are implementing servers, but I don't see any real preference one way or the other - let's take this to the list.

There is the concept of a "door" (previously this was called "lockdown"). Initial allocation can ask for the "door" property. Creates a binding for the first datagram or TCP  connection received at the door, then closes the door and doesn't allow any more destinations.

Eric Rescorla - If the server allocates the same port every time, then it is possible to run a server for certain types of protocols. But is this important? 

Jonathan - The idea of TURN has been around for a long time, and when it was originally created, we wanted to limit it so it could not be used to subvert firewall policies. Regarding this specific issue, this is a place where Rohan and I have agreed to disagree. This was a concept that was in TURN a long time ago, and was abandoned. My concern is that this is adding machinery that is close to allowing a client to use the TURN server to run a public server -- all that is needed is for the TURN server to ignore the little bit about closing the door.

Rohan - To run a general server, both the client and server would have to violate several MUSTs. Would have to cooperate is subversion.

Cullen - I think it is very important to stick with our original requirement that this can not be used to run a general purpose server.

Eric -Even with the "close the door" feature, it is still possible to run a general purpose server. (Describes how).

If we don't do Doors, we have to use two TURN servers with TCP simultaneous open between servers. This would allow you to optimize down to a single TURN server in some cases.

Also can use Doors to interop with non-ICE peers. 

Greg - this is a solution but don't think this is the right one. Can still DOS if you aren't able to control who can access the listening port.  Think it's too trivial to block a port.

Rohan - Doesn't agree. Don't have to use doors, and can use explicit bindings instead. 

Jonathan - many reasons we abandoned lockdown. For example, attacker hits the TURN server with address and port from eavesdropped packet and blocks the real sender. So we got rid of lockdown because there was no cryptographic mechanism that would solve this problem. However, Rohan points out that we can still get the non-optimal path through two TURN servers if both endpoints are doing ICE. This argues against " interop with non-ICE". 

Rohan - The door property allows an endpoint to communicate with a second endpoint that is behind a symmetric NAT and which does not have a TURN server. There is this attack which can lock out the desired destination, but ... (feels the advantages outweigh the disadvantages).

Brian Stucker - support this for a couple of reasons. TISPAN and NGN have requirements for this, have seen something like this implemented and it works well. May not work well on public Internet, but it works well. 

Jonathan - We shouldn't work on this at the IETF.  And I will note that TURN will work as previously defined  once symmetric NATs have gone away. This is a use-case whose value diminishes over time.

Philip - That statement is true for TURN in general, because as soon as we have BEHAVE-compliant NATs, we don't need TURN at all.

Rohan - this is a wart on the hairy back-side of TURN.

Derek - Previous statement that "you need doors to talk to a non-ICE client behind a symmetric NAT" is not true. Only need doors if both endpoints are behind symmetric NATs and you want to get rid of one TURN relay.

Will remove the Door from next version of the draft.

Keepalives - was also open issue in previous version. Allocations only refreshed by STUN messages. Data does not refresh binding timers - is this OK? 

Proposal to have separate allocation and binding timers.  Allocation timer would be long and would be refreshed only by STUN messages, while binding timer would be short and would be refreshed by data packets.

Derek - I like the split. 

Alan Hawrylyshen - like the split because of exposure for low-bandwidth, large number of clients.

Will provisionally make this change and post to the list.

- TCP, draft-ietf-behave-tcp-01 -- Saikat Guha, 30 minutes

Now much more standalone than previous draft.

Cullen - many e-mail messages about getting UDP terminology correctly so we didn't have to repeat them in this document - are we doing the right thing?

Saikat - Got lots of complaints about the previous version requiring people to read the UDP document in order to understand the TCP document.

Dan - So the issue is: Do we want the TCP document to be self-contained, or do we want people to have to read the UDP document first?

Joe Touch - TCPM comments, no sense to expect TCP implementers to read UDP documents. IP would be OK. I have worked with NATs that support only TCP.

Francois - Makes sense that this document is self-contained as possible. Concerned that people might twist terminology.

Cullen - Concern is that we made a decision with a lot of e-mail traffic onlist and then reversed it without much traffic.

Poll: Do people want this document to be self-contained? Normatively cite the UDP document? Don't care?  Preference in room was to normatively cite the UDP document.

What to do with unsolicited SYNs? These are SYNs that are inbound, at not part of a TCP simultaneous open (TCP-SO) and are not allowed by filtering behavior.

First option is to silently drop. This is good for P2P, because it allows TCP S-O. It is bad for erroneous SYNs, because there is no indication of error. Most NATs (92%) behave like this today. This behavior was the old working group consensus.

Second option is to send ICMP error. This is good for erroneous SYN, but bad for P2P unless you have a new ICMP error that doesn't cause stack to abort, you won't get a TCP S-O to work.

Third option is to delay for an interval delay and see if internal endpoint sends a SYN. If no SYN from inside, send the ICMP. Suggested delay is 6 seconds.

?? - What's magic about six seconds? 

Saikat - Original proposal was 3 seconds, since SYN retransmission after 3 seconds. (Philip was concerned with 3 seconds). 6 seconds is double that. However, really 6 seconds is just a number picked out of the hat. So question is: is 6 seconds too low for P2P, or too high for erroneous SYN case?

Cullen - Like this idea. Requires that we can get both ends to send SYNs in both directions within 6 seconds, and I think that is plenty long enough.

Philip - Wasn't comfortable with 3 seconds, 6 seconds is fine, but deployed reality is to not send anything - why are we doing this?  Also, if we adopt this procedure, then I feel we need to agree how an application would work given a NAT that behaved in this manner. In other words, what would the behave-app draft say in this case?

Dan - If we don't send an error, then through IESG review will be hard ("deadly sin").

Joe - RFC 1122 says you're obliged to send ICMP errors if you're a host, and NATs are hosts in this sense. Going through IESG review will be hard ("deadly sin").

In order to establish TCP between two candidates: open 3 sockets, bind all to same port, listen, connect(s2, peer.s1), connect (s3, peer.s2). In other words, first one is a server socket, second one is a client socket, and the third one is trying to trigger a TCP S-O. Then, depending on what NAT scenario you are in, one of them will work.

Jonathan - This is exactly what ICE-TCP does.

Will go with Joe's approach of six seconds? Hum is to go this way ("opposed" was silent).

Does TCP need source range to be preserved (when port is below 1024)?

?? - I believe "r"- services (rlogin, rsh, ...) use this, for the 20 or so people in the world who still use plain r-services.

Spencer Dawkins - These services use plaintext passwords (Dan: no, no passwords at all. Spencer: Great. Twice as good!). So you are really concerned about protecting the installed base here, and I think that might not be a great thing to  be worried about

Eric Rescorla - "R"-services are an abomination. The whole notion that you can use someone's source port to determine privileges is crazy, and to use this through a NAT is sheer crack. So no, do not attempt to  support this.  

Dan - So if we find another use-case, we can bring it to the list.

Francois - If we find a good use-case, then yes. But if something is ill-designed, or not use, or misunderstood. Don't try to accommodate every weird case. We went through similar issues with the UDP document, and the amount of time we wasted on issues like this is mind-boggling. 

?? - In some sense, you are almost arguing that port range should not be preserved.

Saikat - I propose is to stay silent on this and let NAT vendors do whatever. Is that ok? 

(Issue will be taken to the list).

ICMP Scope issue will also go to list.

- Diagnostics document - Derek MacDonald

(Was supposed to write a document on this, but didn't get it done for this meeting.)

NAT type discovery dropped from 3489bis because didn't work - NATs became "worse" over time, as load changed, etc. Consumer NATs seem to be more stable? 

Cullen - or not, read Slashdot recently.

How much is this worth for SIP endpoints? May help you detect if the NAT type requires a relay. ICE will do all this for you, but this might be useful when communicating with non-ICE endpoints,  though you are taking a risk.

Might be useful to detect if your NAT supports hairpinning.

P2P applications might want to use this to detect if they are a supernode candidate, or if they are a peer that requires a relay node.

My proposal: Don't say how to use the primitives, but say here are the primitives and "buyer beware". Is this of interest to people?

Francois - yes, useful. May be useful to describe how your NAT is broken. Don't say "this will determine that your NAT is OK", but could be used to determine that your NAT is not OK. 

David Bryan - can we provide ANY guidance, even negative? 

Bruce Lowecamp -No documentation on NATs that appear to work, but actually don't. For example, a box that appears to hairpin, but hairpinning with fragments broken. Having  a document that would say "You can test this, but here are ways that the test can appear to work but will actually fail" would be incredibly useful. - no tests work in all cases.

Jonathan - You talked about how this would work with  ICE-unaware endpoints, which means you have some idea for how this might be integrated with ICE.  ICE is at SHOULD strength to populate MC line probablistically, this is a normative change to ICE. NATs that give you the internal address and port externally, all of these tests fail to even detect a NAT. This makes ICE less reliable, now need alternative way to optimize out relays.

Problem is people who don't want all their traffic to go through relays on the way to non-ICE-aware PSTN gateways. This is a market pressure.

Francois - need at least a little explanation about things that don't always work, because people don't know enough to do this. Some text may be in this document, some in ICE. 

Philip - Perhaps we should wait for P2P-SIP input, if it gets formed? 

Dan - Would like to be in front of the requirements (this time).

(End of session)