Last Modified: 2005-01-07
|Mar 05||Produce a BCP document that describes the usage of protocols like STUN for performing black-box testing and characterizing NAT behavior|
|May 05||Produce a BCP that defines unicast UDP behavioral requirements for NATs|
|Jul 05||Any revisions to STUN required by other WG deliverables|
|Sep 05||Produce a BCP that defines TCP behavioral requirements for NATs|
|Nov 05||Produce a BCP that defines basic ICMP behavioral requirements for NATs|
|Dec 05||Produce a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches|
|Jan 06||Close WG or recharter|
CHAIRS: Jiri Kuthan <email@example.com>
Cullen Jennings <firstname.lastname@example.org>
Scribe: Spencer Dawkins <email@example.com>
9:00 Agenda Bashing - Chairs
* UDP close to consensus (unicast and multicast)
* TCP getting slose
* Thinkng about application draft
* Missed "Using STUN for testing UDP" milestone
* Do we need a separate draft for ICMP, or include this in other protocol drafts? include as part of general recommendation? TCPM is looking at problems with mapping ICMP messages back to TCP connections - could BEHAVE look at this?
IAB Considerations for NAT Traversaql - Jonathan Rosenberg
* draft-iab-nat-traversal-considerations-00 released just prior to the meeting
* IAB wants inputs from multiple WGs, including BEHAVE
* Lots of traversal mechanisms - how to choose the right general approach?
* Looking at these considerations: security, deployability, manageability, availability
* Please send comments to firstname.lastname@example.org or to IAB
9:05 Unicast UDP - Francois Audet
* Second release of draft (first was individual submission)
* No major outstanding issues raised on mailing list
* "Address and port mapping" <> "binding" in terminology
* "Big NAT/FW opt-out" in applicability statement- large enterprise NATs that may partially comply to this recommendation because of of security, multihoming, etc. - do we really want to do this? Can we downgrade MUSTs to SHOULDs and give applications a heads-up that they can't count on specific behavior? We need to be realistic about MUSTs and SHOULDs, and explain when SHOULDs might not apply. Can we bring these issues onto the list? NAT security is too important to punt on it. If we want NATs to be deterministic, we can't punt. We should be talking about comply/non-comply - but we have "partially complybecause we don't implement all the SHOULDs", and this isn't 2119 language. The IESG thinks we're working on consensus in the industry, not opt-out. We have devices in the field today that randomize IP addresses for every session and we can't solve the problems we want to solve if this is OK. We've worked around these problems before, but it's a huge issue and we need to be aware of them.
* Removed "RECOMMENDED but you MAY do something else" language - now "RECOMMENDED". Simpler, clearer.
* Removed "REQ-8: NAT UDP filter and UDP binding timeout behaviors MUST be the same" - this was confusing.
* ALGs - "If a NAT includes ALGs, it is RECOMMENDED that all of these ALGs should be disabled by default,, and that the NAT allow the user to enable or disable each ALG separately" - what about DNS ALG? But we need to turn SIP ALGs off by default (they aren't as helpful as they wish they were). Recommend DNS and FTP be on by default? Residential NAT defaults aren't likely to be changed - the defaults need to be right in the document.
* Added definition of "deterministic NATs" into REQ-10. Can we reactively filter? Many NATs try to preserve the port mapping (cone NATs), but when they realize they can't because multiple endpoints are using the port, they suddenly become symmetric NATs - sometimes your application works, other times it fails. We don't care as much about what behavior a NAT adopts as we do about NATs that change behaviors. This isn't just about making testing work better, it's about making applications work better.
* Port Parity - didn't change requirement, but changed text on RFC 3550, pointed out that some implementations don't support RFC 3605, and SDP-new-24 requires you to either respect the parity rule or use RFC 3605. What happens if only on party supprots RFC 3605?
* No attempt ro require continuity of ports.
* Now showing the relationship with Cone and Symmetric NAT terminology. We're still rat-holing on this. Some NATs make forwarding decisions based on IP address/port, others only on IP address - these have been documented during the testing sponsored by BEHAVE. Some NATs allow multiple hosts to send a UDP packet back to the internal host, although Symmetric NATs shouldn't allow this. Should we worry about this? We're trying to come up with more determinism, and allowing this behavior in requirements isn't giving us more determinism. Some spinning over definition of Symmetric NATs in STUN. We've already said not to build Symmetric NATs, do we need to talk about different ways ot building quasi-Symmetric NATs? Can we just show the mapping in a diagram? RFC 3489 definition is problematic - can't change the RFC 3489 definition, so do we need to use another definition? We'll take this to the list for exact wording discussion.
* Open issue: REQ-3 recommends "No port assignment" behavior, but random behavior can result in port preservation. Don't recommend anything at all? Ports may/'may not be preserved, not important.
9:45 Multicast UDP - Dan Wing
* Would like to adopt this as WG document, but not getting comments on the list since last IETF.
* Determination on adoption will be made after checking with mailing list.
10:00 Testing Results Status - Chairs
* We have open source implementations for all the tests we've discussed - what should we test?
10:05 What To Test? - Open Discussion & Chairs
* Haven't seen any tests for multicast yet.
* If you have ideas for testing, please tell us!
* Requests: Router alert option, MTU handling on TCP and UDP, deterministic behavior with multiple devices behind NATs, ALG translation,
10:15 TCP Behavior - Pyda Srisuresh
* Contains general recommendations that will be moved to behave-gen draft (after WG consensus).
* Requiring a light-weight state machine (STARTUP, ACTIVE, CLOSING phases).
* Allow reuse of TCP address/port binding across multiple sessions - does this accommodate peer-to-peer TCP connections we've been discussing? Yes, it's a MUST. Does port parity/continuity matter for TCP? No, we'll exclude this from discussion.
* State machine should have timers for each state in the state machine - STARTUP timer values need to be shorter than ACTIVE timer values. How minmalistic can these requirements be, and still make sense? NATs are changing paradigm from packets to sessions. Is this requiring more than is necessary? We don't want to do applications - maybe we should be leaving timer values to NAT vendors, and not stating MUSTs? Timeout values probably make more sense for UDP (no explicity shutdowns, etc.). Does any of this help with SYN flood attacks? 30-60 seconds is way too long to help with SYN flooding attacks. 60 minutes are way too long for ACTIVE timer - Juniper does 30 minutes for long-lived applications, 10 minutes for other applications. We clear sessions completely on FINs. Indiustry has seven years of experience making this work - don't overlook this. Specifying values is a separate issue from specifying timers - maybe timers are enough?
* TCP MUST NOT use a singed TCP port for both NAT'ed and local application sessions at the same time.
* Suggest moving IP fragment requirements to behave-gen draft.
* Suggest sequence number/ack number adjustments only when ALG is on the same ALG.
* Suggestr moving ICMP error requiements to behave-gen draft.
* New requirements - generate and process P-MTU for TCP. This could be used by UDP, too - move to behave-gen draft?
10:30 TCP Behavior - Nagendra Modadugu
* Does NAT allow incoming SYN with simultaneous TCP open? Recommendation is "yes". What about traditional (outbound-only) NATs? Qualify this in the recommendation.
* NATs don't send RST when port is unbound and you get a SYN. Recommendation is "discard silently".
* How many TCP applications actually use TCP connections that go silent for long periods of time? Could have NAT implement TCP keep-alive - recommend that we don't do this. NATs have limited amounts of memory, have to time things out to avoid intentional/unintentional DoS attacks. If applications don't have keepalives, can't expect NATs to guess what's going on. SO_KEEPALIVE timer is on the order of 2 hours - if NATs are shorter, we keep creating zombie sessions on the servers. Doing RESETs in both directions without probing is not good. Need to make sure we don't keep dead sessions up forever. Can't we just rely on applications? NAT devices shouldn't cause a meltdown (but wasn't clear on how this would happen). Servers still have to worry about zombie clients, anyway. Can we make suggestions without tying them to requirements? But then we lose determinism, and application designers have to code for the worst case, anyway.
* Do timer values need to be aware of standard TCP values?
* Other behavior of NATs we need to consider? NAT rules based on specific destinations, other classes of traffic? If we have two different polcies, would both be BEHAVE-compliant? Greg to follow up offline.
* Can we say "MUST NOT be symmetric NAT"?
10:45 TCP Behavior - Open Discussion & Chairs
* Recommend port mapping is endpoint-independent? General nods.
* Port preservation? What about specific port numbers? BGP and IKE? Not IKE - this was a misunderstanding, DESTINATION port must be 500, but not source port - but this is is a deployed misunderstanding. Please send other examples to the list. BGP source port is also ephemeral.
* Receive RESET behavior - do we care about this? Greg recommending NATing the RESET and starting a short timer (5 seconds) to accommodate packets in transit, but this is probably a hint to the NAT implementer. Don't want the NAT doing RESET processing unless it's tracking sequence numbers. What if RESET gets dropped and retransmitted? This is off to the land of firewalls, anyway - do we have to go there? If a NAT knows that RESETs don't open connections, it's turning into a firewall anyway.
* Receiving an external SYN - General nods.
* Port range preservation? Try to keep it in the same range.
* Sequence number adjustment - in scope or ALG scope? If we recommend that some ALGs are on by default, can we declare ALG functionality out of scope? NATs won't change sequence numbers, so need to decide if we're going to be talking about ALGs.
* Port parity? No
* Port continuity? No
* IP Fragmentation? Concern that requiring out-of-order fragmentation processing is open to DoS attack. Concern that NFS relies on fragmentation - can't break this. But aren't we talking about new applications? Do we need to care about existing applications in the decisions we make?
* TCP timers? Lower bounds, or do we include defaults? What problem are we solving? Do applications really need to worry about keepalives? Existing customers dial down when they approach memory limits now - can't really give applications guidance on what you expect for timers - application timers have to be dialable, too.
* Is ALG Segmentation Reassembly in scope? Don't know.
* ICMP fix-up?
* Refresh direction? We don't care?
* Refresh scope? If it's TCP unicast, probably we don't care, and TCPs will need to keepalive on a per-connection case. UDP may have wildcards in both directions - we'll assume that we don't care.
* IP Header Options to identify BEHAVE-compliance? Too vulnerable to manipulation - same as evil bit.
Mail Archive: http://list.sipfoundry.org/archive/ietf-behave