BEHAVE BOF (Behavior Engineering for Hindrance AVoidancE)

1
BEHAVEBOF(Behavior Engineering for Hindrance
AVoidancE)

• Cullen Jennings ltfluffy_at_cisco.comgt
• Jiri Kuthan ltjiri_at_iptel.orggt

2
NOTE WELL

• Any submission to the IETF intended by the
  Contributor for publication as all
• or part of an IETF Internet-Draft or RFC and any
  statement made within the
• context of an IETF activity is considered an
  "IETF Contribution". Such
• statements include oral statements in IETF
  sessions, as well as written and
• electronic communications made at any time or
  place, which are addressed
• to
• the IETF plenary session,
• any IETF working group or portion thereof,
• the IESG, or any member thereof on behalf of the
  IESG,
• the IAB or any member thereof on behalf of the
  IAB,
• any IETF mailing list, including the IETF list
  itself, any working group or design team list,
  or any other list functioning under IETF
  auspices,
• the RFC Editor or the Internet-Drafts function
• All IETF Contributions are subject to the rules
  of RFC 3667 and RFC 3668.
• Statements made outside of an IETF session,
  mailing list or other function,
• that are clearly not intended to be input to an
  IETF activity, group or
• function, are not IETF Contributions in the
  context of this notice.
• Please consult RFC 3667 for details.

3
Agenda

• Scribe?
• Agenda bashing (5 min.)
• Problem Statement, Scope, and Charter (30 min.)
• Behavior Recommendations (15 min.)
• draft-audet-nat-behave-00.txt
• Summary and conclusions (10 min.)

4
Problem

• Very large deployment of NATs in public internet
• Inconsistent behavior
• Difficult to detect or predict behavior
• Contributes to problems and difficulty of
  deployment of end to end applications

5
Proposal

• Consider what is broken
• Generate a BCP to enable vendors to build NATs
  with appropriate behavior
• Consider how to characterize and test NATs
• Advise application developers on how to reliably
  function in environments with conforming NATs
• Done is a way consistent with UNSAF and
  transition to IPv6

6
Goals Milestones

• Jan 05
• produce a BCP document that describes the usage
  of protocols like STUN for performing black-box
  testing and characterizing NAT behavior
• Mar 05
• produce a BCP that defines behavioral
  requirements for NATs
• May 05
• produce a BCP that discusses protocol design
  techniques for using the existing set of NAT
  traversal approaches
• Jun 05
• Any revisions to STUN required by other WG
  deliverables

7
Proposed Charter 1

• Given the current near-universal deployment of
  NATs (Network Address
• Translators) in the public Internet, the lack of
  standards for NAT behavior
• has given rise to a crisis. While it is widely
  acknowledged that NATs create
• problems for numerous Internet applications, our
  inability to understand
• precisely what a NAT is or how it behaves leaves
  us few solutions for
• compensating for the presence of NATs.
• The behavior of NATs varies dramatically from one
  implementation to
• another. As a result it is very difficult for
  applications to predict or discover
• the behavior of these devices. Predicting and/or
  discovering the behavior of
• NATs is important for designing application
  protocols and NAT traversal
• techniques that work reliably in existing
  networks. This situation is
• especially problematic for end-to-end interactive
  applications such as
• multiuser games and interactive multimedia.
• NATs continue to proliferate and have seen an
  increasing rate of
• deployment. IPv6 deployments can eliminate this
  problem, but there is
• a significant interim period in which
  applications will need to work both in
• IPv4 NAT environments and with the IPv6 to IPv4
  transition

8
Proposed Charter 2

• This working group proposes to generate
  requirements documents and best
• current practices to enable vendors of both
  traditional NATs and IPv6 to
• IPv4 transition mechanisms (e.g. 6to4) to
  function in as deterministic a
• fashion as possible. It will consider what is
  broken by these devices and
• document approaches for characterizing and
  testing them. The group will
• also advise on how to develop applications that
  discover and reliably
• function in environments with NATs and IPv6 to
  IPv4 transition
• mechanisms that follow the best current practices
  identified by this working
• group. The group will consider the security
  implications (or non-implications)
• of these devices.
• The work will be done with the goal of
  encouraging eventual migration to
• IPv6 and compliance with the UNSAF RFC 3424
  considerations. It will not
• encourage the proliferation of NATs.
• The behavior that will be considered includes the
  behavior includes IP
• fragmentation and parameters that impact ICMP,
  UDP, TCP, IGMP, MLD,
• and multicast. The proposed WG will coordinate
  with v6ops, midcom and
• nsis. The work is largely limited to examining
  various approaches that are

9
Proposed Charter 3

• Discussion will start from several existingdrafts
  or RFCs,
• including
• draft-jennings-midcom-stun-results
• draft-audet-nat-behave
• RFC 3489
• draft-ford-midcom-p2p