IETF 64
BEHAVE
November 8, 2005, 1510 - 1710
Eric Burger, unworthy scribe, but will work for beer
NAT Behavioral Requirements for Unicast TCP
===========================================
Discussion:
Security considerations say do not send RST to SYN, but send ICMP
soft-error, in order to prevent identity theft. TCP WG is working on
this problem. Should be different error. Also, sending error can make
life difficult for end system.
Looks like coordination between two working groups, as BEHAVE document
may conflict with new TCP document. Galling as new TCP document might
address problem BEHAVE is trying to address.
Randall Stuart for writing some text on this.
Scope: things that are good for firewall to do, but not required for a
NAT, are out of scope. Not for us to forbid good properties, but not
really for us to mandate, either.
NAT needs to keep track of TCP Timestamp wraparound.
SHOULD send RST to both parties probably will not work. This encourages
attacks, as timeouts trigger 3rd-part attack. Ideally, this should be a
local configuration option. If done this way, note it in the document
that YOUR application behavior may vary.
Chairs: RST discussion in document is out of scope, as it has nothing to
do with NAT traversal.
Reminder: traversal of more than just SIP, but IPTV, etc.
sivakumar-draft on TCP traversal
================================
Should drop the SYN & RST attack language, for same reasons described
above. (viz REQ-5)
What about REQ-6, on keep-alives? Jiri - feels out of scope for behave.
Looks like application-specific behavior. Hard to do in firmware.
Smells like firewall stuff, not NAT stuff. Inappropriate to do in NAT
Times: Establishment phase timeout is way too short. Get around by
regular ping over ssh, or have per-flow timer settings. Need to specify
minimum TCP keep-alive value.
What about having variable, load-based timeouts? Not worthwhile, as
client will not know.
TCPM is looking to allow per-TCP stream timeouts.
ipfilter uses 5 day timeouts. 8 years old; driven by long-lived TELNET
sessions.
Closing things in 4 minutes can actually cause more load on NAT.
Back to configurable, per-stream configuration
Eric with lemonade hat on, brings up the mobile battery problem: lots of
keep-alive = no battery life
Rohan: if timers in current RFCs are sub-optimal, write a draft to
update those RFCs (e.g., TCP, UDP)
Most low-end NATs are not configurable; need reasonable values
Consensus: start with draft-hoffman-behave-tcp-03 as starting point. WG
can put stuff into it as necessary.
STUN
====
Rohan: Need STUN over TCP for ICE, too.
Rohan: likes concept of defining what is STUN is. Does not like it to be
called a framework. Likes it to be "a request/response protocol".
Francois points out this work will be useful, as it clarifies what it
means to "implement STUN."
Noted that MUST have shared secret, but NO implementations do it.
However, so much pain from security directorate that not really
interested in taking it out and fighting battles again. Might be able
to hide it in the use cases.
Home for TURN
=============
Why not do ICE in this work group, too? Mute issue: ICE is pretty much
done. Also, ICE really is an extension to offer/answer, and thus
MMUSIC.
Clarification: TURN would still be a separate document, just a use case
of STUN.
Mood for adopting TURN in BEHAVE? Positive.
Rohan: people have done hacks, like UDP<->TCP translation on TURN
TURN Extension for IPv4/IPv6 Transition
=======================================
IPv6 possible and backwards compatible.
Mood is to adopt this draft, too.
Milestone Discussion
====================
Dropping STUN Test from milestones?
Francois: might be worth doing, since stuff is more settled.
Push to whenever?
STUN Revisions: Rohan thinks March is better; JDR is willing to sign up
for January 2006.
Need author for BCP on Usage
SCTP and NAT
============
Use 32-bit random numbers to identify multi-homed streams, even if port
numbers change. 2^16 combinations to avoid birthday problem. In, for
example, SIP case, lots of clients will have same destination address
(SIP server).
|
