[Ietf-behave] Minutes from Dallas

["Dan Wing" <[e-mail]>]

Minutes, BEHAVE WG at IETF 65

Minutes edited by Dan Wing based on notes by Spencer Dawkins 
Meeting chaired by Dan Wing


Thursday, March 23, 2006, 13:00-15:00
-------------------------------------

Topic:  Agenda and Chair Update (Chairs, 15 min)

  It was announced that Jiri Kuthan was stepping down as chair, and
  Dan Wing is the new co-chair (with Cullen Jennings).  The new ADs,
  Magnus Westerlund and Lars Eggert, were introduced.  The agenda was
  accepted as-is.


-----

Topic: TCP Issues (Saikat Guha, 30 min)
draft-ietf-behave-tcp-00

  Saikat presented the draft.  This is a revision of hoffman-03 draft,
  including comments from last meeting and the mailing list.  This draft
  is now a WG item.

  The TCP draft describes NAT behavior to allow simultaneous open so
  that two hosts behind their own NATs can establish a TCP connection.

  Open issues:

  * Req-3, "MUST support inbounc SYN/3-way from specific endpoints
    (handle  full cone or restrictive cone behavior)", generated some
    discussion.  Jonathan asked if this requirement was just for SYN,
    and Saikat agreed it was and the next version of the draft would
    reflect this.

    Philip Matthews asked if we wanted same filtering behaviors for
    TCP and UDP. Discussion concluded that the TCP filtering behavior
    needed to be IP address dependant, but shouldn't be TCP port
    dependant, to allow for a BEHAVE- compliant NAT to talk with a
    non-BEHAVE-compliant NAT which changes the ephemeral TCP port.

  * REQ-5 - timeouts.

    Cullen asked if REQ-5 could specify an absolute minimum so
    applications could do keepalives just faster than this minimum.
    Cullen pointed out this was done in the UDP draft.

    Magnus asked if there was a DoS problem with keeping NAT bindings
    alive for hours if the host had crashed.

    Philip Matthews pointed out the UDP draft didn't discuss what should
    occur when the NAT "fills up" -- deleting the most recently used is
    exactly the wrong behavior from application view since the failures
    look random.  Cullen said such decisions were up to vendors.  Magnus
    said security implications of any such behavior should be
    considered.  Philip suggested that applications want consistent
    behavior, and that is what we need to rely on.

    Francois - too late to recommend behavior for UDP, but TCP may be
    different - need to discuss this on list

    Lars suggested the principle of least astonishment would be good.
    Also - 2 hours is when TCP keepalive occur, and TCP keepalives are
    optional - if you don't use TCP keepalives, connection could be
    open and silent for years.  No good answer that gives consistent
    behavior.

  Question was raised if TCP ALGs are in scope, such as FTP ALG.
  Consensus in the room is they are out of scope unless there is a
  compelling reason to make them in scope.  Dan pointed out that
  Internet Explorer's FTP client doesn't use Passive mode (which is
  inaccurate as of 2004, <http://support.microsoft.com/?kbid=309816>,
  dwing).

  A hum was taken that the FTP ALG is turned off by default.  Hums
  were 'yes' with some opposed.  All other TCP ALGs were decided to be
  off by default.


-----

