WEDNESDAY, November
8, 2006, 9:00-11:30
Chair: Dan Wing, dwing@cisco.com
Minutes: Gregory M. Lebovitz, gregory.ietf@gmail.com and
Spencer Dawkins, spencer@mcsr-labs.org
WG Status
- RFC editor’s queue – NAT-UDP
- New Doc proposed:
draft-ietf-behave-p2p-state
- Adopt draft-ford-behave-app-04 to meet our Application
milestone?
- Have had a few posts on the list -
other opinions?
- Cullen - authors need to come to the
meeting.
- Philip - like this document, don't
beat the authors up.
- Jonathan - did have text lying
around that didn't end up in any document, couple of pages for
this.
- Dan - looking for
co-author who can come to meetings. Don't have strong consensus to
adopt as WG item at this time. If we adopt this document, will get
strong ICE review.
Multicast, Dan Wing, draft-ietf-behave-multicast-04
- Is this needed?
- Dan Wing, author -- Very few people
seem to be interested in this document, not sure what to do with it. AD
has reviewed, one other reviewer, but nothing in BEHAVE. Do we care?
- Gregory Lebovitz, Juniper – probably
more interesting to Enterprises that are running the NATs and
taking/building the Mcast applications
- – good to have this work. Happy to
have it in the WG if people are willing to come and give comments
- Cullen Jennings – several folks looking
forward to this for IPTV for residential nats.
- Chair (who is also the document
author)- All these are SSM, but no real details need to put into our
documents except from IGMP proxy.
- David Oran – What if SSM source is
on inside of NAT? Someone should think about this before we
decide what to do.
- Francois Audet – is the issue that
we can’t find the problem or that we don’t know if we’ve scoped it
properly? Or people don’t know what we are trying to do?
- Chair – there isn’t really much to
do for this, the document is thin. Not many requirements for it.
- Magnus – maybe only requirement is
need to increment the MAGMA document, implement IGMP proxy.
- Spencer Dawkins – if issue is not
motivation here, is it bad to advance it as individual standards track?
That is allowed.
- Chair, not a bad idea.
- Gregory Lebovitz – maybe we need to
solicit the app makers and the primary users. We’ve heard the
Financials and the IPTV markets/apps shared here. Maybe we need to
brainstorm a list of killer apps, the makers of those apps, and the
verticals that consume them, and go share the work with them. If we
don’t and their apps don’t get through NATs, they’ll be bummed. Perhaps
they just don’t know what we are doing, but would get involved if they
did. Do we have enough energy to pursue them?
- FINGERPRINT /
CRC approach
- Have gotten lots of
excellent comments in review here. ICE connectivity check is out,
FINGERPRINT changed is optional, TCP-based congestion control added in.
- If you know anything
about CRCs, please look at the FINGERPRINT section.
- Cullen - people
stealing iSCSI CRC.
- Randall Stewart – will not find HW
that supports it yet. Good algo from Intel. Cuts processing time down
immensely. But no hw that supports it.
- Jonathon – list seemed to say get
rid of the hash.
- Chair – people didn’t like hash
because was processor slow. Replacing it with something that is equally
slow is not helpful
- Philip matthews (PM) - Pre – header
advantage, choose pre-header with what you want to multiplex against
it. Pre-header needs to just go on the STUN packet. Put some bytes in
front of stun header so stun header doesn’t look like header of the
other packet you have. Put it there so don’t get a match on stun header
- Adam – in order to do that would
have to know the other application
- Philip – likely we could chose one
work in many cases. Mainly need for RTP and SIP.
- Alan – we know share secret and
configuration problem that is application specific. Like this method
(CRC-32 (v.42 polynomial)
- Adam – prefer this to something that
is application protocol specific.
- Jonathon (JR)– like this too. Want
to keep it. There is a section on multiplexing that goes thru three
options, magic cookie, fingerprint, crc. Think we should have one
mechanism.
- Rohan Mahy (RM)– some existing proto
that we want to seamlessly toss stun into. Someone using STUn w/ rtp
and now we are going to add dtls. We want to make sure it doesn’t
clobber the other things there. Backwards
and non-backwards compatible requirements for adding STUN to some
protocol. Can’t change the way framing done, when mux stun and RTP, can
change framing. If we run into some other app where we need it, we can
add the FINGERPRINT option then. I think this is bad engineering to go
so far into the chain to verify this was a STUN packet.
- JR – but this is much better than
SIP over TCP’s framing issues.
- RM – it’s complicated and we don’t
need it.
- DO – is this in a fixed location?
- JR – no. Magic cookie is in fixed
location. It’s a 1/32 probability with some protocols that you would
collide and need to run this check, so not that big of a deal.
- DO – ok. I’m okay with it then.
- Collin Perkins (CP) – this has to be
in a variable location to work.
- JR – really want to be done with
this. Can we hum on this? I’m tired of going over this again and again.
- Chair – hum if this FINGERPRINT
attribute is useful and you want to keep working on it. CONSENSUS to
that it is helpful and to keep working on it.
- TCP Congestion control added
- Initial RTT estimate configurable,
100 ms for fixed broadband
- Retransmit interval doubles after
every xmit (not flatten out)
- Karns’ algorithm for RTT estimation
mentioned
- Number retransmits from 9 to 7
- Any comments? None. Assume people
are fine with it
- New Structure for Message Type
- Bits M11 to M0 is “method”
- C1 to C0 is “class”
- 0: request
- 1: indication
- 2: success response
- 3: error response
- Now can differentiate IANA
attributes. Numeric relationships built into the proto, not need iana
to differentiate
- DM – why embed this here? Better to
just put comment in to say “it’s here for backwards compatibility”
- JR – okay. That makes sense. I’ll do
that.
- Retransmission rules still need
tighter definition
- Servers check for unknown methods and
reject if unknown
- Clarify backwards compatibility for
clients for XOR-MAPPED vs MAPPED, needed for backwards compatibility
- DNS discovery – not pure backwards
compatibility w/ RFC 3489. Main diff: _stun._tcp was for shared secret
before, now for binding usage. _stunpass._tcp
for shared secret now, not defined previously. Not many have deployed
3489 with this feature, so we probably don’t need to worry about it.
Would be
- FA – reason we don’t have the problem
is what?
- JR – because nobody deploying stun
with this shared secret method, WITH DNS. If using IP address, it’s not
a problem. Weren’t worried enough about the attacks to actually use it.
The shared secret method was 10x as hard as the base protocol. I
suggest we keep the new text in the document and call out that it’s not
backwards compatible.
- Gregory – can we reflect in notes that
this is a closed issue?
- JR – will ask in SIPIT, just to make
sure, but will move forward as closed. Robert, can you ask this?
Robert said yes...
- Chair – will last call this version.
All the issues we know we need to address can be fixed in last call, as
nothing is major.
status: ready for technical review and WGLC
- Philip matthews (PM) – presenting, but
not an author. Document editor is on jabber.
- Three main changes since -01, all were
consensus of Montreal
meeting
- Handling of unexpected inbound SYN
packets
- Drop SYN, wait 6 seconds, then
send ICMP Port Unreachable (for diagnostic help) message in reply.
Don’t send ICMP reply if outbound SYN for the connection received w/in
6 seconds
- CJ – is this SHOULD or MUST? If
vendors have option, they probably won’t do it. I thought we decided it
would be a MAY, to ensure that either path vendors use will comply.
Text about the two possible ways is excellent. But only one of the two
ways are “compliant”, and both should be.
- PM – we decided SHOULD in TCPM, so
I’m uncomfortable changing it w/out going back
- CJ – uncomfortable with the text
as is because I don’t think NAT vendors will implement this 6 second
thing.
- Chair – if a NAT configured to
always drop unsolicited incoming SYNs, then it would not be compliant
with the spec as written. Is that your concern CJ?
- CJ – yes
- Chair – the text in the Security
Considerations section may help to clarify this.
- Dan - provide forward linkage?
- CJ – if we put one requirement
here, then put text in Security Considerations section, we confuse
people. Can’t we put explicit text in this section that implementors
can do (a) or (b)?
- PM – we in BEHAVE were fine
without the 6 second thing. It was TCPM and Joe Touch who wanted it upon review. It
was to address their concerns.
- Fernando Gont (FG) – when
responding with such a message, you cannot be sure how a host receiving
ICMP Port Unreachable will take it. Usually sent RESET or drop silently
- Lars Eggert (LE) – if we change
this, since the comment was from TCPM, because it's SHOULD level in
RFC1122, we need to check back with TCPM before we finalize.
- Gregory - as a vendor, we don't
normally send port unreachables, we either send RSET or drop silently.
- Bruce - MAY would give you
"compliant but not fully compliant".
- Dan - will discuss specific text
on the list for this.
- Chair – agreed.
- Remove mention of port preservation
- Used to say “if host’s source port
in range 1-1023, then RECOMMEND that NAT’s source port be in same range”
- All got removed. Now no mention at
all.
- Comments? None.
- Normatively cite BEHAVE-UDP doc
- Previous version did not
- Summarizes some stuff from UDP doc
to make it easier for users
- Remaining Open Issues
- Where put Req-9? Two views:
- 1 - Anything that says ICMP should
go in –ICPM doc,
- 2 - ICMP Request/Response and how
to translate ICMP msg should go into BEHAVE-ICMP. Anything transport
protocol related should go into the transport document.
- CJ – we’ve gone thru this many
times. We made a decision. One doc about this is already in RFC queue.
Why revisiting this?
- DM – We're revisiting this because a
questions came up on mail
list.
- CJ – anyone who doesn’t think option
2 is fine?
- FA – 2 is good.
- Hum – Prefer view 1? Silence. Prefer
2? Lots hums. Consensus for Option 2.. Issue closed.
status: ready
for technical review and WGLC
- Req 1 – ICMP query ID mapping
- Req 2 – ICMP Query Session Timeout
MUST NOT expire < 60 seconds. Recommend to make time configurable.
- Justification: Max
RTT is 4 minutes. Most ICMP apps complete in few seconds. 60 seconds is
pragmatic
- Req3 – ICMP Error Payload Validation
- From discussion on TCPM WG
- NAT SHOULD do following on ICMP
error payload: (a) IP checksum, validate IP checksum, (b) Move past IP
options to get the transport header, (c) Transport checksum validated
- Req 4 – Inbound ICMP error msg
- NAT MUST:
- Revert IP and transport the
headers of the embedded packet to original form, using the matching
mapping
- Leave ICMP error type and code
unchanged.
- ….
- Req5 – outbound ICMP error msg handling
- Revert IP and transport headers of
embedded packet to original, per what is on the outside header, post NAT
- …..
- Conflict between UDP doc and ICMP doc
- UDP doc says ICMP payload SHOULD be
translated and forwarded (section 9, preceding Req12 of UDP draft)
- FA – we have already decided this.
- CJ – this has already been decided.
SHOULD was the WG consensus. And we were to change the ICMP document.
Why does this still come up.
- Chair – WG consensus is SHOULD. UDP
document stands as it. ICMP document will be made to use SHOULD on this
point. This issue is closed now and will not be reopened.
- LE – we do not have IETF consensus
that ICMP is advisory only, we are moving in that direction, but not
there yet. So we have to be careful of how close to that line we come.
- FG – rfc1122 says that ICMP is like
an app protocol in some times. I don’t think we can just ignore that.
Not a decision that this WG can make alone, it is a wider discussion.
w/o the translation, apps may not work.
- PM – given that in UDP spec this is
SHOULD, and we are saying ICMP
- GL – if you don't do translation,
host at other side doesn't know what to do with the packet. We've
gotten TAC calls. This is a realworld problem.
- Philip - UDP, TCP, or both?
- Gregory - TCP primarily.
- Dan - MTU discovery is a lot more
common for TCP, but video guys are starting to do MTU discovery...
- Philip - are we happy with a MUST in
the TCP document?
- Gregory - if you leave it as a
SHOULD in any document, what will happen? Most implementors will, some
won't and will get TAC calls, maybe three years down the road. Up
to WG to decide if that's appropriate for a MUST or a SHOULD. Why would
we not do this?
- Cullen - two questions - if you
forward at all, do you translate (everyone does this), and are you
allowed to drop this silently. Two different questions.
- Lars - no question that you SHOULD
forward it.
- Gregory - "MAY forward, MUST
translate if you do". Security policies differ on forwarding. Don't
write an RFC that prevents people from continuing to drop. Usually when
we have SHOULDs, there's a use case where doing this isn't always the
best thing to do - corner case needs to be described.
- Spencer - was looking at
consistency, not specific recommendation, and Gen-ART reviewers will be
looking for SHOULD explanations.
- Magnus - security posture is
stepping outside our charter. FW is real, but not in our scope.
Why not separate document into ICMP going through/to NAT.
- Chair – SHOULD is probably okay
here, and we need to craft some text to explain the corner case that
makes SHOULD necessary, instead of MUST. Issue closed.
- Gregory - implementers will want to
see this discussion in the TCP document. Can someone explain the
motivation for not forwarding? If we're not talking about security
posture, which is out of scope in the charter, we need another
justification for SHOULD.
- Philip - the slide being shown doesn't represent what is in the TCP document. We are arguing over something that isn't in a document.
- chair - Then we will need to bring this issue to the list.
- Lars - can say that the SHOULD is a
firewall policy issue, that's OK -- just be clear in document.
- Slide 11 – chair decision to adopt the
resolution shown on slide 11. Issue closed
- Slide 12 – Req7 - ICMP hairpinning
support
- Slide 13 – Req8 - when NAT table full,
SHOULD send ICMP error code 13
- Dan pointed out this was an IP requirement; do we care? (WG says it's okay)
- Slide 14 – Req9 – NAT MUST conform to
basic RFC1812 requirements
- Chair : this is not really ICMP
flowing thru the NAT, it’s packets that are generated based on IP
issues in general. Should we have an IP document separately?
- GL – how about if we order this
document with two different sections: one for ICMP flowing thru the Nat
and another for times when ICMP either needs to terminate to the NAT or
be generated from the NAT. We could do the same for the TCP and other
docs. And IF we find down the road that there is so much general IP
stuff in those like sections across the documents, we can pull them out
into their own document. But for now, we keep the text here, in a
specific section, in ICMP.
- LE – likes idea that we reorder the
document to define Thru-ICMP issues and another for ICMP listen and
generate occasions.
- PM – work by Ron Bonica on
extenstions to ICMP in order to support more error handling for MPLS.
- FG – we are intending to do some
tests in the coming months to see if the new ICMP messages will break
anything. My personal opinion is I’m not sure we need to spend a lot of
time on it.
- Chair – it’s a BCP being worked on
today. It’s not even a practice today. We can’t focus too much on it.
If it comes around, we can do a –bis. It’s an important thing to keep
an eye on. Thanks for bringing it up.
- PM- in slide 13 – there are
situations where the ICMP13 may not be actually correct, as in the case
where if the new flow comes in and the table is full, it may release an
older entry to make space for the new entry, then essentially kill
prematurely the older entry.
- GL – it is a real world reality
today that this is an option for configuration. Many, by security
policy, do not want the hosts either on inside or outside to know when
their flow tables are full, or when the connection is explicitly
denied. Most just prefer to silently drop those flows. I give this to
you as data, not propose any specific way you want your text to
represent it.
- Chair – we can leave it as a SHOULD,
and we’ll put in the reasons why one might not want to do it, either in
security considerations section or whatever.
- Chair – Per Lars' suggestion, we
will ask authors to re-order the sections for
ICMP packets going through vs generated/terminated by the NAT, make the
other consensus changes and
rev and present for WGLC.
status:
adopt as working group document?
- This draft was to be done in 2004.
Finally getting done
- From 3489 to 3489bis
- Results are not reliable, and only
give the current state of things. You cannot trust that things won’t
change over time, or over load, or some other axis.
- JR – we need to be careful about
apps being designed around this today, in order to change the defaults
or other application operating modes. This document is diagnostics
only. We need to be very super clear about that.
- Bruce Lowekamp (BL) – justification
for why we need to use this draft for p2psip creating
- JR – let’s not do p2p sip here.
Let’s leave this as diagnostics
- GL – should we go further and be
explicit about being careful if you in fact use it for deciding
application modes?
- Derek MacDonald (DM) – we’ll
strengthen the text to make it clear
- Usage discovery issue – slide 4
- SRV Target – yes, but target should
point to same port as binding usage
- Multiplexing – draft used empty
OTHER-ADDRESS, new proposal add a new OTHER-ADDRESS-REQUEST optional
attribute to request server respond w/ OTHER-ADDRESS. This is for
backwards compatibility to 3489
- JR – There's another solution to
this. Alternative is running on same port and always returning
CHANGE-ADDRESS - for backwards-compatibility, must ignore mandatory
parameters that are defined in RFC 3489. Issue is that bis client that
gets this response will drop the response. I'm totally confused about
why we have another attribute that does the same thing.
- BL – the CHANGE-ADDRESS (from 3489)
was confusing. Replace it with OTHER-ADDRESS-REQUEST; just a name
change.
- Summary – bandwidth of always
sending back is not material, this is a diagnostic. Will change the
text accordingly
- RESPONSE- ADDRESS security (slide 5)
- Draft says server must maintain
state to only follow response-address if a previous request was
received from that address
- CJ – add a timer attribute to allow
enough time for the hosts to respond so that the NAT state entry stays
open long enough to actually get the answer
- JR & DM – discussion about
whether or not needed. Decision, keep the state. Does it work
- Add working group item? Hum – strong
for. None against. Doc will proceed as a WG item. It’s not on charter /
milestones today, but it will be added.
status: separate from ICE, or
integrate into
Application milestone document?
- JR – this is app design guidelines.
How about if we charter to create that document and put this text,
along with other text around it in STUN all in one document?
- Xavier Marjou (speaker, XM) – take to
list.
- Chair – question of which mechanisms
might be best asked in AVT
- FA – good to ask AVT for sure. But we
should discuss here
- Magnus – both groups working on it
- Chair – consensus to fold this into
application document, per JR’s proposal. Will figure out what to do on
list.
- FA – support. Think it’s a good idea.
But do we have an editor for that, will it get done? I don’t want to
send this to dev/null.
- PM – in our BEHAVE app document are we
the best place to have that discussion?
- chair - don't have a clear decision on
what to do, will work to figure out where this goes.
status:
adopt as working group document?
- Cisco explicitly stated IPR on this
work.
- Embed STUN in servers in NAT to enable
STUN to control the NAT. Going to have lots of STUN traffic
coming in SIP Outbound proxy. ICE can discover optimal path when there
are nested NATs. Embed the STUN server in the NAT to deal with this?
Bootstrap them off public STUN servers, and ... If you walk
backwards, you can discover all the NATs. Limited functionality
helps with security problems - only refreshing a binding that's already
there.
- Note: WG ran over time and this preso
was rushed into <10 minutes of over time.
- Magnus - same address space in two
NATed domains?
- JR -- Doesn't work with reuse of
addresses on both sides of a NAT, doesn't work with symmetric NATs.
- RM – read draft and like it. One
issue, but we can figure it out. Like to document when might this
really happen (the nested overlatpping nat condition) so that people
know how unlikely it really is to match the EXACT IP address. Inclined
to caveat this but keep working it.
- FA – think great idea. Want to explain
a bit more detail about where and when to use this. Not a replacement
for other methods we’ve built. But a few use cases where this is really
useful. If we had a use case that shows the most obvious example, it
would help a lot.
- JR- meant to solve the binding refresh
problem we have. Everything else in Behave and ICE works, except this.
It’s complicated, but it works.
- Magnus Westerlund (MW) – do you
refresh to all of the proxies on the path?
- JR – think so, but…. As long as
refresh intervals are ….
- Markus Isomaki (MI) – if we had some
mechanism to learn what the timeout is and set the timeout to be as
long as we want, this would be really good. If we had this, candidates
could do this BEFORE doing any invites, and thus make ICE much faster
to connect calls.
- JR – Yes, those are good points. Think
WiFi
cell phone behind home NAT, would have to push keep alive every 10
seconds, even with SBC. This would reduce this a LOT.
- Will keep working on it on list.
Adjourn