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?

STUNbis, Jonathan Rosenberg - draft-ietf-behave-rfc3489bis-05

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.

TCP, Philip Matthews - draft-ietf-behave-tcp-02

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.

ICMP, Fernando Gont, draft-ietf-behave-nat-icmp-01

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.

NAT Behavior Discovery, Derek MacDonald - draft-macdonald-behave-nat-behavior-discovery-00;

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.

Application Keepalive for NATs, Xavier Marjou - draft-marjou-behave-app-rtp-keepalive-00

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.

NAT Control STUN Usage, Jonathan Rosenberg - draft-wing-behave-nat-control-stun-usage-00