STUN Issues (Jonathan Rosenberg, 25 min)
draft-ietf-behave-rfc3489bis-03


  Dan is now a co-author.  This version is more than a minor revision.
  "STUN Usages" are now defined, and four usages are defined in
  RFC3489bis, discovery, connectivity check, NAT keepalives,
  short-term password.  TURN is a separate draft that defines its own
  STUN Usage.

  A small number of people have implemented shared secret mechanism,
  short-term password would be simpler

  RFC3489bis removed all attributes to determine NAT types.

  Discussion briefly touched on disconnect between sip-outbound and
  rfc3489bis; these will be resolved by the respective authors.

  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. Derek McDonald agreed to
  author this draft.

  Philip Matthews suggested keeping diagnostics for P2P-SIP, even if
  it's not entirely accurate.  Dan pointed out some NATs change
  behavior as they run out of resources, and Cullen pointed out that
  STUN server needs two IP addresses to do the diagnostics checks.

  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

  There was some discussion; Jonathan will up the SRV proposal
  and post it.

  Jonathan requested help on failover behavior.  This behavior is
  usage-specific (for example, NAT keepalive behavior is different
  from connectivity check).

  Cullen said 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.

  Default STUN port, decision was Jonathan would request one
  from IANA.

  Aki asked by IPv6 was added; it's for v4/v6 transition
  (Gonzolo's draft)



-----

Topic: TURN Issues (Jonathan Rosenberg, 20 min)
draft-ietf-behave-turn-00
draft-camarillo-midcom-turn-ipv6-00

  This draft replaces Jonathan's previous individual submission.  It
  is now a WG item.

  Jonathan explained this draft has More changes than STUN, reflecting
  TURN's relative maturity

  Many things moved from TURN to rfc3489bis.

  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 asked by TURN didn't support getting two ports at once?
  Jonathan explained it's because TURN exists to traverse NATs, and if
  you don't send a packet to the TURN server, the TURN server won't be
  able to get through your NAT.

  Francois asked how bad the 'port parity' request is this for TURN
  server?  Jonathan explained it's merely a hint for the TURN server
  to keep an adjacent port available and is no worse than what a
  client does today for RTP port parity.

  Biggest change requested is that requests can now befor a specific
  IP addresses (useful for tcp stun, more than 64K clients), specific
  transports, permissions set on send and set active destination
  operations

  It was pointed out the RTCP SDP attribute (RFC3605) removes parity
  requirement, but Jonathan said there are RFC3605-unaware endpoints
  which need port parity.  Jonathan will include text to this effect
  in the next version of the draft.

  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 Lars - why don't I just wait until something
  succeeds or fails?  If  timeouts were set correctly, this wouldn't
  be an issue.

  Added example, overview of operations

  It was asked if one side of the connection could be closed.
  Jonathan agreed to think about this; it may make  sense.

  Open issue - disambiguation (was skipped over during presentation
  for time concerns)

  Open issue - XOR of other addresses?  Jonathan doesn't think this is
  needed, because NATs are looking for their own addresses.  A
  discussion ensued around XOR-MAPPED-ADDRESS.  Conclusion was to not
  XOR the TURN addresses.

  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.

  The consensus in the room is this framing was good for TCP; not sure
  about UDP.

  Open issue - 32-bit alignment - TURN is 32-bit aligned, but data
  isn't -  pad for 32-bit alignment?  Jonathan agreed to put this in.


-----

Topic: Multicast Draft (Dan Wing, 10 min)
draft-ietf-behave-multicast-01
draft-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 pointed out that the MAGMA draft is in RFC Editor queue and
  we can't squeeze in a change of this size in AUTH-48.

  Dan said he would ask the list for suggestions.


-----

Topic: ICMP Draft (Saikat Guha, 20 min)
draft-srisuresh-behave-nat-icmp-01

  The ICMP draft is an adjunct to the TCP and UDP drafts that
  we already have.

  Saikat: Draft describes five requirements:

  1. same thing with timeouts as UDP/TCP, namely administrator-
     configured timeout.  Want feedback from BEHAVE.

  Cullen asked what applications beyond ICMP PING and ICMP traceroute
  need this draft.  Saikat agreed with Cullen, but said some ICMP
  errors are useful.

  Francois suggested we make sure something is broken before we
  take this as a WG item.

  Saikat skipped to end of presentation, asking room to adopt this
  as WG item.

  Philip Matthews (?) said the document is important if vendors
  screw up ICMP, or ICMP needs more predictable behavior.

  Saikat said the UDP and TCP documents identified what needs to
  change, at minimum, to make UDP and TCP work.  For ICMP, we're
  less sure what those problems are.

  Continuing with the five requirements:

  1. PING sends an echo request, next PING goes to a different
     mapping; what default timeout should exist for the mappings?

  Magnus - should give consideration to using Maximum Segment
  Lifetime.


  2. NAT MUST NOT modify ICMP 'type' values.

  Saikat asked if anyone was familiar with a NAT that actually had
  this behavior, and if we should mention this in the draft.

  Magnus said perhaps it should stay in the draft.

  Cullen said he hadn't seen a NAT that does this.

  Francois asked if this requirement is trying to say "must not block
  ICMP?".  Saikat said this wasn't related to filtering ICMP, but
  rather was related to changing the contents of the ICMP packet.

  Saikat suggested we remove this from the document.  Dan asked that
  this be brought to the mailing list.


  3. Outbound ICMP messages need to have their IP source rewritten
  to the NAT's public IP address.

  Dan - ingress filtering (RFC2827) will cause these packets to be
  dropped, if the NAT doesn't follow this behavior.  So this is why
  such behavior is necessary.


  4. ICMP messages shouldn't cause a binding to be refreshed or
  deleted.

  Saikat pointed out that the UDP draft already mentions this, for
  UDP.  This requirement would generalize this behavior for NAT
  binding tables.

  Dan pointed out that some protocols may need different behavior.

  Saikat said the ICMP draft would allow protocol-specific drafts
  to override its behavior


  5. Send ICMP error code 10 if NAT is exhausted of resources.
  This is a soft error; Saikat pointed out TCPM is modifying the
  interpretation of this ICMP error, and that this message is
  only sent at session initiation.  Saikat suggested bringing
  discussion to the list.


  6. DF behavior, follows normal router behavior.  Question:  keep
  this in the draft, or pull it out.

  Lars suggested that RFC1812 should be the baseline here - "NATs
  should look like routers".  And that instead of duplicating what
  RFC1812 says, just point out the differences from RFC1812.


  7. TTL behavior, should NAT return 'TTL exceeded' when TTL is
  exceeded at the NAT itself.

end of minutes