Subject: [Ietf-behave] FW: BEHAVE minutes IETF 61

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Dec 2004 13:38:14 -0800 (PST)

------ Forwarded Message
From: Cullen Jennings <fluffy@xxxxxxxxx>
Date: Thu, 09 Dec 2004 12:53:11 -0800
To: <proceedings@xxxxxxxx>
Cc: Jiri Kuthan <jiri@xxxxxxxxx>, Cullen Jennings <fluffy@xxxxxxxxx>
Subject: BEHAVE minutes IETF 61

Behavior Engineering for Hindrance Avoidance WG (behave)

TUESDAY, November 9, 2004, 1415-1515
=====================================

CHAIRS:
Jiri Kuthan <jiri@xxxxxxxxx>
Cullen Jennings <fluffy@xxxxxxxxx>

Below is my summary of the key items with * beside the ones where the author
of the draft needs to go do something.

STUN Update - Jonathan - draft-ietf-behave-rfc3489bis-00

  Added server name attribute to this rev

* Agreed to change support for server change address flag from MUST to
  SHOULD

UDP Unicast Behavior Francois AUDET 15 min - draft-ietf-behave-nat-00

* Change name to have udp in the draft name

* Draft is suggesting to preserver ports. Leave draft same but add text that
  indicates that some security devices may not want to do this to obfuscate
  the traffic but that is outside the scope of behave.

* Port parity preservation can not be replied on and thus is not
  deterministic so we probably don't want it. The application usage document
  needs to discuss how RTP applications that work with behave nats need to
  explicitly signal rtp and rtcp port numbers.

* Port range conclusion: if the host's source port was in the range 0-1023,
  the NAT's source port MUST also be in the same range. If the host's source
  port was in the range 1024-65535, the NAT's source port MUST also be in
  that range

* make sure multihoming is addressed in document

UDP Multicast Behavior Dan Wing draft-wing-behave-multicast-00

  Looks good - people need to read this.

TCP Behavior Discussion

  Most people felt that solutions that relied on spoofing source addresses
  were not the way to go.
 
  Some of the other solutions would be scope creep if we dealt them in this
  WG. They would best be dealt with in MIDCOM or NSIS (in fact may already
  be done :-)

  There was interest in pursing what would be required of the NATs to make
  the the simultaneous open approach reliably work.

More details provided in 3 sets of notes below. Many thanks to Mary Barnes,
Spencer Dawkins, and Alan Johnston for the great notes.

AGENDA: (Last revised Nov. 1)

1. Agenda Bashing, Bluesheets, Note-takers 5 min

2. WG status update Chairs 5 min

3. STUN Update - Jonathan - draft-ietf-behave-rfc3489bis-00

Jonanthan added the "changed attribute" in this revision, and we noticed
that there are some interop issues here (with ICE, it's optional for
servers).

Need to at least document when it's OK to not implement  it.

If I send this to a server that doesn't support this, I get an error
response - is that enough? Actually, error is unrecoverable so we need to
try to avoid the situation. ICE specifies a response code - we should
probably use it.

4. UDP Unicast Behavior Francois AUDET 15 min - draft-ietf-behave-nat-00

Should this filename have UDP? Probably - deadline was  problematic.

Integrates post-IETF 60 decisions

Have had new mailing list discussions (in blue, in the slide  deck) and will
be reflected in the next draft

Document only covers NAT - no Firewall and no ALG. Covers  only UDP Unicast

IP address assignment - "paired, best-effort" assignment is  RECOMMENDED,
"arbitrary" is MUST NOT - but customers have requested  "arbitrary" and then
demanded "sticky" behavior for security-by-obscurity  reasons. We can't make
bad behavior illegal, but we can say what conforms, and  doesn't conform, to
BEHAVE behavior in a BCP.

