Subject: [Ietf-behave] My notes from BEHAVE

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 23 Mar 2006 13:07:24 -0800 (PST)

Behavior 
Engineering for Hindrance Avoidance (behave)Agenda Version #4Chairs: 
Dan Wing <dwing@xxxxxxxxx>Thursday, March 23, 13:00 to 15:00 
==================================Agenda Bashing (Chairs, 5 
min)BluesheetsScribesChair Update (Chairs, 10 min) 
  Dan Wing is new working group chair
  Magnus and Lars are new ADs
  Cullen - "complete change of management is bound to 
help..."TCP Issues (Saikat Guha, 30 
min)draft-ietf-behave-tcp-00
  Revision of hoffman-03 draft, including comments from last meeting and 
  list 
  Requirements - allow simultaneous open, specify unsolicited SYN, name 
  dependable timer values 
  REQ-2 - MUST support full TCP state machine ("standards-compliant stacks 
  should always work")
  REQ-3 - MUST support inbounc SYN/3-way from specific endpoints (handle 
  full cone or restrictive cone behavior)
  Jonathan - this is just for SYN, right? right
  Philip Matthews - Same filtering behaviors for TCP and UDP?
  Jonathan - may treat these differently because applications are different, 
  but we should make a specific recommendation
  Cullen - must not use cone terminology, that just confuses us. Filtering 
  can be anything, mapping behavior must be consistent
  Francois - don't think we need a rule to align with UDP draft unless 
  there's a reason. When we went through the questions, the natural reaction 
  was, "of course", but there were cases that didn't make sense. TCP people make 
  informed decision, look at UDP draft, but not constrained.
  Jonathan - use case - one side is a bad NAT, bindings are 
  endpoint-dependent, but NAT has single IP address on public side - works only 
  if NAT implements endpoint-only filtering
  Philip - same recommendations for TCP and UDP - not using address and 
  port, right? Seems correct (Cullen also supports)
  Francois - can this be the last meeting where we use the word "cone"?
  REQ-4 - SHOULD silently discard unhandled inbound SYN - helps TCP NAT 
  traversal - violates host requirements spec because we don't send ICMP
  REQ-5 - RECOMMENDED 2 hour idle timeout, 4 minutes for unestablished 
  sessions, MAY be configurable.
  Cullen - UDP draft had a "must be greater than" value - MUST of 2 minutes. 
  If we don't do this, we'll all do keepalives
  Magnus - what was security problem with unestablished connections? If you 
  have server with lots of established connections behind a NAT that crashes, 
  NAT is wedged until timeout (2 hours)
  Philip - omission from UDP draft - NAT behavior when it does "get filled 
  up" - what gets dropped? least recently used is exactly the wrong behavior 
  from application view since failures look random.
  Hoffman draft did have recommendations on this - could say this, if it 
  matters.
  Cullen - NAT is either full or is't not, so recommendations didn't make 
  sense, turned into a vendor-defined thing.
  Magnus - must consider security implications of any such behavior
  Philip - not saying my recommendation is the right one, but we need a 
  recommendation that gives consistent behavior
  Francois - too late to recommend behavior for UDP, but TCP may be 
  different - need to discuss this on list
  Lars? - principle of least astonishment would be good. Also - 2 hours is 
  keepalives, which are optional - if you don't use keepalives, connection could 
  be open and silent for years. No good answer that gives consistent 
  behavior
  Are ALGs in-scope? They are for UDP.
  Francois - really don't want to go into ALG behaviors, want everything off 
  unless there's a strong reason to turn something on. Especially don't want SIP 
  ALGs on by default.
  Should FTP be on by default? Dan - IE FTP client doesn't use PASV mode 
  (it's the only one)
  Lars - Lots of stuff runs over TCP, FTP isn't special.
  Recommendation that FTP ALG is turned on by default? Hums were "yes", with 
  some opposed.
  What else on by default? Nothing, everything else defaults to 
offSTUN Issues (Jonathan Rosenberg, 25 
min)draft-ietf-behave-rfc3489bis-03
  Dan now a co-author, more than minor revision.
  TURN is now a usage of STUN
  Magic-Cookie determines RFC3489 or RFC3489bis behavior XOR or non-XOR 
  mapped address  - a lot like branch cookie in SIP
  Created "usage" concept and defined four (discover, connectivity check, 
  NAT keepalives, short-term password)
  A small number of people have implemented shared secret mechanism, 
  short-term password would be simpler
  Removed attributes to determine NAT types
  Francois - NAT keepalive is in this version? Yes - SIP Outbound will match 
  this? Doesn't align yet, of course.
  Added clarification, IPv6 support, removed attempt to detect STUN attacks 
  (had to be on-path, so are probably on-path to see RTP anyway)
  Moved things from TURN to STUN - Magic-Cookie, STUN indications, digest 
  authentication framework, attributes (ALTERNATE -SERVER, REALM, NONCE)
  Adding BINDING-LIFETIME attributes as placeholder for STUN keepalives
  Open issue - fate of type-determination attributes? proposal is to create 
  separate "diagnostic usage" I-D, if we can find a stuckee, alternative is to 
  back-reference RFC 3489.
  Cullen - original charter was more ambitious, could just define what STUN 
  server would do with diagnostics, don't tell how to build a client.
  Dan - implementers not going to go into a lot of detail, will implement 
  everything anyway. Put strong note at the top of this usage. 
  Derek McDonald agreed to author this draft.
  Philip - might want to keep diagnostics for P2P-SIP, even if it's not 
  entirely accurate
  Dan - but some NATs change behavior as they run out of resources...
  Cullen - all devices need two IP addresses - that's what killed this 
  material previously
  Jonathan - ICE is the right answer for P2P-SIP, but we'll talk later
  Open issue - whether to send/receive TLS - use NAPTR? SIP used NAPTR, but 
  client knows exactly what it needs in this case - factor in usages (different 
  ports for relays, etc.)
  Proposal - SRV record looks like _useage_.transport.domain
  Geoff - NAPTR records are so cool, couldn't we use them for something 
  besides ENUM?
  Derek - just getting shared secret? No, can request binding for UDP over 
  TLS, etc. Not trying to make a moral decision, what do people want to do? 
  Different ports for different usages
  Jonathan will write this up and post it.
  Jonathan needs help on failover behavior - usage-specific (NAT keepalive 
  behavior is different from connectivity check)
  Dan - this creates assumptions about what is sharing what secrets
  Cullen - server that is "half up" seems unlikely, don't use this as a 
  requirement (although it will happen).
  Who has read? About half the room.
  Wondering about DNS usage - default STUN port, in which direction? three 
  options (inbound, outbound, neither)
  Jonathan doesn't see reason to remove default port - new default port for 
  turn? If you do SRV, this is non-sensical anyway
  Dan - SRV required in SIP, but do not have 100 implementation
  Aki - Why was IPv6 added? For Gonzalo's draft. Is there a transition 
  scenario where it's needed? For TURN, but not for STUN? Cullen - need this to 
  migrate ICE client to IPv6, but this makes IPv6 NATs work...
  Cullen - still think default number is good for configuration 
  purposes.
  Philip - same port for TURN and STUN? Kind of meaningless (use of ports 
  for firewall policy). Jonathan will request from IANATURN Issues 
(Jonathan Rosenberg, 20 
min)draft-ietf-behave-turn-00draft-camarillo-midcom-turn-ipv6-00
  "More changes than STUN", reflecting relative maturity
  Many things moved to STUN
  Set Active Destination rewritten, unified TCP and UDP, Send is an 
  indication, not a request, allow set active destination even if you've never 
  been there.
  MAPPED-ADDRESS is server-reflexive, added RELAY-ADDRESS for relayed 
  address, added requests for port attributes (specific port, port parity, 
  contiguity port requests)
  Francois - why not get two ports at once? protocol relays to requesting 
  port (want two connections, need two requests from two different ports)
  Francois - how bad is this for TURN server? No worse than what client does 
  for RTP port parity today. It's a hint.
  Requests for specific IP addresses (tcp stun, more than 64K clients), 
  specific transports, permissions set on send and set active destination 
  operations (biggest change requested)
  RTCP attribute now removes parity requirement - why are we doing this? 
  LARGE existing deployments - please say "this is a backwards-compatibility 
  thing" - Jonathan will do so
  Other changes - New Connect request for opening TCP connections, TCP 
  connections NOT opened from ephemeral ports, closing TCP connections from 
  external host do not release allocation (open multiple connections from an 
  allocated address). Allocated lifetimes refreshed ONLY by Allocate request, 
  not data flow.
  Hokey mechanism for dealing with connection setups that take longer than 
  STUN transaction
  Added example, overview of operations
  "Close one connection"? Jonathan will think about this, may make 
  sense.
  Lars - why don't I just wait until something succeeds or fails? If 
  timeouts were set correctly, this wouldn't be an issue.
  Open issue - disambiguation (but we skipped over this)
  Open issue - XOR of other addresses? Jonathan doesn't think this is 
  needed, because NATs are looking for their own addresses
  Philip - don't do this because there are already deployments of this 
  draft? IETF policy is to ignore deployments.
  Cullen - this was the only address that was getting messed up.
  Philip - is XOR the default? For mapped address only, with Magic-Cookie, 
  you always get the XOR mapped-address.
  Philip - for STUN? Magic-cookie isn't an attribute anymore. Chances of XOR 
  screw-up is 2**32. "Backward compatible".
  Open issue - allocate identification. Problem is when NATs reboot. If 
  refresh comes over new flow, will update mapping to point to new flow.
  Open issue - demux over TCP. Server needs to look at bytes 5-8 (magic 
  cookie), and server doesn't know framing protocol, doesn't actually know how 
  to do demux when you don't know framing protocols (ex. Jabber requires full 
  XML parsing to identify start/end). Could signal this, but it's a non-starter. 
  "Do cookie hunt" in TCP until you find the cookie? Not at line rate, need 
  timers (so introduce more jitter), danger of four-byte collisions (2**32 
  collisions in gigabyte files not too unlikely). Always use send and 
  indication? Problem is overhead - no unencapsulated data. Lightweight demux 
  (32-bits, 8 bit type, 24-bit length)? STUN and Data types. Propose that we use 
  this for UDP, too, and evoid need for cookie check.
  "TURN is sickly stepchild of ICE, it's ugly, I hope we never use it in a 
  real network"
  Adam - framing doesn't need to be lock-stepped - assume that you're 
  sending two frames at once, you can send multiple within one frame.
  8-bit only? Sure, but this skews protocols by one byte, changing alignment 
  (or lack thereof).
  TCP is a no-brainer - discussion is on UDP. 
  Derek - (missed comment here - sorry!)
  Sense of room - looks good for TCP, we're not sure about UDP. 
  Open issue - 32-bit alignment - TURN is 32-bit aligned, but data isn't - 
  pad for 32-bit alignment? Will put this in.
  (Missed last slide comment - sorry!)Multicast Draft (Dan Wing, 
10 min)draft-ietf-behave-multicast-01draft-ietf-magma-igmp-proxy-06
  Magma draft has already passed IESG review. Will drop the behave draft and 
  let it expire.
  Cullen - looks close, but if we give MAGMA draft to NAT vendors they will 
  be confused. Make behave draft just point to MAGMA draft, point-by-point?
  Francois - how would anyone else figure this out in the first place. Is 
  there an existing document where we can include the pointer?
  Philip - MAGMA draft is in RFC Editor queue, can't squeeze in a change of 
  this size in AUTH-48.ICMP Draft (Saikat Guha, 20 
min)draft-srisuresh-behave-nat-icmp-01
  Has five requirements, intention is to make ICMP processing determinate 
  without overlapping with TCP and UDP drafts
  Cullen - what applications does this fix? Beyond PING and TRACEROUTE?
  Francois - not clear that we need to look for work. If we can't figure out 
  that something's broken, maybe we don't need to do this work at all.
  Philip - can a NAT vendor screw something up with ICMP? This is more 
  likely than it should be...
  Discussion topics: Recommend allowing administrators to configure ICMP 
  query session timeout?
  Magnus - maximum segment lifetime?
  Do we have consensus on not changing ICMP hard errors to soft errors (or 
  vice versa)?
  Lars - should not change, don't know what the effect would be. Say this in 
  the draft.
  Cullen - have never seen a NAT that does this.
  Francois - are we just saying "must not block ICMP?" Needs to be 
  clarified.
  Need to put this in the document? Discuss on mailing list.
  Src IP of ICMP packet with no mapping - NAT must use its own IP address to 
  translate Src IP in the outer IP header - fix checksums if we do?
  Dan - RPF will cause these packets to be dropped, if we don't.
  Don't refresh or delete the NAT session while processing an ICMP error 
  packet?
  Dan - just a little too protocol-specific for us.
  TCPM has proposal to change soft error (code 10) to a hard error - but 
  this is only a proposal now.
  Send Fragment Too Big errors when processing ICMP messages with DF 
  set?
  Lars - RFC 1812 should be the baseline here - "NATs should look like 
  routers". Only show the baseline.