RTCP/RTP is slightly ugly here, we think (because two source  ports are
involved.  Adding text about problems with current  approaches.

Is BEHAVE for all NATs, or just peer-to-peer NATs? We think  it's for all
NATs, but would love to think about this more.

APPS area multi-homing?

We're adding requirement that well-known source ports MUST  map to
well-known ports at the NAT, other source ports MUST NOT. Can cause
confusion with IKE, for instance (and telnet, and SSH, and ...)

We really like NATs that fail deterministically more than  NATs that fail
non-deterministically.

Preserve parity of UDP ports if possible ("if not running out  of ports with
right parity") - this helps with RTP/RTCP parity. If not  possible - SHOULD
log it? 

Want to allow Inband Refresh as a MAY to allow for  MULTICAST.

SHOULDs and MAYs drive Jonathan nuts, because there's more  behavior that
might happen but can't be counted on.

Any outstanding issues? Is multihoming a hard problem to  solve? We haven't
talked about it in these documents.

5. UDP Multicast Behavior Dan Wing 10 min - draft-wing-behave-multicast-00

IGMP from a host keeps multicast NAT bindings open - don't  need
inside-to-outside packets to refresh bindings

NAT devices become IGMP proxies in this document (IGMP to the  left, PIM to
the right?) 

Not everyone has read this draft...

6. TCP Behavior Nagendra 10 min

How to peer-to-peer TCP connections between two hosts  separated by two
facing NATs. 

Using an external server to forge SYN/ACKs in both directions  to get past
unmodified NATs dropping incoming SYNs? Lots of problems (for  instance,
ingress filtering.) - we should make things like this always  fail!

Port reservation? Requires NAT upgrades on at least one  side.

Should we keep looking at this in BEHAVE?

Boy, it would be easier to adopt IPv6 than require this level  of
infrastructure change.

Cornell has done some of these scenarios - they work through  about 70
percent of NATs, unless you do port prediction.

What are we doing in this WG? We aren't standardizing  anything, we're
trying to define behavior. We're still not sure we can make  TCP work
peer-to-peer across multiple NATs, certainly without changes to  protocols
(NSIS, MIDCOM, etc.). This is scope creep actively  creeping.

7. Open Issues Jiri Kuthan 10 min

8. Other Topics TBD 0 min

9. Next steps Chairs 5 min

-----------------------------------------------------------------

AGENDA: (Last revised Nov. 1)

0. Agenda Bashing, Bluesheets, Note-takers 5 min

1. WG status update Chairs 5 min

2. STUN bis - Jonathan
draft-ietf-behave-rfc3489bis-00
Few changes:
o    Added server attribute to include server name and version.

Issue: supporting change flags
o    The change flas and CHANGED-ADDRESS attribute needed only for detection
o    Detection is now not central to STUN
o    Problem: 
o    Servers still need to support it
o    Problematic in ICE
o    Approach: 
o    Optional in server (SHOULD) (change from MUST)
o    Document scenarios when its OK to not implement it
o    Interop concerns?

Discussion:
o    Cullen: if you sent a request to a server that didn't support this,
you'd get an error back?
o    JR: yes. Error response isn't awfully useful (non-recoverable) It's
more important to document.
o    Cullen: right now if you have a server that does this, the client comes
to the wrong conclusion.
o    JR: ICE spec recommends a particular error response code and consider
whether that is the right one.

Conclusion: Agreed to proposal.

3. UDP Unicast Behavior Francois AUDET 15 min
draft-ietf-behave-nat-00

Discussion:
o    JR: add udp in filename

Status:
o    WG doc
o    Last version was draft-audet-nat-behave-00
o    Integrates decisions made in IETF60 and on the list since then.
o    Presentation also describes new mailing list discussion consensus
reached after current text was submitted.
o    No major outstanding issues.

Changes to scope:
o    Covers only nat
o    Firewall out of scope; only inherent filtering aspects of NAT is in
scope.
o    Covers only UDP unicast
o    UDP multicast in another doc
o    TCP behavior to be in separate doc
o    Application aspects still out of scope (but very important)

IP Address Assignment
o    Multiple IP addresses on external side of NAT
o    IP address pooling:
o    "arbitrary": MUST NOT (Req 2a)
o    "paired, strict" MAY (Req-2b
o    "Paired, best effort" (RECOMMENDED) (REQ-2)
o    Required for gaming and other protocols that don't negotiate IP address
for RTP/RTCP separately
o    Minimize port exhaustion

Discussion:
o    Gregory (Juniper): arbitrary, customers have explicitly asked for this
and have had to do functional modes that are sticky (if you start an appl on
one IP, you keep that same arbitrary address).  As an architect, this was
not likable, but did understand why they need this for their appls,
randomness, security (etc.)  We can say MUST NOT if ?
o    Cullen: different appls originating on different ports, if it was data
from same port on PC client, then it would stay on the same IP (source).
o    Gregory: 5 tuple (application) always stays with the same binding.
It's when it's a new dest or source, it can change.  There are valid
requirements for "arbitary", can we really tell the world "MUST NOT" or
restrict that to BEHAVE compliant only.  At high level there is appl, a
layer lower there is the thing that SW does.  You're telling people that you
must bind SW (source addrs). But, the box in the middle of NW doesn't have
this correlation. Not sure that can be created.
o    Francois: if traffic coming from the same internal IP address, it will
always have the same external IP address binding (while it's active -
simultaneously).
o    Gregory: How does box know if streams are for the same higher level
appl?
o    Francois: they don't.
o    Gregory: some people want to know.
o    Spencer: the decision to violate the RFC is at the endpoints and not in
the network; is that true?
o    Cullen: if source IP and port are the same, the assumption is it's the
same appl 
o    Francois: we assume the binding will be the same.
o    Gregory: semantics clarification: same source address&port. Middle of
NW assumes that any 5 tuple is the same stream. (and that will stay bound).
o    Cullen: stickiness is not on the 5 tuple, but on the source IP address
and port. 
o    Steve C: it's often not the case that things are sent from the same
port.  At the same time seems like the right compromise.  It sounds like
some people won't be satisfied with that.
o    Gregory: what we can't say is that "MUST NOT" isn't applicable.  Need
to say if you want to run these sorts of protocols and use these types of
NATs. Be clear to describe what it is that will work.
o    Jiri: there are different boxes with different objectives. BEHAVE
compliant must comply, although there may
o    Christian H: address and port must map to the same address on the other
side.
o    Cullen: might want to mention that there are occasions when this might
not be so.
o    Christian H: when traffic originates from a certain IP addr and port,
it should go out the same IP address and port.  If you don't want to do
that, then behavior must be explicitly defined.
o    Spencer: is it going to be possible for appls that think they're
compliant. 
o    Gregory: "I love SIP". Can we make sure we're not using the SIP hammer?
All appls don't have the same requirements. Concern over Christian's
statement, don't want to force this compliance if they have other security
requirements. Needs further consideration?
o    Leif: SIP is a good model application. Perhaps should refer to Eric
Nordmark's presentation
o    Cullen: Back Christian's comments.  We are saying if you builds NATs
this way for these applications; won't get rid of those.  ICE is what you
use to figure if you have the NATs you need?Like draft how it is.
o    Christian: Microsoft has been looking for such a recommendation.

Conclusion: text is okay as is (?)

Issue: RTCP=RTP+1
o    No requirement to attempt to preserve the port contiguity rule
o    Mailing list consensus for new text for new release:
o    Explaining that techniques currently used have significant issues with
glare and /or wasteful for non-RTP UDP packets.
o    OK with Magnus (AVT): RTSP impact
o    Separate negotiation must be done by application (out-of-scope of this
document, but very important for application doc)

Cullen: this is an RTP issue; they need changes anyway.  There is no
backwards compatibility issue.
Roni: you need to specify what you need for RTP and RTCP.
Francois: there is another doc for appl aspects.  For certain protocols,
it's already done. 

Conclusion: not covered in this doc.

Issue: Source port Range
o    Current text: MUST not use Well-known (REq-3c)
o    Mailing list: some appls will break with this (RFC 2623)
o    Agreement: if the host's source port was in the range 0-1023, the NAT's
source port MUST also be in the same range. If the host's source port was in
the range 1024-65535, the NAT's source port MUST also be in that range
(REq-3c)

Discussion:
o    Michael Richardson: Is it legal for the NAT to use the same source
port?  
o    Francois: yes.
o    Michael: this has caused problems for IKE. Causes problems for gamers.
Prefer consistent failure.  Does not want non-deterministic.
o    Adam: this looks good, but 1024 range is small.  May need that to be a
SHOULD.  Don't want to reject if you have higher ports available.

Issue: Port Parity preservation
o    Behavior:
o    "yes, best effort" RECOMMENDED (REQ4)
o    "yes, strict": MAY (REQ-4a)
o    "No": MUST NOT (REQ-4b)
o    Respect RTP/RTCP parity convention when possible, without running out
of port unnecessarily
o    Some RFC 3550 has some wording that may cause appls to unilaterally
subtract 1 to an odd RTP port
o    Reasonable and simple to implement.

Discussion:
o    Gregory: should have the ability to log if you don't behave in this
way, so that it can be debugged.
o    Steven C: surprised that people make that interpretation, the text is
clear
o    Cullen: should signal both.  This is exactly the non-deterministic
behavior that we wanted to get rid of.  Will have to signal RTCP port in
devices.
o    Gregory: if we're going to say only keep parity, you should still log
it so people know why app is breaking.

Conclusion: still open issue.

Issue: binding refresh direction
o    Outbound refresh=True: MUST (REQ-6) - no change
o    Inband refresh=TRUE: MAY (REQ-6a) - to allow for multicast, described
in new document

Discussion:
o    JR: why is this a problem.  Why can't outbound rule apply? Why can't
the text stay to just address unicast?
o    Christian: what's wrong with MAY?
o    JR: introduces more non-determinism.
o    Francois: ?
o    JR: ?
o    Christian: those are old appls, so they may work.
o    Dan: music on hold is a non-behave aware application, thus NAT vendor
would want inbound refresh.  One solution might be to have

Conclusion: continue discussion on the list.

Discussion: 
o    Henry S: multihoming: don't see it addressed in these docs?
o    Cullen: we'll make sure it's addressed.

4. UDP Multicast Behavior Dan Wing 10 min
draft-wing-behave-multicast-00

o    IGMP packets from a host keeps multicast NAT binding open - don't need
inside-to-outside packets

o    MUST support incoming multicast of IP protocol

Discussion:
o    Dan: only have received a few comments
o    Joerg: you're not assuming a router in the NW?
o    Dan: the NAT behaves as if it were a host. A residential class NAT that
behaves as a host.
o    Gregory: NATing box is multicast aware and acts as a router on the
other side and the other model is IGMP proxy model.
o    Dan: draft is the latter model, the former wasn't considered in scope.
Conclusion: ?  continue discussion on list - need more feedback

5. TCP Behavior Nagendra 10 min

p2p  behavior behind nats.

Solution 1: No changes to NAT:
o    A&B sends ISN's to S
o    S "determines" external port numbers
o    A&B send SYNs towards each other
o    S generates forged SYN/ACKs

o    Pros:
o    Works without changing NATs
o    Cons:
o    Port# prediction may fail
o    Egress/ingress filtering may block forged packets
o    How portable is SO_REUSEPORT?

Discussion:
o    Gregory: IETF work will make this fail.

Solution 2: No forged packets
o    A&B sends ISN's to S
o    S "determines" external port numbers
o    A&B send SYNs towards each other

o    Pros:
o    Works without changing NATs
o    Cons:
o    Port# prediction may fail
o    Requires NATS to allow packets.
o    How portable is SO_REUSEPORT?

Solution 3: Port Reservation

o    Pros:
o    No port number guessing - works reliably
o    Works even if NATs only on one side are upgraded
o    Client code simpler
o    Port reservation can be implemented as an ALG
o    Cons: 
o    Need to define and deploy a new protocol
o    All NATs need upgrading.

Discussion:
o    Suresh: this work has been covered in MIDCOM already (ford draft)
o    Cullen: yes, this last approach is closer to MIDCOM and NSIS.
o    Christian: UPNP port reservation is available (on many ISPs). Or
overlay IPv6. 
o    Paul Francis: have implemented 1 and 2 (at Cornell). Setup about 12
home boxes. Second one works through about 70%. First works in almost all.
o    Gregory: 3rd option is almost how ALGs work today. The delta is that
nothing singles what to try, thus go deeper in appl layer.
o    JR: getting confused about what we're doing in this WG. Have an
opportunity to define NAT behavior so something can work.  Don't want to
have to make some of these assumptions. If we can change behavior of NATs,
should we do that to facilitate the connectivity; that's what this group
should work on. 
o    Melinda: Feature creep: important problem, but doesn't belong in this
WG.  Don't think that there's anything that can be done.
o    Cullen: If the approaches that only modified NAT behavior, might look
at them. 
o    Melinda: agree someone needs to do the work, but not here.
o    Suresh: One suggestion is that TCP port binding, simultaneous open
would work - applicable to this WG.

6. Open Issues Jiri Kuthan 10 min

7. Other Topics TBD 0 min

8. Next steps Chairs 5 min

-----------------------------------------------------------------

Behave WG Minutes

Cullen Jennings
Jiri Kuthan

Tuesday November 9, 2004

Minute Taker: Alan Johnston

Status:

- first meeting of this WG
- four I-Ds written
- still have some documents not yet written

Agenda Bash

- Chairs Update
- STUNbis
- UDP Unicast
- UDP Multicast
- TCP behavior
- Open issues

No changes to agenda.

STUNbis - Jonathan Rosenberg

- few changes
- added Server attribute
- open issue - supporting change flags

solution: make SHOULD strength for server support

Cullen: OK with this

Resolution: document will be updated for this change.

NAT Behavior Requirements - Francois Audet
draft-ietf-behave-nat-00

suggestion: add udp to the filename
Status: WG document
No major outstanding issues
Changes since last version:

- Some changes to scope
- IP address assignment changes

Greg: Can say MUST NOT on arbitrary assignment if we require protocols to
note that they need this requirement or they will break
Spenser Dawkins: It is a good thing if a failure only affects endpoints, not
core of the network, is it?
Cullen; If same source IP address, then address mapping should be the same.
Greg; Is it 5 tuple?
CUllen: Based on source IP address and protocol number only
Stephen Casner: Different ports are used for RTP vs RTCP, for example
Greg: Can't say MUST NOT do this in a NAT
Cullen: We have consensus on this.
Jiri (individual): Can bulid a security NAT box that doesn't conform to this
requirements
Christian Huitma: People can do anything they want.  Can only say,
preferably the same IP address should be used.
Spenser: OK with all comments.
Greg: Make sure this document doesn't only fit SIP requirements.  Sometimes
there are other requirements
Cullen: Behave applies to NATs, but not Security NATs and Firewall devices
Leif: Other applications besides SIP
Cullen: Draft is OK as is.
Christian: Also like draft

- RTCP=RTP+1 port contiguity

No requirement - out of scope
Cullen: Don't see backwards compatibility issue.
Roni: Not just RTP and RTCP

Application specific documents will address this.

- Source port range

Current text: MUsT NOT use well known range
Mail list agreement: if in well known, mapped port in well known, if
1024-65535, stays in that range
Michael Richardson: Can the port stay the same? If so, causes problems with
IKE.  NAT doesn't know if IKE are for it.
Cullen: Also SSH problems, etc.
Michael Richardson: First gamer gets to play, the second does not.  Rather
have deterministic
Adam Roach: Could be port exhaustion problems due to smallness of lower port
range - don't want to fail because of this.

- Port parity preservation

Current text: preserve if you can (yes, best effort)

Greg: Should log if you don't behave due to port exhaustion - helps
troubleshooting
Stephen: RFC 3550 doesn't say this
Cullen: SHould get rid of this because it is not deterministic.  RFC 3550
does not need to be changed

- Binding refresh direction

Jonathan: Don't know why have this problem.  Just say outbound rule only
applies to unicast.
Christian: Proposal is OK - what is wrong with MAY
Jonathan: Avoid non-determinism - SHOULD or MAY is bad
Dan Wing: Solution is to have document be more explicitly unicast

Take rest of issues to the rest

Behave Multicast - Dan Wing
draft-wing-behave-behave-multicast-00

No open issues
Few have read.

Joerg: Are you assuming a router?
Dan: NAT acts as a host
Greg: NAT can be mulicast aware OR NAT can proxy IGMP
Dan: This is an IGMP proxy device

P2P TCP through NATs - Nagendra Modadugu

Problem statement
Solution 1: no change to NAT, clients connect through a server first, server
forges SYN/ACK
Solution 2; no forged packets if NATs allow incoming SYNs
Solution 3: port reservation - requires port reservation requests between
NATs

All NATs on one side must be upgraded.

Question: There is a midcom draft that discusses this.
Cullen: closer to NSIS than MIDCOM

Cullen: Wrap up.  Do we want to solve this problem in BEHAVE?
Christian: UPnP has not been mentioned, is widely used and deployed in home
NATs.  Or could overlap IPv6 across NAT
Paul Francis: We have implemented 1 & 2 and done testing.  2 works for 70%,
1 worked almost all.
Greg: option 3 is like an ALG
Jonathan: We shouldn't standardize any of these things.  We are defining NAT
behavior.  Don't support forging.
Melinda: I have a similar comment.  This is scope creep.  Important problem
but doesn't belong here
Cullen: Might consider other approaches.

------ End of Forwarded Message