From fluffy@cisco.com Thu, 15 Jul 2004 17:15:16 -0700 (PDT) From: Cullen Jennings Date: Thu, 15 Jul 2004 17:15:16 -0700 (PDT) Subject: [Ietf-behave] Test 1 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Test 1 From spencer@mcsr-labs.org Wed, 28 Jul 2004 04:47:04 -0700 (PDT) From: "Spencer Dawkins" Date: Wed, 28 Jul 2004 04:47:04 -0700 (PDT) Subject: [Ietf-behave] As if NATs weren't enough... Message-ID: <3aa301c47498$b7b6fb90$0200a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain This is a question, not a suggestion - it seems to me that a lot of what http://www.ietf.org/ietf/04aug/behave.txt says about NATs is also true of firewalls (disruptive and ill-defined enough that we don't know how to accommodate them) - any chance of firewalls being in scope for BEHAVE? (Or do we ignore middleboxes that break connectivity if they don't translate IP addresses?) Spencer From audet@nortelnetworks.com Wed, 28 Jul 2004 09:44:42 -0700 (PDT) From: "Francois Audet" Date: Wed, 28 Jul 2004 09:44:42 -0700 (PDT) Subject: RE: [Ietf-behave] As if NATs weren't enough... Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D211A3F119@zsc3c030.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] As if NATs weren't enough... Yeah, we are covering Firewall behavior as well in the BEHAVE draft. In fact, distinguising between firewall and nat behavior is one of the key point. I'm not sure why it wasn't included in the Charter. Cullen? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] > Sent: Wednesday, July 28, 2004 04:48 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] As if NATs weren't enough... > > > This is a question, not a suggestion - it seems to me that a > lot of what http://www.ietf.org/ietf/04aug/behave.txt says > about NATs is also true of firewalls (disruptive and > ill-defined enough that we don't know how to accommodate > them) - any chance of firewalls being in scope for BEHAVE? > > (Or do we ignore middleboxes that break connectivity if they > don't translate IP addresses?) > > Spencer > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinf> o/ietf-behave > > From jiri@iptel.org Fri, 30 Jul 2004 18:45:05 -0700 (PDT) From: Jiri Kuthan Date: Fri, 30 Jul 2004 18:45:05 -0700 (PDT) Subject: [Ietf-behave] Fwd: [Serusers] Broken "SIP Aware" Router Message-ID: <6.0.3.0.0.20040731022442.047fce80@localhost> MIME-Version: 1.0 Content-Type: text/plain FYI: here is a real-world testimony which imho captures deployment issues with ALGs and which was reported by a SIP provider on some of iptel's mailing lists. Whereas this is just a single report, we experienced similar issues with other similar products too. I don't think these problems have to do with a young implementation -- I believe they are caused inherently by ALG design. IMHO ALGs are prone to all kind of errors: interoperability (ALGs are likely to miss some novel application aspects), security (ALGs can't handle secured traffic) and generally software-engineering (i.e., increased complexity, difficult troubleshooting, taking care of firmware upgrades). -jiri ---------------------------------- We have started having problems with customers in ********'s ADSL network. New customers are being given the +++++++'s ADSL modem which appears to be "SIP Aware". But the implementation is terribly broken. The symptoms are that SIP INVITES cannot penetrate the NAT on the Modem even though we have a permanent Keep-Alive from the inside (every 15 seconds). Furthermore when the customer tries to make a call, the modem changes the source port of every single packet of the dialog. Thus breaking the SIP dialog completely. Our interim solution was to setup these customer on an alternate server listening on a different port. For everybody's reference the modem version is: ++++++++ ----------- and the Software is: 03.00.61 I have tried to contact +++++++++ directly but they have not answered. I hope this is not something thats going to start happening with all modem manufacturers or else were going to have loads of trouble. From gregory-ietf@earthlink.net Tue, 3 Aug 2004 16:50:37 -0700 (PDT) From: Gregory M Lebovitz Date: Tue, 3 Aug 2004 16:50:37 -0700 (PDT) Subject: [Ietf-behave] area and advisor Message-ID: <5.1.1.6.0.20040803163130.0175dc70@popd.ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain I did not see the AREA and the advisor listed on the Charter and Agenda. Pls advise, +++++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks W - +01 (1) 408 543 8002 From jiri@iptel.org Tue, 3 Aug 2004 19:07:49 -0700 (PDT) From: Jiri Kuthan Date: Tue, 3 Aug 2004 19:07:49 -0700 (PDT) Subject: Re: [Ietf-behave] area and advisor In-Reply-To: <5.1.1.6.0.20040803163130.0175dc70@popd.ix.netcom.com> Message-ID: <6.0.3.0.0.20040804040419.0440bec0@localhost> MIME-Version: 1.0 Content-Type: text/plain Transport Area, with Jon Peterson as transport area advisor. -jiri At 01:50 AM 8/4/2004, Gregory M Lebovitz wrote: >I did not see the AREA and the advisor listed on the Charter and Agenda. Pls >advise, > > >+++++++++++++++++++++++++ >IETF-related email from >Gregory M. Lebovitz >Juniper Networks >W - +01 (1) 408 543 8002 > >_______________________________________________ >Ietf-behave mailing list >Ietf-behave@xxxxxxxxxxxxxxxxxxx >https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jiri Kuthan http://iptel.org/~jiri/ From spencer@mcsr-labs.org Tue, 3 Aug 2004 23:15:46 -0700 (PDT) From: "Spencer Dawkins" Date: Tue, 3 Aug 2004 23:15:46 -0700 (PDT) Subject: [Ietf-behave] Thinking about the BoF Message-ID: <019b01c479ea$7a29bb80$fb828182@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain Dear All, I've gotten a chance to think more about BEHAVE since the BoF - I'd only heard of BEHAVE about a week or so back, so did have time to read drafts, but not to think, prior to the BoF. Thanks, Cullen and Jiri, for taking this on, and Jon, for chartering the BoF. Nice work. Cullen and Francois have a lot of interesting and important observations in draft-audet-nat-behave-00.txt - definitely "Son of RFC 2993", based on more experience with more brain-damaged NATs. We talked about pulling out "identifying the problems" as a first milestone, to be used as input into the "don't do these things" milestone - a separate draft makes sense to me. I'm really seeing this work on a balance beam. I agree with Melinda that the target environment is, and should be, residential NATed networks. I agree with Jonathan that we need BCPs - this is what the NAT working group output was missing, because they produced Informational RFCs. I agree with Brian that the dates offered for the proposed BCPs are extremely aggressive, and are likely to be at least one or two IETF cycles later for any non-UDP protocol. The question is, can we get enough BCPs out before a huge number of residential NATs are deployed that won't be upgraded for five years? For extra credit, remember that the dates in the proposed charter are "working group forwards to IESG" dates, right? So if you want an RFC to use as a clue-by-four, that comes later. One other item - I realize that, politically, we don't NAT IPv6, but I'm having a really hard time swallowing "we made a real mistake when we didn't issue BCPs for IPv4 NATs in 1997, and we're not repeating the same mistake again by not issuing BCPs for IPv6 NATs in 2005/2006". If you tell me that the BCP for IPv6 NAT is that we don't do it at all, great - we still need to issue a BCP that says this, instead of making statements in BoFs, WGs, and hallways. If we're looking at agressive milestones, getting started would be a good thing. Can Cullen and Jiri send an updated milestone list, so we can start volunteering? I'm expecting to see an UDP document called out explicitly, for example. But we need to *not* wait for a working group to descend from on high, if we're going to make a published BCP anytime in 2005. My notes follow - hope they are helpful. Spencer AGENDA: (1) Agenda bashing (5 minutes) (2) Problem Statement, Scope Overview, and Charter (30 mins) Lots of NATs, especially in residential environments, and a lot of variety in how they work - and we can't predict or detect how they will work, on any given network path. This creates problems and makes it harder to deploy end-to-end applications. Think about what's broken and do a BCP about appropriate behaviors for NATs. Probably have to characterize NATs, give application developers NAT clues, and don't make IPv6 transition more difficult. Milestones are really aggressive, especially for a BCP. We have more operational experience, but we have more deployed residential NATs. Maybe looking at Mar 06, more likely than Mar 05 - Mar 05 is probably achievable for UDP, maybe not for everything. Is developing multiple documents, per protocol, OK? We think so. UDP could become a template for other protocols (DCCP, etc.). Should we explicitly state our expectation that this work will lessen the need for media relays? What other protocols? ICMP? ESP? Multicast (and how much work is required for multicast? And do we have enough operational experience to do NATs?)? Not looking at firewalls or at ALGs - this really will be TSV work, so these topics are clearly out of scope - anything that involves embedded addresses. Is RTP out of scope? Already covered when it's UDP-encapsulated. We' ll include examining transport payloads as out-of-scope. Need to wordsmith this carefully in the charter. Should some protocols be handled in protocol working groups? Break up, do a template, doesn't matter who actually writes what where after that? But does this cause inter-working group dependencies? And would the other working groups have people willing to contribute cycles on this topic? Don't make too many assumptions in the charter - do some investigation - maybe even the list of protocols should be "after some thought". What's broken enough that we know how to fix? Do we have to do protocol-by-protocol? Can't we provide general guidelines? Where can we collect "how to get protocol X through NATs" lore from protocol working groups? (3) Behavior Recommendations (15 mins) draft-audet-nat-behave-00.txt Co-authors (Nortel and Cisco) discovered they were drafting similar guidance for NAT/FW vendors for peer-to-peer media. NAT/FW vendors don 't really WANT to break VoIP or gaming, so they want this guidance. Terminology is confusing (at best), and we need to provide simple requirements suitable for consumer-grade NAT/FWs. Draft separates firewall behavior from NAT behavior - this conflation contributes to the confusion. Need some description of firewall behavior, but needs to be the minimum (not policy level aspects). Probably need a different word to avoid confusion - but make it a new term, not a redefinition of existing terms. And NATs aren't NATs, they are NAPTs. Other behaviors matter, too (hair-pinning, determinism, ICMP, fragmentation, TCP, multicast/IGMP). Determinism - NAT behavior is hack-upon-hack - no design at all, just debugging to solve specific problems. Why will anybody listen to the IETF BCP on NATs now? This is like making a BCP on mugging people. NAT vendors have a lot of intellectual property tied up in doing things the way they do things now. This BoF is driven by VoIP people folks, not by NAT folks, so may not be effective when the work is done. Residential NATs are probably easier, because they have less functionality, but NAT happens "inside the box" - no incentive for them to even come to the IETF. This isn't about mugging, it's about sex education. People are going to do this anyway - help make things safe. Abstinence-only is not a winning strategy. We didn't provide an alternative to NAT when people did NATs. We have representatives from 75% of the NAT product vendors in the world. They do have an incentive to do this stuff. Implementers get creative in the absence of standards. You've got to do this, or people will guess, and guess inconsistently. We should have done this two years ago. If we don't tell them what to do, there' s no chance they will do what we didn't tell them to do. Clearly defined documents attract implementers. We need to make it clear that we're talking about IPv4 NATs. We need to provide a discovery mechanism so people can tell a device does what we think they should do. If we say "no NATs in IPv6", are we setting ourselves up for another round of failure? IPv6 could be deployed without these problems - hopefully this will happen. What mailing list? It's in the charter. Deployed NATs won't be changed. Can we also include PROTO-41 forwarding? (4) Summary and conclusions (10 minutes) Hmmm in favor? Room sense is "yes". From mshore@cisco.com Wed, 4 Aug 2004 09:50:37 -0700 (PDT) From: Melinda Shore Date: Wed, 4 Aug 2004 09:50:37 -0700 (PDT) Subject: Re: [Ietf-behave] Thinking about the BoF In-Reply-To: <019b01c479ea$7a29bb80$fb828182@DFNJGL21> Message-ID: <5B5EEBCE-E636-11D8-916E-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Wednesday, August 4, 2004, at 02:15 AM, Spencer Dawkins wrote: I'm really seeing this work on a balance beam. I do, too. NAT behavior is inside-the-box, and I think the line here may lie somewhere in the vicinity of external effects (to what extent is NAT behavior surprising/disruptive and unpredictable?). I'm concerned about interest in deep (relatively) packet-peeking for two reasons. The first is that it may cross the line into implementation concerns and proprietary technology. The second concern is, I think, more compelling, and that's that specifying packet inspection behavior obviously assumes the ability to do so, which in turn implies that the data of interest are unprotected. I'm not sure the IETF would want to publish a BCP that says "first, make sure the data of interest are in the clear." Melinda From bashandy@cisco.com Wed, 4 Aug 2004 11:49:47 -0700 (PDT) From: Ahmed Bashandy Date: Wed, 4 Aug 2004 11:49:47 -0700 (PDT) Subject: Re: [Ietf-behave] Thinking about the BoF In-Reply-To: <5B5EEBCE-E636-11D8-916E-000A95E35274@cisco.com> Message-ID: <4111301D.3000303@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I do agree that peeking into the packet can a bit dangerous. However, we still need to do it. We can put some restrictions on the depth of the category of packets to be be peeked into. For example, we can say we will not look deeper that L4 and will will not look into payloads unless it is a payload of a well-known protocol (e.g. OSPF, RIP, BGP, IGMP, PIM,...) Such restriction can be outlined in a requirement document for example Thanks Ahmed Melinda Shore wrote: On Wednesday, August 4, 2004, at 02:15 AM, Spencer Dawkins wrote: I'm really seeing this work on a balance beam. I do, too. NAT behavior is inside-the-box, and I think the line here may lie somewhere in the vicinity of external effects (to what extent is NAT behavior surprising/disruptive and unpredictable?). I'm concerned about interest in deep (relatively) packet-peeking for two reasons. The first is that it may cross the line into implementation concerns and proprietary technology. The second concern is, I think, more compelling, and that's that specifying packet inspection behavior obviously assumes the ability to do so, which in turn implies that the data of interest are unprotected. I'm not sure the IETF would want to publish a BCP that says "first, make sure the data of interest are in the clear." Melinda _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From jordi.palet@consulintel.es Wed, 4 Aug 2004 22:42:39 -0700 (PDT) From: "JORDI PALET MARTINEZ" Date: Wed, 4 Aug 2004 22:42:39 -0700 (PDT) Subject: Re: [Ietf-behave] Thinking about the BoF In-Reply-To: <019b01c479ea$7a29bb80$fb828182@DFNJGL21> Message-ID: <1e2901c47aae$fd772a80$3f838182@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain Hi all, Fully agree, specially with the point of making NOW a BCP for no-NAT with IPv6. We should clearly state that translation is BAD, there is no need for doing that, it breaks things, and consequently it MUST be avoided. I will even say much more and in a much stronger way: Any product in the market that does IPv6 to IPv6 translation, will not follow the BCPXXXX, is not IPv6 complaint, and consequently should be excluded from interoperability test. Should be clearly perceived by the market (including public and private tenders) as something not-to-be purchased. Question. Is this within the scope of this WG (assuming it becomes a WG) ? If not, where this work need to be developed ? I will be happy to volunteer for that. Anyone else to help ? When we start ? Regards, Jordi ---- Original Message ---- From: "Spencer Dawkins" To: "IETF Behave Mailing List" Sent: Tuesday, August 03, 2004 11:15 PM Subject: [Ietf-behave] Thinking about the BoF > Dear All, > > I've gotten a chance to think more about BEHAVE since the BoF - I'd > only heard of BEHAVE about a week or so back, so did have time to read > drafts, but not to think, prior to the BoF. > > Thanks, Cullen and Jiri, for taking this on, and Jon, for chartering > the BoF. Nice work. > > Cullen and Francois have a lot of interesting and important > observations in draft-audet-nat-behave-00.txt - definitely "Son of RFC > 2993", based on more experience with more brain-damaged NATs. We > talked about pulling out "identifying the problems" as a first > milestone, to be used as input into the "don't do these things" > milestone - a separate draft makes sense to me. > > I'm really seeing this work on a balance beam. I agree with Melinda > that the target environment is, and should be, residential NATed > networks. I agree with Jonathan that we need BCPs - this is what the > NAT working group output was missing, because they produced > Informational RFCs. I agree with Brian that the dates offered for the > proposed BCPs are extremely aggressive, and are likely to be at least > one or two IETF cycles later for any non-UDP protocol. The question > is, can we get enough BCPs out before a huge number of residential > NATs are deployed that won't be upgraded for five years? > > For extra credit, remember that the dates in the proposed charter are > "working group forwards to IESG" dates, right? So if you want an RFC > to use as a clue-by-four, that comes later. > > One other item - I realize that, politically, we don't NAT IPv6, but > I'm having a really hard time swallowing "we made a real mistake when > we didn't issue BCPs for IPv4 NATs in 1997, and we're not repeating > the same mistake again by not issuing BCPs for IPv6 NATs in > 2005/2006". If you tell me that the BCP for IPv6 NAT is that we don't > do it at all, great - we still need to issue a BCP that says this, > instead of making statements in BoFs, WGs, and hallways. > > If we're looking at agressive milestones, getting started would be a > good thing. Can Cullen and Jiri send an updated milestone list, so we > can start volunteering? I'm expecting to see an UDP document called > out explicitly, for example. But we need to *not* wait for a working > group to descend from on high, if we're going to make a published BCP > anytime in 2005. > > My notes follow - hope they are helpful. > > Spencer > > AGENDA: > > (1) Agenda bashing (5 minutes) > > (2) Problem Statement, Scope Overview, and Charter (30 mins) > > > > Lots of NATs, especially in residential environments, and a lot of > variety in how they work - and we can't predict or detect how they > will work, on any given network path. This creates problems and makes > it harder to deploy end-to-end applications. > > > > Think about what's broken and do a BCP about appropriate behaviors for > NATs. Probably have to characterize NATs, give application developers > NAT clues, and don't make IPv6 transition more difficult. > > > > Milestones are really aggressive, especially for a BCP. We have more > operational experience, but we have more deployed residential NATs. > Maybe looking at Mar 06, more likely than Mar 05 - Mar 05 is probably > achievable for UDP, maybe not for everything. > > > > Is developing multiple documents, per protocol, OK? We think so. UDP > could become a template for other protocols (DCCP, etc.). > > > > Should we explicitly state our expectation that this work will lessen > the need for media relays? > > > > What other protocols? ICMP? ESP? Multicast (and how much work is > required for multicast? And do we have enough operational experience > to do NATs?)? > > > > Not looking at firewalls or at ALGs - this really will be TSV work, so > these topics are clearly out of scope - anything that involves > embedded addresses. > > > > Is RTP out of scope? Already covered when it's UDP-encapsulated. We' > ll include examining transport payloads as out-of-scope. Need to > wordsmith this carefully in the charter. > > > > Should some protocols be handled in protocol working groups? Break up, > do a template, doesn't matter who actually writes what where after > that? But does this cause inter-working group dependencies? And would > the other working groups have people willing to contribute cycles on > this topic? > > > > Don't make too many assumptions in the charter - do some > investigation - maybe even the list of protocols should be "after some > thought". What's broken enough that we know how to fix? > > > > Do we have to do protocol-by-protocol? Can't we provide general > guidelines? > > > > Where can we collect "how to get protocol X through NATs" lore from > protocol working groups? > > > > (3) Behavior Recommendations (15 mins) > > draft-audet-nat-behave-00.txt > > > > Co-authors (Nortel and Cisco) discovered they were drafting similar > guidance for NAT/FW vendors for peer-to-peer media. NAT/FW vendors don > 't really WANT to break VoIP or gaming, so they want this guidance. > > > > Terminology is confusing (at best), and we need to provide simple > requirements suitable for consumer-grade NAT/FWs. > > > > Draft separates firewall behavior from NAT behavior - this conflation > contributes to the confusion. > > > > Need some description of firewall behavior, but needs to be the > minimum (not policy level aspects). Probably need a different word to > avoid confusion - but make it a new term, not a redefinition of > existing terms. And NATs aren't NATs, they are NAPTs. > > > > Other behaviors matter, too (hair-pinning, determinism, ICMP, > fragmentation, TCP, multicast/IGMP). Determinism - NAT behavior is > hack-upon-hack - no design at all, just debugging to solve specific > problems. > > > > Why will anybody listen to the IETF BCP on NATs now? This is like > making a BCP on mugging people. > > > > NAT vendors have a lot of intellectual property tied up in doing > things the way they do things now. This BoF is driven by VoIP people > folks, not by NAT folks, so may not be effective when the work is > done. Residential NATs are probably easier, because they have less > functionality, but NAT happens "inside the box" - no incentive for > them to even come to the IETF. > > > > This isn't about mugging, it's about sex education. People are going > to do this anyway - help make things safe. Abstinence-only is not a > winning strategy. > > > > We didn't provide an alternative to NAT when people did NATs. > > > > We have representatives from 75% of the NAT product vendors in the > world. They do have an incentive to do this stuff. > > > > Implementers get creative in the absence of standards. You've got to > do this, or people will guess, and guess inconsistently. We should > have done this two years ago. If we don't tell them what to do, there' > s no chance they will do what we didn't tell them to do. > > > > Clearly defined documents attract implementers. > > > > We need to make it clear that we're talking about IPv4 NATs. > > > > We need to provide a discovery mechanism so people can tell a device > does what we think they should do. > > > > If we say "no NATs in IPv6", are we setting ourselves up for another > round of failure? IPv6 could be deployed without these problems - > hopefully this will happen. > > > > What mailing list? It's in the charter. > > > > Deployed NATs won't be changed. Can we also include PROTO-41 > forwarding? > > > > (4) Summary and conclusions (10 minutes) > > > > Hmmm in favor? Room sense is "yes". > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From gih@apnic.net Thu, 5 Aug 2004 08:00:44 -0700 (PDT) From: Geoff Huston Date: Thu, 5 Aug 2004 08:00:44 -0700 (PDT) Subject: Re: [Ietf-behave] Thinking about the BoF In-Reply-To: <019b01c479ea$7a29bb80$fb828182@DFNJGL21> Message-ID: <6.0.1.1.2.20040806004004.02027ec0@localhost> MIME-Version: 1.0 Content-Type: text/plain Question. Is this within the scope of this WG (assuming it becomes a WG) ? well its not in the proposed charter, nor do I understand that there is a compelling reason to head off into this space in the context of this chartered work. I would advocate to the group not to add this into the behave proposed charter. If not, where this work need to be developed ? I will be happy to volunteer for that. Anyone else to help ? When we start ? I suppose that the previous question (Where do you work? ) needs to be answered first to establish a place in which to do the second set of questions in the context of the IETF. regards, Geoff From jiri@iptel.org Thu, 5 Aug 2004 14:10:23 -0700 (PDT) From: Jiri Kuthan Date: Thu, 5 Aug 2004 14:10:23 -0700 (PDT) Subject: Re: [Ietf-behave] Thinking about the BoF In-Reply-To: <019b01c479ea$7a29bb80$fb828182@DFNJGL21> Message-ID: <6.0.3.0.0.20040805163725.02024a00@localhost> MIME-Version: 1.0 Content-Type: text/plain At 08:15 AM 8/4/2004, Spencer Dawkins wrote: [...] >If we're looking at agressive milestones, getting started would be a >good thing. Can Cullen and Jiri send an updated milestone list, so we >can start volunteering? > I'm expecting to see an UDP document called >out explicitly, for example. But we need to *not* wait for a working >group to descend from on high, if we're going to make a published BCP >anytime in 2005. We will post an update soon. I think there was good acceptance to split the work by protocols and begin with UDP, so the update should reflect it. Thank you for your notes, -jiri From jiri@iptel.org Thu, 5 Aug 2004 17:18:19 -0700 (PDT) From: Jiri Kuthan Date: Thu, 5 Aug 2004 17:18:19 -0700 (PDT) Subject: [Ietf-behave] unrevised behave bof minutes Message-ID: <6.0.3.0.0.20040806020807.01c70268@localhost> MIME-Version: 1.0 Content-Type: text/plain Here are unrevised behave bof minutes, courtesy of Alan Johnston. If people think, there is something missing or worth fixing, let me please know. -jiri --------- BEHAVE BOF (Behavior Engineering for Hindrance AVoidancE) Chairs: Cullen Jennings, Jiri Kuthan Scribe: Alan Johnston Time and date: IETF 60, Aug 04th 2004 Agenda Bash: no comments. ------ Problem Statement - Cullen NATs! Proposal: BCP for NAT vendors, How to characterize, etc. Consistent with UNSAF Goals & Milestones presented (includes possible revisions to STUN) Ed Levinson: "What is broken" is missing from milestones. Brian Carpenter: Draft is good but why BCP instead of informational? Informational easier. Cullen: Agreed we need to discuss this. Spenser Dawkins: Limited to UDP? Cullen wants comments on this. Personal opinion not step into firewall area. Spenser: Can't fix ICMP Jonathan Rosenberg: Strongly in favor of BCP due to inconsistency in deployed devices Rohan Mahy: Charter page comments page 2, should have milestones on a per protocol basis. Alain Durand: Overlap with V6ops charter? Cullen: There are similarities, don't want to overlap (v6/v4 NATs). May feed requirements to V6ops group. Alain: Do you mean RFC 3056 or general v6/v4 translation? Cullen: RFC 3056 only. Alain: Shouldn't limit our scopt to this. Jon: IESG aware of overlap potential. Won't do overlap. Not intention to develop transition mechanisms. Alain: Why has v6/v4 been standardized in v6ops? Brian: Take out parenthetical phrase (6to4) Jiri: OK Spenser: NAT WG took a long time. Rohan: More operational experience now. Also wants BCP strength even if it takes longer. Cullen: We do have operational experience. We won't invent new ways, just look at existing. Jonathan: Can move out dates or split the problem into smaller chunks. UDP-centric nature in document is due to VoIP experience. March '05 should be achievable. John Warner: Problem of pointing vendors at multiple document? Cullen: Feel it is OK. Already thousands. Mark Handley: Jonthan's idea is good - should have templates and continuing document series. Henry Sinnreich: Will this reduce the need for media relays in VoIP? Jiri: Expectation is yes. Cullen: All documents say this helps UDP work without relays. Jonathan: For example STUN doesn't know NAT behavior. As this is deployed, STUN will work more often. Get rid of relays. Cullen: What protocols are important? UDP, TCP, ICMP perhaps? Others? Gregory Lebovitz: ESP - IKE on UDP works, ESP does not. We use tricks today to solve. There are a number of tricks. Spenser: How do we come down on ALGs? Jon: Yes, but this is not the point of BOF. About IKE, we aren't IKE experts, we need to understand requirements. Gregory: Not IKE, but ESP is the problem. Ackman: multicast is next in importance Cullen: More specifics? Ackman: Join using source address. Interdomain behaviors. Don't think it works today. Cullen: Question is do we have operational experience to do this as BCP Melinda Shore: Any problem where solution space is ALG is out of scope of this WG Jonathan: Feel more strongly we need to break it into pieces. Separate multicast joining from routing. Collin Perkins: Is RTP traversal out of scope. Jonathan; Yes. This is like ALG. Don't want NATs to pay attention to RTP. Collin: STUN has RTP implications due to port sharing requirement. Melinda: NATs should not have to deal with embedded addresses Collin: Agree NATs shouldn't deal with RTP. Jonathan: Application guidelines may discuss protocols such as RTP, but not in BCP. Melinda: Assume data is encrypted or proprietary, so can't do anything. Gregory: Can put in charter than NATs shouldn't read into payloads, past transport layer. Cullen: Need to wordsmith Gregory: How will we get the work done? Should protocols be handled in their own working groups? This group provides guidelines for other WGs to pick up and run with it. Cullen: Sounds like a good idea, need to decide which ones. Jiri: Preferences is for experts to come to this WG Jonathan; Agree work should be done here due to sharing of expertise. Need people in the room to commit cycles to get work done. Ackman: All NATs look into payloads, so I don't understand payload comments? Cullen: Need to define which level we mean - don't want to do ALGs at HTTP, RTSP layer. Jon: Look at payload issue as we do the work rather than bounding it in the charter. Same for list of protocols. such as text is good, but do the investigation going forward. John Lochney: Don't get bogged down in protocols but provide general guidelines for NAT makers. For new protocols, it should work based on general guidelines. "Don't mess with Layer 7" for example. Need to read existing literature on this topic as every WG has some text on how to get their protocol through NATs. ----- NAT/Firewall Behavior Requirements - Francois Audet NAT/Firewall behavior was tested separately. Firewall only means filtering rules in NAT. Jonathan; NAT inherently requires filtering, and this is all we are talking about due to binding establishing. Scope is only enough filtering to make a NAT work. Not general behavior which has policy. change the term. Brian; There are boxes that do both. NAT/Firewall term suggests a combined box. Need a new word. Jiri: The WG should sort out this terminology. Really just packet matching Rohan; Lets not define new terminology, but redefine existing. Suraj: Agree with earlier comments on limiting scope to NATs. NATs are not deterministic, unfortunately. Document has requirements. Rohan; Before we start on details, lets get an idea of interest? Jiri: This is our set of requirements. ----- Jon: I think this is a great idea. Alan Johnston: Its great, lets do it. Unknown: Why do it now? Didn't we try to stop them originally? Cullen: Like making rules for how to mug someone. Melinda: Fine line. There is a lot of IPR on NATs. Difficult to convince them to change. There is under participation by NAT folks. Result of groups might not be implemented except small residential NATs. Joe Hildebrand: Sex education is a better analogy, will do it anyway, help them to be safe. Rohan: We didn't provide NAT builders an alternative. Linksys is onboard. Many NAT providers are shipping voice services. Also being beaten up by gamers. Gregory: We have 75% of NATs builders here in this room. Abstinance just won't work. John: We are helping NAT vendors. Jeff Huston: Implementors get creative in the absence of standards. Implementors make guesses at the rough edges. Applications must navigate NATs. By not attacking this problem we are making a mistake. Ackman: Good idea. Jonathan; If we don't tell them what to do, they will not do what we want. Darran Falk; IETF doesn't do conformance testing. Brian: In addition to mention of IPv4, should insert IPv4 at the first occurance of the word "NAT" Joe: Deterministic behavior is good. Unknown: What about v6? Are we making this mistake again. Jon: I hope not. There is a tactical problem now, IPv6 can appear with a minimum of these intermediaries. IPv6 should be designed to prevent this problem, but could be wrong. Alan Parlor: What is the mailing list. Cullen: Mailing list is on agenda page. http://www.ietf.org/ietf/04aug/behave.txt Jarki: Need to make more clear, one goal is that new NATs should meet this. Cullen: Let's take a hum on forming a WG using this charter. Strong consensus to proceed in Hum. From jiri@iptel.org Thu, 5 Aug 2004 17:18:22 -0700 (PDT) From: Jiri Kuthan Date: Thu, 5 Aug 2004 17:18:22 -0700 (PDT) Subject: Re: [Ietf-behave] Thinking about the BoF In-Reply-To: <019b01c479ea$7a29bb80$fb828182@DFNJGL21> Message-ID: <6.0.3.0.0.20040806015711.03929fc8@localhost> MIME-Version: 1.0 Content-Type: text/plain I do not think that statements about IPv6 to IPv6 translations are in scope of behave. Behave's primary goal is to make NATs more deterministic. I would like to keep behave well focused on that. -jiri At 07:42 AM 8/5/2004, JORDI PALET MARTINEZ wrote: >Hi all, > >Fully agree, specially with the point of making NOW a BCP for no-NAT with IPv6. > >We should clearly state that translation is BAD, there is no need for doing >that, it breaks things, and consequently it MUST be avoided. I will even say >much more and in a much stronger way: Any product in the market that does IPv6 >to IPv6 translation, will not follow the BCPXXXX, is not IPv6 complaint, and >consequently should be excluded from interoperability test. Should be clearly >perceived by the market (including public and private tenders) as something >not-to-be purchased. > >Question. Is this within the scope of this WG (assuming it becomes a WG) ? > >If not, where this work need to be developed ? > >I will be happy to volunteer for that. Anyone else to help ? When we start ? > >Regards, >Jordi From audet@nortelnetworks.com Sun, 8 Aug 2004 12:40:59 -0700 (PDT) From: "Francois Audet" Date: Sun, 8 Aug 2004 12:40:59 -0700 (PDT) Subject: RE: [Ietf-behave] Thinking about the BoF Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D211DE16BD@zsc3c030.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Thinking about the BoF I agree. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] > Sent: Thursday, August 05, 2004 17:03 > To: JORDI PALET MARTINEZ; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Thinking about the BoF > > > I do not think that statements about IPv6 to IPv6 > translations are in scope > of behave. Behave's primary goal is to make NATs more > deterministic. I would like to keep behave well focused on that. > > > -jiri > > At 07:42 AM 8/5/2004, JORDI PALET MARTINEZ wrote: > >Hi all, > > > >Fully agree, specially with the point of making NOW a BCP for no-NAT > >with IPv6. > > > >We should clearly state that translation is BAD, there is no > need for > >doing that, it breaks things, and consequently it MUST be avoided. I > >will even say much more and in a much stronger way: Any > product in the > >market that does IPv6 to IPv6 translation, will not follow > the BCPXXXX, > >is not IPv6 complaint, and consequently should be excluded from > >interoperability test. Should be clearly perceived by the market > >(including public and private tenders) as something not-to-be > >purchased. > > > >Question. Is this within the scope of this WG (assuming it becomes a > >WG) ? > > > >If not, where this work need to be developed ? > > > >I will be happy to volunteer for that. Anyone else to help ? When we > >start ? > > > >Regards, > >Jordi > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/i> etf-behave > > From mbhatia@nextone.com Tue, 10 Aug 2004 04:53:45 -0700 (PDT) From: "Medhavi Bhatia" Date: Tue, 10 Aug 2004 04:53:45 -0700 (PDT) Subject: [Ietf-behave] NAT behave draft Message-ID: <200408101153.HAA15695@leviathan.cnchost.com> MIME-Version: 1.0 Content-Type: text/plain Some comments/questions:   REQ-3 comes up with a min-timeout of 2 minutes for UDP dynamic bindings. Is there data somewhere on the internet which can back this up ? REQ-4 suggests that refreshes MUST be based outbound traffic only. This seems to be linked to REQ-1, since for symmetric firewalls, the security problem cited as reason is not quite valid. Also, inbound refreshes pose a problem with setting and maintaining the session. For example, a voice mail server which is outside the firewall cannot assume that simply sending traffic is good enough. For the offer/answer model, the sdp attribute of recvonly in an offer coming from behind the firewall is inapplicable, so this requirements affects how SIP sessions would be setup (or any other protocol…).   -Medhavi.   Medhavi Bhatia Chief Architect   NexTone Communications ****Pioneering Global Communications with Excellence, Integrity and Flawless Execution****   From audet@nortelnetworks.com Tue, 10 Aug 2004 10:33:57 -0700 (PDT) From: "Francois Audet" Date: Tue, 10 Aug 2004 10:33:57 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D211ED8E4C@zsc3c030.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message Hi Medhavi, REQ-3 is based on the fact that too short of a UDP timeout binding will cause problems. We've seen NATs with very short timers (like 30s), but there are 2 problems associated with those NATs: (1) the timer is so short that a short term problem may cause the NAT binding to change, and (2) it causes a very significant rate of refresh packets to be sent which can affect the scalability of the servers receiving them (SIP proxy/registrars, STUN servers, RTP media receivers, RTCP, etc.). The exact value of course is something that can be examined, and if you have any input, please share it with us. As long as it it not too short, I think we can be quite flexible. REQ-4 is because if it were refreshed by the inbound traffic, a termination "outside" the NAT could keep the pinhole opened for as long as it wished, which would be a security concern. I.e., you could phone somebody, then hang-up, and they could keep the pinhole opened by sending packets to you. For the voicemail server, yes, it would mean that the inside device would need to keep the binding alive. For a bi-directional communication, this shouldn't be a problem in the first place. For uni-directional communication (sdp=recvonly), what it means is that if you are behind a NAT, you need to keep the receiving NAT binding open. In practice, it means that when you do your STUN request to find your address binding, you need to keep it alive (by sending packets from the media port: STUN packets or other) during the session. This is STUN or SIP client behavior, and is outside the scope of the BEHAVE document. However, the BEHAVE document is drafted so that it would support such client behavior.
-----Original Message-----From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Medhavi BhatiaSent: Tuesday, August 10, 2004 04:54To: ietf-behave@xxxxxxxxxxxxxxxxxxxSubject: [Ietf-behave] NAT behave draft Some comments/questions: REQ-3 comes up with a min-timeout of 2 minutes for UDP dynamic bindings. Is there data somewhere on the internet which can back this up ? REQ-4 suggests that refreshes MUST be based outbound traffic only. This seems to be linked to REQ-1, since for symmetric firewalls, the security problem cited as reason is not quite valid. Also, inbound refreshes pose a problem with setting and maintaining the session. For example, a voice mail server which is outside the firewall cannot assume that simply sending traffic is good enough. For the offer/answer model, the sdp attribute of recvonly in an offer coming from behind the firewall is inapplicable, so this requirements affects how SIP sessions would be setup (or any other protocol...). -Medhavi. Medhavi Bhatia Chief Architect NexTone Communications ****Pioneering Global Communications with Excellence, Integrity and Flawless Execution**** From mbhatia@nextone.com Tue, 10 Aug 2004 11:16:11 -0700 (PDT) From: "Medhavi Bhatia" Date: Tue, 10 Aug 2004 11:16:11 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211ED8E4C@zsc3c030.us.nortel.com> Message-ID: <200408101814.OAA27998@leviathan.cnchost.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message Francois, In your analysis, did you see any Firewalls which allows only outbound refresh ? -Medhavi. From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx] Sent: Tuesday, August 10, 2004 1:33 PM To: 'mbhatia@xxxxxxxxxxx'; 'ietf-behave@xxxxxxxxxxxxxxxxxxx' Subject: RE: [Ietf-behave] NAT behave draft Hi Medhavi, REQ-3 is based on the fact that too short of a UDP timeout binding will cause problems. We've seen NATs with very short timers (like 30s), but there are 2 problems associated with those NATs: (1) the timer is so short that a short term problem may cause the NAT binding to change, and (2) it causes a very significant rate of refresh packets to be sent which can affect the scalability of the servers receiving them (SIP proxy/registrars, STUN servers, RTP media receivers, RTCP, etc.). The exact value of course is something that can be examined, and if you have any input, please share it with us. As long as it it not too short, I think we can be quite flexible. REQ-4 is because if it were refreshed by the inbound traffic, a termination "outside" the NAT could keep the pinhole opened for as long as it wished, which would be a security concern. I.e., you could phone somebody, then hang-up, and they could keep the pinhole opened by sending packets to you. For the voicemail server, yes, it would mean that the inside device would need to keep the binding alive. For a bi-directional communication, this shouldn't be a problem in the first place. For uni-directional communication (sdp=recvonly), what it means is that if you are behind a NAT, you need to keep the receiving NAT binding open. In practice, it means that when you do your STUN request to find your address binding, you need to keep it alive (by sending packets from the media port: STUN packets or other) during the session. This is STUN or SIP client behavior, and is outside the scope of the BEHAVE document. However, the BEHAVE document is drafted so that it would support such client behavior.
-----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Medhavi Bhatia Sent: Tuesday, August 10, 2004 04:54 To: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: [Ietf-behave] NAT behave draft Some comments/questions: REQ-3 comes up with a min-timeout of 2 minutes for UDP dynamic bindings. Is there data somewhere on the internet which can back this up ? REQ-4 suggests that refreshes MUST be based outbound traffic only. This seems to be linked to REQ-1, since for symmetric firewalls, the security problem cited as reason is not quite valid. Also, inbound refreshes pose a problem with setting and maintaining the session. For example, a voice mail server which is outside the firewall cannot assume that simply sending traffic is good enough. For the offer/answer model, the sdp attribute of recvonly in an offer coming from behind the firewall is inapplicable, so this requirements affects how SIP sessions would be setup (or any other protocol...). -Medhavi. Medhavi Bhatia Chief Architect NexTone Communications ****Pioneering Global Communications with Excellence, Integrity and Flawless Execution**** From audet@nortelnetworks.com Tue, 10 Aug 2004 15:49:38 -0700 (PDT) From: "Francois Audet" Date: Tue, 10 Aug 2004 15:49:38 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D211ED96BD@zsc3c030.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message In the ones that we tested (at Nortel), ALL NAT except one used the Outbound only refresh (which is good, and secure). The bad NAT was an old discontinued product witch worked with inbound only (which is bad). We only tested a small number of NATs however. Cullen may have more data from his own more extensive testing.
-----Original Message-----From: Medhavi Bhatia [mailto:mbhatia@xxxxxxxxxxx] Sent: Tuesday, August 10, 2004 11:15To: Audet, Francois [SC100:9T51:EXCH]; ietf-behave@xxxxxxxxxxxxxxxxxxxSubject: RE: [Ietf-behave] NAT behave draft Francois, In your analysis, did you see any Firewalls which allows only outbound refresh ? -Medhavi.
From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx] Sent: Tuesday, August 10, 2004 1:33 PMTo: 'mbhatia@xxxxxxxxxxx'; 'ietf-behave@xxxxxxxxxxxxxxxxxxx'Subject: RE: [Ietf-behave] NAT behave draft Hi Medhavi, REQ-3 is based on the fact that too short of a UDP timeout binding will cause problems. We've seen NATs with very short timers (like 30s), but there are 2 problems associated with those NATs: (1) the timer is so short that a short term problem may cause the NAT binding to change, and (2) it causes a very significant rate of refresh packets to be sent which can affect the scalability of the servers receiving them (SIP proxy/registrars, STUN servers, RTP media receivers, RTCP, etc.). The exact value of course is something that can be examined, and if you have any input, please share it with us. As long as it it not too short, I think we can be quite flexible. REQ-4 is because if it were refreshed by the inbound traffic, a termination "outside" the NAT could keep the pinhole opened for as long as it wished, which would be a security concern. I.e., you could phone somebody, then hang-up, and they could keep the pinhole opened by sending packets to you. For the voicemail server, yes, it would mean that the inside device would need to keep the binding alive. For a bi-directional communication, this shouldn't be a problem in the first place. For uni-directional communication (sdp=recvonly), what it means is that if you are behind a NAT, you need to keep the receiving NAT binding open. In practice, it means that when you do your STUN request to find your address binding, you need to keep it alive (by sending packets from the media port: STUN packets or other) during the session. This is STUN or SIP client behavior, and is outside the scope of the BEHAVE document. However, the BEHAVE document is drafted so that it would support such client behavior.
-----Original Message-----From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Medhavi BhatiaSent: Tuesday, August 10, 2004 04:54To: ietf-behave@xxxxxxxxxxxxxxxxxxxSubject: [Ietf-behave] NAT behave draft Some comments/questions: REQ-3 comes up with a min-timeout of 2 minutes for UDP dynamic bindings. Is there data somewhere on the internet which can back this up ? REQ-4 suggests that refreshes MUST be based outbound traffic only. This seems to be linked to REQ-1, since for symmetric firewalls, the security problem cited as reason is not quite valid. Also, inbound refreshes pose a problem with setting and maintaining the session. For example, a voice mail server which is outside the firewall cannot assume that simply sending traffic is good enough. For the offer/answer model, the sdp attribute of recvonly in an offer coming from behind the firewall is inapplicable, so this requirements affects how SIP sessions would be setup (or any other protocol...). -Medhavi. Medhavi Bhatia Chief Architect NexTone Communications ****Pioneering Global Communications with Excellence, Integrity and Flawless Execution**** From gih@apnic.net Tue, 10 Aug 2004 16:21:40 -0700 (PDT) From: Geoff Huston Date: Tue, 10 Aug 2004 16:21:40 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211ED96BD@zsc3c030.us.nortel.com> Message-ID: <6.0.1.1.2.20040811091550.0210daf8@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: text/plain This is good data, and is certainly worth bearing in mind, but the underlying exercise is to document what the WG-to-be believes is the _right_ action. For UDP there is the issue of pinhole extension that argues strongly in favour of outbound-only refresh, and it appears that in general NATs are using this mechanism. But for TCP its not so clear to me that an outbound only is so necessary. Cullen's survey was UDP-based, and I've not seen any other data here. Have you surveyed NAT implementations regarding the refresh time trigger for TCP? Do they differ from UDP? I was quietly thinking to myself that in the case of TCP a bidrectional timer refresh trigger would make more sense than outbound only, and I was wondering if that happens in NATs today. At 08:45 AM 11/08/2004, Francois Audet wrote: In the ones that we tested (at Nortel), ALL NAT except one used the Outbound only refresh (which is good, and secure). The bad NAT was an old discontinued product witch worked with inbound only (which is bad). We only tested a small number of NATs however. Cullen may have more data from his own more extensive testing. From audet@nortelnetworks.com Tue, 10 Aug 2004 16:40:20 -0700 (PDT) From: "Francois Audet" Date: Tue, 10 Aug 2004 16:40:20 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D211ED979C@zsc3c030.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behave draft Hi Geoff, I fully agree with your comments: the reason we said "outbound only" is based on what we feel is the proper safe behavior for UDP. We haven't put much tought on TCP so far, and clearly we need to add more information on the requirements. I don't know what current NATs "outbound" versus "inbound" behavior is for TCP. We didn't even cover it in the first version of the draft. Certainly something to investigate. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, August 10, 2004 16:22 > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: RE: [Ietf-behave] NAT behave draft > > > This is good data, and is certainly worth bearing in mind, but the > underlying exercise is to document what the WG-to-be believes is the > _right_ action. > > For UDP there is the issue of pinhole extension that argues > strongly in > favour of outbound-only refresh, and it appears that in > general NATs are > using this mechanism. > > But for TCP its not so clear to me that an outbound only is > so necessary. > Cullen's survey was UDP-based, and I've not seen any other > data here. Have > you surveyed NAT implementations regarding the refresh time > trigger for > TCP? Do they differ from UDP? > > I was quietly thinking to myself that in the case of TCP a > bidrectional > timer refresh trigger would make more sense than outbound > only, and I was > wondering if that happens in NATs today. From kbiswas@cisco.com Tue, 10 Aug 2004 17:20:41 -0700 (PDT) From: Kaushik Biswas Date: Tue, 10 Aug 2004 17:20:41 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211ED979C@zsc3c030.us.norte l.com> Message-ID: <4.3.2.7.2.20040810171157.03866c08@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Nice document. Couple of points below : - REQ 4: Don't think we should not make NAT timer "outbound refresh" a MUST. We can suggest a minimum timeout value, and let the NATs decide whether they want to do "bidirectional", "inbound" or "outbound" refresh. Besides this doesn't hamper the traversal-mechanisms & is a nice-to-have wrt NAT-architecture. - REQ 5: Might be a good to recommend the Filtering EF=APD instead of EF=AP After agreeing upon the basic-requirements we can try to have the respective traversal-mechanisms have some technique to figure out whether the path from A->B traversing n-NATs are indeed all following the basic-requirements (as is required for traversal-mechanism to work). Sort of making this is a MUST for traversal-mechanisms rather than relying upon the network. This way there can be a fall-back mechanism from traversal-mechanisms to "traditional" mechanisms like ALG-processing. This can arise in scenario whereby the traversal mechanism, say X, is working just fine but say 2 companies merged and newly merged company doesn't have NATs following the basic-requirements as required for traversal-mechanism: X to work. Basically a mixed network. In such case if communication is to be between these two, then "traditional" SIP ALG might need to be used. Thanks, Kaushik At 04:40 PM 8/10/2004 -0700, Francois Audet wrote: Hi Geoff, I fully agree with your comments: the reason we said "outbound only" is based on what we feel is the proper safe behavior for UDP. We haven't put much tought on TCP so far, and clearly we need to add more information on the requirements. I don't know what current NATs "outbound" versus "inbound" behavior is for TCP. We didn't even cover it in the first version of the draft. Certainly something to investigate. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, August 10, 2004 16:22 > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: RE: [Ietf-behave] NAT behave draft > > > This is good data, and is certainly worth bearing in mind, but the > underlying exercise is to document what the WG-to-be believes is the > _right_ action. > > For UDP there is the issue of pinhole extension that argues > strongly in > favour of outbound-only refresh, and it appears that in > general NATs are > using this mechanism. > > But for TCP its not so clear to me that an outbound only is > so necessary. > Cullen's survey was UDP-based, and I've not seen any other > data here. Have > you surveyed NAT implementations regarding the refresh time > trigger for > TCP? Do they differ from UDP? > > I was quietly thinking to myself that in the case of TCP a > bidrectional > timer refresh trigger would make more sense than outbound > only, and I was > wondering if that happens in NATs today. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortelnetworks.com Tue, 10 Aug 2004 18:04:53 -0700 (PDT) From: "Francois Audet" Date: Tue, 10 Aug 2004 18:04:53 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D211F1EDE2@zsc3c030.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message
-----Original Message-----From: Kaushik Biswas [mailto:kbiswas@xxxxxxxxx] Sent: Tuesday, August 10, 2004 17:22To: Audet, Francois [SC100:9T51:EXCH]Cc: 'Geoff Huston'; 'ietf-behave@xxxxxxxxxxxxxxxxxxx'Subject: RE: [Ietf-behave] NAT behave draft Nice document. Couple of points below : Thanks.
- REQ 4: Don't think we should not make NAT timer "outbound refresh" a MUST. We can suggest a minimum timeout value, and let the NATs decide whether they want to do "bidirectional", "inbound" or "outbound" refresh. Besides this doesn't hamper the traversal-mechanisms & is a nice-to-have wrt NAT-architecture. I agree that Bidirectional will "work" as well as the "outbound" only. However,I am concerned that it would enable somebody you have been receiving media from to to keep that binding aliveeven after the call has been torn down (maliciously or not), by sending media to you periodically. I personally think this is somewhat of a security issue. On a subsequent genuine session, you may be receiving the garbage media stream interleaved with the real and active new one. So, I'm a bit reluctant on that one.
- REQ 5: Might be a good to recommend the Filtering EF=APD instead of EF=AP I don't personnally have a problem with this recommendation. However, I believe some have told us that it might be an issue with certain gaming protocols. Perhaps we should flag it as an opened issue. In any case, I think we have a concensus that both are acceptable, it is matter of deciding which is recommended.
After agreeing upon the basic-requirements we can try to have the respective traversal-mechanisms have some technique to figure out whether the path from A->B traversing n-NATs are indeed all following the basic-requirements (as is required for traversal-mechanism to work). Sort of making this is a MUST for traversal-mechanisms rather than relying upon the network. This way there can be a fall-back mechanism from traversal-mechanisms to "traditional" mechanisms like ALG-processing. This can arise in scenario whereby the traversal mechanism, say X, is working just fine but say 2 companies merged and newly merged company doesn't have NATs following the basic-requirements as required for traversal-mechanism: X to work. Basically a mixed network. In such case if communication is to be between these two, then "traditional" SIP ALG might need to be used. This is essentially what ICE attempts to do, although you seem to want to widen the scope to alternatives that are not used by ICE (namely, ALGs). I believe this is very important, but I don't believe that it is in the scope of the BEHAVE group since we are not looking at the network and SIP clients aspects. I believe that the nat-scenarios document is being revised in SIPPING. Perhaps this is where this should be addressed: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-nat-scenarios-03.txt From jiri@iptel.org Wed, 11 Aug 2004 03:01:30 -0700 (PDT) From: Jiri Kuthan Date: Wed, 11 Aug 2004 03:01:30 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211ED979C@zsc3c030.us.norte l.com> Message-ID: <6.0.3.0.0.20040811095654.04010eb0@localhost> MIME-Version: 1.0 Content-Type: text/plain At 02:22 AM 8/11/2004, Kaushik Biswas wrote: >Nice document. Couple of points below : > >- REQ 4: Don't think we should not make NAT timer "outbound refresh" a MUST. >We can suggest a minimum timeout value, and let the NATs decide whether they >want to do "bidirectional", "inbound" or "outbound" refresh. Besides this >doesn't hamper the traversal-mechanisms & is a nice-to-have wrt >NAT-architecture. I think the minimum MUST is that outbound refreshes do keep UDP bindings alive for some minimum time. That allows for a combination of NAT logic (open up binding if a client desires to communicate) with client's interest to keep the same binding as long as it is active. Not doing so (reported occurences) breaks applications. The procedural question to me is how far beyond minimum requirements we wish to go. >- REQ 5: Might be a good to recommend the Filtering EF=APD instead of EF=AP > >After agreeing upon the basic-requirements we can try to have the respective >traversal-mechanisms have some technique to figure out whether the path from >A->B traversing n-NATs are indeed all following the basic-requirements (as is >required for traversal-mechanism to work). Sort of making this is a MUST for >traversal-mechanisms rather than relying upon the network. This way there can >be a fall-back mechanism from traversal-mechanisms to "traditional" mechanisms >like ALG-processing. This can arise in scenario whereby the traversal >mechanism, say X, is working just fine but say 2 companies merged and newly >merged company doesn't have NATs following the basic-requirements as required >for traversal-mechanism: X to work. Basically a mixed network. In such case if >communication is to be between these two, then "traditional" SIP ALG might >need to be used. See ICE -- it tries to determine IP connectivity in end-2-end manner. That's being pursued in MMUSIC WG. -jiri From jiri@iptel.org Wed, 11 Aug 2004 03:21:22 -0700 (PDT) From: Jiri Kuthan Date: Wed, 11 Aug 2004 03:21:22 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211ED96BD@zsc3c030.us.nortel.com> Message-ID: <6.0.3.0.0.20040811102248.01f2eec0@localhost> MIME-Version: 1.0 Content-Type: text/plain At 01:21 AM 8/11/2004, Geoff Huston wrote: >This is good data, and is certainly worth bearing in mind, but the underlying >exercise is to document what the WG-to-be believes is the _right_ action. > >For UDP there is the issue of pinhole extension that argues strongly in favour >of outbound-only refresh, and it appears that in general NATs are using this >mechanism. > >But for TCP its not so clear to me that an outbound only is so necessary. >Cullen's survey was UDP-based, and I've not seen any other data here. Have you >surveyed NAT implementations regarding the refresh time trigger for TCP? Do >they differ from UDP? I am not aware of such a survey. >I was quietly thinking to myself that in the case of TCP a bidrectional timer >refresh trigger would make more sense than outbound only, and I was wondering >if that happens in NATs today. Does bidirectional mean in&&out or in||out? I haven't looked at what's today NATs criteria for keeping TCP bindings alive. The question to me is whether we would like to go beyond a minimalistic set of requirements. It may be that minimalistic requirements (keep binding alive based on outbound packets) will work for TCP too. All in all, if an inbound TCP packet comes in, it will cause an outbound TCP packet sent out. -jiri >At 08:45 AM 11/08/2004, Francois Audet wrote: >>In the ones that we tested (at Nortel), ALL NAT except one used the Outbound >>only refresh (which is good, and secure). >> >>The bad NAT was an old discontinued product witch worked with inbound only >>(which is bad). >> >>We only tested a small number of NATs however. >> >>Cullen may have more data from his own more extensive testing. > > >_______________________________________________ >Ietf-behave mailing list >Ietf-behave@xxxxxxxxxxxxxxxxxxx >https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jiri Kuthan http://iptel.org/~jiri/ From mshore@cisco.com Wed, 11 Aug 2004 04:21:16 -0700 (PDT) From: Melinda Shore Date: Wed, 11 Aug 2004 04:21:16 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211F1EDE2@zsc3c030.us.nortel.com> Message-ID: <7D3EDA3B-EB88-11D8-923B-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Tuesday, August 10, 2004, at 09:01 PM, Francois Audet wrote: However,I am concerned that it would enable somebody you have been receiving media from to to keep that binding aliveeven after the call has been torn down (maliciously or not), by sending media to you periodically. I personally think this is somewhat of a security issue. It would be, depending on whether or not you think that NAT is security technology and that directionality is a security property. I could go either way - I personally don't think of NATs as security devices, but that's how they're very often used in the real world. It would probably be useful to include a few sentences explaining the issue. Melinda From audet@nortelnetworks.com Wed, 11 Aug 2004 11:13:20 -0700 (PDT) From: "Francois Audet" Date: Wed, 11 Aug 2004 11:13:20 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D211F1F79B@zsc3c030.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behave draft OK. I'll capture it in the draft. > -----Original Message----- > From: Melinda Shore [mailto:mshore@xxxxxxxxx] > Sent: Wednesday, August 11, 2004 04:21 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: Re: [Ietf-behave] NAT behave draft > > > On Tuesday, August 10, 2004, at 09:01 PM, Francois Audet wrote: > > However,I am concerned that it would enable somebody you have been > > receiving media from to to keep that binding aliveeven > after the call > > has been torn down (maliciously or not), by sending media to you > > periodically. I personally think this is somewhat of a > security issue. > > It would be, depending on whether or not you think that NAT > is security technology and that directionality is a security > property. I could go either way - I personally don't think > of NATs as security devices, but that's how they're very > often used in the real world. It would > probably be > useful to include a few sentences explaining the issue. > > Melinda > > > From gih@apnic.net Wed, 11 Aug 2004 15:16:24 -0700 (PDT) From: Geoff Huston Date: Wed, 11 Aug 2004 15:16:24 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211ED96BD@zsc3c030.us.nortel.com> Message-ID: <6.0.1.1.2.20040812081024.01f7b278@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: text/plain Bidirectional, as I understand it in the context of the draft, means that an inbound packet or an outbound packet will refresh the binding expiration timer. You are right that in must circumstances TCP follows a packet in one direction with a packet in the other, so in the case of TCP the three options produce a very similar outcome. On thinking about this some more, the circumstances where this would _not_ happen are when one end has closed its connection but the other has not. In this case I guess that the safest action for the NAT is to use outbound as the binding expiration timer trigger for TCP. i.e. the binding will expire once the 'internal' host has closed its TCP state, even if the external end continues to direct packets to the closed session. Geoff At 08:18 PM 11/08/2004, Jiri Kuthan wrote: At 01:21 AM 8/11/2004, Geoff Huston wrote: >This is good data, and is certainly worth bearing in mind, but the underlying exercise is to document what the WG-to-be believes is the _right_ action. > >For UDP there is the issue of pinhole extension that argues strongly in favour of outbound-only refresh, and it appears that in general NATs are using this mechanism. > >But for TCP its not so clear to me that an outbound only is so necessary. Cullen's survey was UDP-based, and I've not seen any other data here. Have you surveyed NAT implementations regarding the refresh time trigger for TCP? Do they differ from UDP? I am not aware of such a survey. >I was quietly thinking to myself that in the case of TCP a bidrectional timer refresh trigger would make more sense than outbound only, and I was wondering if that happens in NATs today. Does bidirectional mean in&&out or in||out? I haven't looked at what's today NATs criteria for keeping TCP bindings alive. The question to me is whether we would like to go beyond a minimalistic set of requirements. It may be that minimalistic requirements (keep binding alive based on outbound packets) will work for TCP too. All in all, if an inbound TCP packet comes in, it will cause an outbound TCP packet sent out. -jiri >At 08:45 AM 11/08/2004, Francois Audet wrote: >>In the ones that we tested (at Nortel), ALL NAT except one used the Outbound only refresh (which is good, and secure). >> >>The bad NAT was an old discontinued product witch worked with inbound only (which is bad). >> >>We only tested a small number of NATs however. >> >>Cullen may have more data from his own more extensive testing. > > >_______________________________________________ >Ietf-behave mailing list >Ietf-behave@xxxxxxxxxxxxxxxxxxx >https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jiri Kuthan http://iptel.org/~jiri/ From audet@nortelnetworks.com Wed, 11 Aug 2004 15:20:10 -0700 (PDT) From: "Francois Audet" Date: Wed, 11 Aug 2004 15:20:10 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D211F76616@zsc3c030.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behave draft So you are advocating the same logic for TCP as UDP? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Geoff Huston > Sent: Wednesday, August 11, 2004 15:16 > To: Jiri Kuthan; 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: RE: [Ietf-behave] NAT behave draft > > > Bidirectional, as I understand it in the context of the > draft, means that an inbound packet or an outbound packet > will refresh the binding expiration timer. > > You are right that in must circumstances TCP follows a packet > in one direction with a packet in the other, so in the case > of TCP the three options produce a very similar outcome. > > On thinking about this some more, the circumstances where > this would _not_ > happen > are when one end has closed its connection but the other has > not. In this case I guess that the safest action for the NAT > is to use outbound as the binding expiration timer trigger > for TCP. i.e. the binding will expire once the 'internal' > host has closed its TCP state, even if the external end > continues to direct packets to the closed session. > > Geoff From dwing@cisco.com Wed, 11 Aug 2004 16:13:32 -0700 (PDT) From: "Dan Wing" Date: Wed, 11 Aug 2004 16:13:32 -0700 (PDT) Subject: TCP RE: [Ietf-behave] NAT behave draft In-Reply-To: <6.0.3.0.0.20040811102248.01f2eec0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > I haven't looked at what's today NATs criteria for keeping TCP > bindings alive. The question to me is whether we would like to go > beyond a minimalistic set of requirements. It may be that minimalistic > requirements (keep binding alive based on outbound packets) will work > for TCP too. All in all, if an inbound TCP packet comes in, it will > cause an outbound TCP packet sent out. The end of a TCP session is indicated with FIN (from either end) or RST (from either end). Except for the odd case of both TCP peers forgetting about an active session, a NAT can expect to see a FIN or RST from one of the TCP peers (most likely from both of the TCP peers). The NAT can safely destroy its NAT binding after seeing the 3-way FIN teardown (in the case of FIN) or the 2-way RST teardown (in the case of RST). To handle the case of the TCP peer being unreachable the NAT needs a timeout for when only peer attempts a RST or FIN but isn't receiving a response -- the binding should eventually be destroyed even without a normal TCP close. I expect the BCP should include requirements related to draft-ietf-tcpm-tcpsecure-01.txt which describe middlebox (NAT) behavior around the recently-announced TCP RST and SYN attacks. -d From dwing@cisco.com Wed, 11 Aug 2004 16:15:39 -0700 (PDT) From: "Dan Wing" Date: Wed, 11 Aug 2004 16:15:39 -0700 (PDT) Subject: multicast RE: [Ietf-behave] NAT behave draft In-Reply-To: <6.0.1.1.2.20040811091550.0210daf8@kahuna.telstra.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Geoff Huston wrote: > For UDP there is the issue of pinhole extension that argues > strongly in favour of outbound-only refresh, and it appears > that in general NATs are using this mechanism. Multicast needs inbound-only. Or are we going to declare multicast out-of-scope for this BCP? -d From dwing@cisco.com Wed, 11 Aug 2004 16:24:35 -0700 (PDT) From: "Dan Wing" Date: Wed, 11 Aug 2004 16:24:35 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211ED8E4C@zsc3c030.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > REQ-4 is because if it were refreshed by the inbound traffic, a > termination "outside" the NAT could keep the pinhole opened for > as long as it wished, which would be a security concern. I.e., > you could phone somebody, then hang-up, and they could keep > the pinhole opened by sending packets to you. For the voicemail > server, yes, it would mean that the inside device would need > to keep the binding alive. Similarly for music-on-hold, the inside device will have to keep the binding alive. > For a bi-directional communication, this shouldn't be a problem > in the first place. > > For uni-directional communication (sdp=recvonly), what it means is that > if you are behind a NAT, you need to keep the receiving NAT binding open. > In practice, it means that when you do your STUN request to find your > address binding, you need to keep it alive (by sending packets from > the media port: STUN packets or other) during the session. Right, except then you're not recvonly anymore -- you're transmitting. You might not always even know where to transmit packets to (you might not have enough SDP). This violates the meaning of recvonly. > This is STUN or SIP client behavior, and is outside the scope of the > BEHAVE document. However, the BEHAVE document is drafted so that it > would support such client behavior. Agreed. But we don't have an agreed-upon way of sending these NAT-keepalive packets: it could be STUN, RTP No-Op (draft-wing-avt-rtp-noop-00.txt) which is only an individual submission, 'silence suppression' packet for G.729, or an NSE that is hoped to be silently dropped by the remote end. I believe we need an agreement on this NAT keepalive packet - perhaps this should be brought up in AVT (for packet format) and/or MMUSIC (for issue around transmitting while SDP says 'recvonly'). -d From gih@apnic.net Wed, 11 Aug 2004 17:41:41 -0700 (PDT) From: Geoff Huston Date: Wed, 11 Aug 2004 17:41:41 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211F76616@zsc3c030.us.nortel.com> Message-ID: <6.0.1.1.2.20040812103621.01f8c8e8@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: text/plain In short, yes I am. regards, Geoff At 08:18 AM 12/08/2004, Francois Audet wrote: So you are advocating the same logic for TCP as UDP? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Geoff Huston > Sent: Wednesday, August 11, 2004 15:16 > To: Jiri Kuthan; 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: RE: [Ietf-behave] NAT behave draft > > > Bidirectional, as I understand it in the context of the > draft, means that an inbound packet or an outbound packet > will refresh the binding expiration timer. > > You are right that in must circumstances TCP follows a packet > in one direction with a packet in the other, so in the case > of TCP the three options produce a very similar outcome. > > On thinking about this some more, the circumstances where > this would _not_ > happen > are when one end has closed its connection but the other has > not. In this case I guess that the safest action for the NAT > is to use outbound as the binding expiration timer trigger > for TCP. i.e. the binding will expire once the 'internal' > host has closed its TCP state, even if the external end > continues to direct packets to the closed session. > > Geoff From gih@apnic.net Wed, 11 Aug 2004 17:43:19 -0700 (PDT) From: Geoff Huston Date: Wed, 11 Aug 2004 17:43:19 -0700 (PDT) Subject: Re: multicast RE: [Ietf-behave] NAT behave draft In-Reply-To: <6.0.1.1.2.20040811091550.0210daf8@kahuna.telstra.net> Message-ID: <6.0.1.1.2.20040812103805.020d9c38@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: text/plain At 09:17 AM 12/08/2004, Dan Wing wrote: Geoff Huston wrote: > For UDP there is the issue of pinhole extension that argues > strongly in favour of outbound-only refresh, and it appears > that in general NATs are using this mechanism. Multicast needs inbound-only. Or are we going to declare multicast out-of-scope for this BCP? The draft I've been working from attempts to look at this on a per-protocol basis, and my "in general" comment was about the observation that has been made that _for UDP_ NATS use outbound-only refresh in general. Multicast does need different treatment and this should be flagged with the Multicast considerations, I did not see an out-of-scope for multicast in the IETF session, and, in the contrary, I though it had been accepted as needing consideration. Geoff From jdrosen@dynamicsoft.com Fri, 13 Aug 2004 12:23:25 -0700 (PDT) From: Jonathan Rosenberg Date: Fri, 13 Aug 2004 12:23:25 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211F1EDE2@zsc3c030.us.nortel.com> Message-ID: <411D14A4.1050409@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain inline. Francois Audet wrote: -----Original Message----- *From:* Kaushik Biswas [mailto:kbiswas@xxxxxxxxx] *Sent:* Tuesday, August 10, 2004 17:22 *To:* Audet, Francois [SC100:9T51:EXCH] *Cc:* 'Geoff Huston'; 'ietf-behave@xxxxxxxxxxxxxxxxxxx' *Subject:* RE: [Ietf-behave] NAT behave draft Nice document. Couple of points below : Thanks. - REQ 4: Don't think we should not make NAT timer "outbound refresh" a MUST. We can suggest a minimum timeout value, and let the NATs decide whether they want to do "bidirectional", "inbound" or "outbound" refresh. Besides this doesn't hamper the traversal-mechanisms & is a nice-to-have wrt NAT-architecture. I agree that Bidirectional will "work" as well as the "outbound" only. However, I am concerned that it would enable somebody you have been receiving media from to to keep that binding alive even after the call has been torn down (maliciously or not), by sending media to you periodically. I personally think this is somewhat of a security issue. The other issue is determinism. The point of the behave effort is to define a well-understood baseline set of behaviors that applications can depend on. In particular, I think a good metric is that, if an application has to do something quite different if a NAT exhibits behavior X as opposed to behavior Y, we should specify, at MUST strength, the behavior. Otherwise, we are right back to where we are now. As it pertains to this topic, if an application doesn't know which direction a NAT uses to keep bindings active, and it guesses wrong, it won't get service. We want to avoid that. Indeed, if you don't specify which direction, an app will need to assume the worst case and refresh both.... After agreeing upon the basic-requirements we can try to have the respective traversal-mechanisms have some technique to figure out whether the path from A->B traversing n-NATs are indeed all following the basic-requirements (as is required for traversal-mechanism to work). Sort of making this is a MUST for traversal-mechanisms rather than relying upon the network. This way there can be a fall-back mechanism from traversal-mechanisms to "traditional" mechanisms like ALG-processing. This can arise in scenario whereby the traversal mechanism, say X, is working just fine but say 2 companies merged and newly merged company doesn't have NATs following the basic-requirements as required for traversal-mechanism: X to work. Basically a mixed network. In such case if communication is to be between these two, then "traditional" SIP ALG might need to be used. This is essentially what ICE attempts to do, although you seem to want to widen the scope to alternatives that are not used by ICE (namely, ALGs). ALGs are covered by ICE, although not explicitly. If an ALG should attempt to rewrite the SDP, that rewritten address becomes just another choice which can be tried. I believe this is very important, but I don't believe that it is in the scope of the BEHAVE group since we are not looking at the network and SIP clients aspects. Agree. I believe that the nat-scenarios document is being revised in SIPPING. Perhaps this is where this should be addressed: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-nat-scenarios-03.txt Yes, I think we should have a use case that shows the interaction with a B2BUAWM with ICE. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Fri, 13 Aug 2004 12:32:43 -0700 (PDT) From: Jonathan Rosenberg Date: Fri, 13 Aug 2004 12:32:43 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <7D3EDA3B-EB88-11D8-923B-000A95E35274@cisco.com> Message-ID: <411D16E3.3000002@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain inline. Melinda Shore wrote: On Tuesday, August 10, 2004, at 09:01 PM, Francois Audet wrote: However, I am concerned that it would enable somebody you have been receiving media from to to keep that binding alive even after the call has been torn down (maliciously or not), by sending media to you periodically. I personally think this is somewhat of a security issue. It would be, depending on whether or not you think that NAT is security technology I think that is an important question. Francois and Cullen's draft does a good job in trying to pull apart the filtering and binding aspects of NAT behavior, but they are ultimately linked. The lack of a binding inherently creates a filtering rule that would prohibit any inbound communications to the host. Since bindings are created by outbound traffic, NATs have an inherent filtering property which prohibit inbound packets to a host unless it has communicated outward. I think it is widely accepted that there are security properties afforded by this kind of behavior. I think we should avoiding calling this a "firewall", since the filtering is a byproduct of the fundamental property of NAT, rather than an expression of operator policy. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From audet@nortelnetworks.com Fri, 13 Aug 2004 15:51:52 -0700 (PDT) From: "Francois Audet" Date: Fri, 13 Aug 2004 15:51:52 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D21203C152@zsc3c030.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behave draft Agree with Jonathan. As stated in the meeting, I will make it clear in the next revision that we are covering the inherent "filtering" behavior of NAT, but that "Firewalling" is out-of-scope (as per the charter). > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxxxxxxxx] > Sent: Friday, August 13, 2004 12:31 > To: Melinda Shore > Cc: Audet, Francois [SC100:9T51:EXCH]; > 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: Re: [Ietf-behave] NAT behave draft > > > inline. > > Melinda Shore wrote: > > > On Tuesday, August 10, 2004, at 09:01 PM, Francois Audet wrote: > > > >> However, I am concerned that it would enable somebody you have been > >> receiving media from to to keep that binding alive even > after the call > >> has been torn down (maliciously or not), by sending media to you > >> periodically. I personally think this is somewhat of a > security issue. > > > > > > It would be, depending on whether or not you think that NAT is > > security technology > > I think that is an important question. Francois and Cullen's > draft does > a good job in trying to pull apart the filtering and binding > aspects of > NAT behavior, but they are ultimately linked. The lack of a binding > inherently creates a filtering rule that would prohibit any inbound > communications to the host. Since bindings are created by outbound > traffic, NATs have an inherent filtering property which > prohibit inbound > packets to a host unless it has communicated outward. I think it is > widely accepted that there are security properties afforded > by this kind > of behavior. I think we should avoiding calling this a > "firewall", since > the filtering is a byproduct of the fundamental property of > NAT, rather > than an _expression_ of operator policy. > > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > From laforge@netfilter.org Sun, 15 Aug 2004 07:26:21 -0700 (PDT) From: Harald Welte Date: Sun, 15 Aug 2004 07:26:21 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211ED979C@zsc3c030.us.nortel.com> Message-ID: <20040815142613.GT15418@sunbeam2> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630131.multipart/signed" --Boundary..27398.1163630131.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, Aug 10, 2004 at 04:40:10PM -0700, Francois Audet wrote: > Hi Geoff, > > We haven't put much tought on TCP so far, and clearly we need to add more > information on the requirements. > > I don't know what current NATs "outbound" versus "inbound" behavior is for > TCP. At least for all the linux-2.4 (netfilter/iptables) based NAT devices out there (quite a lot, across all vendors): They do full TCP state tracking. So any non-FIN/non-RST packet either inbound or outbound will update the timeout. In the linux 2.4/2.6 netfilter/iptables implementation, this is the case with any layer 4 protocol. -- - Harald Welte http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie Attachment: signature.asc --Boundary..27398.1163630131.multipart/signed Content-Type: application/octet-stream; name="pgp00000.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00000.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQkgzS0ZYYVhHVlREMGkvOFJBdlBZQUo5N3haL2YxSG4yQUVpMzhCL0sv VzNhaHJ0SXpBQ2d0S2tyClFnZ0wzc0RFUENlbmFTQS9HNDBlYjJRPQo9MS9iTwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630131.multipart/signed-- From laforge@netfilter.org Sun, 15 Aug 2004 08:43:40 -0700 (PDT) From: Harald Welte Date: Sun, 15 Aug 2004 08:43:40 -0700 (PDT) Subject: [Ietf-behave] Comments to draft-audet-nat-behave-00.txt Message-ID: <20040815154336.GU15418@sunbeam2> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630131.multipart/signed" --Boundary..27398.1163630131.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi! First of all, let me introduce myself as one of the authors and maintainer of the Linux 2.4.x and 2.6.x packet filter and NAT subsystem, called netfilter/iptables. linux-based NAT's are found in commercial products for professional use from various vendors, but have recently gained huge market share in the consumer markent NAT devices. I'm mentioning this, since this seems to be unknown to a lot of people, including the 'Vendors' themselves (which often OEM the devices and have no idea what software is running on them). Vendors shipping netfilter/iptables based consumer NAT devices include Linksys, Belkin, Buffalo, U.S.Robotics, Asus, Siemens, Fujitsu-Siemsns, Sitecom, Airnyx, Arlotto, CenturySystems, Fiberline, Medion, Ovislink, Allnet, ... This should be considered if somebody makes a statement like '75% of NAT vendors present in this room' ;) I am very happy about an IETF working group on unifying NAT behaviour, and I think some guidelines/recommendations for NAT vendors would really be helpful to NAT implementors. > Some particularly nasty NATs use Port overloading, i.e. they > always use port preservation even in the case of collision (i.e., > X1:x to X':x, and X2:x to X':x). These NATs rely on the source of > the response from the external endpoint (Y:y, Z:z) to forward a > packet to the proper internal endpoint (X1 or X2). netfilter/iptables would be such a 'nasty' implementation. Please note however, that it cleanly handles thee 'port overload' case. Reasons for this 'nasty' implementations are: - don't change port numbers unless absolutely neccessarry. This adds extra transparency. We hate that we have to do NAT in netfilter/iptables, but we try to be as invisible as possible, causing the least of interferernce to applications. And yes, there are protocols/applications that validate source port numbers (some DNS implementations, for example). - don't waste port number address space (NB=PAD allows way more simultaneous sessions via a single public IP address than NB=I or NB=AD implementations) > Port overloading fails if the two internal endpoints are establishing > sessions to the same external destination. Which is a situation that is handled cleanly. A clash of port numbers is detected, and the source port number altered (as little as possible, and only in the same range (i.e. <1024 will always map to a different port < 1024). So, obviously, I have some resistance to 'REQ-2b'. I support the proposal to change 'REQ-4' to "MUST be "Outbound" or "Bidirectional", whereas "Outbound" is RECOMMENDED. Reg. REQ-4a: If (like in our implementation) a binding always only has a single session [an inevitable consequence of being 'fully symmetric'], does it fulfill the requirement? > Non-deterministic NATs and firewalls are risky from a security point > of view. They are very difficult to test because they are, well, > non-deterministic. Well, they are non-deterministic only if you don't know the rules determining the 'non-deterministic' behaviour. I don't really understand how this is a security risk. If a NAT tries to preserve ports as long as possible (as long as the tuple of [srcip,srcport,dstip,dstport] is unique) and alter the port only if this is neccessary, how does this impose a security risk? It might make a certain application fail to connect in such an event - but security? > Testing by a person configuring one may result in the person thinking > it is behaving as desired, yet under different conditions, which an > attacker can create, it may behave differently. I agree, if 'testing' means 'functional testing' and not 'security testing'. And even then onl only if it is proven that an attacker can create such a condition resulting in 'non-deterministic' behaviour. > These requirements recommend that devices be deterministic. This contradicts REQ-9 whihc states 'MUST be deterministic' -- - Harald Welte http://www.gnumonks.org/ ============================================================================ Programming is like sex: One mistake and you have to support it your lifetime Attachment: signature.asc --Boundary..27398.1163630131.multipart/signed Content-Type: application/octet-stream; name="pgp00001.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00001.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQkg0U29YYVhHVlREMGkvOFJBczA5QUo5T0ZoVzVSbHh3U2JmcGJUOE5w YlBtcEhPS1hBQ2JCU3c3ClJSb1NOcXowRU41SWJMZnNKTlRmaGlBPQo9Z3l0UQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630131.multipart/signed-- From fluffy@cisco.com Sun, 15 Aug 2004 12:12:25 -0700 (PDT) From: Cullen Jennings Date: Sun, 15 Aug 2004 12:12:25 -0700 (PDT) Subject: Re: [Ietf-behave] Thinking about the BoF In-Reply-To: <6.0.1.1.2.20040806004004.02027ec0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I have been trying to find the right balance of this with statements in the charter like "will not encourage the proliferation of NATs". The goals is reduce the harm in the places where NATs do exist by making the behavior more predictable. There is plenty of documentation around proving NATs cause problems and lots of pain should be expected if you use them. I don't imagine it would make much difference to have this group repeat this about v6 to v6 NATs - it has been said before. IMHO the best way to make sure there are no v6 to v6 NATs is to go look at all the reason that someone might want to do them and show that there are good non NAT solutions to all of these. I hear the rumor that some good V6 people might be working on such a document and I think that is great. Clearly this work would be out of scope. Cullen On 8/5/04 7:44 AM, "Geoff Huston" wrote: > >> Question. Is this within the scope of this WG (assuming it becomes a WG) ? > > well its not in the proposed charter, nor do I understand that there is a > compelling > reason to head off into this space in the context of this chartered work. I > would > advocate to the group not to add this into the behave proposed charter. > > >> If not, where this work need to be developed ? >> >> I will be happy to volunteer for that. Anyone else to help ? When we start ? > > I suppose that the previous question (Where do you work? ) needs to be > answered first to establish a place in which to do the second set of > questions in the context of the IETF. > > regards, > > Geoff > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Sun, 15 Aug 2004 12:12:28 -0700 (PDT) From: Cullen Jennings Date: Sun, 15 Aug 2004 12:12:28 -0700 (PDT) Subject: [Ietf-behave] TCP NAT binding times and directions Message-ID: MIME-Version: 1.0 Content-Type: text/plain I have not done very many experiments with this but have seen a bit of code and done a little. It is clear that the times in NATs are much larger for TCP than UDP. Some of the NATs I looked at had a binding time of 7200 seconds which was sort of disturbing given many OS have a TCP Keepalice of 7200. It was a race and if the keepalive was not lost it would work but if a few keep alives got lost, it would not. Some devices treat timeouts for formed connection differently than the flows where only a syn has been sent. From jordi.palet@consulintel.es Sun, 15 Aug 2004 12:21:39 -0700 (PDT) From: "JORDI PALET MARTINEZ" Date: Sun, 15 Aug 2004 12:21:39 -0700 (PDT) Subject: Re: [Ietf-behave] Thinking about the BoF In-Reply-To: Message-ID: <045801c482fd$0b3e8540$640a0a0a@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain Hi Cullen, I understood that is out of the scope, and I already started to work in a document to be submitted somewhere else. I'm not aware about other people working in that, and will be good to have a single unified document, joining the different works on this. So if you can point me to other people it will be great ! Regards, Jordi ----- Original Message ----- From: "Cullen Jennings" To: "Geoff Huston" ; "JORDI PALET MARTINEZ" ; "Behave" Sent: Sunday, August 15, 2004 8:08 PM Subject: Re: [Ietf-behave] Thinking about the BoF > > I have been trying to find the right balance of this with statements in the > charter like "will not encourage the proliferation of NATs". The goals is > reduce the harm in the places where NATs do exist by making the behavior > more predictable. > > There is plenty of documentation around proving NATs cause problems and lots > of pain should be expected if you use them. I don't imagine it would make > much difference to have this group repeat this about v6 to v6 NATs - it has > been said before. IMHO the best way to make sure there are no v6 to v6 NATs > is to go look at all the reason that someone might want to do them and show > that there are good non NAT solutions to all of these. I hear the rumor that > some good V6 people might be working on such a document and I think that is > great. Clearly this work would be out of scope. > > Cullen > > > On 8/5/04 7:44 AM, "Geoff Huston" wrote: > > > > >> Question. Is this within the scope of this WG (assuming it becomes a WG) ? > > > > well its not in the proposed charter, nor do I understand that there is a > > compelling > > reason to head off into this space in the context of this chartered work. I > > would > > advocate to the group not to add this into the behave proposed charter. > > > > > >> If not, where this work need to be developed ? > >> > >> I will be happy to volunteer for that. Anyone else to help ? When we start > >> ? > > > > I suppose that the previous question (Where do you work? ) needs to be > > answered first to establish a place in which to do the second set of > > questions in the context of the IETF. > > > > regards, > > > > Geoff > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From fluffy@cisco.com Sun, 15 Aug 2004 12:28:15 -0700 (PDT) From: Cullen Jennings Date: Sun, 15 Aug 2004 12:28:15 -0700 (PDT) Subject: Re: [Ietf-behave] Thinking about the BoF In-Reply-To: <045801c482fd$0b3e8540$640a0a0a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Give Brian Carpenter a ping - I was talking to him about it. On 8/15/04 12:20 PM, "JORDI PALET MARTINEZ" wrote: > Hi Cullen, > > I understood that is out of the scope, and I already started to work in a > document to be submitted somewhere else. > > I'm not aware about other people working in that, and will be good to have a > single unified document, joining the different works on this. So if you can > point me to other people it will be great ! > > Regards, > Jordi > > ----- Original Message ----- > From: "Cullen Jennings" > To: "Geoff Huston" ; "JORDI PALET MARTINEZ" > ; "Behave" > Sent: Sunday, August 15, 2004 8:08 PM > Subject: Re: [Ietf-behave] Thinking about the BoF > > >> >> I have been trying to find the right balance of this with statements in the >> charter like "will not encourage the proliferation of NATs". The goals is >> reduce the harm in the places where NATs do exist by making the behavior >> more predictable. >> >> There is plenty of documentation around proving NATs cause problems and lots >> of pain should be expected if you use them. I don't imagine it would make >> much difference to have this group repeat this about v6 to v6 NATs - it has >> been said before. IMHO the best way to make sure there are no v6 to v6 NATs >> is to go look at all the reason that someone might want to do them and show >> that there are good non NAT solutions to all of these. I hear the rumor that >> some good V6 people might be working on such a document and I think that is >> great. Clearly this work would be out of scope. >> >> Cullen >> >> >> On 8/5/04 7:44 AM, "Geoff Huston" wrote: >> >>> >>>> Question. Is this within the scope of this WG (assuming it becomes a WG) ? >>> >>> well its not in the proposed charter, nor do I understand that there is a >>> compelling >>> reason to head off into this space in the context of this chartered work. I >>> would >>> advocate to the group not to add this into the behave proposed charter. >>> >>> >>>> If not, where this work need to be developed ? >>>> >>>> I will be happy to volunteer for that. Anyone else to help ? When we start >>>> ? >>> >>> I suppose that the previous question (Where do you work? ) needs to be >>> answered first to establish a place in which to do the second set of >>> questions in the context of the IETF. >>> >>> regards, >>> >>> Geoff >>> >>> >>> _______________________________________________ >>> Ietf-behave mailing list >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> >> >> > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From gih@apnic.net Sun, 15 Aug 2004 15:27:03 -0700 (PDT) From: Geoff Huston Date: Sun, 15 Aug 2004 15:27:03 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211ED979C@zsc3c030.us.nortel.com> Message-ID: <6.0.1.1.2.20040816080110.02149750@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: text/plain At 12:26 AM 16/08/2004, Harald Welte wrote: On Tue, Aug 10, 2004 at 04:40:10PM -0700, Francois Audet wrote: > Hi Geoff, > > We haven't put much tought on TCP so far, and clearly we need to add more > information on the requirements. > > I don't know what current NATs "outbound" versus "inbound" behavior is for > TCP. At least for all the linux-2.4 (netfilter/iptables) based NAT devices out there (quite a lot, across all vendors): They do full TCP state tracking. So any non-FIN/non-RST packet either inbound or outbound will update the timeout. In the linux 2.4/2.6 netfilter/iptables implementation, this is the case with any layer 4 protocol. Does this imply that an external third party entity can keep a NAT TCP binding open by injecting out of sequence packets into the TCP stream? Geoff From laforge@netfilter.org Sun, 15 Aug 2004 16:14:38 -0700 (PDT) From: Harald Welte Date: Sun, 15 Aug 2004 16:14:38 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D211ED979C@zsc3c030.us.nortel.com> Message-ID: <20040815231432.GA15418@sunbeam2> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630131.multipart/signed" --Boundary..27398.1163630131.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, Aug 16, 2004 at 08:03:34AM +1000, Geoff Huston wrote: > >At least for all the linux-2.4 (netfilter/iptables) based NAT devices > >out there (quite a lot, across all vendors): They do full TCP state > >tracking. > > > >So any non-FIN/non-RST packet either inbound or outbound will update the > >timeout. > > > >In the linux 2.4/2.6 netfilter/iptables implementation, this is the case > >with any layer 4 protocol. > > Does this imply that an external third party entity can keep a NAT TCP > binding open by injecting out of sequence packets into the TCP stream? As with default 2.4/2.6 kernels: yes. But only until a FIN/RST teardown is noticed. We have numerous different timeouts in the lifetime of a TCP session, similar to the TCP state machine at the two connection endpoints. netfilter/iptables NAT is closely tied to our TCP state tracking code. In fact, the NAT transformations (source/destination/payload/...) are stored within the 'connection tracking entry' that resembles the state of one TCP session. Also, we offer a patch for full tcp window tracking since about three years. This will finally make it in mainline linux-2.6.9. > Geoff -- - Harald Welte http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie Attachment: signature.asc --Boundary..27398.1163630131.multipart/signed Content-Type: application/octet-stream; name="pgp00002.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00002.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQkgrNVlYYVhHVlREMGkvOFJBcE5VQUo5d3V1VFBRZ1phSWxUb3lJZnpJ WElFZUIwclhnQ2drTTBRCmpDRHBZdzczK2IyZFRiWGtrdG9qQklRPQo9RldFTQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630131.multipart/signed-- From audet@nortelnetworks.com Mon, 16 Aug 2004 11:01:48 -0700 (PDT) From: "Francois Audet" Date: Mon, 16 Aug 2004 11:01:48 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D21203CC02@zsc3c030.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behave draft If the "full TCP window tracking" option is used, does this mean that the vulnerability that an external third party can keep a NAT TCP binding open goes away? Any recommendation on what the draft *should* say for TCP? > -----Original Message----- > From: Harald Welte [mailto:laforge@xxxxxxxxxxxxx] > Sent: Sunday, August 15, 2004 16:15 > To: Geoff Huston > Cc: Audet, Francois [SC100:9T51:EXCH]; > 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: Re: [Ietf-behave] NAT behave draft > > > On Mon, Aug 16, 2004 at 08:03:34AM +1000, Geoff Huston wrote: > > > >At least for all the linux-2.4 (netfilter/iptables) based > NAT devices > > >out there (quite a lot, across all vendors): They do full > TCP state > > >tracking. > > > > > >So any non-FIN/non-RST packet either inbound or outbound > will update > > >the timeout. > > > > > >In the linux 2.4/2.6 netfilter/iptables implementation, > this is the > > >case with any layer 4 protocol. > > > > Does this imply that an external third party entity can > keep a NAT TCP > > binding open by injecting out of sequence packets into the > TCP stream? > > As with default 2.4/2.6 kernels: yes. But only until a > FIN/RST teardown > is noticed. We have numerous different timeouts in the lifetime of a > TCP session, similar to the TCP state machine at the two > connection endpoints. > > netfilter/iptables NAT is closely tied to our TCP state > tracking code. In fact, the NAT transformations > (source/destination/payload/...) are stored within the > 'connection tracking entry' that resembles the state of one > TCP session. > > Also, we offer a patch for full tcp window tracking since > about three years. This will finally make it in mainline linux-2.6.9. > > > Geoff > > -- > - Harald Welte > http://www.netfilter.org/ > > ============================================================== > ============== > "Fragmentation is like classful addressing -- an interesting early > architectural error that shows how much experimentation was going > on while IP was being designed." -- Paul Vixie > From laforge@netfilter.org Mon, 16 Aug 2004 11:32:36 -0700 (PDT) From: Harald Welte Date: Mon, 16 Aug 2004 11:32:36 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D21203CC02@zsc3c030.us.nortel.com> Message-ID: <20040816183227.GZ15418@sunbeam2> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630131.multipart/signed" --Boundary..27398.1163630131.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, Aug 16, 2004 at 11:01:45AM -0700, Francois Audet wrote: > If the "full TCP window tracking" option is used, does this mean > that the vulnerability that an external third party can keep a NAT > TCP binding open goes away? There is no 'vulnerability' what so ever in the TCP case. A fully established TCP session has a timeout of five days. If somebody wants to spoof packets into this TCP session, the five day timeout will be refreshed, but hey, then it's six days instead of five. This _only_ works as long as the real endpoints did not start a connection teardown (RST / FIN) in some way. If yes, the timeout is reduced and cannot be refreshed by any further spoofed packets. So in our implementation the 'vulnerability' with regard to inbound packets exists only in the UDP case. > Any recommendation on what the draft *should* say for TCP? I would say a draft on NAT behave should not try to require NAT devices to provide security features. Let it up to the implementors and users. It should require behaviour to enable higher level protocols and applications, but not require some kind of security. On the other hand, it should not require implementors to make the devices insecure, to ;) As I see it, whether or not inbound packets will refresh the nat binding (in addition to the required outbound packets) does not affect the functionality of any application on a higher level. I cannot see how this would negatively effect any SIP/STUN/... operation. So from my point of view, the draft should require oubound packets to refresh the NAT binding (since it is important for functionality), but only give recommendations on inbound packets. -- - Harald Welte http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie Attachment: signature.asc --Boundary..27398.1163630131.multipart/signed Content-Type: application/octet-stream; name="pgp00003.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00003.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQklQMjdYYVhHVlREMGkvOFJBamhSQUo5Wi9hWW1FVStqckhNOGFlS0lP UXNpRFdtN0h3Q2dwSDZVCjdpR3A0WDZqSG9DV0dyNlpaM0hUTGtrPQo9YVFTdwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630131.multipart/signed-- From audet@nortelnetworks.com Mon, 16 Aug 2004 15:18:54 -0700 (PDT) From: "Francois Audet" Date: Mon, 16 Aug 2004 15:18:54 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2120D85F9@zsc3c030.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behave draft > So from my point of view, the draft should require oubound > packets to refresh the NAT binding (since it is important for > functionality), but only give recommendations on inbound packets. Is that for both TCP and UDP, or just for UDP? From dwing@cisco.com Mon, 16 Aug 2004 18:07:14 -0700 (PDT) From: "Dan Wing" Date: Mon, 16 Aug 2004 18:07:14 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <20040816183227.GZ15418@sunbeam2> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Harald Welte wrote: > As I see it, whether or not inbound packets will refresh the nat binding > (in addition to the required outbound packets) does not affect the > functionality of any application on a higher level. I cannot see how > this would negatively effect any SIP/STUN/... operation. Then let me provide two examples: 1. Your VoIP phone implements VAD, you're on mute, and dialed your bank. Your bank has placed you into a queue and is playing 1 minute of music-on-hold followed by a "please wait, calls will be answered in the order received" message. We could argue about how SIP would Do This Differently, but if your VoIP phone dialed a PSTN number, the only RTP traffic will be incoming. 2. you're receiving multicast audio or multicast video. > So from my point of view, the draft should require oubound packets to > refresh the NAT binding (since it is important for functionality), but > only give recommendations on inbound packets. I'm feeling we're going to need a companion BEHAVE document for how voice over IP and video over IP endpoints need to behave in face of a BEHAVE-compliant NAT. For example, in case (1), above, we might need to require the VoIP endpoints leak occasional RTP traffic (or STUN traffic?), such as Silence Suppression packets or RTP No-Op packets. By having a companion document for VoIP endpoint behavior, we may be able to reduce, as much as possible, having BEHAVE specify things that are too complex or too hard to achieve consensus on, such as if incoming UDP packets should keep a binding alive. -d From fluffy@cisco.com Mon, 16 Aug 2004 21:37:01 -0700 (PDT) From: Cullen Jennings Date: Mon, 16 Aug 2004 21:37:01 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <20040816183227.GZ15418@sunbeam2> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 8/16/04 11:32 AM, "Harald Welte" wrote: > I would say a draft on NAT behave should not try to require NAT devices > to provide security features. Let it up to the implementors and users. > It should require behaviour to enable higher level protocols and > applications, but not require some kind of security. On the other hand, > it should not require implementors to make the devices insecure, to ;) Completely agree. We really don't want to try and specify firewalls here other than the trivial stuff we have to talk about to describe the NAT behavior. From laforge@netfilter.org Wed, 18 Aug 2004 14:12:07 -0700 (PDT) From: Harald Welte Date: Wed, 18 Aug 2004 14:12:07 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <20040816183227.GZ15418@sunbeam2> Message-ID: <20040818211150.GS3921@sunbeam.de.gnumonks.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630131.multipart/signed" --Boundary..27398.1163630131.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, Aug 16, 2004 at 06:07:10PM -0700, Dan Wing wrote: > Harald Welte wrote: > > > As I see it, whether or not inbound packets will refresh the nat binding > > (in addition to the required outbound packets) does not affect the > > functionality of any application on a higher level. I cannot see how > > this would negatively effect any SIP/STUN/... operation. > > Then let me provide two examples: > [...] Sorry, again I'm fighting with my own wording. Given the current draft's spirit that only outbound packets should refresh the NAT binding, I see no way how a NAT implementation that also refreshes for inbound packets could break anything (that wasn't already broken by the draft's requirement). So independent of the (important) policy question whether inbound or bidirectional packets should refresh (which I'm not even trying to answer): If the draft is in favour of incoming-only as requirement, it should leave bidirectional as a possibility to the implementor. > > So from my point of view, the draft should require oubound packets to > > refresh the NAT binding (since it is important for functionality), but > > only give recommendations on inbound packets. > > I'm feeling we're going to need a companion BEHAVE document for how > voice over IP and video over IP endpoints need to behave in face of > a BEHAVE-compliant NAT. Sounds reasonable to me. Maybe accompany it by another draft on terminology? I really dislike the cofusion mostly caused by equipment vendors calling their devices 'access routers' if they really are fully-fledged NAT/NAPT + Stateful Packet Filter devices.. NAT NAPT Masquerading Firewall Packet filter Stateful Packet Filter Stateless Packet Filter Router Gateway Bridge (where the last three are most likely quite well-defined already, so it oculd just reference them). > -d -- - Harald Welte http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie Attachment: signature.asc --Boundary..27398.1163630131.multipart/signed Content-Type: application/octet-stream; name="pgp00004.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00004.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQkk4WVdYYVhHVlREMGkvOFJBb1kyQUp3T2JFY3FSK1ZjTk9jUXNEUStD WkFEWFQ3UG1RQ2VOS2oyCml3MWR5d0lMdTllNUJveFl0VDVOcXZRPQo9allGdQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630131.multipart/signed-- From dwing@cisco.com Wed, 18 Aug 2004 14:55:59 -0700 (PDT) From: "Dan Wing" Date: Wed, 18 Aug 2004 14:55:59 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <20040818211150.GS3921@sunbeam.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > > Then let me provide two examples: > > [...] > > Sorry, again I'm fighting with my own wording. > > Given the current draft's spirit that only outbound packets should > refresh the NAT binding, I see no way how a NAT implementation that also > refreshes for inbound packets could break anything (that wasn't already > broken by the draft's requirement). > > So independent of the (important) policy question whether inbound or > bidirectional packets should refresh (which I'm not even trying to > answer): If the draft is in favour of incoming-only as requirement, it (I believe you intended to write "outgoing-only" in the line above.) > should leave bidirectional as a possibility to the implementor. Okay, I now understand what you're saying. My point is that if the BEHAVE document is silent and only requires outbound NAT binding refresh, two applications (multicast and music- on-hold) won't work. I believe we can workaround music-on-hold so that it works with outbound-only NAT refresh (the workaround is to leak packets in violation of recvonly), but I don't believe we can workaround multicast. > > > So from my point of view, the draft should require oubound packets to > > > refresh the NAT binding (since it is important for functionality), but > > > only give recommendations on inbound packets. > > > > I'm feeling we're going to need a companion BEHAVE document for how > > voice over IP and video over IP endpoints need to behave in face of > > a BEHAVE-compliant NAT. > > Sounds reasonable to me. Is this group's consensus that we allow multicast to be broken by BEHAVE- compliant NATs? If so, we could have a separate specification that describes how a BEHAVE-compliant NAT could also support multicast. In my opinion a separate document for multicast, IPsec, and other oddball things (Router Alert Option) might be the best way to allow BEHAVE to process quickly around UDP and ICMP without being held back with more complicated and less-common protocols. > Maybe accompany it by another draft on terminology? I really dislike > the cofusion mostly caused by equipment vendors calling their devices > 'access routers' if they really are fully-fledged NAT/NAPT + > Stateful Packet Filter devices.. > > NAT > NAPT > Masquerading > Firewall > Packet filter > Stateful Packet Filter > Stateless Packet Filter > Router > Gateway > Bridge > > (where the last three are most likely quite well-defined already, so it > oculd just reference them). We could define those terms, but I don't anticipate that changing product packaging or advertising. -d From audet@nortelnetworks.com Wed, 18 Aug 2004 15:04:14 -0700 (PDT) From: "Francois Audet" Date: Wed, 18 Aug 2004 15:04:14 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <868DC79D233649489252C20617E95C5007985B6E@zrc2c009.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behave draft Hi Dan, I think we need Multicast & other specific requirements, to be done in a later document. Fist document could be focused on UDP only. The intent is not to "break" multicast, but we should certainly not introduce issues just for multicast. Of course, I'm assuming that somehow it is possible to allow for multicast without requiring bidirectional or inbound binding for UDP. (I'm not sure on this point, not being a expert on multicast). Perhaps someone can clarify. For the "music-on-hold" issue, my take is that the sending of probe packets for that purpose is quite widespread, so I don't think it is an issue. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Wednesday, August 18, 2004 14:54 > To: Harald Welte > Cc: Audet, Francois [SC100:9T51:EXCH]; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] NAT behave draft > > > > > Then let me provide two examples: > > > [...] > > > > Sorry, again I'm fighting with my own wording. > > > > Given the current draft's spirit that only outbound packets should > > refresh the NAT binding, I see no way how a NAT implementation that > > also refreshes for inbound packets could break anything > (that wasn't > > already broken by the draft's requirement). > > > > So independent of the (important) policy question whether > inbound or > > bidirectional packets should refresh (which I'm not even trying to > > answer): If the draft is in favour of incoming-only as > requirement, > > it > > (I believe you intended to write "outgoing-only" in the line above.) > > > should leave bidirectional as a possibility to the implementor. > > Okay, I now understand what you're saying. > > > My point is that if the BEHAVE document is silent and only > requires outbound NAT binding refresh, two applications > (multicast and music- > on-hold) won't work. I believe we can workaround > music-on-hold so that it works with outbound-only NAT refresh > (the workaround is to leak packets in violation of recvonly), > but I don't believe we can workaround multicast. > > > > > So from my point of view, the draft should require > oubound packets > > > > to refresh the NAT binding (since it is important for > > > > functionality), but only give recommendations on > inbound packets. > > > > > > I'm feeling we're going to need a companion BEHAVE > document for how > > > voice over IP and video over IP endpoints need to behave > in face of > > > a BEHAVE-compliant NAT. > > > > Sounds reasonable to me. > > Is this group's consensus that we allow multicast to be > broken by BEHAVE- compliant NATs? If so, we could have a > separate specification that describes how a BEHAVE-compliant > NAT could also support multicast. In my opinion a separate > document for multicast, IPsec, and other oddball things > (Router Alert Option) might be the best way to allow BEHAVE > to process quickly around UDP and ICMP without being held > back with more complicated and less-common protocols. > > > Maybe accompany it by another draft on terminology? I > really dislike > > the cofusion mostly caused by equipment vendors calling > their devices > > 'access routers' if they really are fully-fledged NAT/NAPT > + Stateful > > Packet Filter devices.. > > > > NAT > > NAPT > > Masquerading > > Firewall > > Packet filter > > Stateful Packet Filter > > Stateless Packet Filter > > Router > > Gateway > > Bridge > > > > (where the last three are most likely quite well-defined > already, so > > it oculd just reference them). > > We could define those terms, but I don't anticipate that > changing product packaging or advertising. > > -d > > From dwing@cisco.com Wed, 18 Aug 2004 15:21:49 -0700 (PDT) From: "Dan Wing" Date: Wed, 18 Aug 2004 15:21:49 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <868DC79D233649489252C20617E95C5007985B6E@zrc2c009.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > I think we need Multicast & other specific requirements, to be done > in a later document. > Fist document could be focused on UDP only. Multicast is UDP; I expect you mean to focus this on unicast UDP. > The intent is not to "break" multicast, but we should certainly > not introduce issues just for multicast. If we only require NATs keep their bindings open for outgoing UDP packets, it means multicast won't work. > Of course, I'm assuming that somehow it is possible to allow for multicast > without requiring bidirectional or inbound binding for UDP. (I'm not sure > on this point, not being a expert on multicast). Me, neither, but an off-list conversation confirmed that it is possible. > Perhaps someone can clarify. > For the "music-on-hold" issue, my take is that the sending of probe > packets for that purpose is quite widespread, so I don't think it is > an issue. Except that widespread behavior isn't documented in any IETF document, at least not to my knowledge. What other behaviors are necessary for UDP applications (games, VoIP, etc.) to work over NATs? It would be useful to collect those into a document to provide guidance to UDP application developers who hope to work with a BEHAVE-compliant NAT. Otherwise they'll re-invent the same solution or, worse, invent a different solution which works with the specific NATs they're testing with and fail with other NATs in the market they haven't (yet) seen. -d > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Wednesday, August 18, 2004 14:54 > To: Harald Welte > Cc: Audet, Francois [SC100:9T51:EXCH]; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] NAT behave draft > > > > > Then let me provide two examples: > > > [...] > > > > Sorry, again I'm fighting with my own wording. > > > > Given the current draft's spirit that only outbound packets should > > refresh the NAT binding, I see no way how a NAT implementation that > > also refreshes for inbound packets could break anything > (that wasn't > > already broken by the draft's requirement). > > > > So independent of the (important) policy question whether > inbound or > > bidirectional packets should refresh (which I'm not even trying to > > answer): If the draft is in favour of incoming-only as > requirement, > > it > > (I believe you intended to write "outgoing-only" in the line above.) > > > should leave bidirectional as a possibility to the implementor. > > Okay, I now understand what you're saying. > > > My point is that if the BEHAVE document is silent and only > requires outbound NAT binding refresh, two applications > (multicast and music- > on-hold) won't work. I believe we can workaround > music-on-hold so that it works with outbound-only NAT refresh > (the workaround is to leak packets in violation of recvonly), > but I don't believe we can workaround multicast. > > > > > So from my point of view, the draft should require > oubound packets > > > > to refresh the NAT binding (since it is important for > > > > functionality), but only give recommendations on > inbound packets. > > > > > > I'm feeling we're going to need a companion BEHAVE > document for how > > > voice over IP and video over IP endpoints need to behave > in face of > > > a BEHAVE-compliant NAT. > > > > Sounds reasonable to me. > > Is this group's consensus that we allow multicast to be > broken by BEHAVE- compliant NATs? If so, we could have a > separate specification that describes how a BEHAVE-compliant > NAT could also support multicast. In my opinion a separate > document for multicast, IPsec, and other oddball things > (Router Alert Option) might be the best way to allow BEHAVE > to process quickly around UDP and ICMP without being held > back with more complicated and less-common protocols. > > > Maybe accompany it by another draft on terminology? I > really dislike > > the cofusion mostly caused by equipment vendors calling > their devices > > 'access routers' if they really are fully-fledged NAT/NAPT > + Stateful > > Packet Filter devices.. > > > > NAT > > NAPT > > Masquerading > > Firewall > > Packet filter > > Stateful Packet Filter > > Stateless Packet Filter > > Router > > Gateway > > Bridge > > > > (where the last three are most likely quite well-defined > already, so > > it oculd just reference them). > > We could define those terms, but I don't anticipate that > changing product packaging or advertising. > > -d > > From audet@nortelnetworks.com Wed, 18 Aug 2004 15:28:23 -0700 (PDT) From: "Francois Audet" Date: Wed, 18 Aug 2004 15:28:23 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <868DC79D233649489252C20617E95C5007985BA0@zrc2c009.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behave draft > Multicast is UDP; I expect you mean to focus this on unicast UDP. Yes. > > The intent is not to "break" multicast, but we should certainly not > > introduce issues just for multicast. > > If we only require NATs keep their bindings open for outgoing > UDP packets, it means multicast won't work. > > > Of course, I'm assuming that somehow it is possible to allow for > > multicast without requiring bidirectional or inbound > binding for UDP. > > (I'm not sure on this point, not being a expert on multicast). > > Me, neither, but an off-list conversation confirmed that it > is possible. So that type of information should be in the second document, provided that it doesn't conflict with the first one. > Except that widespread behavior isn't documented in any IETF > document, at least not to my knowledge. What other behaviors > are necessary for UDP applications (games, VoIP, etc.) to > work over NATs? It would be useful to collect those into a > document to provide guidance to UDP application developers > who hope to work with a BEHAVE-compliant NAT. Otherwise > they'll re-invent the same solution or, worse, invent a > different solution which works with the specific NATs they're > testing with and fail with other NATs in the market they > haven't (yet) seen. I agree 100%. From laforge@netfilter.org Thu, 19 Aug 2004 00:35:08 -0700 (PDT) From: Harald Welte Date: Thu, 19 Aug 2004 00:35:08 -0700 (PDT) Subject: Re: [Ietf-behave] Thinking about the BoF In-Reply-To: <6.0.1.1.2.20040806004004.02027ec0@localhost> Message-ID: <20040819073457.GV3921@sunbeam.de.gnumonks.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630131.multipart/signed" --Boundary..27398.1163630131.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, Aug 15, 2004 at 11:08:57AM -0700, Cullen Jennings wrote: > IMHO the best way to make sure there are no v6 to v6 NATs is to go > look at all the reason that someone might want to do them and show > that there are good non NAT solutions to all of these. I totally agree. The netfilter/iptables project was approached numerous times with a feature request for IPv6 NAT. It is clear within the linxu kernel networking community that we will not tolerate a v6<->v6 NAT implementation in the official kernel tree, even if somebody wrote one. I'm having a hard time to understand how and in which document a "MUST NOT implement IPv6 <-> IPv6 NA(P)T" would fit, bout it would definitely have my support. > I hear the rumor that some good V6 people might be working on such a > document and I think that is great. Any idea who those 'good ipv6 people' are? > Cullen -- - Harald Welte http://www.gnumonks.org/ ============================================================================ Programming is like sex: One mistake and you have to support it your lifetime Attachment: signature.asc --Boundary..27398.1163630131.multipart/signed Content-Type: application/octet-stream; name="pgp00005.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00005.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQkpGZ2hYYVhHVlREMGkvOFJBcGFZQUo5NkRRamFMYzRFZEM5b1ZmcXJK TEMyYkdUV0ZRQ2RIOG42CkhnQVp4cVJwK2E1R0MrUzRYTGpOV3ZzPQo9d0k0cAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630131.multipart/signed-- From laforge@netfilter.org Thu, 19 Aug 2004 01:35:30 -0700 (PDT) From: Harald Welte Date: Thu, 19 Aug 2004 01:35:30 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <868DC79D233649489252C20617E95C5007985B6E@zrc2c009.us.nortel.com> Message-ID: <20040819083522.GW3921@sunbeam.de.gnumonks.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630131.multipart/signed" --Boundary..27398.1163630131.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, Aug 18, 2004 at 05:02:11PM -0500, Francois Audet wrote: > Hi Dan, > > I think we need Multicast & other specific requirements, to be done in > a later document. Mh, why is that? Multicast requirements are split in two parts: 1) in 99.9% of all cases udp-based payload 2) IGMP multicast subscriptions The only requirement for '1' that I can see, is the requirement of having inbound-only UDP packets refresh the NAT binding. Since it was argued multiple times that inbound refresh is needed for other applications, too - the draft could just demand bidirectional refresh. This would automatically give us 50% of the functionality we need for multicast listeners behind the NAT. > The intent is not to "break" multicast, but we should certainly not > introduce issues just for multicast. My take on this is, that as soon as we do not require inbound packets to refresh the NAT binding, we > Of course, I'm assuming that somehow it is possible to allow for > multicast without requiring bidirectional or inbound binding for UDP. > (I'm not sure on this point, not being a expert on multicast). Perhaps > someone can clarify. Not without some ugly kludge like having a multicast listener sending back bogus packets to the multicast group, i.e. every other listener. (because the NAT treats multicast just like unicast and needs to see the same source/destination tuple) Firsty, this would break existing multicast applications and requires specifically BEHAVE compliant designed applications. Secondly, you would flood all the group members with your keepalive packets ;( > For the "music-on-hold" issue, my take is that the sending of probe packets > for that purpose is quite widespread, so I don't think it is an issue. I think this issue is a question of whether this group wants to a) focus on making NAT's as invisible and interoperable with existing applications or b) draft some specific requirements for NAT's and application designers to make future applications interoperate better with behave-compliant NAT's. If we favor 'a', then we cannot require any keepalive packets either in the unicast nor in the multicast case and must require inbound refresh. -- - Harald Welte http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie Attachment: signature.asc --Boundary..27398.1163630131.multipart/signed Content-Type: application/octet-stream; name="pgp00006.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00006.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQkpHWktYYVhHVlREMGkvOFJBaWU1QUo5ZkMxWVF0UGZ2OTZzRkpQVnox ZTQybDlmOGl3Q2RGTTJ6CmM3UGs2b1o0SXVLcnNMUjhJNXNRY2xnPQo9VVE3ZgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630131.multipart/signed-- From jdrosen@dynamicsoft.com Thu, 19 Aug 2004 14:11:39 -0700 (PDT) From: Jonathan Rosenberg Date: Thu, 19 Aug 2004 14:11:39 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <20040819083522.GW3921@sunbeam.de.gnumonks.org> Message-ID: <41251784.3080502@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain Harald Welte wrote: Of course, I'm assuming that somehow it is possible to allow for multicast without requiring bidirectional or inbound binding for UDP. (I'm not sure on this point, not being a expert on multicast). Perhaps someone can clarify. Not without some ugly kludge like having a multicast listener sending back bogus packets to the multicast group, i.e. every other listener. (because the NAT treats multicast just like unicast and needs to see the same source/destination tuple) I don't see the problem here, actually. Why can't we specify different keepalive rules for multicast and unicast? The two are readily differentiated in the NAT by the IP address. For multicast, there basically is a "keepalive" from the inside to the out - IGMP. If the user decides to leave the group, packets won't be forwarded, and there is no problem. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From audet@nortelnetworks.com Thu, 19 Aug 2004 14:59:25 -0700 (PDT) From: "Francois Audet" Date: Thu, 19 Aug 2004 14:59:25 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <1ECE0EB50388174790F9694F77522CCF4925D0@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behave draft > I don't see the problem here, actually. Why can't we specify > different > keepalive rules for multicast and unicast? The two are readily > differentiated in the NAT by the IP address. For multicast, there > basically is a "keepalive" from the inside to the out - IGMP. If the > user decides to leave the group, packets won't be forwarded, > and there > is no problem. That's kind of my thinking too. Isn't there a way the NAT can distinguish between multicast traffic and uniscast traffic are apply different rules? From spencer@mcsr-labs.org Thu, 19 Aug 2004 16:10:51 -0700 (PDT) From: "Spencer Dawkins" Date: Thu, 19 Aug 2004 16:10:51 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <1ECE0EB50388174790F9694F77522CCF4925D0@zrc2hxm0.corp.nortel.com> Message-ID: <089a01c48641$c935f7d0$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behave draft I may have misunderstood the thread, but I thought the request was that BEHAVE NATs are multicast-aware enough that they don't break multicast (by dropping all multicast packets, for instance)... were we talking about something else? Spencer
----- Original Message -----
From: Francois Audet To: 'Jonathan Rosenberg' ; 'Harald Welte' Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' Sent: Thursday, August 19, 2004 4:59 PM Subject: RE: [Ietf-behave] NAT behave draft > I don't see the problem here, actually. Why can't we specify > different > keepalive rules for multicast and unicast? The two are readily > differentiated in the NAT by the IP address. For multicast, there > basically is a "keepalive" from the inside to the out - IGMP. If the > user decides to leave the group, packets won't be forwarded, > and there > is no problem. That's kind of my thinking too. Isn't there a way the NAT can distinguish between multicast traffic and uniscast traffic are apply different rules? _______________________________________________Ietf-behave mailing listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortelnetworks.com Thu, 19 Aug 2004 16:15:20 -0700 (PDT) From: "Francois Audet" Date: Thu, 19 Aug 2004 16:15:20 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <1ECE0EB50388174790F9694F77522CCF492640@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message No, I think you understand properly. It would mean that if you are good enough to support multicast, you need to support the second document. I guess one question I have is, does Multicast work today with home NATs?
-----Original Message-----From: Spencer Dawkins [mailto:spencer@xxxxxxxxxxxxx] Sent: Thursday, August 19, 2004 16:11To: ietf-behave@xxxxxxxxxxxxxxxxxxxSubject: Re: [Ietf-behave] NAT behave draft I may have misunderstood the thread, but I thought the request was that BEHAVE NATs are multicast-aware enough that they don't break multicast (by dropping all multicast packets, for instance)... were we talking about something else? Spencer
----- Original Message -----
From: Francois Audet To: 'Jonathan Rosenberg' ; 'Harald Welte' Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' Sent: Thursday, August 19, 2004 4:59 PM Subject: RE: [Ietf-behave] NAT behave draft > I don't see the problem here, actually. Why can't we specify > different > keepalive rules for multicast and unicast? The two are readily > differentiated in the NAT by the IP address. For multicast, there > basically is a "keepalive" from the inside to the out - IGMP. If the > user decides to leave the group, packets won't be forwarded, > and there > is no problem. That's kind of my thinking too. Isn't there a way the NAT can distinguish between multicast traffic and uniscast traffic are apply different rules? _______________________________________________Ietf-behave mailing listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Sun, 22 Aug 2004 22:59:54 -0700 (PDT) From: Cullen Jennings Date: Sun, 22 Aug 2004 22:59:54 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behave draft In-Reply-To: <20040818211150.GS3921@sunbeam.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 8/18/04 2:11 PM, "Harald Welte" wrote: > Router > Gateway > Bridge > > (where the last three are most likely quite well-defined already, so it > oculd just reference them). Oh the difference between a Router, Switch, and Bridge is something that can consume many beers :-) From fluffy@cisco.com Sun, 22 Aug 2004 23:01:05 -0700 (PDT) From: Cullen Jennings Date: Sun, 22 Aug 2004 23:01:05 -0700 (PDT) Subject: [Ietf-behave] UPD and Multicast scope In-Reply-To: <1ECE0EB50388174790F9694F77522CCF492640@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: UPD and Multicast scope Given the advice we got at the meeting, I would be happiest to propose we do the "UDP Unicast" stuff in one of our first documents then do the "Multicast" stuff in a later document. That said, I think that considering how our future work might break the UDP Unicast work is completely appropriate. We probably need some clue of how we might solve the multicast timeouts issues when we get to them and if that would require changers to the UDP document we need to contemplate that now. I can see several discussion paths we might pursue: treat multicast traffic differently do outbound keep alives in multicast applications update timeouts on inbound packets for unicast UDP Thoughts on pros/cons of these? Cullen From spencer@mcsr-labs.org Mon, 23 Aug 2004 04:29:28 -0700 (PDT) From: "Spencer Dawkins" Date: Mon, 23 Aug 2004 04:29:28 -0700 (PDT) Subject: Re: [Ietf-behave] UPD and Multicast scope In-Reply-To: Message-ID: <0d4e01c48904$7943af90$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain Title: UPD and Multicast scope I'm not disagreeing on the "work on unicast UDP first" strategy, but I do have a question. If I understand the justification for BEHAVE, the idea is to have BCP-strength specifications that vendors and operators will use, and then (they will most likely) claim "BCP 110" (more likely "RFC 4112", but that's a NEWTRK problem) compliance. If we don't work on multicast at this time, I think we're saying "we don't care if people break multicast now - if their NATs drop all multicast traffic,they can stilll say they comply with IETF BCPs for NAT, and that's OK". Is that what we're saying? Spencer
----- Original Message -----
From: Cullen Jennings To: Francois Audet ; Dan Wing ; Behave ; Jiri Kuthan Sent: Sunday, August 22, 2004 8:49 PM Subject: [Ietf-behave] UPD and Multicast scope Given the advice we got at the meeting, I would be happiest to propose we do the "UDP Unicast" stuff in one of our first documents then do the "Multicast" stuff in a later document. That said, I think that considering how our future work might break the UDP Unicast work is completely appropriate. We probably need some clue of how we might solve the multicast timeouts issues when we get to them and if that would require changers to the UDP document we need to contemplate that now.I can see several discussion paths we might pursue: treat multicast traffic differently do outbound keep alives in multicast applications update timeouts on inbound packets for unicast UDPThoughts on pros/cons of these?Cullen From audet@nortelnetworks.com Mon, 23 Aug 2004 08:50:38 -0700 (PDT) From: "Francois Audet" Date: Mon, 23 Aug 2004 08:50:38 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft Message-ID: <1ECE0EB50388174790F9694F77522CCF493038@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behave draft Let's stick with the term NAT. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Sunday, August 22, 2004 18:53 > To: Harald Welte; Dan Wing > Cc: Behave > Subject: Re: [Ietf-behave] NAT behave draft > > > On 8/18/04 2:11 PM, "Harald Welte" wrote: > > > Router > > Gateway > > Bridge > > > > (where the last three are most likely quite well-defined > already, so > > it oculd just reference them). > > Oh the difference between a Router, Switch, and Bridge is > something that can consume many beers :-) > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinf> o/ietf-behave > From dwing@cisco.com Mon, 23 Aug 2004 09:44:20 -0700 (PDT) From: "Dan Wing" Date: Mon, 23 Aug 2004 09:44:20 -0700 (PDT) Subject: [Ietf-behave] RE: UPD and Multicast scope In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain I like (1), because multicast is already handled differently by the NATs -- to do multicast they have to see an IGMP from the Ethernet-attached computer, propagate the IGMP towards the service provider, and set up a NAT binding. What is critical in the base document is that the base BEHAVE document allows incoming-only multicast packets to keep the NAT binding open. I suggest the following straw-man wording in BEHAVE: For unicast traffic, a binding MUST remain open if a UDP packet is sent from an inside address to an outside address. Additionally, unicast UDP bindings MAY be kept open if a UDP packet is received from the outside to the inside. Requirements for timing out these bindings are in section X.Y.Z. Section X.Y.Z can talk about timeouts being a MUST. In a glossary we need to define 'unicast traffic' as an IP packet with an IP source unicast address and IP destination unicast address. I feel we should be silent on multicast (and probably also IPsec Security Parameters Index (SPI)), so that they can be fully described in their own separate document. -d -----Original Message----- From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] Sent: Sunday, August 22, 2004 6:50 PM To: Francois Audet; Dan Wing; Behave; Jiri Kuthan Subject: UPD and Multicast scope Given the advice we got at the meeting, I would be happiest to propose we do the "UDP Unicast" stuff in one of our first documents then do the "Multicast" stuff in a later document. That said, I think that considering how our future work might break the UDP Unicast work is completely appropriate. We probably need some clue of how we might solve the multicast timeouts issues when we get to them and if that would require changers to the UDP document we need to contemplate that now. I can see several discussion paths we might pursue: treat multicast traffic differently do outbound keep alives in multicast applications update timeouts on inbound packets for unicast UDP Thoughts on pros/cons of these? Cullen From audet@nortelnetworks.com Mon, 23 Aug 2004 09:55:26 -0700 (PDT) From: "Francois Audet" Date: Mon, 23 Aug 2004 09:55:26 -0700 (PDT) Subject: [Ietf-behave] RE: UPD and Multicast scope Message-ID: <1ECE0EB50388174790F9694F77522CCF493101@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: UPD and Multicast scope I'm fine with this. The only issue is that this wording doesn't give any hints at why one would allow keep Unicast binding open on inbound UDP unicast, and what the tradeoff are. I think we would need to describe the security aspects of it (i.e., an interlocutor could keep the binding opened indefinitely after a conversation). In other words, I think Cullen's points 1 & 2 are what we really want, but 3 is acceptable. We just need to figure out wording for the Unicast document that will allow us to get there without contradicting ourselves. I do agree that we should say as little as possible about multicast in the unicast document. Perhaps we should make it clear in the introduction what the scope is. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Monday, August 23, 2004 09:44 > To: Cullen Jennings; Audet, Francois [SC100:9T51:EXCH]; > Behave; Jiri Kuthan > Subject: RE: UPD and Multicast scope > > > I like (1), because multicast is already handled differently > by the NATs -- to do multicast they have to see an IGMP from > the Ethernet-attached computer, propagate the IGMP towards > the service provider, and set up a NAT binding. > > What is critical in the base document is that the base BEHAVE > document allows incoming-only multicast packets to keep the > NAT binding open. I suggest the following straw-man wording > in BEHAVE: > > For unicast traffic, a binding MUST remain open if a UDP > packet is sent > from an inside address to an outside address. > Additionally, unicast UDP > bindings MAY be kept open if a UDP packet is received from the > outside to the inside. Requirements for timing out these bindings > are in section X.Y.Z. > > Section X.Y.Z can talk about timeouts being a MUST. In a > glossary we need to define 'unicast traffic' as an IP packet > with an IP source unicast address and IP destination unicast address. > > I feel we should be silent on multicast (and probably also > IPsec Security Parameters Index (SPI)), so that they can be > fully described in their own separate document. > > -d > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Sunday, August 22, 2004 6:50 PM > To: Francois Audet; Dan Wing; Behave; Jiri Kuthan > Subject: UPD and Multicast scope > > > > Given the advice we got at the meeting, I would be happiest > to propose we do the "UDP Unicast" stuff in one of our first > documents then do the "Multicast" stuff in a later document. > > That said, I think that considering how our future work might > break the UDP Unicast work is completely appropriate. We > probably need some clue of how we might solve the multicast > timeouts issues when we get to them and if that would require > changers to the UDP document we need to contemplate that now. > > I can see several discussion paths we might pursue: > > treat multicast traffic differently > do outbound keep alives in multicast applications > update timeouts on inbound packets for unicast UDP > > > Thoughts on pros/cons of these? > > Cullen > > From dwing@cisco.com Mon, 23 Aug 2004 10:26:13 -0700 (PDT) From: "Dan Wing" Date: Mon, 23 Aug 2004 10:26:13 -0700 (PDT) Subject: [Ietf-behave] RE: UPD and Multicast scope In-Reply-To: <1ECE0EB50388174790F9694F77522CCF493101@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: RE: UPD and Multicast scope
-----Original Message-----From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx]Sent: Monday, August 23, 2004 9:54 AMTo: 'Dan Wing'; 'Cullen Jennings'; 'Behave'; 'Jiri Kuthan'Subject: RE: UPD and Multicast scope I'm fine with this. The only issue is that this wording doesn't give any hints at why one would allow keep Unicast binding open on inbound UDP unicast, and what the tradeoff are. I think we would need to describe the security aspects of it (i.e., an interlocutor could keep the binding opened indefinitely after a conversation). I agree that needs to be in the document -- for all of the MUSTs and SHOULDs. However, there isn't a risk with someone keeping the binding open indefinately; the risk is that an open binding will cause packets to be sent to a host that (a) has no application listening on that port [and sends back an ICMP message] or (b) has a different application listening on that port. Those problems can be resolved with (1) a timer, (2)using new DHCP leases to break old NAT bindings, or (3) using some number of ICMP 'port unreachable' messages from the PCto close the NAT binding (akin to TCP RSTs and FINs which help to quickly close NAT bindings). There are probably a few other solutions, too, but these came to mind immediately. A timer is easy, but doesn't quite close things up neatly unless the timer is very short -- and a short timer means NAT keepalives have to be quite aggressive, which leads to scaling difficulties. Perhaps these fancier techniques, though, shouldn't be in BEHAVE? -d
In other words, I think Cullen's points 1 & 2 are what we really want, but 3 is acceptable. We just need to figure out wording for the Unicast document that will allow us to get there without contradicting ourselves. I do agree that we should say as little as possible about multicast in the unicast document. Perhaps we should make it clear in the introduction what the scope is. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Monday, August 23, 2004 09:44 > To: Cullen Jennings; Audet, Francois [SC100:9T51:EXCH]; > Behave; Jiri Kuthan > Subject: RE: UPD and Multicast scope > > > I like (1), because multicast is already handled differently > by the NATs -- to do multicast they have to see an IGMP from > the Ethernet-attached computer, propagate the IGMP towards > the service provider, and set up a NAT binding. > > What is critical in the base document is that the base BEHAVE > document allows incoming-only multicast packets to keep the > NAT binding open. I suggest the following straw-man wording > in BEHAVE: > > For unicast traffic, a binding MUST remain open if a UDP > packet is sent > from an inside address to an outside address. > Additionally, unicast UDP > bindings MAY be kept open if a UDP packet is received from the > outside to the inside. Requirements for timing out these bindings > are in section X.Y.Z. > > Section X.Y.Z can talk about timeouts being a MUST. In a > glossary we need to define 'unicast traffic' as an IP packet > with an IP source unicast address and IP destination unicast address. > > I feel we should be silent on multicast (and probably also > IPsec Security Parameters Index (SPI)), so that they can be > fully described in their own separate document. > > -d > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Sunday, August 22, 2004 6:50 PM > To: Francois Audet; Dan Wing; Behave; Jiri Kuthan > Subject: UPD and Multicast scope > > > > Given the advice we got at the meeting, I would be happiest > to propose we do the "UDP Unicast" stuff in one of our first > documents then do the "Multicast" stuff in a later document. > > That said, I think that considering how our future work might > break the UDP Unicast work is completely appropriate. We > probably need some clue of how we might solve the multicast > timeouts issues when we get to them and if that would require > changers to the UDP document we need to contemplate that now. > > I can see several discussion paths we might pursue: > > treat multicast traffic differently > do outbound keep alives in multicast applications > update timeouts on inbound packets for unicast UDP > > > Thoughts on pros/cons of these? > > Cullen > > From audet@nortelnetworks.com Mon, 23 Aug 2004 10:29:18 -0700 (PDT) From: "Francois Audet" Date: Mon, 23 Aug 2004 10:29:18 -0700 (PDT) Subject: RE: [Ietf-behave] UPD and Multicast scope Message-ID: <1ECE0EB50388174790F9694F77522CCF49314B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message I think what we are saying is that when we do publish the multicast document, it can not contradict the unicast document. The hooks must be in place in the unicast document so that a NAT manufacturer may decide after having produced a unicast-support compliant NAT, to enhance it for multicast-support compliancy, without contradicting the first RFC. As a concrete example: Vendor makes NAT that support unicast UDP with outgoing binding refresh only. Spec says "for unicast UDP, RECOMMEND outgoing binding only". Complies with first RFC. Very secure. 6 months later, the multicast document goes out. It says "for multicast UDP, SHALL support blablabla". Vendor adds multicast support. Complies with second RFC, still complies with first RFC, still very secure. A second concrete example: Vendor makes NAT that support unicast UDP with both outgoing and incoming binding refresh. Complies with first RFC, but not as secure as previous example. 6 months later the multicast document goes out. Vendor already supports multicast. Vendor updates the print on the boxes as it complies with second RFC. Of course, if we find out other things that are missing for multicast (which is likely), vendor may still have to do some work before claiming support for multicast.
-----Original Message-----From: Spencer Dawkins [mailto:spencer@xxxxxxxxxxxxx] Sent: Monday, August 23, 2004 04:30To: IETF Behave Mailing ListSubject: Re: [Ietf-behave] UPD and Multicast scope I'm not disagreeing on the "work on unicast UDP first" strategy, but I do have a question. If I understand the justification for BEHAVE, the idea is to have BCP-strength specifications that vendors and operators will use, and then (they will most likely) claim "BCP 110" (more likely "RFC 4112", but that's a NEWTRK problem) compliance. If we don't work on multicast at this time, I think we're saying "we don't care if people break multicast now - if their NATs drop all multicast traffic,they can stilll say they comply with IETF BCPs for NAT, and that's OK". Is that what we're saying? Spencer
----- Original Message -----
From: Cullen Jennings To: Francois Audet ; Dan Wing ; Behave ; Jiri Kuthan Sent: Sunday, August 22, 2004 8:49 PM Subject: [Ietf-behave] UPD and Multicast scope Given the advice we got at the meeting, I would be happiest to propose we do the "UDP Unicast" stuff in one of our first documents then do the "Multicast" stuff in a later document. That said, I think that considering how our future work might break the UDP Unicast work is completely appropriate. We probably need some clue of how we might solve the multicast timeouts issues when we get to them and if that would require changers to the UDP document we need to contemplate that now.I can see several discussion paths we might pursue: treat multicast traffic differently do outbound keep alives in multicast applications update timeouts on inbound packets for unicast UDPThoughts on pros/cons of these?Cullen From audet@nortelnetworks.com Mon, 23 Aug 2004 10:40:01 -0700 (PDT) From: "Francois Audet" Date: Mon, 23 Aug 2004 10:40:01 -0700 (PDT) Subject: [Ietf-behave] RE: UPD and Multicast scope Message-ID: <1ECE0EB50388174790F9694F77522CCF49316B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message .
I agree that needs to be in the document -- for all of the MUSTs and SHOULDs. However, there isn't a risk with someone keeping the binding open indefinately; the risk is that an open binding will cause packets to be sent to a host that (a) has no application listening on that port [and sends back an ICMP message] or (b) has a different application listening on that port. Those problems can be resolved with (1) a timer, (2)using new DHCP leases to break old NAT bindings, or (3) using some number of ICMP 'port unreachable' messages from the PCto close the NAT binding (akin to TCP RSTs and FINs which help to quickly close NAT bindings). There are probably a few other solutions, too, but these came to mind immediately. A timer is easy, but doesn't quite close things up neatly unless the timer is very short -- and a short timer means NAT keepalives have to be quite aggressive, which leads to scaling difficulties. Perhaps these fancier techniques, though, shouldn't be in BEHAVE? What worries me is(b). As an example,I may hang up, and phone somebody else right away.If my phone uses the same UDP port for every call (which many phonesdo), then I could be receiving from two places simultaneously (the real new call, and the other call that didn't hang up properly), with no good way for the phone to figure out which one is the right one. TheDHCP approach doesn't seem realistic to me: you might not even be using DHCP in the first place, and it would be quite slow. The timer approach works only if the outgoing traffic refreshes the binding but not the incoming (which is what we are discussing). The ICMP won't work if the phones want to use the same port. As you say, the techniques you are describing are valid, but not NAT-specific, and therefore not for BEHAVE (they could be described in a client document of course). I still think that we should put something in BEHAVE that encourage NAT vendors to minimize the chances of ports being kept opened from the outside. From dwing@cisco.com Mon, 23 Aug 2004 10:57:35 -0700 (PDT) From: "Dan Wing" Date: Mon, 23 Aug 2004 10:57:35 -0700 (PDT) Subject: [Ietf-behave] RE: UPD and Multicast scope In-Reply-To: <1ECE0EB50388174790F9694F77522CCF49316B@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Message
-----Original Message-----From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx]Sent: Monday, August 23, 2004 10:38 AMTo: 'Dan Wing'; 'Cullen Jennings'; 'Behave'; 'Jiri Kuthan'Subject: RE: UPD and Multicast scope .
I agree that needs to be in the document -- for all of the MUSTs and SHOULDs. However, there isn't a risk with someone keeping the binding open indefinately; the risk is that an open binding will cause packets to be sent to a host that (a) has no application listening on that port [and sends back an ICMP message] or (b) has a different application listening on that port. Those problems can be resolved with (1) a timer, (2)using new DHCP leases to break old NAT bindings, or (3) using some number of ICMP 'port unreachable' messages from the PCto close the NAT binding (akin to TCP RSTs and FINs which help to quickly close NAT bindings). There are probably a few other solutions, too, but these came to mind immediately. A timer is easy, but doesn't quite close things up neatly unless the timer is very short -- and a short timer means NAT keepalives have to be quite aggressive, which leads to scaling difficulties. Perhaps these fancier techniques, though, shouldn't be in BEHAVE? What worries me is(b). As an example,I may hang up, and phone somebody else right away.If my phone uses the same UDP port for every call (which many phonesdo), then I could be receiving from two places simultaneously (the real new call, and the other call that didn't hang up properly), with no good way for the phone to figure out which one is the right one. So if you don't have a NAT at all, this application would misbehave, right?That is, following the scenario above and without a NAT anywhereyou would hear the previous call's audio.
TheDHCP approach doesn't seem realistic to me: you might not even be using DHCP in the first place, and it would be quite slow. What's slow -- getting an IP address via DHCP? My Linksys boxresponds to DHCP requests prettyquickly inmy experience, although I have never timed it. I do agree expectingDHCP isn't ideal. Instead, you could notice a new MAC address for a new host.
The timer approach works only if the outgoing traffic refreshes the binding but not the incoming (which is what we are discussing). The ICMP won't work if the phones want to use the same port. The timer only solves the scenario you're describing if the phone stays onhook for the timer duration. So if I'm calling "quickly", and the timer is a very aggressive 10 seconds, the timer won't be effective to resolve this scenario.
As you say, the techniques you are describing are valid, but not NAT-specific, and therefore not for BEHAVE (they could be described in a client document of course). I still think that we should put something in BEHAVE that encourage NAT vendors to minimize the chances of ports being kept opened from the outside. I agree. Let's continue evolving strawman text. -d From audet@nortelnetworks.com Mon, 23 Aug 2004 11:30:08 -0700 (PDT) From: "Francois Audet" Date: Mon, 23 Aug 2004 11:30:08 -0700 (PDT) Subject: [Ietf-behave] RE: UPD and Multicast scope Message-ID: <1ECE0EB50388174790F9694F77522CCF56329E@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message
What worries me is(b). As an example,I may hang up, and phone somebody else right away.If my phone uses the same UDP port for every call (which many phonesdo), then I could be receiving from two places simultaneously (the real new call, and the other call that didn't hang up properly), with no good way for the phone to figure out which one is the right one. So if you don't have a NAT at all, this application would misbehave, right?That is, following the scenario above and without a NAT anywhereyou would hear the previous call's audio. I see your point. I'm taking the view that people buy NATs not just for NATing, but also for some protection. This is perhaps outside of the charter of BEHAVE. I'm not sure. Cullen? Jiri?
I still think that we should put something in BEHAVE that encourage NAT vendors to minimize the chances of ports being kept opened from the outside. I agree. Let's continue evolving strawman text. Yes, I think your current strawman is a good start. From dwing@cisco.com Mon, 23 Aug 2004 11:47:39 -0700 (PDT) From: "Dan Wing" Date: Mon, 23 Aug 2004 11:47:39 -0700 (PDT) Subject: [Ietf-behave] RE: UPD and Multicast scope In-Reply-To: <1ECE0EB50388174790F9694F77522CCF56329E@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Message
-----Original Message-----From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx]Sent: Monday, August 23, 2004 11:29 AMTo: 'Dan Wing'; 'Cullen Jennings'; 'Behave'; 'Jiri Kuthan'Subject: RE: UPD and Multicast scope
What worries me is(b). As an example,I may hang up, and phone somebody else right away.If my phone uses the same UDP port for every call (which many phonesdo), then I could be receiving from two places simultaneously (the real new call, and the other call that didn't hang up properly), with no good way for the phone to figure out which one is the right one. So if you don't have a NAT at all, this application would misbehave, right?That is, following the scenario above and without a NAT anywhereyou would hear the previous call's audio. I see your point. I'm taking the view that people buy NATs not just for NATing, but also for some protection. I agree folks buy NATs for this reason. It's one of the reasons I personally have a NAT (the is to share one IP address). But if an application behaves as you describe, the user will continue to hear the previous conversation without a NAT. I don't see how a NAT could, or should, prevent the described application behavior. -d
This is perhaps outside of the charter of BEHAVE. I'm not sure. Cullen? Jiri?
I still think that we should put something in BEHAVE that encourage NAT vendors to minimize the chances of ports being kept opened from the outside. I agree. Let's continue evolving strawman text. Yes, I think your current strawman is a good start. From gih@apnic.net Mon, 23 Aug 2004 15:56:04 -0700 (PDT) From: Geoff Huston Date: Mon, 23 Aug 2004 15:56:04 -0700 (PDT) Subject: Re: [Ietf-behave] UPD and Multicast scope In-Reply-To: Message-ID: <6.0.1.1.2.20040824081744.01fefec0@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: text/plain Spencer, you seem to be taking that view that the period between these two documents would be an extended one - perhaps measured in geological eons ( :-) ). While that may indeed be a useful metric for measuring the progress of IETF documents these days, I'm not sure that it has to be this way, and in the case of writing down NAT behaviours and what is a reasonable set of such behaviours for various protocol, it would be definitely be preferable to produce these documents in a scale of months, so the time period between the UDP specification and multicast would be minor. Geoff At 09:29 PM 23/08/2004, Spencer Dawkins wrote: I'm not disagreeing on the "work on unicast UDP first" strategy, but I do have a question. If I understand the justification for BEHAVE, the idea is to have BCP-strength specifications that vendors and operators will use, and then (they will most likely) claim "BCP 110" (more likely "RFC 4112", but that's a NEWTRK problem) compliance. If we don't work on multicast at this time, I think we're saying "we don't care if people break multicast now - if their NATs drop all multicast traffic, they can stilll say they comply with IETF BCPs for NAT, and that's OK". Is that what we're saying? Spencer ----- Original Message ----- From: Cullen Jennings To: Francois Audet ; Dan Wing ; Behave ; Jiri Kuthan Sent: Sunday, August 22, 2004 8:49 PM Subject: [Ietf-behave] UPD and Multicast scope Given the advice we got at the meeting, I would be happiest to propose we do the "UDP Unicast" stuff in one of our first documents then do the "Multicast" stuff in a later document. That said, I think that considering how our future work might break the UDP Unicast work is completely appropriate. We probably need some clue of how we might solve the multicast timeouts issues when we get to them and if that would require changers to the UDP document we need to contemplate that now. I can see several discussion paths we might pursue: * treat multicast traffic differently * do outbound keep alives in multicast applications * update timeouts on inbound packets for unicast UDP Thoughts on pros/cons of these? Cullen _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Tue, 24 Aug 2004 21:37:20 -0700 (PDT) From: "Dan Wing" Date: Tue, 24 Aug 2004 21:37:20 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behave draft In-Reply-To: <1ECE0EB50388174790F9694F77522CCF492640@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Thursday, August 19, Francois Audet wrote: > I guess one question I have is, does Multicast work > today with home NATs? It's available as a feature on my 3-year-old Linksys NAT box, but I have never tried using it so I don't know if it actually works. -d From dwing@cisco.com Wed, 25 Aug 2004 13:50:00 -0700 (PDT) From: "Dan Wing" Date: Wed, 25 Aug 2004 13:50:00 -0700 (PDT) Subject: RE: [Ietf-behave] UPD and Multicast scope In-Reply-To: <6.0.1.1.2.20040824081744.01fefec0@kahuna.telstra.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Geoff wrote: > Spencer, you seem to be taking that view that the period between these > two documents would be an extended one - perhaps measured in > geological eons ( :-) ). While that may indeed be a useful metric for > measuring the progress of IETF documents these days, I'm not sure that > it has to be this way, and in the case of writing down NAT behaviours > and what is a reasonable set of such behaviours for various protocol, > it would be definitely be preferable to produce these documents in a > scale of months, so the time period between the UDP specification and > multicast would be minor. With that in mind, I believe we're attempting to write the following documents in this yet-to-be-formed working group: 1. base BEHAVE document for UDP, TCP, fragmentation, and ICMP (based on draft-audet-nat-behave-00.txt) 2. separate document for UDP multicast receivers 3. separate document for IPsec initiators Can we safely combine (1) and (3) without delaying things? -d From dwing@cisco.com Mon, 30 Aug 2004 18:07:21 -0700 (PDT) From: "Dan Wing" Date: Mon, 30 Aug 2004 18:07:21 -0700 (PDT) Subject: RE: [Ietf-behave] RE: UPD and Multicast scope In-Reply-To: <20040827075540.GT5824@sunbeam.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > On Mon, Aug 23, 2004 at 10:57:33AM -0700, Dan Wing wrote: > > The DHCP approach doesn't seem realistic to me: you might not even be > > using DHCP in the first place, and it would be quite slow. > > > > What's slow -- getting an IP address via DHCP? My Linksys box > > responds to > > DHCP requests pretty quickly in my experience, although I have > > never timed it. > > It don't like the idea of requiring/recommending NAT devices use DHCP in > their internal network. There are lots of setups which use static IP's, > and that's perfectly fine. Fine - I agree with that. But I'm still not understand what is slow. To catch everyone else up, Francois Audet had written: The DHCP approach doesn't seem realistic to me: you might not even be using DHCP in the first place, and it would be quite slow. And I asked what is "quite slow". > > The timer approach works only if the outgoing traffic refreshes the > > binding but not the incoming (which is what we are discussing). > > > > The ICMP won't work if the phones want to use the same port. > > so why don't we just require the BEHAVE-compliant protocols to not reuse > the same UDP port for a given time 'X'. 'X' is to be defined larger > than the timeout for inbound NAT refreshing, so we're guaranteed that > the internal host will at least send ICMP port unreachable once. When such behavior occurs on a host, I don't see the new side-effect that a NAT causes. If there is a side effect that a NAT causes, could you or Francois describe it? -d > > I still think that we should put something in BEHAVE that > > encourage NAT > > vendors to minimize the chances of ports being kept opened from > > the outside. > > > > -- > - Harald Welte http://www.gnumonks.org/ ============================================================================ Programming is like sex: One mistake and you have to support it your lifetime From audet@nortelnetworks.com Tue, 31 Aug 2004 10:03:57 -0700 (PDT) From: "Francois Audet" Date: Tue, 31 Aug 2004 10:03:57 -0700 (PDT) Subject: RE: [Ietf-behave] RE: UPD and Multicast scope Message-ID: <1ECE0EB50388174790F9694F77522CCF6B1766@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] RE: UPD and Multicast scope > But I'm still not understand what is slow. To catch everyone > else up, Francois Audet had written: > > The DHCP approach doesn't seem realistic to me: you might > not even be > using DHCP in the first place, and it would be quite slow. > > And I asked what is "quite slow". Perhaps it doesn't matter how fast it is. I don't think using DHCP is the way to address this problem anyways. As mentioned above, static configurations are used. I think we can put that issue to rest. > > > The timer approach works only if the outgoing traffic refreshes > > > the binding but not the incoming (which is what we are > discussing). > > > > > > The ICMP won't work if the phones want to use the same port. > > > > so why don't we just require the BEHAVE-compliant protocols to not > > reuse the same UDP port for a given time 'X'. 'X' is to be defined > > larger than the timeout for inbound NAT refreshing, so we're > > guaranteed that the internal host will at least send ICMP port > > unreachable once. > > When such behavior occurs on a host, I don't see the new > side-effect that a NAT causes. If there is a side effect > that a NAT causes, could you or Francois describe it? I'm not sure I'm following the train of thought for this question (and the previous suggestion about no re-using the same port). Can you elaborate? From audet@nortelnetworks.com Tue, 31 Aug 2004 16:08:03 -0700 (PDT) From: "Francois Audet" Date: Tue, 31 Aug 2004 16:08:03 -0700 (PDT) Subject: [Ietf-behave] Where we are with draft-audet-nat-behave Message-ID: <1ECE0EB50388174790F9694F77522CCF6B1B0B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Where we are with draft-audet-nat-behave I'd like to summarize where I think we are with draft-audet-nat-behave. I would like to be able to issue a new release of the document soon, so I will put on the table the things that were agreed-to in San Diego, and what my take is on the mailing list discussions. I'm writing this from the point of view of the changes to expect between version -00 and -01. I would like to advance the document to a new version, with the things that have a good concensus on, and highlight where there is no concensus yet. I'd like to get a view of "yes/no" on the following bullet items. 1 - From San Diego, it was agreed to explicitely limit the scope to NATs, and exclude Firewalls. The document will make that clear, and will only cover the intrinsic filtering aspects of NATs. 2 - I believe we have a broad concensus that this first document will ONLY cover UDP Unicast. TCP, Multicast, ICMP, etc. are to be covered in later draft(s). 3 - I'm not sure if we should include fragmentation or not (any views?). 4 - We will still try to think a bit about UDP multicast, and try to ensure our UDP unicast requirements will not make supporting UDP multicast later on problematic. (see 7) 5 - From San Diego: state that scope stops at UDP layer (i.e., RTP, or ALGs are out-of-scope). No looking at embedded addresses for example. 6 - From San Diego: State that one of the goals is to lessen the dependence on Media Relays. 7 - On the binding refresh issue, as it stands now, I am inclined to go with Dan Wing's suggestion which essentialy says that "Outbound traffic MUST refresh the binding" and "Inbound traffic MAY also refresh the binding". (I.e., I've been convinced by the arguments against the "outbound-only" position I was advocating earlier). And we will be silent on multicast. Can you guys tell me what you think? Thanks. ---- Franois AUDET, Nortel Networks Tel: +1 408 495 3756 From gih@apnic.net Tue, 31 Aug 2004 16:43:48 -0700 (PDT) From: Geoff Huston Date: Tue, 31 Aug 2004 16:43:48 -0700 (PDT) Subject: Re: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <1ECE0EB50388174790F9694F77522CCF6B1B0B@zrc2hxm0.corp.nortel.com> Message-ID: <6.0.1.1.2.20040901092837.0211bec0@localhost> MIME-Version: 1.0 Content-Type: text/plain I'd like to get a view of "yes/no" on the following bullet items. thanks - my responses are listed against your items.... 1 - From San Diego, it was agreed to explicitely limit the scope to NATs, and exclude Firewalls. The document will make that clear, and will only cover the intrinsic filtering aspects of NATs. yes 2 - I believe we have a broad concensus that this first document will ONLY cover UDP Unicast. TCP, Multicast, ICMP, etc. are to be covered in later draft(s). yes 3 - I'm not sure if we should include fragmentation or not (any views?). Fragmentation should be included in my view - it is part of the variability of NAT implementations today and some clear statement of behavioural variability that are seen today would be helpful imho. 4 - We will still try to think a bit about UDP multicast, and try to ensure our UDP unicast requirements will not make supporting UDP multicast later on problematic. (see 7) yes - although I'm cautious about this, as it may reopen the previous question! 5 - From San Diego: state that scope stops at UDP layer (i.e., RTP, or ALGs are out-of-scope). No looking at embedded addresses for example. yes 6 - From San Diego: State that one of the goals is to lessen the dependence on Media Relays. yes - assuming that the distinction here is between media relays and application agents. 7 - On the binding refresh issue, as it stands now, I am inclined to go with Dan Wing's suggestion which essentialy says that "Outbound traffic MUST refresh the binding" and "Inbound traffic MAY also refresh the binding". (I.e., I've been convinced by the arguments against the "outbound-only" position I was advocating earlier). And we will be silent on multicast. yes regards, Geoff From dwing@cisco.com Tue, 31 Aug 2004 17:22:10 -0700 (PDT) From: "Dan Wing" Date: Tue, 31 Aug 2004 17:22:10 -0700 (PDT) Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <1ECE0EB50388174790F9694F77522CCF6B1B0B@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain ... > 2 - I believe we have a broad concensus that this first > document will ONLY cover UDP Unicast. TCP, Multicast, ICMP, > etc. are to be covered in later draft(s). I believe we need to cover UDP and ICMP as the received ICMP message apply to those UDP packets that were sent by the NAT. If a NAT 'eats' an ICMP message, or uses a certain ICMP message to close its UDP binding, it has significant operational effects on an application -- especially if the application didn't receive the ICMP message (due to congestion on the home Ethernet network or home wireless network, for example). Similarly, I believe the TCP document needs to describe ICMP as those ICMP messages apply to the TCP packets that were sent by the NAT. > 3 - I'm not sure if we should include fragmentation or > not (any views?). I agree with Geoff - the handling of fragmentation is variable and needs to be discussed. This doesn't mean we'll necessarily require reassembly in a NAT to be BEHAVE-compliant, but we need to describe how fragmentation in should be handled. We need to discuss both incoming fragmentation (packet arrives in fragments) and outgoing fragmentation (I believe there are two cases, (a) host set DF=1, and NAT discovers the access link is too small to handle it [PPPoE], and (b) NAT sends packet and receives ICMP 'fragmentation needed DF set' packet, what should it do. To do this, we'll need to mention ICMP ('fragmentation needed DF set'). ... > Can you guys tell me what you think? The others items all sound fine to me. -d From audet@nortelnetworks.com Tue, 31 Aug 2004 17:28:55 -0700 (PDT) From: "Francois Audet" Date: Tue, 31 Aug 2004 17:28:55 -0700 (PDT) Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave Message-ID: <1ECE0EB50388174790F9694F77522CCF6B1B55@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Where we are with draft-audet-nat-behave OK. Perfect. Thanks. Should we keep ICMP and Fragmentation as separate items, or should they be combined? (In the current document, they are separate). Any suggestions on wording are welcomed. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Tuesday, August 31, 2004 17:22 > To: Audet, Francois [SC100:9T51:EXCH]; 'Behave' > Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave > > > ... > > 2 - I believe we have a broad concensus that this first > > document will ONLY cover UDP Unicast. TCP, Multicast, ICMP, > > etc. are to be covered in later draft(s). > > I believe we need to cover UDP and ICMP as the received ICMP > message apply to those UDP packets that were sent by the NAT. > > If a NAT 'eats' an ICMP message, or uses a certain ICMP message > to close its UDP binding, it has significant operational > effects on an application -- especially if the application > didn't receive the ICMP message (due to congestion on the > home Ethernet network or home wireless network, for example). > > Similarly, I believe the TCP document needs to describe ICMP > as those ICMP messages apply to the TCP packets that were > sent by the NAT. > > > 3 - I'm not sure if we should include fragmentation or > > not (any views?). > > I agree with Geoff - the handling of fragmentation is > variable and needs to be discussed. This doesn't mean we'll > necessarily require reassembly in a NAT to be > BEHAVE-compliant, but we need to describe how fragmentation > in should be handled. > > We need to discuss both incoming fragmentation (packet > arrives in fragments) and outgoing fragmentation (I believe > there are two cases, (a) host set DF=1, and NAT discovers the > access link > is too small to handle it [PPPoE], and (b) NAT sends packet > and receives ICMP 'fragmentation needed DF set' packet, what > should it do. > > To do this, we'll need to mention ICMP ('fragmentation needed > DF set'). > > ... > > Can you guys tell me what you think? > > The others items all sound fine to me. > > -d > > From jdrosen@dynamicsoft.com Tue, 31 Aug 2004 19:32:55 -0700 (PDT) From: Jonathan Rosenberg Date: Tue, 31 Aug 2004 19:32:55 -0700 (PDT) Subject: Re: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <1ECE0EB50388174790F9694F77522CCF6B1B0B@zrc2hxm0.corp.nortel.com> Message-ID: <413534D0.70901@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain My take inline: Francois Audet wrote: I'd like to summarize where I think we are with draft-audet-nat-behave. I would like to be able to issue a new release of the document soon, so I will put on the table the things that were agreed-to in San Diego, and what my take is on the mailing list discussions. I'm writing this from the point of view of the changes to expect between version -00 and -01. I would like to advance the document to a new version, with the things that have a good concensus on, and highlight where there is no concensus yet. I'd like to get a view of "yes/no" on the following bullet items. 1 - From San Diego, it was agreed to explicitely limit the scope to NATs, and exclude Firewalls. The document will make that clear, and will only cover the intrinsic filtering aspects of NATs. Yes. 2 - I believe we have a broad concensus that this first document will ONLY cover UDP Unicast. TCP, Multicast, ICMP, etc. are to be covered in later draft(s). I think separate drafts are fine, but there are UDP/ICMP interactions as has already been commented. As such, the ICMP and UDP documents may need to be done jointly. 3 - I'm not sure if we should include fragmentation or not (any views?). Definitely yes! 4 - We will still try to think a bit about UDP multicast, and try to ensure our UDP unicast requirements will not make supporting UDP multicast later on problematic. (see 7) Yes. 5 - From San Diego: state that scope stops at UDP layer (i.e., RTP, or ALGs are out-of-scope). No looking at embedded addresses for example. Yes. 6 - From San Diego: State that one of the goals is to lessen the dependence on Media Relays. Yes. 7 - On the binding refresh issue, as it stands now, I am inclined to go with Dan Wing's suggestion which essentialy says that "Outbound traffic MUST refresh the binding" and "Inbound traffic MAY also refresh the binding". (I.e., I've been convinced by the arguments against the "outbound-only" position I was advocating earlier). And we will be silent on multicast. OK. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From spencer@mcsr-labs.org Wed, 1 Sep 2004 04:46:51 -0700 (PDT) From: "Spencer Dawkins" Date: Wed, 1 Sep 2004 04:46:51 -0700 (PDT) Subject: Re: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <1ECE0EB50388174790F9694F77522CCF6B1B55@zrc2hxm0.corp.nortel.com> Message-ID: <066201c49019$6a5f9e50$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Where we are with draft-audet-nat-behave So, we're talking about the difference between NAT effects on traffic that is actually fragmented, and NAT effects on P-MTU Discovery, right? These seem to be separate topics in my mind. Spencer
----- Original Message -----
From: Francois Audet To: 'Dan Wing' ; 'Behave' Sent: Tuesday, August 31, 2004 7:27 PM Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave OK. Perfect. Thanks. Should we keep ICMP and Fragmentation as separate items, or should they be combined? (In the current document, they are separate). From mshore@cisco.com Wed, 1 Sep 2004 07:46:54 -0700 (PDT) From: Melinda Shore Date: Wed, 1 Sep 2004 07:46:54 -0700 (PDT) Subject: Re: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <1ECE0EB50388174790F9694F77522CCF6B1B0B@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Tuesday, August 31, 2004, at 07:05 PM, Francois Audet wrote: 1 - From San Diego, it was agreed to explicitely limit the scope to NATs, and exclude Firewalls. The document will make that clear, and will only cover the intrinsic filtering aspects of NATs. Absolutely. 2 - I believe we have a broad concensus that this first document will ONLY cover UDP Unicast. TCP, Multicast, ICMP, etc. are to be covered in later draft(s). Yes 3 - I'm not sure if we should include fragmentation or not (any views?). Definitely, if the goal is to describe what NAT designers need to do to make their devices more well-behaved. 4 - We will still try to think a bit about UDP multicast, and try to ensure our UDP unicast requirements will not make supporting UDP multicast later on problematic. (see 7) Okay. 5 - From San Diego: state that scope stops at UDP layer (i.e., RTP, or ALGs are out-of-scope). No looking at embedded addresses for example. I'd state it a little differently - that we're dealing only with transport layer and below issues. 6 - From San Diego: State that one of the goals is to lessen the dependence on Media Relays. Meh. I'd try to keep this from being too voice-ish. Media relays are an instance of a broader class of problem, which is the (perceived) need to introduce new devices and functions into networks in order to work around problems introduced by NAT. Other applications, notably online gaming and peer-to-peer applications, have the same problem. I'd prefer to see this broadened. 7 - On the binding refresh issue, as it stands now, I am inclined to go with Dan Wing's suggestion which essentialy says that "Outbound traffic MUST refresh the binding" and "Inbound traffic MAY also refresh the binding". (I.e., I've been convinced by the arguments against the "outbound-only" position I was advocating earlier). And we will be silent on multicast. Yes. Melinda From dwing@cisco.com Wed, 1 Sep 2004 08:51:23 -0700 (PDT) From: "Dan Wing" Date: Wed, 1 Sep 2004 08:51:23 -0700 (PDT) Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <1ECE0EB50388174790F9694F77522CCF6B1B55@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > OK. Perfect. Thanks. > > Should we keep ICMP and Fragmentation as separate > items, or should they be combined? (In the current > document, they are separate). There are three issues around fragmentation: 1. The NAT trying to send a packet that exceeds the MTU of the local access link. This can occur if the NAT is doing PPPoE, as is common on many DSL networks. This packet could have DF=1 or DF=0. If it has DF=1, we need to describe what the NAT should do (I suggest a properly-behaving NAT would behave like a router in this instance, and send back an ICMP message to the host, and the host then Does The Right thing per Path MTU Discovery). A question, though, is how well PMTUD works for UDP in Windows and various other common PC operating systems. PMTUD has been historically pretty spotty for TCP.. If it has DF=0, the NAT should fragment the packet and send the fragments. This is the same function a router performs with DF=0 and a smaller MTU on the egress interface. 2. The NAT sending a packet that exceeds the MTU of some link in the middle of the network. In this case the NAT will receive an ICMP 'fragmentation needed DF set' message. I suggest we follow the router requirements here, too, and that the NAT is sends the ICMP message to the host. This incoming packet cannot destroy the NAT binding. I don't care if the incoming packet extends the lifetime of the binding. 3. The NAT receives a fragmented UDP packet. The IP packet containing the UDP header could arrive first or last - depending on network conditions, packet ordering, and the implementation of the sending IP stack. The easiest thing is to discard such packets. However, this is problematic for relatively obvious reasons. The easiest thing which works well is to keep the fragments in memory and, when the fragment containing the UDP header is received, to send all of the fragments to the appropriate NAT binding. This has obvious denial of service implications, though, but we can discuss several mitigations that implementors can safely use. I feel that (1) and (2) can be discussed together, and (3) should be in a separate section, like you have them now. But I think (1) and (2) are sufficiently distinct that they should be discussed individually. > Any suggestions on wording are welcomed. I'll try to get a few paragraphs built later this week. -d > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Tuesday, August 31, 2004 17:22 > To: Audet, Francois [SC100:9T51:EXCH]; 'Behave' > Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave > > > ... > > 2 - I believe we have a broad concensus that this first > > document will ONLY cover UDP Unicast. TCP, Multicast, ICMP, > > etc. are to be covered in later draft(s). > > I believe we need to cover UDP and ICMP as the received ICMP > message apply to those UDP packets that were sent by the NAT. > > If a NAT 'eats' an ICMP message, or uses a certain ICMP message > to close its UDP binding, it has significant operational > effects on an application -- especially if the application > didn't receive the ICMP message (due to congestion on the > home Ethernet network or home wireless network, for example). > > Similarly, I believe the TCP document needs to describe ICMP > as those ICMP messages apply to the TCP packets that were > sent by the NAT. > > > 3 - I'm not sure if we should include fragmentation or > > not (any views?). > > I agree with Geoff - the handling of fragmentation is > variable and needs to be discussed. This doesn't mean we'll > necessarily require reassembly in a NAT to be > BEHAVE-compliant, but we need to describe how fragmentation > in should be handled. > > We need to discuss both incoming fragmentation (packet > arrives in fragments) and outgoing fragmentation (I believe > there are two cases, (a) host set DF=1, and NAT discovers the > access link > is too small to handle it [PPPoE], and (b) NAT sends packet > and receives ICMP 'fragmentation needed DF set' packet, what > should it do. > > To do this, we'll need to mention ICMP ('fragmentation needed > DF set'). > > ... > > Can you guys tell me what you think? > > The others items all sound fine to me. > > -d > > From audet@nortelnetworks.com Wed, 1 Sep 2004 09:10:28 -0700 (PDT) From: "Francois Audet" Date: Wed, 1 Sep 2004 09:10:28 -0700 (PDT) Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave Message-ID: <1ECE0EB50388174790F9694F77522CCF78645F@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Where we are with draft-audet-nat-behave > > 5 - From San Diego: state that scope stops at UDP layer > (i.e., RTP, or > > ALGs are out-of-scope). No looking at embedded addresses for > > example. > > I'd state it a little differently - that we're dealing only with > transport > layer and below issues. Yeah, some people have problems with that terminology. I'll try to find some appropriate wording. Since the scope of the document is only UDP, it shouldn't be too difficult. > > 6 - From San Diego: State that one of the goals is to lessen the > > dependence on Media Relays. > > Meh. I'd try to keep this from being too voice-ish. Media > relays are an instance of a broader class of problem, which > is the (perceived) need to introduce new devices and > functions into networks in order to work around problems > introduced by NAT. Other applications, notably online gaming > and peer-to-peer applications, have the same problem. I'd > prefer to see this broadened. OK. What about just talking about "relays" in a very general way? From dwing@cisco.com Wed, 1 Sep 2004 10:53:43 -0700 (PDT) From: "Dan Wing" Date: Wed, 1 Sep 2004 10:53:43 -0700 (PDT) Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <1ECE0EB50388174790F9694F77522CCF78645F@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain >>> > 6 - From San Diego: State that one of the goals is to lessen the >>> > dependence on Media Relays. >> >> Meh. I'd try to keep this from being too voice-ish. Media >> relays are an instance of a broader class of problem, which >> is the (perceived) need to introduce new devices and >> functions into networks in order to work around problems >> introduced by NAT. Other applications, notably online gaming >> and peer-to-peer applications, have the same problem. I'd >> prefer to see this broadened. > > OK. What about just talking about "relays" in a very general way? Be careful that you don't define a SIP Proxy or DNS server as a 'relay' -- unless that's your intent. -d From audet@nortelnetworks.com Wed, 1 Sep 2004 11:27:57 -0700 (PDT) From: "Francois Audet" Date: Wed, 1 Sep 2004 11:27:57 -0700 (PDT) Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave Message-ID: <1ECE0EB50388174790F9694F77522CCF7865F8@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Where we are with draft-audet-nat-behave Good point. Of course, the other alternative is not to talk about it at all.. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Wednesday, September 01, 2004 10:54 > To: Audet, Francois [SC100:9T51:EXCH]; 'Melinda Shore' > Cc: 'Behave' > Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave > > > >>> > 6 - From San Diego: State that one of the goals is to lessen the > >>> > dependence on Media Relays. > >> > >> Meh. I'd try to keep this from being too voice-ish. Media relays > >> are an instance of a broader class of problem, which is the > >> (perceived) need to introduce new devices and functions > into networks > >> in order to work around problems introduced by NAT. Other > >> applications, notably online gaming and peer-to-peer applications, > >> have the same problem. I'd prefer to see this broadened. > > > > OK. What about just talking about "relays" in a very general way? > > Be careful that you don't define a SIP Proxy or DNS server as > a 'relay' -- unless that's your intent. > > -d > > From mshore@cisco.com Wed, 1 Sep 2004 11:40:38 -0700 (PDT) From: Melinda Shore Date: Wed, 1 Sep 2004 11:40:38 -0700 (PDT) Subject: Re: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <1ECE0EB50388174790F9694F77522CCF78645F@zrc2hxm0.corp.nortel.com> Message-ID: <560138A8-FC46-11D8-B4E7-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Wednesday, September 1, 2004, at 12:09 PM, Francois Audet wrote: OK. What about just talking about "relays" in a very general way? My preference would be to drop any mention of relays completely and keep the focus on the things that NATs must do to be good network citizens. Melinda From dwing@cisco.com Wed, 1 Sep 2004 12:24:14 -0700 (PDT) From: "Dan Wing" Date: Wed, 1 Sep 2004 12:24:14 -0700 (PDT) Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <1ECE0EB50388174790F9694F77522CCF7865F8@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I propose the following wording: A NAT device compliant with this document will not need an external UDP relay devices solely for UDP traversal of the NAT device. SIP proxies and DNS servers don't exist solely for UDP traversal of NATs. However, I suppose one could argue that user-facing media relay exists for purposes other than NAT traversal. Can anyone enumerate those other purposes? -d -----Original Message----- From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx] Sent: Wednesday, September 01, 2004 11:26 AM To: 'Dan Wing'; 'Melinda Shore' Cc: 'Behave' Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave Good point. Of course, the other alternative is not to talk about it at all.. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Wednesday, September 01, 2004 10:54 > To: Audet, Francois [SC100:9T51:EXCH]; 'Melinda Shore' > Cc: 'Behave' > Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave > > > >>> > 6 - From San Diego: State that one of the goals is to lessen the > >>> > dependence on Media Relays. > >> > >> Meh. I'd try to keep this from being too voice-ish. Media relays > >> are an instance of a broader class of problem, which is the > >> (perceived) need to introduce new devices and functions > into networks > >> in order to work around problems introduced by NAT. Other > >> applications, notably online gaming and peer-to-peer applications, > >> have the same problem. I'd prefer to see this broadened. > > > > OK. What about just talking about "relays" in a very general way? > > Be careful that you don't define a SIP Proxy or DNS server as > a 'relay' -- unless that's your intent. > > -d > > From audet@nortelnetworks.com Wed, 1 Sep 2004 14:47:48 -0700 (PDT) From: "Francois Audet" Date: Wed, 1 Sep 2004 14:47:48 -0700 (PDT) Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave Message-ID: <1ECE0EB50388174790F9694F77522CCF786624@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Where we are with draft-audet-nat-behave OK. So we have one vote for "no mention of UDP relays". Any other votes? If I don't hear anything, I'll leave it out (as per the current draft). > -----Original Message----- > From: Melinda Shore [mailto:mshore@xxxxxxxxx] > Sent: Wednesday, September 01, 2004 11:40 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Re: [Ietf-behave] Where we are with draft-audet-nat-behave > > > On Wednesday, September 1, 2004, at 12:09 PM, Francois Audet wrote: > > OK. What about just talking about "relays" in a very general way? > > My preference would be to drop any mention of relays > completely and keep the focus on the things that NATs must do > to be good network citizens. > > Melinda > > From jdrosen@dynamicsoft.com Wed, 1 Sep 2004 18:49:17 -0700 (PDT) From: Jonathan Rosenberg Date: Wed, 1 Sep 2004 18:49:17 -0700 (PDT) Subject: Re: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: Message-ID: <41365AF3.3040705@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain inline. Dan Wing wrote: I propose the following wording: A NAT device compliant with this document will not need an external UDP relay devices solely for UDP traversal of the NAT device. SIP proxies and DNS servers don't exist solely for UDP traversal of NATs. However, I suppose one could argue that user-facing media relay exists for purposes other than NAT traversal. Can anyone enumerate those other purposes? They are often used for not-so-nice things, primarily lawful intercept. However, I dont think we need to go into those other reasons at all. I believe you have captured it correctly - the objective is not to require yet another intermediary device *solely* for the purposes of traversing the nat. If one needs to be there for other reasons, that another story entirely and outside of the scope of this document. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From dwing@cisco.com Wed, 1 Sep 2004 23:06:25 -0700 (PDT) From: "Dan Wing" Date: Wed, 1 Sep 2004 23:06:25 -0700 (PDT) Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <41365AF3.3040705@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > > However, I suppose one could argue that user-facing media relay > > exists for > > purposes other than NAT traversal. Can anyone enumerate those other > > purposes? > > They are often used for not-so-nice things, primarily lawful intercept. draft-baker-slem-architecture-02.txt is a superior way to provide LI, and can perform LI for all services -- not just for cooperative voice services that go through a media relay in the (in)appropriate country that wants a wiretap. > However, I dont think we need to go into those other reasons at all. I > believe you have captured it correctly - the objective is not to require > yet another intermediary device *solely* for the purposes of traversing > the nat. If one needs to be there for other reasons, that another story > entirely and outside of the scope of this document. Thanks, -d From jdrosen@dynamicsoft.com Thu, 2 Sep 2004 06:16:55 -0700 (PDT) From: Jonathan Rosenberg Date: Thu, 2 Sep 2004 06:16:55 -0700 (PDT) Subject: Re: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: Message-ID: <41371CD3.5040005@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain Dan Wing wrote: However, I suppose one could argue that user-facing media relay exists for purposes other than NAT traversal. Can anyone enumerate those other purposes? They are often used for not-so-nice things, primarily lawful intercept. draft-baker-slem-architecture-02.txt is a superior way to provide LI, and can perform LI for all services -- not just for cooperative voice services that go through a media relay in the (in)appropriate country that wants a wiretap. I agree. However, the question wasnt whether or not I think LI should be done in one way or another. The question was whether there were ever reasons why someone might want a relay besides nat traversal. I think the answer is yes, but I still believe the question is moot as far as this document is concerned. I am fine with the statement that our objective is to eliminate the need to install a packet relay solely for the purpose of nat traversal. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From dwing@cisco.com Thu, 2 Sep 2004 08:06:17 -0700 (PDT) From: "Dan Wing" Date: Thu, 2 Sep 2004 08:06:17 -0700 (PDT) Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <41371CD3.5040005@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > >>>However, I suppose one could argue that user-facing media relay > >>>exists for > >>>purposes other than NAT traversal. Can anyone enumerate those other > >>>purposes? > >> > >>They are often used for not-so-nice things, primarily lawful intercept. > > > > > > draft-baker-slem-architecture-02.txt is a superior way to provide LI, > > and can perform LI for all services -- not just for cooperative voice > > services that go through a media relay in the (in)appropriate country > > that wants a wiretap. > > I agree. However, the question wasnt whether or not I think LI should be > done in one way or another. The question was whether there were ever > reasons why someone might want a relay besides nat traversal. Sure. > I think > the answer is yes, but I still believe the question is moot as far as > this document is concerned. I am fine with the statement that our > objective is to eliminate the need to install a packet relay solely for > the purpose of nat traversal. Thanks, -d > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com From audet@nortelnetworks.com Thu, 2 Sep 2004 08:29:48 -0700 (PDT) From: "Francois Audet" Date: Thu, 2 Sep 2004 08:29:48 -0700 (PDT) Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave Message-ID: <1ECE0EB50388174790F9694F77522CCF786AC0@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Where we are with draft-audet-nat-behave I won't talk about legal intercept in the document. At this point, I'm tempted to leave a mention going through UDP relays is not needed if a NAT supports the requirements of this document in the introduction. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Wednesday, September 01, 2004 23:06 > To: Jonathan Rosenberg > Cc: Audet, Francois [SC100:9T51:EXCH]; 'Melinda Shore'; 'Behave' > Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave > > > > > However, I suppose one could argue that user-facing media relay > > > exists for > > > purposes other than NAT traversal. Can anyone enumerate > those other > > > purposes? > > > > They are often used for not-so-nice things, primarily lawful > > intercept. > > draft-baker-slem-architecture-02.txt is a superior way to > provide LI, and can perform LI for all services -- not just > for cooperative voice > services that go through a media relay in the (in)appropriate country > that wants a wiretap. > > > However, I dont think we need to go into those other > reasons at all. I > > believe you have captured it correctly - the objective is > not to require > > yet another intermediary device *solely* for the purposes > of traversing > > the nat. If one needs to be there for other reasons, that > another story > > entirely and outside of the scope of this document. > > Thanks, > -d > > From audet@nortelnetworks.com Thu, 2 Sep 2004 09:22:48 -0700 (PDT) From: "Francois Audet" Date: Thu, 2 Sep 2004 09:22:48 -0700 (PDT) Subject: [Ietf-behave] Two suggestions for BEHAVE document Message-ID: <1ECE0EB50388174790F9694F77522CCF786BA8@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Two suggestions for BEHAVE document I've got 2 suggestions for requirements for the BEHAVE document. They both relate to faciliting RTP/RTCP traffic WITHOUT doing deep-packet inspection. - I'd like to mandate that the port parity (even/odd) be respected by the NAT when assigning UDP bindings. This is to respect the RTP=even and RTCP=odd rule. There is some very unfortunate wording in RFC 3550 section 11, second paragraph, which have caused some problematic behavior in client. The wording can be interpreted as saying that if a client receives an odd port for sending RTP, it SHOULD change it to next lower even number. This would obviously break peer-to-peer media. - I'd also like to mandate that for NATs that assign bindings using a pool of IP addresses (as opposed to just 1 IP address) on the external side, that the same external IP address be used for all bindings to the same internal IP address. For example, if a NAT has 10.10.98.12 and 10.10.98.13 on the external side, if internal 192.168.0.4:5000 sends packets and get assigned 10.10.98.12:6000, if 192.168.0.12:45444 then sends packets, it should get assigned 10.10.98.12:X (and NOT 10.10.98.13:X). The reason for this is that I'd like to avoid RTP and RTCP for the same stream having different IP addresses. I'd like feedback from the group. I have seen nice NATs that behave like this. I think these requirements are easily met by NATs and will avoid a lot of problems. PS: People may argue that "extensions" were added to SIP for addressing those problems. However, the problem is that the onus is on the end that is NOT behind the NAT to support them. This is problematic because if I make a device that behaves well behind the NAT and does all the SIP extensions, it will do me no good if the other end doesn't implement it because they are not part of the core specification. These two simple requirements will avoid the problem altogether. Other protocols may not even have these extensions. ---- Franois AUDET, Nortel Networks Tel: +1 408 495 3756 From mshore@cisco.com Thu, 2 Sep 2004 09:53:46 -0700 (PDT) From: Melinda Shore Date: Thu, 2 Sep 2004 09:53:46 -0700 (PDT) Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document In-Reply-To: <1ECE0EB50388174790F9694F77522CCF786BA8@zrc2hxm0.corp.nortel.com> Message-ID: <9413D0A8-FD00-11D8-B4E7-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Both sound good with the caveat that there may be situations in which the NAT runs out of resources (either addresses or ports). In those cases the NAT has several options, including failing to create a mapping or creating a mapping that doesn't satisfy the requirements. Which way it needs to go depends on whether you prefer that the NAT's behavior be as deterministic as possible or that the NAT be as unobtrusive as possible (it's reasonable to think that most of the traffic traversing a NAT will not be broken by the NAT in the first place - HTTP, SMTP, POP, etc.). At any rate, I think that those two requirements are reasonable as long as there's some discussion of failure modes. Melinda From audet@nortelnetworks.com Thu, 2 Sep 2004 10:11:27 -0700 (PDT) From: "Francois Audet" Date: Thu, 2 Sep 2004 10:11:27 -0700 (PDT) Subject: RE: [Ietf-behave] Two suggestions for BEHAVE document Message-ID: <1ECE0EB50388174790F9694F77522CCF786C19@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Two suggestions for BEHAVE document Sounds reasonable. Do you think we should define the failure mode? (I personally think we should, so that our document is deterministic). Or do you think we should just do a RECOMMEND? What is your preference: "deterministic" or "conservative"? PS: This document applies to UDP only, not TCP where these rules wouldn't make sense. So the examples you have HTTP/SMTP/POP wouldn't apply, right? Personnally I would imagine that the majority of UDP traffic is RTP/RTCP. Am I mistaking? I'm OK on either although I prefer the "deterministic" approach. Other opinions? > -----Original Message----- > From: Melinda Shore [mailto:mshore@xxxxxxxxx] > Sent: Thursday, September 02, 2004 09:53 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document > > > Both sound good with the caveat that there may be situations > in which the NAT runs out of resources (either addresses or > ports). In those cases the NAT has several options, including > failing to create a mapping or creating a mapping that > doesn't satisfy the requirements. Which way it needs to go > depends on whether you prefer that the NAT's behavior be as > deterministic as possible or that the NAT be as unobtrusive > as possible (it's reasonable to think that most of the > traffic traversing a NAT will not be broken by the NAT in the > first place - HTTP, SMTP, POP, etc.). At any rate, I think > that those two requirements are reasonable as long as there's > some discussion of failure modes. > > Melinda > > From mshore@cisco.com Thu, 2 Sep 2004 10:23:22 -0700 (PDT) From: Melinda Shore Date: Thu, 2 Sep 2004 10:23:22 -0700 (PDT) Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document In-Reply-To: <1ECE0EB50388174790F9694F77522CCF786C19@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Thursday, September 2, 2004, at 01:08 PM, Francois Audet wrote: What is your preference: "deterministic" or "conservative"? I think the answer to that depends on what kind of model you're working from. If you've got a best-effort view of the world, it's probably best to go with conservative. If you've got a reliable delivery view of the world, it probably best to go with deterministic. My own feeling is that it's probably a mistake to allow UDP- encapsulated IPSec to fail even though you've got resources available when those available resources don't conform to what you'd need for voice. Melinda From audet@nortelnetworks.com Thu, 2 Sep 2004 10:41:24 -0700 (PDT) From: "Francois Audet" Date: Thu, 2 Sep 2004 10:41:24 -0700 (PDT) Subject: RE: [Ietf-behave] Two suggestions for BEHAVE document Message-ID: <1ECE0EB50388174790F9694F77522CCF786C6D@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Two suggestions for BEHAVE document I'm interpreting this as a vote for "conservative". I'm OK with that. Any other views? > -----Original Message----- > From: Melinda Shore [mailto:mshore@xxxxxxxxx] > Sent: Thursday, September 02, 2004 10:23 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document > > > On Thursday, September 2, 2004, at 01:08 PM, Francois Audet wrote: > > What is your preference: "deterministic" or "conservative"? > > I think the answer to that depends on what kind of model > you're working from. If you've got a best-effort view of the > world, it's probably best to go with conservative. If you've > got a reliable delivery view of the world, it probably best > to go with deterministic. My own feeling is that it's > probably a mistake to allow UDP- encapsulated IPSec to fail > even though you've got resources available > when > those available resources don't conform to what you'd need for voice. > > Melinda > > From jdrosen@dynamicsoft.com Wed, 8 Sep 2004 11:09:42 -0700 (PDT) From: Jonathan Rosenberg Date: Wed, 8 Sep 2004 11:09:42 -0700 (PDT) Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document In-Reply-To: <1ECE0EB50388174790F9694F77522CCF786C19@zrc2hxm0.corp.nortel.com> Message-ID: <413F4A7A.7080703@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain Francois Audet wrote: Sounds reasonable. Do you think we should define the failure mode? (I personally think we should, so that our document is deterministic). Or do you think we should just do a RECOMMEND? I think you want to define it. If you define it as "fall back to providing a port on the other address", then a client would know that it should probably implement RFC 3605 (the RTCP address/port attribute in SDP) anyway, allowing it to still get RTCP to work in the event that the peer supports RFC 3605. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From alan@jasomi.com Mon, 13 Sep 2004 14:33:31 -0700 (PDT) From: Alan Hawrylyshen Date: Mon, 13 Sep 2004 14:33:31 -0700 (PDT) Subject: [Ietf-behave] NAT behavior not mentioned thus far. Message-ID: MIME-Version: 1.0 Content-Type: text/plain All; There is a notion of inbound traffic and outbound traffic. For a single packet, these concepts are quite easy to understand. However, I've noticed a few NAT implementations that characterize a particular UDP 'stream' as being principally inbound or outbound based on the temporal duty-cycle of the packets travelling between the peers in the stream. Specifically, for a node (A) behind a NAT (N), sending data via the NAT to a Peer (P). I see the NAT behave as though it calculates 'duty cycle' for the 'stream' and refuse to refresh the binding for those with duty cycles over 50%. Perhaps an illustration would help, consider that the 'edges' in these two timelines represent a packet being sent. A is the baseline (represented by '.') and P is the upper edge (represented by '). .......'''.......'''.......'''.......'''.......'''....... (duty-cycle 30%) [1] ...'''''''...'''''''...'''''''...'''''''...'''''''...''''''' (duty-cycle 70%) [2] You could imagine that in a situation where the peer-P processing is quicker than the node-A processing (or rate of generating requests) that we would see something like line [1] above. In the case where the server has much work to do in order to calculate a response, then we would see [2]. However, NATs that implement this algorithm will close the binding after a short (30s) period of time if the timing looks like [2]. The intent, I would guess, is to prevent the 'peer side' from maintaining the binding on the NAT by sending requests that solicit responses from node A. Since we cannot distinguish the true 'direction' of a session based only on timing analysis -- this mechanism is flawed and I feel that we should have some text that points this out in the document. If only to discourage NAT implementors from outsmarting themselves. I might not have the most concise text above to describe the problem, but I think I've managed to illustrate the problem, don't hesitate to request clarification if I'm off my rocker here. Thanks. Alan Hawrylyshen Jasomi Networks Inc. http://jasomi.com/ a l a n a t j a s o m i d o t c o m From audet@nortelnetworks.com Mon, 13 Sep 2004 19:33:22 -0700 (PDT) From: "Francois Audet" Date: Mon, 13 Sep 2004 19:33:22 -0700 (PDT) Subject: RE: [Ietf-behave] Two suggestions for BEHAVE document Message-ID: <1ECE0EB50388174790F9694F77522CCF946513@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Two suggestions for BEHAVE document Yep, makes sense > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxxxxxxxx] > Sent: Wednesday, September 08, 2004 11:08 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Melinda Shore'; 'Behave' > Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document > > > > > Francois Audet wrote: > > > Sounds reasonable. Do you think we should define the > failure mode? (I > > personally think we should, so that our document is > deterministic). Or > > do you think we should just do a RECOMMEND? > > I think you want to define it. If you define it as "fall back to > providing a port on the other address", then a client would > know that it > should probably implement RFC 3605 (the RTCP address/port > attribute in > SDP) anyway, allowing it to still get RTCP to work in the > event that the > peer supports RFC 3605. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > From fluffy@cisco.com Tue, 14 Sep 2004 08:26:47 -0700 (PDT) From: Cullen Jennings Date: Tue, 14 Sep 2004 08:26:47 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behavior not mentioned thus far. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Interesting Seems like one could test for this using STUN. First create a binding to the STUN server, call that A. Then create a binding to the alternate IP address, call B. Now send 1 request every 15 seconds on B while at the same time send 1 request every 5 seconds on A that has the change IP set so the response will come back on B. A NAT that does this should have binding B close after 30 seconds of whatever the time is and the requests sent on A that return on B should stop working. Cullen On 9/13/04 2:35 PM, "Alan Hawrylyshen" wrote: > All; > > There is a notion of inbound traffic and outbound traffic. For a > single packet, these concepts are quite easy to understand. > However, I've noticed a few NAT implementations that characterize a > particular UDP 'stream' as being principally inbound or outbound based > on the temporal duty-cycle of the packets travelling between the peers > in the stream. > > Specifically, for a node (A) behind a NAT (N), sending data via the > NAT to a Peer (P). I see the NAT behave as though it calculates 'duty > cycle' for the 'stream' and refuse to refresh the binding for those > with duty cycles over 50%. > > Perhaps an illustration would help, consider that the 'edges' in these > two timelines represent a packet being sent. > A is the baseline (represented by '.') and P is the upper edge > (represented by '). > > .......'''.......'''.......'''.......'''.......'''....... (duty-cycle > 30%) [1] > > ...'''''''...'''''''...'''''''...'''''''...'''''''...''''''' > (duty-cycle 70%) [2] > > You could imagine that in a situation where the peer-P processing is > quicker than the node-A processing (or rate of generating requests) > that we would see something like line [1] above. In the case where the > server has much work to do in order to calculate a response, then we > would see [2]. However, NATs that implement this algorithm will close > the binding after a short (30s) period of time if the timing looks like > [2]. The intent, I would guess, is to prevent the 'peer side' from > maintaining the binding on the NAT by sending requests that solicit > responses from node A. > > Since we cannot distinguish the true 'direction' of a session based > only on timing analysis -- this mechanism is flawed and I feel that we > should have some text that points this out in the document. If only to > discourage NAT implementors from outsmarting themselves. > > I might not have the most concise text above to describe the problem, > but I think I've managed to illustrate the problem, don't hesitate to > request clarification if I'm off my rocker here. > > Thanks. > > Alan Hawrylyshen > Jasomi Networks Inc. > http://jasomi.com/ > a l a n a t j a s o m i d o t c o m > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Tue, 14 Sep 2004 10:08:34 -0700 (PDT) From: Cullen Jennings Date: Tue, 14 Sep 2004 10:08:34 -0700 (PDT) Subject: [Ietf-behave] Re: Where we are with draft-audet-nat-behave In-Reply-To: <1ECE0EB50388174790F9694F77522CCF6B1B0B@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain With my contributor hat on ... On 8/31/04 4:05 PM, "Francois Audet" wrote: > I'd like to summarize where I think we are with draft-audet-nat-behave. > > I would like to be able to issue a new release of the document soon, > so I will put on the table the things that were agreed-to in San Diego, > and what my take is on the mailing list discussions. > > I'm writing this from the point of view of the changes to expect between > version -00 and -01. I would like to advance the document to a new > version, with the things that have a good concensus on, and highlight > where there is no concensus yet. > > I'd like to get a view of "yes/no" on the following bullet items. > > 1 - From San Diego, it was agreed to explicitely limit the scope to > NATs, and exclude Firewalls. The document will make that clear, > and will only cover the intrinsic filtering aspects of NATs. > yes > 2 - I believe we have a broad concensus that this first document will > ONLY cover UDP Unicast. TCP, Multicast, ICMP, etc. are to be > covered in later draft(s). > TCP is out, multicast out other than the wording on separate thread for inbound/outbound updates. I think ICMP needs to be dealt with at least a little bit. > 3 - I'm not sure if we should include fragmentation or not (any views?). > Think we should mention it. Not sure what to say. I don't think UDP fragmentation will be covered in any other document. > 4 - We will still try to think a bit about UDP multicast, and try to > ensure our UDP unicast requirements will not make supporting UDP > multicast later on problematic. (see 7) yes > > 5 - From San Diego: state that scope stops at UDP layer (i.e., RTP, or > ALGs are out-of-scope). No looking at embedded addresses for example. yes > > 6 - From San Diego: State that one of the goals is to lessen the > dependence on Media Relays. sure but this is just introduction stuff and one of several motivations > > 7 - On the binding refresh issue, as it stands now, I am inclined to go > with Dan Wing's suggestion which essentialy says that "Outbound > traffic MUST refresh the binding" and "Inbound traffic MAY also > refresh the binding". (I.e., I've been convinced by the arguments > against the "outbound-only" position I was advocating earlier). And > we will be silent on multicast. yes > > Can you guys tell me what you think? > > Thanks. > > ---- > Franois AUDET, Nortel Networks > Tel: +1 408 495 3756 > From fluffy@cisco.com Tue, 14 Sep 2004 10:08:57 -0700 (PDT) From: Cullen Jennings Date: Tue, 14 Sep 2004 10:08:57 -0700 (PDT) Subject: Re: [Ietf-behave] RE: UPD and Multicast scope In-Reply-To: <20040827074939.GS5824@sunbeam.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 8/27/04 3:49 PM, "Harald Welte" wrote: > On Mon, Aug 23, 2004 at 09:44:16AM -0700, Dan Wing wrote: >> What is critical in the base document is that the base BEHAVE document >> allows incoming-only multicast packets to keep the NAT binding open. I >> suggest the following straw-man wording in BEHAVE: >> >> For unicast traffic, a binding MUST remain open if a UDP packet is sent >> from an inside address to an outside address. Additionally, unicast UDP >> bindings MAY be kept open if a UDP packet is received from the >> outside to the inside. Requirements for timing out these bindings >> are in section X.Y.Z. > > I totally agree with this wording. I like this wording and it nicely leaves the door open for whatever we have happen in the multicast document. From fluffy@cisco.com Tue, 14 Sep 2004 10:09:05 -0700 (PDT) From: Cullen Jennings Date: Tue, 14 Sep 2004 10:09:05 -0700 (PDT) Subject: Re: [Ietf-behave] Where we are with draft-audet-nat-behave In-Reply-To: <1ECE0EB50388174790F9694F77522CCF786AC0@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 9/2/04 8:24 AM, "Francois Audet" wrote: > I won't talk about legal intercept in the document. Thank you :-) From fluffy@cisco.com Tue, 14 Sep 2004 10:09:23 -0700 (PDT) From: Cullen Jennings Date: Tue, 14 Sep 2004 10:09:23 -0700 (PDT) Subject: [Ietf-behave] UDP binding timeouts In-Reply-To: <200408101153.HAA15695@leviathan.cnchost.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Medhavi raises a good point, how long should the binding times be and more importantly, any particular reason why? Lacking any other good reason, we will likely pick times that are consistent with what devices do today only because these somewhat match what customers seem comfortable with. On 8/10/04 7:53 AM, "Medhavi Bhatia" wrote: > Some comments/questions: > > 1. REQ-3 comes up with a min-timeout of 2 minutes for UDP dynamic bindings. Is > there data somewhere on the internet which can back this up ? .. snip... > Medhavi Bhatia > Chief Architect > > NexTone Communications > ****Pioneering Global Communications with Excellence, Integrity and Flawless > Execution**** > From fluffy@cisco.com Tue, 14 Sep 2004 10:10:11 -0700 (PDT) From: Cullen Jennings Date: Tue, 14 Sep 2004 10:10:11 -0700 (PDT) Subject: [Ietf-behave] UDP packet fragmentation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain In the case where some fragment other than the first arrives before the first fragment, I'm not sure I like the idea that the NAT should save the fragments and send them later. It seem like it would be really complicated to correctly do the memory management to make this work reliably and not have a huge DOS opportunity. Cullen On 9/1/04 8:51 AM, "Dan Wing" wrote: >> OK. Perfect. Thanks. >> >> Should we keep ICMP and Fragmentation as separate >> items, or should they be combined? (In the current >> document, they are separate). > > There are three issues around fragmentation: > > 1. The NAT trying to send a packet that exceeds the > MTU of the local access link. This can occur > if the NAT is doing PPPoE, as is common on many > DSL networks. This packet could have DF=1 or > DF=0. > > If it has DF=1, we need to describe what the > NAT should do (I suggest a properly-behaving > NAT would behave like a router in this instance, > and send back an ICMP message to the host, and > the host then Does The Right thing per Path MTU > Discovery). A question, though, is how well > PMTUD works for UDP in Windows and various other > common PC operating systems. PMTUD has been > historically pretty spotty for TCP.. > > If it has DF=0, the NAT should fragment the packet > and send the fragments. This is the same function > a router performs with DF=0 and a smaller MTU on > the egress interface. > > 2. The NAT sending a packet that exceeds the MTU > of some link in the middle of the network. In this > case the NAT will receive an ICMP 'fragmentation > needed DF set' message. I suggest we follow the > router requirements here, too, and that the NAT > is sends the ICMP message to the host. This incoming > packet cannot destroy the NAT binding. I don't care > if the incoming packet extends the lifetime of the > binding. > > 3. The NAT receives a fragmented UDP packet. The > IP packet containing the UDP header could arrive first > or last - depending on network conditions, packet ordering, > and the implementation of the sending IP stack. > > The easiest thing is to discard such packets. However, > this is problematic for relatively obvious reasons. > > The easiest thing which works well is to keep the fragments > in memory and, when the fragment containing the UDP header > is received, to send all of the fragments to the appropriate > NAT binding. This has obvious denial of service implications, > though, but we can discuss several mitigations that implementors > can safely use. > > I feel that (1) and (2) can be discussed together, and (3) should be in a > separate section, like you have them now. But I think (1) and (2) are > sufficiently distinct that they should be discussed individually. > >> Any suggestions on wording are welcomed. > > I'll try to get a few paragraphs built later this week. > > -d > > >> -----Original Message----- >> From: Dan Wing [mailto:dwing@xxxxxxxxx] >> Sent: Tuesday, August 31, 2004 17:22 >> To: Audet, Francois [SC100:9T51:EXCH]; 'Behave' >> Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave >> >> >> ... >>> 2 - I believe we have a broad concensus that this first >>> document will ONLY cover UDP Unicast. TCP, Multicast, ICMP, >>> etc. are to be covered in later draft(s). >> >> I believe we need to cover UDP and ICMP as the received ICMP >> message apply to those UDP packets that were sent by the NAT. >> >> If a NAT 'eats' an ICMP message, or uses a certain ICMP message >> to close its UDP binding, it has significant operational >> effects on an application -- especially if the application >> didn't receive the ICMP message (due to congestion on the >> home Ethernet network or home wireless network, for example). >> >> Similarly, I believe the TCP document needs to describe ICMP >> as those ICMP messages apply to the TCP packets that were >> sent by the NAT. >> >>> 3 - I'm not sure if we should include fragmentation or >>> not (any views?). >> >> I agree with Geoff - the handling of fragmentation is >> variable and needs to be discussed. This doesn't mean we'll >> necessarily require reassembly in a NAT to be >> BEHAVE-compliant, but we need to describe how fragmentation >> in should be handled. >> >> We need to discuss both incoming fragmentation (packet >> arrives in fragments) and outgoing fragmentation (I believe >> there are two cases, (a) host set DF=1, and NAT discovers the >> access link >> is too small to handle it [PPPoE], and (b) NAT sends packet >> and receives ICMP 'fragmentation needed DF set' packet, what >> should it do. >> >> To do this, we'll need to mention ICMP ('fragmentation needed >> DF set'). >> >> ... >>> Can you guys tell me what you think? >> >> The others items all sound fine to me. >> >> -d >> >> > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From jdrosen@dynamicsoft.com Tue, 14 Sep 2004 11:40:09 -0700 (PDT) From: Jonathan Rosenberg Date: Tue, 14 Sep 2004 11:40:09 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behavior not mentioned thus far. In-Reply-To: Message-ID: <41473AA3.7060405@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain There are two things here. One, is I agree with Cullen it would be good to document a STUN-based test to check for this kind of behavior. More importantly, though, is to try and understand the underlying problem/requirement that the implementor was trying to address with this, and make sure that the underlying problem is handled by the behaviors we recommend. In this case here, its not clear to me why the vendor went with this more complex definition of inbound/outbound, rather than doing the simpler "refresh the binding on outbound packet" that we have been discussing. -Jonathan R. Cullen Jennings wrote: Interesting Seems like one could test for this using STUN. First create a binding to the STUN server, call that A. Then create a binding to the alternate IP address, call B. Now send 1 request every 15 seconds on B while at the same time send 1 request every 5 seconds on A that has the change IP set so the response will come back on B. A NAT that does this should have binding B close after 30 seconds of whatever the time is and the requests sent on A that return on B should stop working. Cullen On 9/13/04 2:35 PM, "Alan Hawrylyshen" wrote: All; There is a notion of inbound traffic and outbound traffic. For a single packet, these concepts are quite easy to understand. However, I've noticed a few NAT implementations that characterize a particular UDP 'stream' as being principally inbound or outbound based on the temporal duty-cycle of the packets travelling between the peers in the stream. Specifically, for a node (A) behind a NAT (N), sending data via the NAT to a Peer (P). I see the NAT behave as though it calculates 'duty cycle' for the 'stream' and refuse to refresh the binding for those with duty cycles over 50%. Perhaps an illustration would help, consider that the 'edges' in these two timelines represent a packet being sent. A is the baseline (represented by '.') and P is the upper edge (represented by '). .......'''.......'''.......'''.......'''.......'''....... (duty-cycle 30%) [1] ...'''''''...'''''''...'''''''...'''''''...'''''''...''''''' (duty-cycle 70%) [2] You could imagine that in a situation where the peer-P processing is quicker than the node-A processing (or rate of generating requests) that we would see something like line [1] above. In the case where the server has much work to do in order to calculate a response, then we would see [2]. However, NATs that implement this algorithm will close the binding after a short (30s) period of time if the timing looks like [2]. The intent, I would guess, is to prevent the 'peer side' from maintaining the binding on the NAT by sending requests that solicit responses from node A. Since we cannot distinguish the true 'direction' of a session based only on timing analysis -- this mechanism is flawed and I feel that we should have some text that points this out in the document. If only to discourage NAT implementors from outsmarting themselves. I might not have the most concise text above to describe the problem, but I think I've managed to illustrate the problem, don't hesitate to request clarification if I'm off my rocker here. Thanks. Alan Hawrylyshen Jasomi Networks Inc. http://jasomi.com/ a l a n a t j a s o m i d o t c o m _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From dwing@cisco.com Tue, 14 Sep 2004 11:48:17 -0700 (PDT) From: "Dan Wing" Date: Tue, 14 Sep 2004 11:48:17 -0700 (PDT) Subject: [Ietf-behave] RE: UDP packet fragmentation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain I agree. The trouble with UDP is that, unlike TCP, most stacks don't do Path MTU Discovery for UDP and thus fragmentation is more likely with UDP than with TCP. This is seldom noticed with voice as the packets are small, but will be more commonplace with video especially in conjunction with PPPoE, IPsec, or if someone configures a link with a small MTU to reduce serialization delay. However, the alternative to properly handling fragments means that fragmented UDP packets may, or may not, make it across the NAT depending on (a) how the NAT handles fragments arriving out of order, (b) if the network reordered the fragments, and (c) if the host (or router) that fragmented the packets transmitted the fragments in order. I don't feel the alternative meets the spirit of BEHAVE. But perhaps we can provide the necessary guidance in the 'how client should function with a BEHAVE-compliant NAT' document, namely: do PMTUD with UDP, and if you have to fragment send the fragments in-order. As we can't control the routers in the network, though, so it's best to do PMTUD with UDP. -d > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Tuesday, September 14, 2004 10:10 AM > To: Dan Wing; Francois Audet; Behave > Subject: UDP packet fragmentation > > > > In the case where some fragment other than the first arrives before the > first fragment, I'm not sure I like the idea that the NAT should save the > fragments and send them later. It seem like it would be really complicated > to correctly do the memory management to make this work reliably and not > have a huge DOS opportunity. > > Cullen > > > On 9/1/04 8:51 AM, "Dan Wing" wrote: > > >> OK. Perfect. Thanks. > >> > >> Should we keep ICMP and Fragmentation as separate > >> items, or should they be combined? (In the current > >> document, they are separate). > > > > There are three issues around fragmentation: > > > > 1. The NAT trying to send a packet that exceeds the > > MTU of the local access link. This can occur > > if the NAT is doing PPPoE, as is common on many > > DSL networks. This packet could have DF=1 or > > DF=0. > > > > If it has DF=1, we need to describe what the > > NAT should do (I suggest a properly-behaving > > NAT would behave like a router in this instance, > > and send back an ICMP message to the host, and > > the host then Does The Right thing per Path MTU > > Discovery). A question, though, is how well > > PMTUD works for UDP in Windows and various other > > common PC operating systems. PMTUD has been > > historically pretty spotty for TCP.. > > > > If it has DF=0, the NAT should fragment the packet > > and send the fragments. This is the same function > > a router performs with DF=0 and a smaller MTU on > > the egress interface. > > > > 2. The NAT sending a packet that exceeds the MTU > > of some link in the middle of the network. In this > > case the NAT will receive an ICMP 'fragmentation > > needed DF set' message. I suggest we follow the > > router requirements here, too, and that the NAT > > is sends the ICMP message to the host. This incoming > > packet cannot destroy the NAT binding. I don't care > > if the incoming packet extends the lifetime of the > > binding. > > > > 3. The NAT receives a fragmented UDP packet. The > > IP packet containing the UDP header could arrive first > > or last - depending on network conditions, packet ordering, > > and the implementation of the sending IP stack. > > > > The easiest thing is to discard such packets. However, > > this is problematic for relatively obvious reasons. > > > > The easiest thing which works well is to keep the fragments > > in memory and, when the fragment containing the UDP header > > is received, to send all of the fragments to the appropriate > > NAT binding. This has obvious denial of service implications, > > though, but we can discuss several mitigations that implementors > > can safely use. > > > > I feel that (1) and (2) can be discussed together, and (3) > should be in a > > separate section, like you have them now. But I think (1) and (2) are > > sufficiently distinct that they should be discussed individually. > > > >> Any suggestions on wording are welcomed. > > > > I'll try to get a few paragraphs built later this week. > > > > -d > > > > > >> -----Original Message----- > >> From: Dan Wing [mailto:dwing@xxxxxxxxx] > >> Sent: Tuesday, August 31, 2004 17:22 > >> To: Audet, Francois [SC100:9T51:EXCH]; 'Behave' > >> Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave > >> > >> > >> ... > >>> 2 - I believe we have a broad concensus that this first > >>> document will ONLY cover UDP Unicast. TCP, Multicast, ICMP, > >>> etc. are to be covered in later draft(s). > >> > >> I believe we need to cover UDP and ICMP as the received ICMP > >> message apply to those UDP packets that were sent by the NAT. > >> > >> If a NAT 'eats' an ICMP message, or uses a certain ICMP message > >> to close its UDP binding, it has significant operational > >> effects on an application -- especially if the application > >> didn't receive the ICMP message (due to congestion on the > >> home Ethernet network or home wireless network, for example). > >> > >> Similarly, I believe the TCP document needs to describe ICMP > >> as those ICMP messages apply to the TCP packets that were > >> sent by the NAT. > >> > >>> 3 - I'm not sure if we should include fragmentation or > >>> not (any views?). > >> > >> I agree with Geoff - the handling of fragmentation is > >> variable and needs to be discussed. This doesn't mean we'll > >> necessarily require reassembly in a NAT to be > >> BEHAVE-compliant, but we need to describe how fragmentation > >> in should be handled. > >> > >> We need to discuss both incoming fragmentation (packet > >> arrives in fragments) and outgoing fragmentation (I believe > >> there are two cases, (a) host set DF=1, and NAT discovers the > >> access link > >> is too small to handle it [PPPoE], and (b) NAT sends packet > >> and receives ICMP 'fragmentation needed DF set' packet, what > >> should it do. > >> > >> To do this, we'll need to mention ICMP ('fragmentation needed > >> DF set'). > >> > >> ... > >>> Can you guys tell me what you think? > >> > >> The others items all sound fine to me. > >> > >> -d > >> > >> > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From laforge@netfilter.org Tue, 14 Sep 2004 12:22:20 -0700 (PDT) From: Harald Welte Date: Tue, 14 Sep 2004 12:22:20 -0700 (PDT) Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document In-Reply-To: <1ECE0EB50388174790F9694F77522CCF786BA8@zrc2hxm0.corp.nortel.com> Message-ID: <20040914192216.GH8434@sunbeam.de.gnumonks.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630131.multipart/signed" --Boundary..27398.1163630131.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, Sep 02, 2004 at 12:22:38PM -0400, Francois Audet wrote: > - I'd like to mandate that the port parity (even/odd) be respected > by the NAT when assigning UDP bindings. This is to respect the RTP=even > and RTCP=odd rule. There is some very unfortunate wording in RFC 3550 > section 11, second paragraph, which have caused some problematic > behavior in client. The wording can be interpreted as saying that > if a client receives an odd port for sending RTP, it SHOULD change it to > next lower even number. This would obviously break peer-to-peer media. Isn't there also the requirement that RTP/RTCP are on two consecutive port numbers? Is this in the specification, or just some broken clients that require this? We're currently developing quite complex and ugly code for consecutive-portnumber-reservation of ALG's :( Anyway, I don't see any problems with the 'port parity respected' requirement you would like to add. > - I'd also like to mandate that for NATs that assign bindings using > a pool of IP addresses (as opposed to just 1 IP address) on the > external side, that the same external IP address be used for all > bindings to the same internal IP address. For example, if a NAT > has 10.10.98.12 and 10.10.98.13 on the external side, if internal > 192.168.0.4:5000 sends packets and get assigned 10.10.98.12:6000, > if 192.168.0.12:45444 then sends packets, it should get assigned > 10.10.98.12:X (and NOT 10.10.98.13:X). The reason for this is > that I'd like to avoid RTP and RTCP for the same stream having > different IP addresses. Yes, this is a commonly-seen problem with NAT implementations. This usually breaks lot of applications, even web-based applications, eg. homebanking. I fully support adding this requirement to the BEHAVE document. > Franois AUDET, Nortel Networks -- - Harald Welte http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie Attachment: signature.asc --Boundary..27398.1163630131.multipart/signed Content-Type: application/octet-stream; name="pgp00007.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00007.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQlIwVG9YYVhHVlREMGkvOFJBc3FpQUp3TndsdTh6WDJLVFB2L1E5RFNs WjlUSkkxdnp3Q2ZhVHRICjRMTWhTL3FyNkRkTHdFVytZc3I3ejJrPQo9VEdUOQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630131.multipart/signed-- From laforge@netfilter.org Tue, 14 Sep 2004 12:24:10 -0700 (PDT) From: Harald Welte Date: Tue, 14 Sep 2004 12:24:10 -0700 (PDT) Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document In-Reply-To: <1ECE0EB50388174790F9694F77522CCF786BA8@zrc2hxm0.corp.nortel.com> Message-ID: <20040914192408.GI8434@sunbeam.de.gnumonks.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630131.multipart/signed" --Boundary..27398.1163630131.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, Sep 02, 2004 at 12:53:13PM -0400, Melinda Shore wrote: > Both sound good with the caveat that there may be situations in > which the NAT runs out of resources (either addresses or ports). > In those cases the NAT has several options, including failing > to create a mapping or creating a mapping that doesn't satisfy > the requirements. It was my current understandign of the existing draft document that in such a case, a BEHAVE compliant NAT would have to fail, rather than creating a non-satisfactory mapping. -- - Harald Welte http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie Attachment: signature.asc --Boundary..27398.1163630131.multipart/signed Content-Type: application/octet-stream; name="pgp00008.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00008.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQlIwVllYYVhHVlREMGkvOFJBbzd4QUtDa2Z2OEVwK3cwdkl0a1ViTVZQ VUhlMWF2Z3VRQ2ZlUXdOCk9jME5WK0RMdno4UWhsZHl6Tm5XUUcwPQo9c04zdQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630131.multipart/signed-- From laforge@netfilter.org Tue, 14 Sep 2004 12:29:52 -0700 (PDT) From: Harald Welte Date: Tue, 14 Sep 2004 12:29:52 -0700 (PDT) Subject: Re: [Ietf-behave] NAT behavior not mentioned thus far. In-Reply-To: Message-ID: <20040914192945.GJ8434@sunbeam.de.gnumonks.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630131.multipart/signed" --Boundary..27398.1163630131.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, Sep 14, 2004 at 02:38:27PM -0400, Jonathan Rosenberg wrote: > In this case here, its not clear to me why the vendor went with this > more complex definition of inbound/outbound, rather than doing the > simpler "refresh the binding on outbound packet" that we have been > discussing. Maybe because there are undocumented proprietary protocols (mostly for online gaming, but IIRC also the original RealAudio protocol) that break when using a outbound-only refresh :( We would really need an expert on gaming protocols to join this dicsussion. I assume that those protocols currently have a considerable share of UDP unicast traffic on the net. Does anybody know some expert in this area? > -Jonathan R. -- - Harald Welte http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie Attachment: signature.asc --Boundary..27398.1163630131.multipart/signed Content-Type: application/octet-stream; name="pgp00009.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00009.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQlIwYXBYYVhHVlREMGkvOFJBdXFKQUo5OGlodkFUdUo2SWlHQXY4SzVD MVU4ZU9jUkh3Q2dqcFRRCmlWclNyTXZrOWFZcmprNjVLK3FmTkJzPQo9VEdPdgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630131.multipart/signed-- From dwing@cisco.com Tue, 14 Sep 2004 12:31:13 -0700 (PDT) From: "Dan Wing" Date: Tue, 14 Sep 2004 12:31:13 -0700 (PDT) Subject: RE: [Ietf-behave] UDP packet fragmentation In-Reply-To: <20040914191441.GG8434@sunbeam.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I agree that encouraging PMTUD is the way to to. Which means we need to ensure BEHAVE requires NATs to handle those ICMP messages correctly. I'm hoping to get some suggested text out later today on ICMP. -d > -----Original Message----- > From: Harald Welte [mailto:laforge@xxxxxxxxxxxx] > Sent: Tuesday, September 14, 2004 12:15 PM > To: Cullen Jennings > Cc: Dan Wing; Francois Audet; Behave > Subject: Re: [Ietf-behave] UDP packet fragmentation > > > On Tue, Sep 14, 2004 at 10:09:59AM -0700, Cullen Jennings wrote: > > > > In the case where some fragment other than the first arrives before the > > first fragment, I'm not sure I like the idea that the NAT > should save the > > fragments and send them later. It seem like it would be really > complicated > > to correctly do the memory management to make this work reliably and not > > have a huge DOS opportunity. > > I agree that this can be problematic on very small devices. > > JFYI: Linux NAT actually uses the same defragmentation code as for local > sockets, so the same limitations (maximum number of queued fragments at > any given time, ...) apply. > > Encouraging the use of UDP PMTU discovery is the way to go. > > Any reasonably configured packet filter will drop inbound fragments > anyway... too much DoS-capability, too many fragment-based attacks... > And recently due to 16bit fragID wrapping on links with large bandwith > even unnoticed data corruption... (seen a lot with fragmented NFS over > UDP these days). > > > Cullen > -- > - Harald Welte http://www.gnumonks.org/ ============================================================================ Programming is like sex: One mistake and you have to support it your lifetime From dwing@cisco.com Tue, 14 Sep 2004 13:10:46 -0700 (PDT) From: "Dan Wing" Date: Tue, 14 Sep 2004 13:10:46 -0700 (PDT) Subject: RE: [Ietf-behave] Two suggestions for BEHAVE document In-Reply-To: <20040914192216.GH8434@sunbeam.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > On Thu, Sep 02, 2004 at 12:22:38PM -0400, Francois Audet wrote: > > - I'd like to mandate that the port parity (even/odd) be respected > > by the NAT when assigning UDP bindings. This is to respect > the RTP=even > > and RTCP=odd rule. There is some very unfortunate wording in RFC 3550 > > section 11, second paragraph, which have caused some problematic > > behavior in client. The wording can be interpreted as saying that > > if a client receives an odd port for sending RTP, it SHOULD > change it to > > next lower even number. This would obviously break > peer-to-peer media. > > Isn't there also the requirement that RTP/RTCP are on two consecutive > port numbers? Yes, the RTP specification requires this, but RFC3605 shows how the actual RTCP port can be signaled. This is something we need to mention in the RTP client specification (which, to my knowledge, nobody has yet started, but I'm getting an itch here to start it). > Is this in the specification, or just some broken clients > that require this? We're currently developing quite complex and ugly > code for consecutive-portnumber-reservation of ALG's :( I bet! It's a difficult problem with an ALG, but it's even harder (I would say impossible) if you have a NAT that doesn't ALG your signaling and that NAT is also really busy with lots of requests from a bunch of clients -- such as a typical enterprise-scale NAT would be. > Anyway, I don't see any problems with the 'port parity respected' > requirement you would like to add. > > > - I'd also like to mandate that for NATs that assign bindings using > > a pool of IP addresses (as opposed to just 1 IP address) on the > > external side, that the same external IP address be used for all > > bindings to the same internal IP address. For example, if a NAT > > has 10.10.98.12 and 10.10.98.13 on the external side, if internal > > 192.168.0.4:5000 sends packets and get assigned 10.10.98.12:6000, > > if 192.168.0.12:45444 then sends packets, it should get assigned > > 10.10.98.12:X (and NOT 10.10.98.13:X). The reason for this is > > that I'd like to avoid RTP and RTCP for the same stream having > > different IP addresses. > > Yes, this is a commonly-seen problem with NAT implementations. This > usually breaks lot of applications, even web-based applications, eg. > homebanking. > > I fully support adding this requirement to the BEHAVE document. -d > > Franois AUDET, Nortel Networks > > -- > - Harald Welte http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie From audet@nortelnetworks.com Tue, 14 Sep 2004 13:59:28 -0700 (PDT) From: "Francois Audet" Date: Tue, 14 Sep 2004 13:59:28 -0700 (PDT) Subject: RE: [Ietf-behave] NAT behavior not mentioned thus far. Message-ID: <1ECE0EB50388174790F9694F77522CCF946A8E@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] NAT behavior not mentioned thus far. > There are two things here. > > One, is I agree with Cullen it would be good to document a STUN-based > test to check for this kind of behavior. Correct. I assume this is not to be included in the BEHAVE draft. > More importantly, though, is to try and understand the underlying > problem/requirement that the implementor was trying to address with > this, and make sure that the underlying problem is handled by the > behaviors we recommend. > > In this case here, its not clear to me why the vendor went with this > more complex definition of inbound/outbound, rather than doing the > simpler "refresh the binding on outbound packet" that we have been > discussing. If anybody is able to let us know the why of the offending behavior, it would be helpful. > -Jonathan R. > > Cullen Jennings wrote: > > > Interesting > > > > Seems like one could test for this using STUN. First create > a binding > > to the STUN server, call that A. Then create a binding to the > > alternate IP address, call B. Now send 1 request every 15 > seconds on B > > while at the same time send 1 request every 5 seconds on A that has > > the change IP set so the response will come back on B. > > > > A NAT that does this should have binding B close after 30 > seconds of > > whatever the time is and the requests sent on A that return on B > > should stop working. > > > > Cullen > > > > > > On 9/13/04 2:35 PM, "Alan Hawrylyshen" wrote: > > > > > >>All; > >> > >>There is a notion of inbound traffic and outbound traffic. For a > >>single packet, these concepts are quite easy to understand. > However, > >>I've noticed a few NAT implementations that characterize a > particular > >>UDP 'stream' as being principally inbound or outbound based on the > >>temporal duty-cycle of the packets travelling between the > peers in the > >>stream. > >> > >>Specifically, for a node (A) behind a NAT (N), sending > data via the > >>NAT to a Peer (P). I see the NAT behave as though it > calculates 'duty > >>cycle' for the 'stream' and refuse to refresh the binding for those > >>with duty cycles over 50%. > >> > >>Perhaps an illustration would help, consider that the > 'edges' in these > >>two timelines represent a packet being sent. A is the baseline > >>(represented by '.') and P is the upper edge (represented by '). > >> > >>.......'''.......'''.......'''.......'''.......'''....... > (duty-cycle > >>30%) [1] > >> > >>...'''''''...'''''''...'''''''...'''''''...'''''''...''''''' > >>(duty-cycle 70%) [2] > >> > >>You could imagine that in a situation where the peer-P > processing is > >>quicker than the node-A processing (or rate of generating requests) > >>that we would see something like line [1] above. In the case where > >>the server has much work to do in order to calculate a > response, then > >>we would see [2]. However, NATs that implement this algorithm will > >>close the binding after a short (30s) period of time if the timing > >>looks like [2]. The intent, I would guess, is to prevent the 'peer > >>side' from maintaining the binding on the NAT by sending > requests that > >>solicit responses from node A. > >> > >>Since we cannot distinguish the true 'direction' of a session based > >>only on timing analysis -- this mechanism is flawed and I > feel that we > >>should have some text that points this out in the document. > If only to > >>discourage NAT implementors from outsmarting themselves. > >> > >>I might not have the most concise text above to describe > the problem, > >>but I think I've managed to illustrate the problem, don't > hesitate to > >>request clarification if I'm off my rocker here. > >> > >>Thanks. > >> > >>Alan Hawrylyshen > >>Jasomi Networks Inc. > >>http://jasomi.com/ > >>a l a n a t j a s o m i d o t c o m > >> > >>_______________________________________________ > >>Ietf-behave mailing list > >>Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinf> o/ietf-behave > > From audet@nortelnetworks.com Tue, 14 Sep 2004 16:17:40 -0700 (PDT) From: "Francois Audet" Date: Tue, 14 Sep 2004 16:17:40 -0700 (PDT) Subject: RE: [Ietf-behave] Two suggestions for BEHAVE document Message-ID: <1ECE0EB50388174790F9694F77522CCF946BAF@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Two suggestions for BEHAVE document Dan/Harald, The very first pre-draft that Cullen and I wrote (before we actually submitted it) attempted to address the consecutive port number issue. After reviewing it with others we removed it completely. It was felt that it would be complicated for NAT manufacturers. It was also felt that if a NAT does not address the contiguous UDP port requirement, the consequence is at worst (if either client do not support the RTCP indication) that the RTCP stream will be lost. This is not a "fatal" problem like loosing the RTP stream. However, what Harald is saying is worrying me (i.e., "We're currently developing quite complex and ugly code for consecutive-portnumber- reservation of ALG's"). I think that there is a very good chance based on past experience that if NAT vendors use different algorithms for preserving consecutive port numbers, we will end-up in trouble. So I think that we need to discuss the issue in the document. Perhaps it's as simple as saying that we don't recommend putting hacks in the NAT to address the issue because of reasons X, Y, Z. As I said earlier, we had tought of ways to address the issue (by doing port reservations and sequential assignment), but it grew more complex and we utimately didn't include them. Any views from others? > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Tuesday, September 14, 2004 13:11 > To: Harald Welte; Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: RE: [Ietf-behave] Two suggestions for BEHAVE document > > > > On Thu, Sep 02, 2004 at 12:22:38PM -0400, Francois Audet wrote: > > > - I'd like to mandate that the port parity (even/odd) be respected > > > by the NAT when assigning UDP bindings. This is to respect > > the RTP=even > > > and RTCP=odd rule. There is some very unfortunate > wording in RFC 3550 > > > section 11, second paragraph, which have caused some problematic > > > behavior in client. The wording can be interpreted as > saying that > > > if a client receives an odd port for sending RTP, it SHOULD > > change it to > > > next lower even number. This would obviously break > > peer-to-peer media. > > > > Isn't there also the requirement that RTP/RTCP are on two > consecutive > > port numbers? > > Yes, the RTP specification requires this, but RFC3605 shows > how the actual RTCP port can be signaled. This is something > we need to mention in the RTP client specification (which, to > my knowledge, nobody has yet started, but I'm getting an itch > here to start it). > > > Is this in the specification, or just some broken clients > that require > > this? We're currently developing quite complex and ugly code for > > consecutive-portnumber-reservation of ALG's :( > > I bet! It's a difficult problem with an ALG, but it's even > harder (I would say impossible) if you have a NAT that > doesn't ALG your signaling and that NAT is also really busy > with lots of requests from a bunch of clients -- such as a > typical enterprise-scale NAT would be. From jdrosen@dynamicsoft.com Tue, 14 Sep 2004 18:32:24 -0700 (PDT) From: Jonathan Rosenberg Date: Tue, 14 Sep 2004 18:32:24 -0700 (PDT) Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document In-Reply-To: <1ECE0EB50388174790F9694F77522CCF946BAF@zrc2hxm0.corp.nortel.com> Message-ID: <41479B66.2060804@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain inline. Francois Audet wrote: I think that there is a very good chance based on past experience that if NAT vendors use different algorithms for preserving consecutive port numbers, we will end-up in trouble. Agreed. So I think that we need to discuss the issue in the document. Perhaps it's as simple as saying that we don't recommend putting hacks in the NAT to address the issue because of reasons X, Y, Z. Well, normally, one doesnt include in the document all of the design choices that the group elected NOT to pursue. I think our objective is to document the recommended solution and explain why it is the recommended solution. If Harald or others have concerns about the port affinity approach, we should discuss that and conclude on a recommendation. I for one like the port affinity solution. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Tue, 14 Sep 2004 19:04:41 -0700 (PDT) From: Jonathan Rosenberg Date: Tue, 14 Sep 2004 19:04:41 -0700 (PDT) Subject: Re: [Ietf-behave] UDP binding timeouts In-Reply-To: Message-ID: <4147A2DD.3040707@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain I think the most important thing is that there is a deterministic minimum that you can count on; the actual value is far less important. In principal, you'd like to tie the timeout to typical maximum activity intervals for UDP-based applications. That is, normal outbound packet activity for applications should keep the bindings active withot requiring additional keepalives. For RTP, even a much smaller number would typically suffice. For SIP over UDP, packet retransmits can be spaced as large as 16s towards the tail end of the transaction. If you want the binding to be active for a transaction lifetime without special keepalives, you'd want a minimum of 20s or so. It'd be interesting to look at other UDP based protocols and see what timeouts would be appropriate. Of course, who knows what future apps would do. Again, the key thing is really determinism. -Jonathan R. Cullen Jennings wrote: Medhavi raises a good point, how long should the binding times be and more importantly, any particular reason why? Lacking any other good reason, we will likely pick times that are consistent with what devices do today only because these somewhat match what customers seem comfortable with. On 8/10/04 7:53 AM, "Medhavi Bhatia" wrote: Some comments/questions: 1. REQ-3 comes up with a min-timeout of 2 minutes for UDP dynamic bindings. Is there data somewhere on the internet which can back this up ? .. snip... Medhavi Bhatia Chief Architect NexTone Communications ****Pioneering Global Communications with Excellence, Integrity and Flawless Execution**** _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From laforge@netfilter.org Wed, 15 Sep 2004 03:11:21 -0700 (PDT) From: Harald Welte Date: Wed, 15 Sep 2004 03:11:21 -0700 (PDT) Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document In-Reply-To: <1ECE0EB50388174790F9694F77522CCF946BAF@zrc2hxm0.corp.nortel.com> Message-ID: <20040915101115.GC1274@sunbeam.de.gnumonks.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630131.multipart/signed" --Boundary..27398.1163630131.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, Sep 14, 2004 at 07:16:24PM -0400, Francois Audet wrote: > Dan/Harald, > > After reviewing it with others we removed it completely. It was felt that it > would be complicated for NAT manufacturers. It was also felt that if a NAT > does not address the contiguous UDP port requirement, the consequence is > at worst (if either client do not support the RTCP indication) that the > RTCP stream will be lost. This is not a "fatal" problem like loosing the > RTP stream. I can understand this position. However, wasn't RTCP thought of a means to communicate packet loss rates? If I put this in context with the IAB problem statement on congestion control, I doubt it is a good idea to just silently prevent RTCP from working. > However, what Harald is saying is worrying me (i.e., "We're currently > developing quite complex and ugly code for consecutive-portnumber- > reservation of ALG's"). Well, there are developers working on a SIP ALG for netfilter, and they asked us to include infrastructure for consecutive port number reservation into the netfilter NAT core. Our current position on this is 1) consecutive port numbers are a bad idea, somebody should LART the protocol designers 2) now that we are facing the problem, we have to come up with a solution (i.e. implement it). > I think that there is a very good chance based on past experience that > if NAT vendors use different algorithms for preserving consecutive port > numbers, we will end-up in trouble. We'd just chose any two (or even four in the case of A/V streams?) consecutive port numbers that are available. Just like we would chose any single available port number. > So I think that we need to discuss the issue in the document. > > Perhaps it's as simple as saying that we don't recommend putting hacks in > the NAT to address the issue because of reasons X, Y, Z. I would definitely like that. It saves us from those hacks in the code. However, it should then be considered to alter the RTP/RTCP specification to not require those consecutive port numbers in the first place. Either the protocol changes, or the NAT's will have to adress it. I don't see any way in between. -- - Harald Welte http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie Attachment: signature.asc --Boundary..27398.1163630131.multipart/signed Content-Type: application/octet-stream; name="pgp00010.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00010.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQlNCVkRYYVhHVlREMGkvOFJBamNSQUtDZ1VkSjdlNEcxRGZ5cUw4cDcv VjFZUEZOcmh3Q2ZUNkltCnVxUjJxdkNiU1JQZEp1YXdCL0pndTZBPQo9cXREcgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630131.multipart/signed-- From audet@nortelnetworks.com Wed, 15 Sep 2004 07:25:19 -0700 (PDT) From: "Francois Audet" Date: Wed, 15 Sep 2004 07:25:19 -0700 (PDT) Subject: RE: [Ietf-behave] UDP binding timeouts Message-ID: <1ECE0EB50388174790F9694F77522CCF9AF605@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] UDP binding timeouts I think we can leave it to 2 minutes until we have reasons to change it. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jonathan Rosenberg > Sent: Tuesday, September 14, 2004 19:03 > To: Cullen Jennings > Cc: Behave > Subject: Re: [Ietf-behave] UDP binding timeouts > > > I think the most important thing is that there is a deterministic > minimum that you can count on; the actual value is far less important. > > In principal, you'd like to tie the timeout to typical > maximum activity > intervals for UDP-based applications. That is, normal outbound packet > activity for applications should keep the bindings active withot > requiring additional keepalives. For RTP, even a much smaller number > would typically suffice. For SIP over UDP, packet retransmits can be > spaced as large as 16s towards the tail end of the > transaction. If you > want the binding to be active for a transaction lifetime > without special > keepalives, you'd want a minimum of 20s or so. > > It'd be interesting to look at other UDP based protocols and see what > timeouts would be appropriate. Of course, who knows what future apps > would do. Again, the key thing is really determinism. > > -Jonathan R. > > Cullen Jennings wrote: > > > Medhavi raises a good point, how long should the binding > times be and > > more importantly, any particular reason why? > > > > Lacking any other good reason, we will likely pick times that are > > consistent with what devices do today only because these somewhat > > match what customers seem comfortable with. > > > > > > On 8/10/04 7:53 AM, "Medhavi Bhatia" wrote: > > > > > >>Some comments/questions: > >> > >>1. REQ-3 comes up with a min-timeout of 2 minutes for UDP dynamic > >>bindings. Is there data somewhere on the internet which can > back this > >>up ? > > > > .. snip... > > > >>Medhavi Bhatia > >>Chief Architect > >> > >>NexTone Communications > >>****Pioneering Global Communications with Excellence, Integrity and > >>Flawless > >>Execution**** > >> > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/i> etf-behave > > From dwing@cisco.com Wed, 15 Sep 2004 08:40:34 -0700 (PDT) From: "Dan Wing" Date: Wed, 15 Sep 2004 08:40:34 -0700 (PDT) Subject: RE: [Ietf-behave] UDP binding timeouts In-Reply-To: <4147A2DD.3040707@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > I think the most important thing is that there is a deterministic > minimum that you can count on; the actual value is far less important. > > In principal, you'd like to tie the timeout to typical maximum activity > intervals for UDP-based applications. That is, normal outbound packet > activity for applications should keep the bindings active withot > requiring additional keepalives. For RTP, even a much smaller number > would typically suffice. For SIP over UDP, packet retransmits can be > spaced as large as 16s towards the tail end of the transaction. If you > want the binding to be active for a transaction lifetime without special > keepalives, you'd want a minimum of 20s or so. With such short binding lifetimes, wouldn't you need SIP keepalives (.) to keep the binding open so you can be signaled for an incoming call? That's a lot of silly keepalive traffic for a SIP proxy. > It'd be interesting to look at other UDP based protocols and see what > timeouts would be appropriate. Of course, who knows what future apps > would do. Again, the key thing is really determinism. I agree. -d > -Jonathan R. > > Cullen Jennings wrote: > > > Medhavi raises a good point, how long should the binding times > be and more > > importantly, any particular reason why? > > > > Lacking any other good reason, we will likely pick times that > are consistent > > with what devices do today only because these somewhat match > what customers > > seem comfortable with. > > > > > > On 8/10/04 7:53 AM, "Medhavi Bhatia" wrote: > > > > > >>Some comments/questions: > >> > >>1. REQ-3 comes up with a min-timeout of 2 minutes for UDP > dynamic bindings. Is > >>there data somewhere on the internet which can back this up ? > > > > .. snip... > > > >>Medhavi Bhatia > >>Chief Architect > >> > >>NexTone Communications > >>****Pioneering Global Communications with Excellence, Integrity > and Flawless > >>Execution**** > >> > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Wed, 15 Sep 2004 10:22:59 -0700 (PDT) From: Cullen Jennings Date: Wed, 15 Sep 2004 10:22:59 -0700 (PDT) Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document In-Reply-To: <20040915101115.GC1274@sunbeam.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 9/15/04 3:11 AM, "Harald Welte" wrote: > > Either the protocol changes, or the NAT's will have to adress it. I > don't see any way in between. Yep, I think this is the heart of it. So we are in one of the gray area's where we make a judgment call - we have two choices - both could work. A) Don't do consecutive port stuff on NAT. This means RTP applications will need to use RFC 3605 to work through NATs. (as well as RFC 3489) B) Force NATs to do consecutive port assignment. A is a change for many RTP program, but none of this is going to work without changes to them such as supporting STUN. B is a *big* change for the NAT vendors. The way the draft is written now, many NATs would be compliant with it and many others would require only very small changes. I think I lean in favor of A over B because I think that the people that have to do the work for B have far less incentive to do the work than the people that have to do the work for A. Thus I view A as more likely to succeed than B. As a side note, RTP is the only protocol I am aware of that would desires NATs to have this behavior. Cullen From audet@nortelnetworks.com Wed, 15 Sep 2004 10:28:27 -0700 (PDT) From: "Francois Audet" Date: Wed, 15 Sep 2004 10:28:27 -0700 (PDT) Subject: RE: [Ietf-behave] Two suggestions for BEHAVE document Message-ID: <1ECE0EB50388174790F9694F77522CCF9AF81A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Two suggestions for BEHAVE document > I can understand this position. However, wasn't RTCP thought > of a means to communicate packet loss rates? If I put this > in context with the IAB problem statement on congestion > control, I doubt it is a good idea to just silently prevent > RTCP from working. Agreed: the question is do we do anything on the NAT, or do we leave it strictlly to the application itself (e.g., in SDP-based protoctols like SIP, use RFC 3605 plus STUN-type discovery for both RTP and RTCP), or do also try to load the dice so the NAT will use consecutive ports. > Well, there are developers working on a SIP ALG for > netfilter, and they asked us to include infrastructure for > consecutive port number reservation into the netfilter NAT > core. Our current position on this is > > 1) consecutive port numbers are a bad idea, somebody should LART the > protocol designers > 2) now that we are facing the problem, we have to come up with a > solution (i.e. implement it). > > > I think that there is a very good chance based on past > experience that > > if NAT vendors use different algorithms for preserving consecutive > > port numbers, we will end-up in trouble. > > We'd just chose any two (or even four in the case of A/V > streams?) consecutive port numbers that are available. Just > like we would chose any single available port number. That works well with ALGs, but not so well with the non-ALG based BEHAVE is addressing. > > So I think that we need to discuss the issue in the document. > > > > Perhaps it's as simple as saying that we don't recommend > putting hacks > > in the NAT to address the issue because of reasons X, Y, Z. > > I would definitely like that. It saves us from those hacks > in the code. However, it should then be considered to alter > the RTP/RTCP specification to not require those consecutive > port numbers in the first place. > > Either the protocol changes, or the NAT's will have to adress > it. I don't see any way in between. So I'm counting this as a vote for "don't attempt to do complicated consecutive port preservation algorithms on the NAT"? Is this correct? From jdrosen@dynamicsoft.com Wed, 15 Sep 2004 20:15:47 -0700 (PDT) From: Jonathan Rosenberg Date: Wed, 15 Sep 2004 20:15:47 -0700 (PDT) Subject: Re: [Ietf-behave] UDP binding timeouts In-Reply-To: Message-ID: <4149053A.4080502@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain inline. Dan Wing wrote: I think the most important thing is that there is a deterministic minimum that you can count on; the actual value is far less important. In principal, you'd like to tie the timeout to typical maximum activity intervals for UDP-based applications. That is, normal outbound packet activity for applications should keep the bindings active withot requiring additional keepalives. For RTP, even a much smaller number would typically suffice. For SIP over UDP, packet retransmits can be spaced as large as 16s towards the tail end of the transaction. If you want the binding to be active for a transaction lifetime without special keepalives, you'd want a minimum of 20s or so. With such short binding lifetimes, wouldn't you need SIP keepalives (.) to keep the binding open so you can be signaled for an incoming call? Sure, but that's different. My argument was that it made sense to set the binding timeout so that it was large enough to not require additional keepalive traffic for UDP applications. I probably should have been clear that I meant client/server applications - ones for which an infinite binding lifetime is not required. For those cases where the binding effectively needs to be infinitely long, such as receiving a SIP call, I think there is no way to avoid keepalives. In such a case, the following might make a reasonable metric for choosing the lifetime: the binding lifetime should be large enough such that a reasonable keepalive message, sent at intervals equal to that binding lifetime, would only represent a fraction of the overall bandwidth for the application protocol itself in its typical usage - say, no more than 5%. Again looking at SIP, if we assume (REGISTER,200) refreshes of (1kB,1kB) every hour, plus a SIP call every other hour (INV/200/ACK/BYE/200) with rough sizes of (1k,1k,.5k,1k,.5k), thats 4kB/hour. 5% of that is 200B/hr. Assuming STUN for keepalives, its roughly 50B for a minimal request/response transaction. That gives you 4 of them per hour, which would argue for a relatively large keepalive interval - 15m. The tradeoff, of course, is that increasing the keepalive increases the memory required for a certain volume of user traffic, and thus the cost. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From csp@csperkins.org Thu, 16 Sep 2004 02:24:23 -0700 (PDT) From: Colin Perkins Date: Thu, 16 Sep 2004 02:24:23 -0700 (PDT) Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document In-Reply-To: Message-ID: <1DB41BD7-07C2-11D9-81C8-000A957FC5F2@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain On 14 Sep 2004, at 21:10, Dan Wing wrote: On Thu, Sep 02, 2004 at 12:22:38PM -0400, Francois Audet wrote: - I'd like to mandate that the port parity (even/odd) be respected by the NAT when assigning UDP bindings. This is to respect the RTP=even and RTCP=odd rule. There is some very unfortunate wording in RFC 3550 section 11, second paragraph, which have caused some problematic behavior in client. The wording can be interpreted as saying that if a client receives an odd port for sending RTP, it SHOULD change it to next lower even number. This would obviously break peer-to-peer media. Isn't there also the requirement that RTP/RTCP are on two consecutive port numbers? Yes, the RTP specification requires this, but RFC3605 shows how the actual RTCP port can be signaled. This is something we need to mention in the RTP client specification (which, to my knowledge, nobody has yet started, but I'm getting an itch here to start it). The RTP specification says [RFC 3550, section 11]: RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number. For applications that take a single port number as a parameter and derive the RTP and RTCP port pair from that number, if an odd number is supplied then the application SHOULD replace that number with the next lower (even) number to use as the base of the port pair. For applications in which the RTP and RTCP destination port numbers are specified via explicit, separate parameters (using a signaling protocol or other means), the application MAY disregard the restrictions that the port numbers be even/odd and consecutive although the use of an even/odd port pair is still encouraged. The RTP and RTCP port numbers MUST NOT be the same since RTP relies on the port numbers to demultiplex the RTP data and RTCP control streams. The relaxation on the port numbers when explicit signalling is used was put in place to ease NAT traversal. Colin From dwing@cisco.com Thu, 16 Sep 2004 10:28:46 -0700 (PDT) From: "Dan Wing" Date: Thu, 16 Sep 2004 10:28:46 -0700 (PDT) Subject: RE: [Ietf-behave] UDP binding timeouts In-Reply-To: <4149053A.4080502@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > > With such short binding lifetimes, wouldn't you need SIP keepalives > > (.) to keep the binding open so you can be signaled > > for an incoming call? > > Sure, but that's different. My argument was that it made sense to set > the binding timeout so that it was large enough to not require > additional keepalive traffic for UDP applications. I probably should > have been clear that I meant client/server applications - ones for which > an infinite binding lifetime is not required. > > For those cases where the binding effectively needs to be infinitely > long, such as receiving a SIP call, I think there is no way to avoid > keepalives. In such a case, the following might make a reasonable metric > for choosing the lifetime: the binding lifetime should be large enough > such that a reasonable keepalive message, sent at intervals equal to > that binding lifetime, The keepalives need to be sent a little more aggressively than the timeout. If you consider the keepalive itself could get dropped between the application and the NAT (such as a noisy WiFi connection or a busy Ethernet segment or an over-taxed NAT), the keepalives need to be even more aggressive. > would only represent a fraction of the overall > bandwidth for the application protocol itself in its typical usage - > say, no more than 5%. > > Again looking at SIP, if we assume (REGISTER,200) refreshes of (1kB,1kB) > every hour, plus a SIP call every other hour (INV/200/ACK/BYE/200) with > rough sizes of (1k,1k,.5k,1k,.5k), thats 4kB/hour. 5% of that is > 200B/hr. Assuming STUN for keepalives, its roughly 50B for a minimal > request/response transaction. That gives you 4 of them per hour, which > would argue for a relatively large keepalive interval - 15m. Most NATs have a keepalive of 30 seconds, and the current BEHAVE I-D suggests 2 minutes. 15 minutes is quite a long way from where we are today. Are you perhaps suggesting that certain ports, such as the SIP port (UDP 5060) should be required, by BEHAVE, to have long keepalives? > The tradeoff, of course, is that increasing the keepalive increases the > memory required for a certain volume of user traffic, and thus the cost. Are you referring to the memory in the NAT to keep the state? It's not just memory, of course, but also the increased 'security exposure' of this binding staying open a long time that causes many NATs to want to have aggressive binding timeouts. -d From audet@nortelnetworks.com Thu, 16 Sep 2004 10:52:37 -0700 (PDT) From: "Francois Audet" Date: Thu, 16 Sep 2004 10:52:37 -0700 (PDT) Subject: RE: [Ietf-behave] UDP binding timeouts Message-ID: <1ECE0EB50388174790F9694F77522CCF9AFE8B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] UDP binding timeouts > The keepalives need to be sent a little more aggressively > than the timeout. If you consider the keepalive itself could > get dropped between the application and the NAT (such as a > noisy WiFi connection or a busy Ethernet segment or an > over-taxed NAT), the keepalives need to be even more aggressive. This is where I think we are having different views. Cullen and I seemed to have seen different data. More like 2-5 minutes being very common. We did see NATs with 30 s or 1 minute timeouts, but we considered them to be broken. This is really the question: do we want to encourage NAT vendors to have longer timeouts (like the suggested 2 minutes), or do we want shorter timeouts? Personally, I think 30s is too short. I'd like us to recommend at least 1 minute. Other views? From dwing@cisco.com Thu, 16 Sep 2004 11:10:08 -0700 (PDT) From: "Dan Wing" Date: Thu, 16 Sep 2004 11:10:08 -0700 (PDT) Subject: RE: [Ietf-behave] UDP binding timeouts In-Reply-To: <1ECE0EB50388174790F9694F77522CCF9AFE8B@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > > The keepalives need to be sent a little more aggressively > > than the timeout. If you consider the keepalive itself could > > get dropped between the application and the NAT (such as a > > noisy WiFi connection or a busy Ethernet segment or an > > over-taxed NAT), the keepalives need to be even more aggressive. > > This is where I think we are having different views. > > Cullen and I seemed to have seen different data. More like > 2-5 minutes being very common. We did see NATs with 30 s or > 1 minute timeouts, but we considered them to be broken. > > This is really the question: do we want to encourage NAT vendors > to have longer timeouts (like the suggested 2 minutes), or do we > want shorter timeouts? > > Personally, I think 30s is too short. I'd like us to recommend at > least 1 minute. > > Other views? I'm sorry, are you saying that we have different views that keepalive messages can be dropped between the application and the NAT (which is the excerpt from my email you quoted above), or that we have different views on the minimum duration of a UDP binding that BEHAVE should require? I'm happy with requiring a 2 minute timeout and I agree a 30 second timeout is too aggressive. -d From audet@nortelnetworks.com Thu, 16 Sep 2004 11:42:51 -0700 (PDT) From: "Francois Audet" Date: Thu, 16 Sep 2004 11:42:51 -0700 (PDT) Subject: RE: [Ietf-behave] UDP binding timeouts Message-ID: <1ECE0EB50388174790F9694F77522CCF9AFF07@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] UDP binding timeouts > I'm sorry, are you saying that we have different views that > keepalive messages can be dropped between the application and the > NAT (which is the excerpt from my email you quoted above), or > that we have different views on the minimum duration of a UDP > binding that BEHAVE should require? Different views on the minimum duration of a UDP binding BEHAVE should require. > I'm happy with requiring a 2 minute timeout and I agree a 30 > second timeout is too aggressive. OK: so we don't have different views after all :-) So I'll leave it at 2 minutes. From spencer@mcsr-labs.org Fri, 24 Sep 2004 06:07:38 -0700 (PDT) From: "Spencer Dawkins" Date: Fri, 24 Sep 2004 06:07:38 -0700 (PDT) Subject: [Ietf-behave] Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd) In-Reply-To: Message-ID: <0abd01c4a237$7a139060$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain Dear IESG, On Fri, 17 Sep 2004, The IESG wrote: A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@xxxxxxxx) by September 24. My apologies for responding at the last second... I happen to agree with the current charter, as far as it goes. I also note that there's a fascinating discussion (thread starts at http://www1.ietf.org/mail-archive/web/sip/current/msg10349.html on "GRUU and things that rewrite contacts", about the impact of Session Border Controllers on new features in SIP. If I understand the meta-goal for BEHAVE, it's "write a BCP so NAT vendors stop breaking VoIP" (since classic TCP-based client-server protocols work passably well on NAT/ALGs). BEHAVE declined the privilege (I think correctly) of defining BCP behavior for ALGs in general, but I expect that while BEHAVE is fixing NATs, the Internet will deploy SBCs with behavior just as destructive for VoIP as NATs, and we'll be back doing "Son of BEHAVE" in five years (and arguing whether it's worth doing, because of all the SBCs that are built into wireless APs, etc.). We could sidestep that agony by attacking the problem now (or "immediately after finishing a BCP for NATs", if you are worried about defocusing BEHAVE. Maybe BEHAVE isn't the right WG to think about SBCs, but there sure are a lot of BEHAVE participants I recognize from SIP/SIPPING/SIMPLE/XCON... I would hate to see them wasting their time if we move from "can't deploy because of broken NAT behavior" to "can't deploy because of broken SBC behavior". Spencer From jon.peterson@neustar.biz Fri, 24 Sep 2004 16:59:05 -0700 (PDT) From: "Peterson, Jon" Date: Fri, 24 Sep 2004 16:59:05 -0700 (PDT) Subject: [Ietf-behave] RE: WG Review: Behavior Engineering for Hindrance Avoidance (beha ve) (fwd) Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF41C9@stntexch04.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain Spencer, I agree that there are parallels between Session Border Controllers (SBCs) and NATs - the most striking being that the SIP community is in the same phase of denial about SBCs that the Internet community once went through with NATs. People in the SIP community are loathe to specify what an SBC is; there's just a general sentiment that SBCs are evil intermediaries, and if we codify them, we'll surely further their adoption. Sounds familiar, doesn't it. However else one might "benefit" from a NAT deployment, the primary reason for the existence of NAT is IPv4 address conservation. It is in this context that residences, for example, with no particular need for network-layer policy enforcement, are burdened with NATs. SBCs exist for a number of reasons - ironically, SBCs are frequently used for firewall/NAT traversal (since they act as media relays), and if NATs went away, some of the reasons for SBCs might go away as well. They rewrite the Contact header for two reasons, generally - as a part of their NAT traversal function, or in order to maintain their presence as a policy control point for SIP session signaling. I guess on balance, I think the problem of NATs and the problem of SBCs are separable problems - getting good behavioral guidance for NATs would help a number of applications (not just VoIP, but things like real-time Internet gaming, and so on), and might decrease the number of SBCs out there. Maybe we should say this: BEHAVE should reserve the right to recharter at a later time to look at other sorts of intermediaries that are harassing real-time applications on the Internet. For a first morsel to bite off, though, I think NATs are a mouthful. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@xxxxxxxxxxxxx] > Sent: Friday, September 24, 2004 6:08 AM > To: iesg@xxxxxxxx > Cc: IETF Behave Mailing List > Subject: Re: WG Review: Behavior Engineering for Hindrance Avoidance > (behave) (fwd) > > > Dear IESG, > > On Fri, 17 Sep 2004, The IESG wrote: > > A new IETF working group has been proposed in the Transport Area. The IESG has > > not made any determination as yet. The following description was submitted, > > and is provided for informational purposes only. Please send your comments to > > the IESG mailing list (iesg@xxxxxxxx) by September 24. > > My apologies for responding at the last second... > > I happen to agree with the current charter, as far as it goes. > > I also note that there's a fascinating discussion (thread starts at > http://www1.ietf.org/mail-archive/web/sip/current/msg10349.html on > "GRUU and things that rewrite contacts", about the impact of Session > Border Controllers on new features in SIP. > > If I understand the meta-goal for BEHAVE, it's "write a BCP so NAT > vendors stop breaking VoIP" (since classic TCP-based client-server > protocols work passably well on NAT/ALGs). > > BEHAVE declined the privilege (I think correctly) of defining BCP > behavior for ALGs in general, but I expect that while BEHAVE > is fixing > NATs, the Internet will deploy SBCs with behavior just as destructive > for VoIP as NATs, and we'll be back doing "Son of BEHAVE" in five > years (and arguing whether it's worth doing, because of all the SBCs > that are built into wireless APs, etc.). We could sidestep that agony > by attacking the problem now (or "immediately after finishing a BCP > for NATs", if you are worried about defocusing BEHAVE. > > Maybe BEHAVE isn't the right WG to think about SBCs, but there sure > are a lot of BEHAVE participants I recognize from > SIP/SIPPING/SIMPLE/XCON... I would hate to see them wasting > their time > if we move from "can't deploy because of broken NAT behavior" to > "can't deploy because of broken SBC behavior". > > Spencer > > > From dwing@cisco.com Tue, 28 Sep 2004 16:13:50 -0700 (PDT) From: "Dan Wing" Date: Tue, 28 Sep 2004 16:13:50 -0700 (PDT) Subject: RE: [Ietf-behave] Re: WG Review: Behavior Engineering for HindranceAvoidance (behave) (fwd) In-Reply-To: <0abd01c4a237$7a139060$0400a8c0@DFNJGL21> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Session Border Controllers are most like HTTP proxies and FTP proxies -- packets are generally sent to the IP address of the SBC, much like most HTTP proxies and FTP proxies. And, like HTTP and FTP proxies, SBCs oftentimes change the content of the packets. (There are invisible HTTP and FTP proxies, too, of course). -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Spencer > Dawkins > Sent: Friday, September 24, 2004 6:08 AM > To: iesg@xxxxxxxx > Cc: IETF Behave Mailing List > Subject: [Ietf-behave] Re: WG Review: Behavior Engineering for > HindranceAvoidance (behave) (fwd) > > > Dear IESG, > > On Fri, 17 Sep 2004, The IESG wrote: > > A new IETF working group has been proposed in the Transport Area. > > The IESG has > > not made any determination as yet. The following description was > > submitted, > > and is provided for informational purposes only. Please send your > > comments to > > the IESG mailing list (iesg@xxxxxxxx) by September 24. > > My apologies for responding at the last second... > > I happen to agree with the current charter, as far as it goes. > > I also note that there's a fascinating discussion (thread starts at > http://www1.ietf.org/mail-archive/web/sip/current/msg10349.html on > "GRUU and things that rewrite contacts", about the impact of Session > Border Controllers on new features in SIP. > > If I understand the meta-goal for BEHAVE, it's "write a BCP so NAT > vendors stop breaking VoIP" (since classic TCP-based client-server > protocols work passably well on NAT/ALGs). > > BEHAVE declined the privilege (I think correctly) of defining BCP > behavior for ALGs in general, but I expect that while BEHAVE is fixing > NATs, the Internet will deploy SBCs with behavior just as destructive > for VoIP as NATs, and we'll be back doing "Son of BEHAVE" in five > years (and arguing whether it's worth doing, because of all the SBCs > that are built into wireless APs, etc.). We could sidestep that agony > by attacking the problem now (or "immediately after finishing a BCP > for NATs", if you are worried about defocusing BEHAVE. > > Maybe BEHAVE isn't the right WG to think about SBCs, but there sure > are a lot of BEHAVE participants I recognize from > SIP/SIPPING/SIMPLE/XCON... I would hate to see them wasting their time > if we move from "can't deploy because of broken NAT behavior" to > "can't deploy because of broken SBC behavior". > > Spencer > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Tue, 28 Sep 2004 16:35:46 -0700 (PDT) From: "Dan Wing" Date: Tue, 28 Sep 2004 16:35:46 -0700 (PDT) Subject: [Ietf-behave] draft-wing-mmusic-symmetric-rtprtcp Message-ID: MIME-Version: 1.0 Content-Type: text/plain I wanted to point folks at the following brief I-D which defines Symmetric RTP and Symmetric RTCP: Title : Symmetric RTP and RTCP Considered Helpful Author(s) : D. Wing Filename : draft-wing-mmusic-symmetric-rtprtcp-00.txt Pages : 8 Date : 2004-9-23 This document defines symmetric RTP and symmetric RTCP and recommends their use. http://www.ietf.org/internet-drafts/draft-wing-mmusic-symmetric-rtprtcp-00.t xt I'd like this to be a standards-track RFC, so vendors can claim compliance to the RFC. It should probably be rolled into a document describing other endpoint requirements, but one doesn't currently exist; if BEHAVE turns into a WG it might make sense to put the text of -symmetric-rtprtcp- into an overall document describing how VoIP endpoints should behave when they're behind a Behave-compliant NAT. Comments welcome. -d From jdrosen@dynamicsoft.com Tue, 28 Sep 2004 23:16:08 -0700 (PDT) From: Jonathan Rosenberg Date: Tue, 28 Sep 2004 23:16:08 -0700 (PDT) Subject: [Ietf-behave] port-type preservation? Message-ID: <415A5327.6080808@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain Folks, An interesting thread has been going on on the mmusic list, which is relevant to behave. The discussion was around NAT preservation of port-types, where the types are (for UDP) "well-known" from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/private" from 49152 through 65535. See: http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html If a NAT sees an outbound packet with one of these types, does it attempt to maintain the preservation? That is, should an outbound packet within the dynamic range always map to a port in the dynamic range? I think the behave draft should probably say something about this. I suspect its probably a good idea to preserve the port-type. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From audet@nortelnetworks.com Wed, 29 Sep 2004 15:51:16 -0700 (PDT) From: "Francois Audet" Date: Wed, 29 Sep 2004 15:51:16 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? Message-ID: <1ECE0EB50388174790F9694F77522CCFB2D54B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] port-type preservation? So, if I understand correctly, you want us to put in the Behave document something saying that port binding assignments are to be done from the dynamic/private port range 49152-65535? Right? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jonathan Rosenberg > Sent: Tuesday, September 28, 2004 23:16 > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: [Ietf-behave] port-type preservation? > > > Folks, > > An interesting thread has been going on on the mmusic list, which is > relevant to behave. The discussion was around NAT preservation of > port-types, where the types are (for UDP) "well-known" from 0 > to 1023, > "registered" from 1024 to 49151, and "dynamic/private" from 49152 > through 65535. See: > http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html If a NAT sees an outbound packet with one of these types, does it attempt to maintain the preservation? That is, should an outbound packet within the dynamic range always map to a port in the dynamic range? I think the behave draft should probably say something about this. I suspect its probably a good idea to preserve the port-type. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Wed, 29 Sep 2004 21:09:44 -0700 (PDT) From: "Dan Wing" Date: Wed, 29 Sep 2004 21:09:44 -0700 (PDT) Subject: [Ietf-behave] RE: [Sip] draft-takeda-symmetric-nat-traversal ?? In-Reply-To: <415A986B.9070008@aftek.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Thanks for bringing that I-D to the group's attention. I, for one, hadn't seen it. Section 8.1 is where the meat is, and it says: ... If the port allocation rule of the other endpoint is a symmetric type, the endpoint needs either to record the source port number of an incoming packet or to predict a port number that the symmetric NAT will assign, with a MAPPED-ADDRESS obtained from the other endpoint. ... which I agree isn't a good mechanism, especially with a large NAT. It could work just fine on a small, residential NAT which isn't processing much new traffic (and thus it is, in theory, possible to guess the next port number it will assign for the next mapping). This technique is too fragile for my blood. There is a lot of other good information in this Internet Draft, though; I hope we can incorporate some of it into the BEHAVE work if the author is willing. -d > -----Original Message----- > From: sip-bounces@xxxxxxxx [mailto:sip-bounces@xxxxxxxx]On Behalf Of > Vikram Bhuskute > Sent: Wednesday, September 29, 2004 4:12 AM > To: sip@xxxxxxxx > Subject: [Sip] draft-takeda-symmetric-nat-traversal ?? > > > Hello all, > While searching for NAT traversal solution i came across a > draft "draft-takeda-symmetric-nat-traversal-00.txt" > from url ( > http://cnscenter.future.co.kr/resource/ietf/ind-draft/draft-takeda > -symmetric-nat-traversal-00.txt) > > It proposes some solution for Symmetric NAT based on some > Prediction .....? It dosent seem reliable ... !!! > (however it gives glimps on type of Symmetric NATs ) > > Is it still a matter of further research ? or the concept is > not well accepted ? > > thanks in advance > > vikram > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > Use sipping@xxxxxxxx for new developments on the application of sip From jdrosen@dynamicsoft.com Thu, 30 Sep 2004 07:52:15 -0700 (PDT) From: Jonathan Rosenberg Date: Thu, 30 Sep 2004 07:52:15 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: <1ECE0EB50388174790F9694F77522CCFB2D54B@zrc2hxm0.corp.nortel.com> Message-ID: <415C1D9C.3020207@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain Almost. What I'm saying is, if the source port on the private side is in the dynamic range, the source port on the public side should probably be in that range. If the source port is in the registered range, so too should the source port on the public side, and same for the well-known range. -Jonathan R. Francois Audet wrote: So, if I understand correctly, you want us to put in the Behave document something saying that port binding assignments are to be done from the dynamic/private port range 49152-65535? Right? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jonathan Rosenberg > Sent: Tuesday, September 28, 2004 23:16 > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: [Ietf-behave] port-type preservation? > > > Folks, > > An interesting thread has been going on on the mmusic list, which is > relevant to behave. The discussion was around NAT preservation of > port-types, where the types are (for UDP) "well-known" from 0 > to 1023, > "registered" from 1024 to 49151, and "dynamic/private" from 49152 > through 65535. See: > http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html If a NAT sees an outbound packet with one of these types, does it attempt to maintain the preservation? That is, should an outbound packet within the dynamic range always map to a port in the dynamic range? I think the behave draft should probably say something about this. I suspect its probably a good idea to preserve the port-type. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Thu, 30 Sep 2004 08:32:43 -0700 (PDT) From: Jonathan Rosenberg Date: Thu, 30 Sep 2004 08:32:43 -0700 (PDT) Subject: [Ietf-behave] Re: WG Action: Behavior Engineering for Hindrance Avoidance (behave) In-Reply-To: <200409291945.PAA03118@ietf.org> Message-ID: <415C26B6.8050409@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain Great news! Thanks to Cullen and Jiri for taking the lead on this and doing a good job in getting it organized and started. -Jonathan R. The IESG wrote: A new IETF working group has been formed in the Transport Area. For additional information, please contact the Area Directors or the WG Chairs. Behavior Engineering for Hindrance Avoidance (behave) ===================================================== Current Status: Active Working Group CHAIRS: Cullen Jennings Jiri Kuthan Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Jon Peterson MAILING LISTS: General Discussion: ietf-behave@xxxxxxxxxxxxxxxxxxx To Subscribe: ietf-behave-request@xxxxxxxxxxxxxxxxxxx with subscribe in body Archive: http://list.sipfoundry.org/archive/ietf-behave DESCRIPTION: Given the current near-universal deployment of NATs (Network Address Translators) in the public Internet, the lack of standards for NAT behavior has given rise to a crisis. While it is widely acknowledged that NATs create problems for numerous Internet applications, our inability to describe precisely what a NAT is or how it behaves leaves us few solutions for compensating for the presence of NATs. The behavior of NATs varies dramatically from one implementation to another.As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end-to-end interactive applications such as multiuser games and interactive multimedia. NATs continue to proliferate and have seen an increasing rate of deployment. IPv6 deployments can eliminate this problem, but there is a significant interim period in which applications will need to work both in IPv4 NAT environments and with the IPv6 to IPv4 transition mechanisms. This working group proposes to generate requirements documents and best current practices to enable NATs to function in as deterministic a fashion as possible. It will consider what is broken by these devices and document approaches for characterizing and testing them. The NAT behavior practices will be application independent. The group will also advise on how to develop applications that discover and reliably function in environments with NATs that follow the best current practices identified by this working group. The group will consider the security implications (or non-implications) of these devices. The work will be done with the goal of encouraging eventual migration to IPv6 and compliance with the UNSAF [RFC 3424] considerations. It will not encourage the proliferation of NATs. The behavior that will be considered includes IP fragmentation and parameters that impact ICMP, UDP, TCP, IGMP, MLD, and multicast. The proposed WG will coordinate with v6ops, midcom and nsis. The work is largely limited to examining various approaches that are already in use today and providing suggestions about which ones are likely to work best in the internet architecture. Discussion will start from several existing drafts or RFCs, including: draft-jennings-midcom-stun-results draft-audet-nat-behave RFC 3489 draft-ford-midcom-p2p Goals & Milestones 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf-announce -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From audet@nortelnetworks.com Thu, 30 Sep 2004 10:07:53 -0700 (PDT) From: "Francois Audet" Date: Thu, 30 Sep 2004 10:07:53 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? Message-ID: <1ECE0EB50388174790F9694F77522CCFB2D8DD@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] port-type preservation? Hi Jonathan, I'm not sure I understand the logic. Why would a well-known value be mapped to ANOTHER registered value? Are you saying that we would map, say, the registered value for http to the registered value for, say, FTP? I was thinking that what we need to say is that there is a mapping (i.e., in cases where the port number is not preserved), it shall always map to the dynamic range. I'm sure I'm misunderstanding what you are saying or missing something obvious... > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxxxxxxxx] > Sent: Thursday, September 30, 2004 07:52 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: Re: [Ietf-behave] port-type preservation? > > > Almost. > > What I'm saying is, if the source port on the private side is in the > dynamic range, the source port on the public side should > probably be in > that range. If the source port is in the registered range, so > too should > the source port on the public side, and same for the well-known range. > > -Jonathan R. > > Francois Audet wrote: > > > So, if I understand correctly, you want us to put in the Behave > > document something saying that port binding assignments are > to be done > > from the dynamic/private port range 49152-65535? > > > > Right? > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > Jonathan Rosenberg > Sent: Tuesday, September 28, 2004 23:16 > > > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > > Subject: [Ietf-behave] port-type preservation? > > > > > > > > > Folks, > > > > > > An interesting thread has been going on on the mmusic > list, which is > > > relevant to behave. The discussion was around NAT preservation of > > > port-types, where the types are (for UDP) "well-known" from 0 > > > to 1023, > > > "registered" from 1024 to 49151, and "dynamic/private" from 49152 > > > through 65535. See: > > > > > http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html > > > > If a NAT sees an outbound packet with one of these types, does it > > attempt to maintain the preservation? That is, should an outbound > > packet within the dynamic range always map to a port in the dynamic > > range? > > > > I think the behave draft should probably say something > about this. I > > suspect its probably a good idea to preserve the port-type. > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ > 07054-2711 > > dynamicsoft > > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > From dwing@cisco.com Thu, 30 Sep 2004 11:14:21 -0700 (PDT) From: "Dan Wing" Date: Thu, 30 Sep 2004 11:14:21 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? In-Reply-To: <415C1D9C.3020207@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain This sounds like a good idea, and it's logical. However, do we know of any IETF or non-IETF protocol that breaks if you don't have a source UDP port within the appropriate range? I poked around DNS and TFTP and neither care about the source UDP port number for their operation. NFSv2 (RFC1831) has a preference for the connections to come from privileged ports, but with everyone having privileges on their own computer now-a-days I think NFS's preference is historic. Without an application that breaks, the best I think we should say is a strongly-worded "MAY", like this strawman text: When deciding the source UDP port for an outgoing binding a NAT MAY choose a source port that is in the same IANA range (well known, registered, or dynamic) as the original source UDP port. However, as most modern applications to not utilize source port numbers as an indicator of trust, there is little value in a NAT to provide this function. -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Jonathan > Rosenberg > Sent: Thursday, September 30, 2004 7:52 AM > To: Francois Audet > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: Re: [Ietf-behave] port-type preservation? > > > Almost. > > What I'm saying is, if the source port on the private side is in the > dynamic range, the source port on the public side should probably be in > that range. If the source port is in the registered range, so too should > the source port on the public side, and same for the well-known range. > > -Jonathan R. > > Francois Audet wrote: > > > So, if I understand correctly, you want us to put in the Behave document > > something saying that port binding assignments are to be done from the > > dynamic/private port range 49152-65535? > > > > Right? > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > Jonathan Rosenberg > > > Sent: Tuesday, September 28, 2004 23:16 > > > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > > Subject: [Ietf-behave] port-type preservation? > > > > > > > > > Folks, > > > > > > An interesting thread has been going on on the mmusic list, which is > > > relevant to behave. The discussion was around NAT preservation of > > > port-types, where the types are (for UDP) "well-known" from 0 > > > to 1023, > > > "registered" from 1024 to 49151, and "dynamic/private" from 49152 > > > through 65535. See: > > > > > http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html > > > > If a NAT sees an outbound packet with one of these types, does it > > attempt to maintain the preservation? That is, should an outbound packet > > within the dynamic range always map to a port in the dynamic range? > > > > I think the behave draft should probably say something about this. I > > suspect its probably a good idea to preserve the port-type. > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ 07054-2711 > > dynamicsoft > > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortelnetworks.com Thu, 30 Sep 2004 11:18:44 -0700 (PDT) From: "Francois Audet" Date: Thu, 30 Sep 2004 11:18:44 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? Message-ID: <1ECE0EB50388174790F9694F77522CCFB2D997@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] port-type preservation? Can you explain the downside of always using the dynamic range for outgoing port binding? > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Thursday, September 30, 2004 11:14 > To: Jonathan Rosenberg; Audet, Francois [SC100:9T51:EXCH] > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] port-type preservation? > > > This sounds like a good idea, and it's logical. > > However, do we know of any IETF or non-IETF protocol that > breaks if you don't have a source UDP port within the > appropriate range? > > I poked around DNS and TFTP and neither care about the source > UDP port number for their operation. NFSv2 (RFC1831) has a > preference for the connections to come from privileged ports, > but with everyone having privileges on their own computer > now-a-days I think NFS's preference is historic. > > Without an application that breaks, the best I think we > should say is a strongly-worded "MAY", like this strawman text: > > When deciding the source UDP port for an outgoing binding a NAT > MAY choose a source port that is in the same IANA range (well > known, registered, or dynamic) as the original source UDP port. > However, as most modern applications to not utilize source port > numbers as an indicator of trust, there is little value in a NAT > to provide this function. > > -d > > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf > Of Jonathan > > Rosenberg > > Sent: Thursday, September 30, 2004 7:52 AM > > To: Francois Audet > > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > Subject: Re: [Ietf-behave] port-type preservation? > > > > > > Almost. > > > > What I'm saying is, if the source port on the private side > is in the > > dynamic range, the source port on the public side should > probably be > > in that range. If the source port is in the registered > range, so too > > should the source port on the public side, and same for the > well-known > > range. > > > > -Jonathan R. > > > > Francois Audet wrote: > > > > > So, if I understand correctly, you want us to put in the Behave > > > document something saying that port binding assignments are to be > > > done from the dynamic/private port range 49152-65535? > > > > > > Right? > > > > > > > -----Original Message----- > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > Behalf Of > > > > Jonathan Rosenberg > Sent: Tuesday, September 28, 2004 23:16 > > > > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > > > Subject: [Ietf-behave] port-type preservation? > > > > > > > > > > > > Folks, > > > > > > > > An interesting thread has been going on on the mmusic > list, which is > > > > relevant to behave. The discussion was around NAT > preservation of > > > > port-types, where the types are (for UDP) "well-known" from 0 > > > > to 1023, > > > > "registered" from 1024 to 49151, and "dynamic/private" > from 49152 > > > > through 65535. See: > > > > > > > http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html > > > > > > If a NAT sees an outbound packet with one of these types, does it > > > attempt to maintain the preservation? That is, should an outbound > > > packet within the dynamic range always map to a port in > the dynamic > > > range? > > > > > > I think the behave draft should probably say something > about this. I > > > suspect its probably a good idea to preserve the port-type. > > > > > > -Jonathan R. > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, > NJ 07054-2711 > > > dynamicsoft > > > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ > 07054-2711 > > dynamicsoft > > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > From dwing@cisco.com Thu, 30 Sep 2004 11:58:17 -0700 (PDT) From: "Dan Wing" Date: Thu, 30 Sep 2004 11:58:17 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? In-Reply-To: <1ECE0EB50388174790F9694F77522CCFB2D997@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Unless we can find a modern UDP-based application that cares about preserving the range, I don't see a downside. -d -----Original Message----- From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx] Sent: Thursday, September 30, 2004 11:17 AM To: 'Dan Wing'; 'Jonathan Rosenberg' Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' Subject: RE: [Ietf-behave] port-type preservation? Can you explain the downside of always using the dynamic range for outgoing port binding? > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Thursday, September 30, 2004 11:14 > To: Jonathan Rosenberg; Audet, Francois [SC100:9T51:EXCH] > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] port-type preservation? > > > This sounds like a good idea, and it's logical. > > However, do we know of any IETF or non-IETF protocol that > breaks if you don't have a source UDP port within the > appropriate range? > > I poked around DNS and TFTP and neither care about the source > UDP port number for their operation. NFSv2 (RFC1831) has a > preference for the connections to come from privileged ports, > but with everyone having privileges on their own computer > now-a-days I think NFS's preference is historic. > > Without an application that breaks, the best I think we > should say is a strongly-worded "MAY", like this strawman text: > > When deciding the source UDP port for an outgoing binding a NAT > MAY choose a source port that is in the same IANA range (well > known, registered, or dynamic) as the original source UDP port. > However, as most modern applications to not utilize source port > numbers as an indicator of trust, there is little value in a NAT > to provide this function. > > -d > > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf > Of Jonathan > > Rosenberg > > Sent: Thursday, September 30, 2004 7:52 AM > > To: Francois Audet > > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > Subject: Re: [Ietf-behave] port-type preservation? > > > > > > Almost. > > > > What I'm saying is, if the source port on the private side > is in the > > dynamic range, the source port on the public side should > probably be > > in that range. If the source port is in the registered > range, so too > > should the source port on the public side, and same for the > well-known > > range. > > > > -Jonathan R. > > > > Francois Audet wrote: > > > > > So, if I understand correctly, you want us to put in the Behave > > > document something saying that port binding assignments are to be > > > done from the dynamic/private port range 49152-65535? > > > > > > Right? > > > > > > > -----Original Message----- > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > Behalf Of > > > > Jonathan Rosenberg > Sent: Tuesday, September 28, 2004 23:16 > > > > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > > > Subject: [Ietf-behave] port-type preservation? > > > > > > > > > > > > Folks, > > > > > > > > An interesting thread has been going on on the mmusic > list, which is > > > > relevant to behave. The discussion was around NAT > preservation of > > > > port-types, where the types are (for UDP) "well-known" from 0 > > > > to 1023, > > > > "registered" from 1024 to 49151, and "dynamic/private" > from 49152 > > > > through 65535. See: > > > > > > > http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html > > > > > > If a NAT sees an outbound packet with one of these types, does it > > > attempt to maintain the preservation? That is, should an outbound > > > packet within the dynamic range always map to a port in > the dynamic > > > range? > > > > > > I think the behave draft should probably say something > about this. I > > > suspect its probably a good idea to preserve the port-type. > > > > > > -Jonathan R. > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, > NJ 07054-2711 > > > dynamicsoft > > > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ > 07054-2711 > > dynamicsoft > > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > From audet@nortelnetworks.com Thu, 30 Sep 2004 12:06:35 -0700 (PDT) From: "Francois Audet" Date: Thu, 30 Sep 2004 12:06:35 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? Message-ID: <1ECE0EB50388174790F9694F77522CCFB2DA35@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] port-type preservation? That's what I think. Let's wait for Jonathan's input. To summarize, I'm saying that instead of preserving the port range, always use the dynamic range when doing a mapping to a new port. My concern about preserving the well-known and registered range is that it could cause some traffic to look like something else and thus be intercepted by layer 4-7 equipment doing deep-packet inspection and causing problems. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Thursday, September 30, 2004 11:57 > To: Audet, Francois [SC100:9T51:EXCH]; 'Jonathan Rosenberg' > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] port-type preservation? > > > Unless we can find a modern UDP-based application that cares > about preserving the range, I don't see a downside. > > -d > > -----Original Message----- > From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx] > Sent: Thursday, September 30, 2004 11:17 AM > To: 'Dan Wing'; 'Jonathan Rosenberg' > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: RE: [Ietf-behave] port-type preservation? > > > Can you explain the downside of always using the dynamic > range for outgoing port binding? > > -----Original Message----- > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Thursday, September 30, 2004 11:14 > > To: Jonathan Rosenberg; Audet, Francois [SC100:9T51:EXCH] > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] port-type preservation? > > > > > > This sounds like a good idea, and it's logical. > > > > However, do we know of any IETF or non-IETF protocol that breaks if > > you don't have a source UDP port within the appropriate range? > > > > I poked around DNS and TFTP and neither care about the > source UDP port > > number for their operation. NFSv2 (RFC1831) has a > preference for the > > connections to come from privileged ports, but with everyone having > > privileges on their own computer now-a-days I think NFS's > preference > > is historic. > > > > Without an application that breaks, the best I think we > should say is > > a strongly-worded "MAY", like this strawman text: > > > > When deciding the source UDP port for an outgoing binding a NAT > > MAY choose a source port that is in the same IANA range (well > > known, registered, or dynamic) as the original source UDP port. > > However, as most modern applications to not utilize source port > > numbers as an indicator of trust, there is little value in a NAT > > to provide this function. > > > > -d > > > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf > > Of Jonathan > > > Rosenberg > > > Sent: Thursday, September 30, 2004 7:52 AM > > > To: Francois Audet > > > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > > Subject: Re: [Ietf-behave] port-type preservation? > > > > > > > > > Almost. > > > > > > What I'm saying is, if the source port on the private side > > is in the > > > dynamic range, the source port on the public side should > > probably be > > > in that range. If the source port is in the registered > > range, so too > > > should the source port on the public side, and same for the > > well-known > > > range. > > > > > > -Jonathan R. > > > > > > Francois Audet wrote: > > > > > > > So, if I understand correctly, you want us to put in the Behave > > > > document something saying that port binding assignments > are to be > > > > done from the dynamic/private port range 49152-65535? > > > > > > > > Right? > > > > > > > > > -----Original Message----- > > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > > Behalf Of > > > > > Jonathan Rosenberg > Sent: Tuesday, September 28, 2004 > 23:16 > > > > > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: [Ietf-behave] > > > > port-type preservation? > > > > > > > > > > > Folks, > > > > > > > > > > An interesting thread has been going on on the mmusic > > list, which is > > > > > relevant to behave. The discussion was around NAT > > preservation of > > > > > port-types, where the types are (for UDP) > "well-known" from 0 > > > > > to 1023, > "registered" from 1024 to 49151, and > > > > "dynamic/private" > > from 49152 > > > > > through 65535. See: > > > > > > > > > > http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html > > > > > > > > If a NAT sees an outbound packet with one of these > types, does it > > > > attempt to maintain the preservation? That is, should > an outbound > > > > packet within the dynamic range always map to a port in > > the dynamic > > > > range? > > > > > > > > I think the behave draft should probably say something > > about this. I > > > > suspect its probably a good idea to preserve the port-type. > > > > > > > > -Jonathan R. > > > > -- > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Chief Technology Officer Parsippany, > > NJ 07054-2711 > > > > dynamicsoft > > > > jdrosen@xxxxxxxxxxxxxxx FAX: > (973) 952-5050 > > > > http://www.jdrosen.net PHONE: > (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ > > 07054-2711 > > > dynamicsoft > > > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > From audet@nortelnetworks.com Thu, 30 Sep 2004 16:14:18 -0700 (PDT) From: "Francois Audet" Date: Thu, 30 Sep 2004 16:14:18 -0700 (PDT) Subject: RE: [Ietf-behave] RE: [Sip] draft-takeda-symmetric-nat-traversal ?? Message-ID: <1ECE0EB50388174790F9694F77522CCFB2DC5B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] RE: [Sip] draft-takeda-symmetric-nat-traversal ?? I've removed from the SIP mailing list and kept it in BEHAVE. I agree with Dan that the mechanism is brittle. However, there is some good information in there. In particular, I find Table 6.3.1 a nice way to reconcile the categories of NAT behavior we have in BEHAVE with the "old" terminology (Cone, Symmetric, etc). Might be a good idea to think about a similar format. I'll think about it. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wing > Sent: Wednesday, September 29, 2004 21:10 > To: Vikram Bhuskute; sip@xxxxxxxx > Cc: takeday@xxxxxxxxx; IETF Behave Mailing List > Subject: [Ietf-behave] RE: [Sip] > draft-takeda-symmetric-nat-traversal ?? > > > Thanks for bringing that I-D to the group's attention. I, > for one, hadn't seen it. > > Section 8.1 is where the meat is, and it says: > > ... > If > the port allocation rule of the other endpoint is a symmetric type, > the endpoint needs either to record the source port number of an > incoming packet or to predict a port number that the symmetric NAT > will assign, with a MAPPED-ADDRESS obtained from the other > endpoint. > ... > > which I agree isn't a good mechanism, especially with a large > NAT. It could work just fine on a small, residential NAT > which isn't processing much new traffic (and thus it is, in > theory, possible to guess the next port number it will assign > for the next mapping). > > This technique is too fragile for my blood. > > > There is a lot of other good information in this Internet > Draft, though; I hope we can incorporate some of it into the > BEHAVE work if the author is willing. > > -d > > > -----Original Message----- > > From: sip-bounces@xxxxxxxx [mailto:sip-bounces@xxxxxxxx]On > Behalf Of > > Vikram Bhuskute > > Sent: Wednesday, September 29, 2004 4:12 AM > > To: sip@xxxxxxxx > > Subject: [Sip] draft-takeda-symmetric-nat-traversal ?? > > > > > > Hello all, > > While searching for NAT traversal solution i > came across a > > draft "draft-takeda-symmetric-nat-traversal-00.txt" > > from url ( > > http://cnscenter.future.co.kr/resource/ietf/ind-draft/draft-takeda > > -symmetric-nat-traversal-00.txt) > > > > It proposes some solution for Symmetric NAT > based on some > > Prediction .....? It dosent seem reliable ... !!! > > (however it gives glimps on type of Symmetric NATs ) > > > > Is it still a matter of further research ? or > the concept > > is not well accepted ? > > > > thanks in advance > > > > vikram > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@xxxxxxxxxxxxxxx for questions on > current sip Use > > sipping@xxxxxxxx for new developments on the application of sip > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinf> o/ietf-behave > > From jdrosen@dynamicsoft.com Thu, 30 Sep 2004 21:04:13 -0700 (PDT) From: Jonathan Rosenberg Date: Thu, 30 Sep 2004 21:04:13 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: <1ECE0EB50388174790F9694F77522CCFB2DA35@zrc2hxm0.corp.nortel.com> Message-ID: <415CA23B.9090009@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain The primary issue that motivated my comment was a discussion on mmusic, where we really wanted to be sure that a client which had a source port in the dynamic range, had it also mapped to one in the dynamic range. The reason had to do with ICE connectivity checks getting misrouted, and that you would not want them to be directed to well-known service ports. So, my extrapolation of this was that you would range port type presentation for the other types as well. However, I also can't think of a case where preservation in the other ranges is the right thing, and so mapping everything into dynamic should work. My first concern about this, though, is that the dynamic range is not that large (16k ports). Thus, if an enterprise is buying a nat to mux a large number of internal hosts into a small number of addresses, this reduces the "compression" ratio by a factor of four, compared to allowing the NAT to map anywhere into the 16 bit space. I would also expect that, in most cases, the packets originating from the private side of a nat would have source ports in the dynamic range. Almost by definition, only client/server protocols work through nat, implying that the packets which originate on the private side of the nat would be the result of a client operation in a C/S protocol. These ususally get sent from ephemeral ports, and operating systems should be allocating those from the dynamic range. If you're running a server on a host behind a nat (which would cause the responses to contain the well-known service port in the source port), that would have required you to configure port forwarding on the nat anyway, so the allocation is not dynamic there. -Jonathan R. Francois Audet wrote: That's what I think. Let's wait for Jonathan's input. To summarize, I'm saying that instead of preserving the port range, always use the dynamic range when doing a mapping to a new port. My concern about preserving the well-known and registered range is that it could cause some traffic to look like something else and thus be intercepted by layer 4-7 equipment doing deep-packet inspection and causing problems. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Thursday, September 30, 2004 11:57 > To: Audet, Francois [SC100:9T51:EXCH]; 'Jonathan Rosenberg' > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] port-type preservation? > > > Unless we can find a modern UDP-based application that cares > about preserving the range, I don't see a downside. > > -d > > -----Original Message----- > From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx] > Sent: Thursday, September 30, 2004 11:17 AM > To: 'Dan Wing'; 'Jonathan Rosenberg' > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: RE: [Ietf-behave] port-type preservation? > > > Can you explain the downside of always using the dynamic > range for outgoing port binding? > > -----Original Message----- > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Thursday, September 30, 2004 11:14 > > To: Jonathan Rosenberg; Audet, Francois [SC100:9T51:EXCH] > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] port-type preservation? > > > > > > This sounds like a good idea, and it's logical. > > > > However, do we know of any IETF or non-IETF protocol that breaks if > > you don't have a source UDP port within the appropriate range? > > > > I poked around DNS and TFTP and neither care about the > source UDP port > > number for their operation. NFSv2 (RFC1831) has a > preference for the > > connections to come from privileged ports, but with everyone having > > privileges on their own computer now-a-days I think NFS's > preference > > is historic. > > > > Without an application that breaks, the best I think we > should say is > > a strongly-worded "MAY", like this strawman text: > > > > When deciding the source UDP port for an outgoing binding a NAT > > MAY choose a source port that is in the same IANA range (well > > known, registered, or dynamic) as the original source UDP port. > > However, as most modern applications to not utilize source port > > numbers as an indicator of trust, there is little value in a NAT > > to provide this function. > > > > -d > > > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf > > Of Jonathan > > > Rosenberg > > > Sent: Thursday, September 30, 2004 7:52 AM > > > To: Francois Audet > > > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > > Subject: Re: [Ietf-behave] port-type preservation? > > > > > > > > > Almost. > > > > > > What I'm saying is, if the source port on the private side > > is in the > > > dynamic range, the source port on the public side should > > probably be > > > in that range. If the source port is in the registered > > range, so too > > > should the source port on the public side, and same for the > > well-known > > > range. > > > > > > -Jonathan R. > > > > > > Francois Audet wrote: > > > > > > > So, if I understand correctly, you want us to put in the Behave > > > > document something saying that port binding assignments > are to be > > > > done from the dynamic/private port range 49152-65535? > > > > > > > > Right? > > > > > > > > > -----Original Message----- > > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > > Behalf Of > > > > > Jonathan Rosenberg > Sent: Tuesday, September 28, 2004 > 23:16 > > > > > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: [Ietf-behave] > > > > port-type preservation? > > > > > > > > > > > Folks, > > > > > > > > > > An interesting thread has been going on on the mmusic > > list, which is > > > > > relevant to behave. The discussion was around NAT > > preservation of > > > > > port-types, where the types are (for UDP) > "well-known" from 0 > > > > > to 1023, > "registered" from 1024 to 49151, and > > > > "dynamic/private" > > from 49152 > > > > > through 65535. See: > > > > > > > > > > http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html > > > > > > > > If a NAT sees an outbound packet with one of these > types, does it > > > > attempt to maintain the preservation? That is, should > an outbound > > > > packet within the dynamic range always map to a port in > > the dynamic > > > > range? > > > > > > > > I think the behave draft should probably say something > > about this. I > > > > suspect its probably a good idea to preserve the port-type. > > > > > > > > -Jonathan R. > > > > -- > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Chief Technology Officer Parsippany, > > NJ 07054-2711 > > > > dynamicsoft > > > > jdrosen@xxxxxxxxxxxxxxx FAX: > (973) 952-5050 > > > > http://www.jdrosen.net PHONE: > (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ > > 07054-2711 > > > dynamicsoft > > > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From spencer@mcsr-labs.org Fri, 1 Oct 2004 04:14:02 -0700 (PDT) From: "Spencer Dawkins" Date: Fri, 1 Oct 2004 04:14:02 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: <1ECE0EB50388174790F9694F77522CCFB2DA35@zrc2hxm0.corp.nortel.com> Message-ID: <0ff401c4a7a7$cd804890$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain Hi, Jonathan, The primary issue that motivated my comment was a discussion on mmusic, where we really wanted to be sure that a client which had a source port in the dynamic range, had it also mapped to one in the dynamic range. The reason had to do with ICE connectivity checks getting misrouted, and that you would not want them to be directed to well-known service ports. So, my extrapolation of this was that you would range port type presentation for the other types as well. However, I also can't think of a case where preservation in the other ranges is the right thing, and so mapping everything into dynamic should work. My first concern about this, though, is that the dynamic range is not that large (16k ports). Thus, if an enterprise is buying a nat to mux a large number of internal hosts into a small number of addresses, this reduces the "compression" ratio by a factor of four, compared to allowing the NAT to map anywhere into the 16 bit space. Is it at all realistic to ask NATs to avoid "well-known service ports", unless they are configured for port forwarding? Spencer From dwing@cisco.com Fri, 1 Oct 2004 10:07:48 -0700 (PDT) From: "Dan Wing" Date: Fri, 1 Oct 2004 10:07:48 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? In-Reply-To: <415CA23B.9090009@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > The primary issue that motivated my comment was a discussion on mmusic, > where we really wanted to be sure that a client which had a source port > in the dynamic range, had it also mapped to one in the dynamic range. > The reason had to do with ICE connectivity checks getting misrouted, and > that you would not want them to be directed to well-known service ports. The best way to avoid using well-known service ports is to never have a NAT map to a well-known service port. After all, if one host uses a source port of, say, 53 (DNS), and the NAT also uses a source port of 53, what will the NAT do when another host also uses a source port of 53? If the NAT uses some other port in the well-known range (<1024), that port might be assumed -- by something else -- to be a well-known service that carries P2P, NetBios, NFS, or whatever traffic. > So, my extrapolation of this was that you would range port type > presentation for the other types as well. > > However, I also can't think of a case where preservation in the other > ranges is the right thing, and so mapping everything into dynamic should > work. My first concern about this, though, is that the dynamic range is > not that large (16k ports). Thus, if an enterprise is buying a nat to > mux a large number of internal hosts into a small number of addresses, > this reduces the "compression" ratio by a factor of four, compared to > allowing the NAT to map anywhere into the 16 bit space. Yep. > I would also expect that, in most cases, the packets originating from > the private side of a nat would have source ports in the dynamic range. > Almost by definition, only client/server protocols work through nat, > implying that the packets which originate on the private side of the nat > would be the result of a client operation in a C/S protocol. These > ususally get sent from ephemeral ports, and operating systems should be > allocating those from the dynamic range. Windows 2000 doesn't use the dynamic range for its ephemeral ports - it uses a range between 1024-5000 according to: http://www.microsoft.com/resources/documentation/windows/2000/server/reskit/ en-us/tcpip/part4/tcpappc.mspx (or http://tinyurl.com/56p9f) -- search for "ephemeral". As do most other OSs: http://www.ncftpd.com/ncftpd/doc/misc/ephemeral_ports.html > If you're running a server on a host behind a nat (which would cause the > responses to contain the well-known service port in the source port), > that would have required you to configure port forwarding on the nat > anyway, so the allocation is not dynamic there. Of course not all servers are in the well-known port range, though. For example, port 5060 (SIP) isn't inside the well-known port range. -d > -Jonathan R. > > > Francois Audet wrote: > > > That's what I think. > > > > Let's wait for Jonathan's input. > > > > To summarize, I'm saying that instead of preserving the port > range, always > > use the dynamic range when doing a mapping to a new port. > > > > My concern about preserving the well-known and registered range > is that it > > could cause some traffic to look like something else and thus be > > intercepted > > by layer 4-7 equipment doing deep-packet inspection and causing > problems. > > > > > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > Sent: Thursday, September 30, 2004 11:57 > > > To: Audet, Francois [SC100:9T51:EXCH]; 'Jonathan Rosenberg' > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: RE: [Ietf-behave] port-type preservation? > > > > > > > > > Unless we can find a modern UDP-based application that cares > > > about preserving the range, I don't see a downside. > > > > > > -d > > > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx] > > > Sent: Thursday, September 30, 2004 11:17 AM > > > To: 'Dan Wing'; 'Jonathan Rosenberg' > > > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > > Subject: RE: [Ietf-behave] port-type preservation? > > > > > > > > > Can you explain the downside of always using the dynamic > > > range for outgoing port binding? > > > > -----Original Message----- > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > Sent: Thursday, September 30, 2004 11:14 > > > > To: Jonathan Rosenberg; Audet, Francois [SC100:9T51:EXCH] > > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Subject: RE: [Ietf-behave] port-type preservation? > > > > > > > > > > > > This sounds like a good idea, and it's logical. > > > > > > > > However, do we know of any IETF or non-IETF protocol that breaks if > > > > you don't have a source UDP port within the appropriate range? > > > > > > > > I poked around DNS and TFTP and neither care about the > > > source UDP port > > > > number for their operation. NFSv2 (RFC1831) has a > > > preference for the > > > > connections to come from privileged ports, but with everyone having > > > > privileges on their own computer now-a-days I think NFS's > > > preference > > > > is historic. > > > > > > > > Without an application that breaks, the best I think we > > > should say is > > > > a strongly-worded "MAY", like this strawman text: > > > > > > > > When deciding the source UDP port for an outgoing binding a NAT > > > > MAY choose a source port that is in the same IANA range (well > > > > known, registered, or dynamic) as the original source UDP port. > > > > However, as most modern applications to not utilize source port > > > > numbers as an indicator of trust, there is little value in a NAT > > > > to provide this function. > > > > > > > > -d > > > > > > > > > > > > > -----Original Message----- > > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf > > > > Of Jonathan > > > > > Rosenberg > > > > > Sent: Thursday, September 30, 2004 7:52 AM > > > > > To: Francois Audet > > > > > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > > > > Subject: Re: [Ietf-behave] port-type preservation? > > > > > > > > > > > > > > > Almost. > > > > > > > > > > What I'm saying is, if the source port on the private side > > > > is in the > > > > > dynamic range, the source port on the public side should > > > > probably be > > > > > in that range. If the source port is in the registered > > > > range, so too > > > > > should the source port on the public side, and same for the > > > > well-known > > > > > range. > > > > > > > > > > -Jonathan R. > > > > > > > > > > Francois Audet wrote: > > > > > > > > > > > So, if I understand correctly, you want us to put in the Behave > > > > > > document something saying that port binding assignments > > > are to be > > > > > > done from the dynamic/private port range 49152-65535? > > > > > > > > > > > > Right? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > > > > Behalf Of > > > > > > > Jonathan Rosenberg > Sent: Tuesday, September 28, 2004 > > > 23:16 > > > > > > > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: [Ietf-behave] > > > > > > port-type preservation? > > > > > > > > > > > > > > > Folks, > > > > > > > > > > > > > > An interesting thread has been going on on the mmusic > > > > list, which is > > > > > > > relevant to behave. The discussion was around NAT > > > > preservation of > > > > > > > port-types, where the types are (for UDP) > > > "well-known" from 0 > > > > > > > to 1023, > "registered" from 1024 to 49151, and > > > > > > "dynamic/private" > > > > from 49152 > > > > > > > through 65535. See: > > > > > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html > > > > > > > > > > > > If a NAT sees an outbound packet with one of these > > > types, does it > > > > > > attempt to maintain the preservation? That is, should > > > an outbound > > > > > > packet within the dynamic range always map to a port in > > > > the dynamic > > > > > > range? > > > > > > > > > > > > I think the behave draft should probably say something > > > > about this. I > > > > > > suspect its probably a good idea to preserve the port-type. > > > > > > > > > > > > -Jonathan R. > > > > > > -- > > > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > > > Chief Technology Officer Parsippany, > > > > NJ 07054-2711 > > > > > > dynamicsoft > > > > > > jdrosen@xxxxxxxxxxxxxxx FAX: > > > (973) 952-5050 > > > > > > http://www.jdrosen.net PHONE: > > > (973) 952-5000 > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > _______________________________________________ > > > > > > Ietf-behave mailing list > > > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > -- > > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > > Chief Technology Officer Parsippany, NJ > > > > 07054-2711 > > > > > dynamicsoft > > > > > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > > > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > > > http://www.dynamicsoft.com > > > > > _______________________________________________ > > > > > Ietf-behave mailing list > > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > > > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > From audet@nortelnetworks.com Fri, 1 Oct 2004 14:07:35 -0700 (PDT) From: "Francois Audet" Date: Fri, 1 Oct 2004 14:07:35 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? Message-ID: <1ECE0EB50388174790F9694F77522CCFB7E60C@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] port-type preservation? Thanks Dan, this is extremelly useful. My conclusions are: (1) Bindings MUST NOT be assigned from the Well-known port range (0-1023). I think everybody agrees with that. (2) I would tend to conclude that the bindings could be assigned from any other ports, depending on implementation, i.e. any ephemeral port or dynamic port, which means the whole 1024-65535. I would therefore say that in the text, we will that UDP bindings MUST not be assigned from the well-known port range (0-1023) and shall be assigned from the 1024-65535 range (without getting into details of ephemeral versus registered/dynamic. Does evererybody agree? > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Friday, October 01, 2004 10:08 > To: Jonathan Rosenberg; Audet, Francois [SC100:9T51:EXCH] > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] port-type preservation? > > > > The primary issue that motivated my comment was a discussion on > > mmusic, where we really wanted to be sure that a client which had a > > source port in the dynamic range, had it also mapped to one in the > > dynamic range. The reason had to do with ICE connectivity checks > > getting misrouted, and that you would not want them to be > directed to > > well-known service ports. > > The best way to avoid using well-known service ports is to > never have a NAT map to a well-known service port. > > After all, if one host uses a source port of, say, 53 (DNS), > and the NAT also uses a source port of 53, what will the NAT > do when another host also uses a source port of 53? If the > NAT uses some other port in the well-known range (<1024), > that port might be assumed -- by something else -- to be a > well-known service that carries P2P, NetBios, NFS, or > whatever traffic. > > > So, my extrapolation of this was that you would range port type > > presentation for the other types as well. > > > > However, I also can't think of a case where preservation in > the other > > ranges is the right thing, and so mapping everything into dynamic > > should work. My first concern about this, though, is that > the dynamic > > range is not that large (16k ports). Thus, if an enterprise > is buying > > a nat to mux a large number of internal hosts into a small > number of > > addresses, this reduces the "compression" ratio by a factor > of four, > > compared to allowing the NAT to map anywhere into the 16 bit space. > > Yep. > > > I would also expect that, in most cases, the packets > originating from > > the private side of a nat would have source ports in the dynamic > > range. Almost by definition, only client/server protocols > work through > > nat, implying that the packets which originate on the > private side of > > the nat would be the result of a client operation in a C/S > protocol. > > These ususally get sent from ephemeral ports, and operating systems > > should be allocating those from the dynamic range. > > Windows 2000 doesn't use the dynamic range for its ephemeral > ports - it uses a range between 1024-5000 according to: > http://www.microsoft.com/resources/documentation/windows/2000/ > server/reskit/ > en-us/tcpip/part4/tcpappc.mspx > (or http://tinyurl.com/56p9f) -- search for "ephemeral". > > As do most other OSs: > http://www.ncftpd.com/ncftpd/doc/misc/ephemeral_ports.html > > > If you're running a server on a host behind a nat (which > would cause > > the responses to contain the well-known service port in the source > > port), that would have required you to configure port forwarding on > > the nat anyway, so the allocation is not dynamic there. > > Of course not all servers are in the well-known port range, > though. For example, port 5060 (SIP) isn't inside the > well-known port range. > From jdrosen@dynamicsoft.com Fri, 1 Oct 2004 22:36:19 -0700 (PDT) From: Jonathan Rosenberg Date: Fri, 1 Oct 2004 22:36:19 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: <1ECE0EB50388174790F9694F77522CCFB7E60C@zrc2hxm0.corp.nortel.com> Message-ID: <415E0A7B.7010500@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain Francois Audet wrote: Thanks Dan, this is extremelly useful. My conclusions are: (1) Bindings MUST NOT be assigned from the Well-known port range (0-1023). I think everybody agrees with that. Yes. Thinking about it more, it doesn't make any sense to every assign ports in this range. (2) I would tend to conclude that the bindings could be assigned from any other ports, depending on implementation, i.e. any ephemeral port or dynamic port, which means the whole 1024-65535. I would therefore say that in the text, we will that UDP bindings MUST not be assigned from the well-known port range (0-1023) and shall be assigned from the 1024-65535 range (without getting into details of ephemeral versus registered/dynamic. Well, lets think about that. As Dan pointed out, not all service ports are in the well-known range. Many aer in the registered range. Is there a reason to believe that its not ok to map a source port into 53, but it would be ok to map it into 5060? The same concerns would apply - things in the network mistaking this packet as a response to a query on the service port. Ideally, I would say that a NAT shouldn't map into well-known port or into ports in the registered range that are in fact registered. I suspect that this is an unreasonable requirement, since no nat vendor is going to want to periodially download the iana port assignment page and figure out whether a new port is assigned. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From audet@nortelnetworks.com Sat, 2 Oct 2004 11:42:25 -0700 (PDT) From: "Francois Audet" Date: Sat, 2 Oct 2004 11:42:25 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? Message-ID: <1ECE0EB50388174790F9694F77522CCF491E72@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] port-type preservation? So, how do we achieve closure? I think we can safely say: (1) Bindings MUST NOT be assigned from the Well-known port range (0-1023). What do we say beyond that? I see the following alternatives: (2a) Nothing. (2b) It is RECOMMENDED that a NAT SHOULD NOT map into ports in the registered range that are in fact registered. (2c) It is RECOMMENDED that a NAT assing bindings from the Dynamic port range first, before using ports from the registered range. I doubt that 2b-2c would be acceptable, considering current usage in major OSs, but they are only recommendations. I'm happy with 2a, 2b and 2c, but my preference is 2a. Jonathan? Dan? -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxxxxxxxx] Sent: Fri 10/1/2004 6:55 PM To: Audet, Francois [SC100:9T51:EXCH] Cc: 'Dan Wing'; 'ietf-behave@xxxxxxxxxxxxxxxxxxx'; 'Cullen Jennings' Subject: Re: [Ietf-behave] port-type preservation? Francois Audet wrote: > Thanks Dan, this is extremelly useful. > > My conclusions are: > > (1) Bindings MUST NOT be assigned from the Well-known port range > (0-1023). I think > everybody agrees with that. Yes. Thinking about it more, it doesn't make any sense to every assign ports in this range. > > (2) I would tend to conclude that the bindings could be assigned from > any other > ports, depending on implementation, i.e. any ephemeral port or > dynamic port, > which means the whole 1024-65535. > > I would therefore say that in the text, we will that UDP bindings MUST > not be assigned > from the well-known port range (0-1023) and shall be assigned from the > 1024-65535 > range (without getting into details of ephemeral versus registered/dynamic. Well, lets think about that. As Dan pointed out, not all service ports are in the well-known range. Many aer in the registered range. Is there a reason to believe that its not ok to map a source port into 53, but it would be ok to map it into 5060? The same concerns would apply - things in the network mistaking this packet as a response to a query on the service port. Ideally, I would say that a NAT shouldn't map into well-known port or into ports in the registered range that are in fact registered. I suspect that this is an unreasonable requirement, since no nat vendor is going to want to periodially download the iana port assignment page and figure out whether a new port is assigned. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From fluffy@cisco.com Mon, 4 Oct 2004 21:36:10 -0700 (PDT) From: Cullen Jennings Date: Mon, 4 Oct 2004 21:36:10 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: <415E0A7B.7010500@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 10/1/04 6:55 PM, "Jonathan Rosenberg" wrote: > Ideally, I would say that a NAT shouldn't map into well-known port or > into ports in the registered range that are in fact registered. I > suspect that this is an unreasonable requirement, since no nat vendor is > going to want to periodially download the iana port assignment page and > figure out whether a new port is assigned. I think that requirement would be hard to meet. For one thing, a quick glance at http://www.iana.org/assignments/port-numbers makes it look like a large percentage of the ports are assigned and running out of ports is a real issue for large NATs. Anyone know how many are free? I guess I have not heard any harm that comes from Franois' proposal of only using 1024 to 65k so I sort of lean that direction. From fluffy@cisco.com Mon, 4 Oct 2004 21:36:10 -0700 (PDT) From: Cullen Jennings Date: Mon, 4 Oct 2004 21:36:10 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: <1ECE0EB50388174790F9694F77522CCFB7E60C@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 10/1/04 2:06 PM, "Francois Audet" wrote: > Thanks Dan, this is extremelly useful. > > My conclusions are: > > (1) Bindings MUST NOT be assigned from the Well-known port range (0-1023). I > think > everybody agrees with that. > > (2) I would tend to conclude that the bindings could be assigned from any > other > ports, depending on implementation, i.e. any ephemeral port or dynamic > port, > which means the whole 1024-65535. > > I would therefore say that in the text, we will that UDP bindings MUST not be > assigned > from the well-known port range (0-1023) and shall be assigned from the > 1024-65535 > range (without getting into details of ephemeral versus registered/dynamic. > > Does evererybody agree? sounds good to me. From sandersr@corp.earthlink.net Mon, 4 Oct 2004 22:33:01 -0700 (PDT) From: Robert Sanders Date: Mon, 4 Oct 2004 22:33:01 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: Message-ID: <41623205.80504@corp.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain Cullen Jennings wrote: I guess I have not heard any harm that comes from Franois' proposal of only using 1024 to 65k so I sort of lean that direction. I agree. This behavior approximates the behavior of an un-NATted host, which I imagine we could all agree is the Platonic ideal. I don't see a problem with recommending the dynamic range, given that we've already ruled out the only port-type-sensitive applications I've ever heard of (e.g., NFS) by not mapping into well-known port space. Unless the NAT is performing actual port # preservation, of course. regards, -- Robert Sanders Chief Architect, EarthLink From jdrosen@dynamicsoft.com Tue, 5 Oct 2004 00:19:00 -0700 (PDT) From: Jonathan Rosenberg Date: Tue, 5 Oct 2004 00:19:00 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: Message-ID: <41624AA6.4000806@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain I don't see any harm in Francois' proposal, so much as I don't understand why we want to stay away from mapping something into a well-known protocol, but allow mapping into a registered protocol. Is there something "special" about the well-known protocols that makes us think that mapping into them is much worse than mapping into a commonly used registered port (like 5060)? -Jonathan R. Cullen Jennings wrote: On 10/1/04 6:55 PM, "Jonathan Rosenberg" wrote: Ideally, I would say that a NAT shouldn't map into well-known port or into ports in the registered range that are in fact registered. I suspect that this is an unreasonable requirement, since no nat vendor is going to want to periodially download the iana port assignment page and figure out whether a new port is assigned. I think that requirement would be hard to meet. For one thing, a quick glance at http://www.iana.org/assignments/port-numbers makes it look like a large percentage of the ports are assigned and running out of ports is a real issue for large NATs. Anyone know how many are free? I guess I have not heard any harm that comes from Franois' proposal of only using 1024 to 65k so I sort of lean that direction. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From spencer@mcsr-labs.org Tue, 5 Oct 2004 04:54:47 -0700 (PDT) From: "Spencer Dawkins" Date: Tue, 5 Oct 2004 04:54:47 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: Message-ID: <124701c4aad2$299e97d0$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain I don't see any harm in Francois' proposal, so much as I don't understand why we want to stay away from mapping something into a well-known protocol, but allow mapping into a registered protocol. Is there something "special" about the well-known protocols that makes us think that mapping into them is much worse than mapping into a commonly used registered port (like 5060)? -Jonathan R. The only "harm" I can see is the chances of someone looking at the port number, unqualified by IP address, and thinking they know what the traffic is. This cluelessness seems harmless (a clueless network operator might think "gee, I'm carrying all KINDS of RAP ('Random Application Protocol') traffic", when they aren't, but since we've known IPsec completely breaks figuring out how much traffic you're carrying by application protocol for a LONG time, I can't see this as a big deal). FWIW, I asked the "and do we ever reclaim any of these registered ports?" on NEWTRK, and the answer is "why would we ever want to do that?" Given that modern protocols can use any port number specified in a URI, I've got to assume overloading registered port numbers is Mostly Harmless... Spencer From mshore@cisco.com Tue, 5 Oct 2004 05:40:07 -0700 (PDT) From: Melinda Shore Date: Tue, 5 Oct 2004 05:40:07 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: <41624AA6.4000806@dynamicsoft.com> Message-ID: <9A97382E-16CB-11D9-9C0F-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Tuesday, October 5, 2004, at 03:17 AM, Jonathan Rosenberg wrote: I don't see any harm in Francois' proposal, so much as I don't understand why we want to stay away from mapping something into a well-known protocol, but allow mapping into a registered protocol. Is there something "special" about the well-known protocols that makes us think that mapping into them is much worse than mapping into a commonly used registered port (like 5060)? In keeping an eye on my own machines I find that they're far more often probed on specific well-known ports than they are port-scanned. I'm less convinced that this is a specific security issue than it is an operational one - you don't want, say, TCP port 25 being given as part of an external address. That difference will make no difference when SIP becomes as ubiquitous as SMTP, but at the moment it does. Still, given that we know that the distinction will over time become irrelevant it seems to me that it would make more sense to say that it's preferred to draw port numbers from the "private" pool. Melinda From fluffy@cisco.com Tue, 5 Oct 2004 06:23:35 -0700 (PDT) From: Cullen Jennings Date: Tue, 5 Oct 2004 06:23:35 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: <9A97382E-16CB-11D9-9C0F-000A95E35274@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I guess the more I think about this, I think these port numbers apply to destination ports and we are only talking about source ports. It's not like if machine A telnets to machine B that the source port will be 25. The only practical difference I see on any of this is that on some OS you need to be root to open a port under 1024. I agree that it's wacky that NFS runs above 1024 and tftp runs below not to mention RTP is generally not in the dynamic range. I'm just not seeing any of this making much difference. On 10/5/04 5:39 AM, "Melinda Shore" wrote: > On Tuesday, October 5, 2004, at 03:17 AM, Jonathan Rosenberg wrote: >> I don't see any harm in Francois' proposal, so much as I don't >> understand why we want to stay away from mapping something into a >> well-known protocol, but allow mapping into a registered protocol. Is >> there something "special" about the well-known protocols that makes us >> think that mapping into them is much worse than mapping into a >> commonly used registered port (like 5060)? > > In keeping an eye on my own machines I find that they're far more often > probed on specific well-known ports than they are port-scanned. I'm > less > convinced that this is a specific security issue than it is an > operational one - you don't want, say, TCP port 25 being given as part > of > an external address. That difference will make no difference when SIP > becomes as ubiquitous as SMTP, but at the moment it does. Still, given > that we know that the distinction will over time become irrelevant it > seems to me that it would make more sense to say that it's preferred > to draw port numbers from the "private" pool. > > Melinda > From jdrosen@dynamicsoft.com Tue, 5 Oct 2004 08:28:15 -0700 (PDT) From: Jonathan Rosenberg Date: Tue, 5 Oct 2004 08:28:15 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: Message-ID: <4162BD50.9000706@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain Well, the issue that I thought was really driving the decision not to have the NAT allocate ports under 1024 was classification. Even though we are talking about source ports, if a client sends a request to a web server, the TCP packets in response have a source port of 80. Thus, classification of packets by intermediate analyzers and other things will need to consider both source and destination port. Thus, the danger of having the nat use the well-known range is that packets emininated from the private network out into the public network will "look" like responses to requests against well-known service ports. Perhaps worse, packets sent back towards the private network from the public side will then have this well-known port in the destination port, which might fool classifiers into thinking that someone is running a well-known service on the private side when they are not. So, my point was, if you believe that this is a problem (and one might argue that it is not), then I see exactly the same problem for the registered ports. If a NAT maps a random UDP session onto 5060, then packets in and out of the NAT will be mis-classified by anything that happens to be listening as SIP. Is that less bad than if it was port 25, and the packets were misclassified as SMTP? I don't think it is any less bad. Now, one might argue that this whole misclassification is nonsense, and that in an era of NAT and firewall bypassing by tunnelling over port 443, anyone who is relying on ports for traffic classification is getting what they deserve. I believe there is still a fair amount of useful traffic classification by port that is happening, but YMMV. -Jonathan R. Cullen Jennings wrote: I guess the more I think about this, I think these port numbers apply to destination ports and we are only talking about source ports. It's not like if machine A telnets to machine B that the source port will be 25. The only practical difference I see on any of this is that on some OS you need to be root to open a port under 1024. I agree that it's wacky that NFS runs above 1024 and tftp runs below not to mention RTP is generally not in the dynamic range. I'm just not seeing any of this making much difference. On 10/5/04 5:39 AM, "Melinda Shore" wrote: On Tuesday, October 5, 2004, at 03:17 AM, Jonathan Rosenberg wrote: I don't see any harm in Francois' proposal, so much as I don't understand why we want to stay away from mapping something into a well-known protocol, but allow mapping into a registered protocol. Is there something "special" about the well-known protocols that makes us think that mapping into them is much worse than mapping into a commonly used registered port (like 5060)? In keeping an eye on my own machines I find that they're far more often probed on specific well-known ports than they are port-scanned. I'm less convinced that this is a specific security issue than it is an operational one - you don't want, say, TCP port 25 being given as part of an external address. That difference will make no difference when SIP becomes as ubiquitous as SMTP, but at the moment it does. Still, given that we know that the distinction will over time become irrelevant it seems to me that it would make more sense to say that it's preferred to draw port numbers from the "private" pool. Melinda -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From fluffy@cisco.com Tue, 5 Oct 2004 11:56:00 -0700 (PDT) From: Cullen Jennings Date: Tue, 5 Oct 2004 11:56:00 -0700 (PDT) Subject: [Ietf-behave] Agenda time for IETF 61 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Jiri and are starting to but together the agenda for the for the next IETF meeting. Let us know if think you might want some agenda time. As always, we prefer to spend meeting time solving problems we can't bring to resolution on this list. Thanks, Cullen PS. I would prefer to see draft slides 24 hours before you present. I think this could help the chairs sort out the material covered to make best use of meeting time. Comments on this idea? People agree or think this sounds useless and we will makes the slides during the presentation? From sandersr@corp.earthlink.net Tue, 5 Oct 2004 14:14:02 -0700 (PDT) From: Robert Sanders Date: Tue, 5 Oct 2004 14:14:02 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: Message-ID: <41630E95.7010403@corp.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain Jonathan Rosenberg wrote: So, my point was, if you believe that this is a problem (and one might argue that it is not), then I see exactly the same problem for the registered ports. If a NAT maps a random UDP session onto 5060, then packets in and out of the NAT will be mis-classified by anything that happens to be listening as SIP. True, and various firewalls and "Intrusion Prevention" devices will react badly to traffic appearing to be from certain services that does not conform to its expectation of that protocol. For example, our office's Checkpoints will drop malformed UDP packets from/to port 5060. (As a matter of fact, it will drop many well-formed and valid SIP packets from that port, but that's a different story.) This is not Checkpoint's ALG; we have that disabled. Now, one might argue that this whole misclassification is nonsense, and that in an era of NAT and firewall bypassing by tunnelling over port 443, anyone who is relying on ports for traffic classification is getting what they deserve. I believe there is still a fair amount of useful traffic classification by port that is happening, but YMMV. I think that port-based traffic classification at the enterprise edge for security purposes is a significant issue, which can be alleviated by using dynamic ports. The intersection between applications common enough to deserve application-specific classification or filtering, and those apps which use "well known" ports from the dynamic range, should be miniscule. If NATs only map ports into the dynamic range, then there is the potential scarcity issue on very large NATs mentioned before. If they only prefer the dynamic range, then the behavior might be unpredictable (from a single host's point of view) on very large NATs which have exhausted their dynamic range ports. However, prefer-dynamic is at least as predictable as having the NAT randomly map into the entire registered+dynamic range, and may avoid falsely triggering some security checks. So I'd propose this modification of the rules that Francois suggested: (1) Bindings which alter the source port MUST NOT be assigned from the Well-known port range (0-1023). (2) It is RECOMMENDED that a NAT assign bindings from the Dynamic port range first, before using ports from the registered range. (3) A NAT MAY preserve a source port exactly in a binding, even if that port is from the well-known or registered range. Rule 3 covers the Linux/Netfilter behavior, which is a useful one for any protocol which can use random source ports. regards, -- Robert P.S. By the way, for those who are wondering who I am, I'm one of the folks involved in implementing EarthLink's recently announced free (Free World Dial-like) VoIP service. My concerns right now are dominated by voice/video and IM, plus a few other apps such as p2p sharing and gaming. From audet@nortelnetworks.com Tue, 5 Oct 2004 15:16:02 -0700 (PDT) From: "Francois Audet" Date: Tue, 5 Oct 2004 15:16:02 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? Message-ID: <1ECE0EB50388174790F9694F77522CCFBE4493@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message Thanks Robert/Jonathan, On your point 3 below, we already had agreed in a previous discussions that "port preservation MAY be used". So I think we are covered. I think everybody agrees that recommending using the dynamic range first is a good idea. The suttle point yet to settle is after using all the dynamic range, should we recommend: Using only the registered range (never the well-known range) Using the registered range first, and then the well-know range upon exhaustion Using either the registered or weel-known (don't differentiate between the two) I don't think anybody is arguing for 1. I think Jonathan is arguing for 3 and I'm OK with it. If anybody has a preference, please let me know, otherwise I'll go for 3.
-----Original Message-----From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Robert SandersSent: Tuesday, October 05, 2004 14:14To: Jonathan RosenbergCc: BehaveSubject: Re: [Ietf-behave] port-type preservation?Jonathan Rosenberg wrote: So, my point was, if you believe that this is a problem (and one might argue that it is not), then I see exactly the same problem for the registered ports. If a NAT maps a random UDP session onto 5060, then packets in and out of the NAT will be mis-classified by anything that happens to be listening as SIP. True, and various firewalls and "Intrusion Prevention" devices will react badly to traffic appearing to be from certain services that does not conform to its expectation of that protocol. For example, our office's Checkpoints will drop malformed UDP packets from/to port 5060. (As a matter of fact, it will drop many well-formed and valid SIP packets from that port, but that's a different story.) This is not Checkpoint's ALG; we have that disabled. Now, one might argue that this whole misclassification is nonsense, and that in an era of NAT and firewall bypassing by tunnelling over port 443, anyone who is relying on ports for traffic classification is getting what they deserve. I believe there is still a fair amount of useful traffic classification by port that is happening, but YMMV. I think that port-based traffic classification at the enterprise edge for security purposes is a significant issue, which can be alleviated by using dynamic ports. The intersection between applications common enough to deserve application-specific classification or filtering, and those apps which use "well known" ports from the dynamic range, should be miniscule.If NATs only map ports into the dynamic range, then there is the potential scarcity issue on very large NATs mentioned before. If they only prefer the dynamic range, then the behavior might be unpredictable (from a single host's point of view) on very large NATs which have exhausted their dynamic range ports. However, prefer-dynamic is at least as predictable as having the NAT randomly map into the entire registered+dynamic range, and may avoid falsely triggering some security checks.So I'd propose this modification of the rules that Francois suggested: (1) Bindings which alter the source port MUST NOT be assigned from the Well-known port range (0-1023). (2) It is RECOMMENDED that a NAT assign bindings from the Dynamic port range first, before using ports from the registered range.(3) A NAT MAY preserve a source port exactly in a binding, even if that port is from the well-known or registered range.Rule 3 covers the Linux/Netfilter behavior, which is a useful one for any protocol which can use random source ports.regards, -- RobertP.S. By the way, for those who are wondering who I am, I'm one of the folks involved in implementing EarthLink's recently announced free (Free World Dial-like) VoIP service. My concerns right now are dominated by voice/video and IM, plus a few other apps such as p2p sharing and gaming. From fluffy@cisco.com Thu, 7 Oct 2004 08:15:01 -0700 (PDT) From: Cullen Jennings Date: Thu, 7 Oct 2004 08:15:01 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: <1ECE0EB50388174790F9694F77522CCFBE4493@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Re: [Ietf-behave] port-type preservation? What do people think of suggesting a configurable range that defaults to the dynamics range and if the range is not configurable then do option 3. On NATs where you are likely to run out, you are also likely to have admins that might change the configuration. I don't know if I like this idea or not, I lean towards option 3. On 10/5/04 3:15 PM, "Francois Audet" wrote: Thanks Robert/Jonathan, On your point 3 below, we already had agreed in a previous discussions that "port preservation MAY be used". So I think we are covered. I think everybody agrees that recommending using the dynamic range first is a good idea. The suttle point yet to settle is after using all the dynamic range, should we recommend: Using only the registered range (never the well-known range) Using the registered range first, and then the well-know range upon exhaustion Using either the registered or weel-known (don't differentiate between the two) I don't think anybody is arguing for 1. I think Jonathan is arguing for 3 and I'm OK with it. If anybody has a preference, please let me know, otherwise I'll go for 3. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Robert Sanders Sent: Tuesday, October 05, 2004 14:14 To: Jonathan Rosenberg Cc: Behave Subject: Re: [Ietf-behave] port-type preservation? Jonathan Rosenberg wrote: So, my point was, if you believe that this is a problem (and one might argue that it is not), then I see exactly the same problem for the registered ports. If a NAT maps a random UDP session onto 5060, then packets in and out of the NAT will be mis-classified by anything that happens to be listening as SIP. True, and various firewalls and "Intrusion Prevention" devices will react badly to traffic appearing to be from certain services that does not conform to its expectation of that protocol. For example, our office's Checkpoints will drop malformed UDP packets from/to port 5060. (As a matter of fact, it will drop many well-formed and valid SIP packets from that port, but that's a different story.) This is not Checkpoint's ALG; we have that disabled. Now, one might argue that this whole misclassification is nonsense, and that in an era of NAT and firewall bypassing by tunnelling over port 443, anyone who is relying on ports for traffic classification is getting what they deserve. I believe there is still a fair amount of useful traffic classification by port that is happening, but YMMV. I think that port-based traffic classification at the enterprise edge for security purposes is a significant issue, which can be alleviated by using dynamic ports. The intersection between applications common enough to deserve application-specific classification or filtering, and those apps which use "well known" ports from the dynamic range, should be miniscule. If NATs only map ports into the dynamic range, then there is the potential scarcity issue on very large NATs mentioned before. If they only prefer the dynamic range, then the behavior might be unpredictable (from a single host's point of view) on very large NATs which have exhausted their dynamic range ports. However, prefer-dynamic is at least as predictable as having the NAT randomly map into the entire registered+dynamic range, and may avoid falsely triggering some security checks. So I'd propose this modification of the rules that Francois suggested: (1) Bindings which alter the source port MUST NOT be assigned from the Well-known port range (0-1023). (2) It is RECOMMENDED that a NAT assign bindings from the Dynamic port range first, before using ports from the registered range. (3) A NAT MAY preserve a source port exactly in a binding, even if that port is from the well-known or registered range. Rule 3 covers the Linux/Netfilter behavior, which is a useful one for any protocol which can use random source ports. regards, -- Robert P.S. By the way, for those who are wondering who I am, I'm one of the folks involved in implementing EarthLink's recently announced free (Free World Dial-like) VoIP service. My concerns right now are dominated by voice/video and IM, plus a few other apps such as p2p sharing and gaming. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortelnetworks.com Thu, 7 Oct 2004 09:52:04 -0700 (PDT) From: "Francois Audet" Date: Thu, 7 Oct 2004 09:52:04 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? Message-ID: <1ECE0EB50388174790F9694F77522CCFBE4F18@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message Personally, I'm also leaning on option 3 (which does not preclude a vendor using a configurable range within that: it's just we won't talk about it in the spec).
-----Original Message-----From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] Sent: Thursday, October 07, 2004 07:30To: Audet, Francois [SC100:9T51:EXCH]; 'Robert Sanders'; Jonathan RosenbergCc: BehaveSubject: Re: [Ietf-behave] port-type preservation?What do people think of suggesting a configurable range that defaults to the dynamics range and if the range is not configurable then do option 3. On NATs where you are likely to run out, you are also likely to have admins that might change the configuration. I don't know if I like this idea or not, I lean towards option 3. On 10/5/04 3:15 PM, "Francois Audet" wrote: Thanks Robert/Jonathan,On your point 3 below, we already had agreed in a previous discussions that "port preservation MAY be used". So I think we are covered.I think everybody agrees that recommending using the dynamic range first is a good idea.The suttle point yet to settle is after using all the dynamic range, should we recommend: Using only the registered range (never the well-known range) Using the registered range first, and then the well-know range upon exhaustion Using either the registered or weel-known (don't differentiate between the two)I don't think anybody is arguing for 1. I think Jonathan is arguing for 3 and I'm OK with it.If anybody has a preference, please let me know, otherwise I'll go for 3. -----Original Message-----From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Robert SandersSent: Tuesday, October 05, 2004 14:14To: Jonathan RosenbergCc: BehaveSubject: Re: [Ietf-behave] port-type preservation?Jonathan Rosenberg wrote: So, my point was, if you believe that this is a problem (and one might argue that it is not), then I see exactly the same problem for the registered ports. If a NAT maps a random UDP session onto 5060, then packets in and out of the NAT will be mis-classified by anything that happens to be listening as SIP. True, and various firewalls and "Intrusion Prevention" devices will react badly to traffic appearing to be from certain services that does not conform to its expectation of that protocol. For example, our office's Checkpoints will drop malformed UDP packets from/to port 5060. (As a matter of fact, it will drop many well-formed and valid SIP packets from that port, but that's a different story.) This is not Checkpoint's ALG; we have that disabled. Now, one might argue that this whole misclassification is nonsense, and that in an era of NAT and firewall bypassing by tunnelling over port 443, anyone who is relying on ports for traffic classification is getting what they deserve. I believe there is still a fair amount of useful traffic classification by port that is happening, but YMMV. I think that port-based traffic classification at the enterprise edge for security purposes is a significant issue, which can be alleviated by using dynamic ports. The intersection between applications common enough to deserve application-specific classification or filtering, and those apps which use "well known" ports from the dynamic range, should be miniscule.If NATs only map ports into the dynamic range, then there is the potential scarcity issue on very large NATs mentioned before. If they only prefer the dynamic range, then the behavior might be unpredictable (from a single host's point of view) on very large NATs which have exhausted their dynamic range ports. However, prefer-dynamic is at least as predictable as having the NAT randomly map into the entire registered+dynamic range, and may avoid falsely triggering some security checks.So I'd propose this modification of the rules that Francois suggested:(1) Bindings which alter the source port MUST NOT be assigned from the Well-known port range (0-1023).(2) It is RECOMMENDED that a NAT assign bindings from the Dynamic port range first, before using ports from the registered range.(3) A NAT MAY preserve a source port exactly in a binding, even if that port is from the well-known or registered range.Rule 3 covers the Linux/Netfilter behavior, which is a useful one for any protocol which can use random source ports.regards,-- RobertP.S. By the way, for those who are wondering who I am, I'm one of the folks involved in implementing EarthLink's recently announced free (Free World Dial-like) VoIP service. My concerns right now are dominated by voice/video and IM, plus a few other apps such as p2p sharing and gaming. _______________________________________________Ietf-behave mailing listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave From jdrosen@dynamicsoft.com Thu, 7 Oct 2004 09:54:25 -0700 (PDT) From: Jonathan Rosenberg Date: Thu, 7 Oct 2004 09:54:25 -0700 (PDT) Subject: Re: [Ietf-behave] port-type preservation? In-Reply-To: Message-ID: <416574B4.3020406@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain I think its fair to say that I'm arguing for 3. Probably far more important than merely the recommendation is a discussion on the issues; I don't want to preclude a nat vendor from doing something smart, like actually tracking the ports that are really used amongst the ones that are registered (I think the vast majority are not in any real usage). Understanding why wading into the well-known or registered ranges can be problematic, is the key to allowing that. -Jonathan R. Cullen Jennings wrote: What do people think of suggesting a configurable range that defaults to the dynamics range and if the range is not configurable then do option 3. On NATs where you are likely to run out, you are also likely to have admins that might change the configuration. I don't know if I like this idea or not, I lean towards option 3. On 10/5/04 3:15 PM, "Francois Audet" wrote: Thanks Robert/Jonathan, On your point 3 below, we already had agreed in a previous discussions that "port preservation MAY be used". So I think we are covered. I think everybody agrees that recommending using the dynamic range first is a good idea. The suttle point yet to settle is after using all the dynamic range, should we recommend: 1. Using only the registered range (never the well-known range) 2. Using the registered range first, and then the well-know range upon exhaustion 3. Using either the registered or weel-known (don't differentiate between the two) I don't think anybody is arguing for 1. I think Jonathan is arguing for 3 and I'm OK with it. If anybody has a preference, please let me know, otherwise I'll go for 3. -----Original Message----- *From:* ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] *On Behalf Of *Robert Sanders *Sent:* Tuesday, October 05, 2004 14:14 *To:* Jonathan Rosenberg *Cc:* Behave *Subject:* Re: [Ietf-behave] port-type preservation? Jonathan Rosenberg wrote: So, my point was, if you believe that this is a problem (and one might argue that it is not), then I see exactly the same problem for the registered ports. If a NAT maps a random UDP session onto 5060, then packets in and out of the NAT will be mis-classified by anything that happens to be listening as SIP. True, and various firewalls and "Intrusion Prevention" devices will react badly to traffic appearing to be from certain services that does not conform to its expectation of that protocol. For example, our office's Checkpoints will drop malformed UDP packets from/to port 5060. (As a matter of fact, it will drop many well-formed and valid SIP packets from that port, but that's a different story.) This is not Checkpoint's ALG; we have that disabled. Now, one might argue that this whole misclassification is nonsense, and that in an era of NAT and firewall bypassing by tunnelling over port 443, anyone who is relying on ports for traffic classification is getting what they deserve. I believe there is still a fair amount of useful traffic classification by port that is happening, but YMMV. I think that port-based traffic classification at the enterprise edge for security purposes is a significant issue, which can be alleviated by using dynamic ports. The intersection between applications common enough to deserve application-specific classification or filtering, and those apps which use "well known" ports from the dynamic range, should be miniscule. If NATs only map ports into the dynamic range, then there is the potential scarcity issue on very large NATs mentioned before. If they only prefer the dynamic range, then the behavior might be unpredictable (from a single host's point of view) on very large NATs which have exhausted their dynamic range ports. However, prefer-dynamic is at least as predictable as having the NAT randomly map into the entire registered+dynamic range, and may avoid falsely triggering some security checks. So I'd propose this modification of the rules that Francois suggested: (1) Bindings which alter the source port MUST NOT be assigned from the Well-known port range (0-1023). (2) It is RECOMMENDED that a NAT assign bindings from the Dynamic port range first, before using ports from the registered range. (3) A NAT MAY preserve a source port exactly in a binding, even if that port is from the well-known or registered range. Rule 3 covers the Linux/Netfilter behavior, which is a useful one for any protocol which can use random source ports. regards, -- Robert P.S. By the way, for those who are wondering who I am, I'm one of the folks involved in implementing EarthLink's recently announced free (Free World Dial-like) VoIP service. My concerns right now are dominated by voice/video and IM, plus a few other apps such as p2p sharing and gaming. ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From audet@nortelnetworks.com Thu, 7 Oct 2004 09:56:23 -0700 (PDT) From: "Francois Audet" Date: Thu, 7 Oct 2004 09:56:23 -0700 (PDT) Subject: RE: [Ietf-behave] port-type preservation? Message-ID: <1ECE0EB50388174790F9694F77522CCFBE4F28@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] port-type preservation? Makes sense to me. We'll include. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxxxxxxxx] > Sent: Thursday, October 07, 2004 09:54 > To: Cullen Jennings > Cc: Audet, Francois [SC100:9T51:EXCH]; 'Robert Sanders'; Behave > Subject: Re: [Ietf-behave] port-type preservation? > > > I think its fair to say that I'm arguing for 3. > > Probably far more important than merely the recommendation is a > discussion on the issues; I don't want to preclude a nat vendor from > doing something smart, like actually tracking the ports that > are really > used amongst the ones that are registered (I think the vast > majority are > not in any real usage). Understanding why wading into the > well-known or > registered ranges can be problematic, is the key to allowing that. > > -Jonathan R. > > Cullen Jennings wrote: > > > > > What do people think of suggesting a configurable range > that defaults > > to > > the dynamics range and if the range is not configurable > then do option > > 3. On NATs where you are likely to run out, you are also > likely to have > > admins that might change the configuration. I don't know > if I like this > > idea or not, I lean towards option 3. > > > > > > On 10/5/04 3:15 PM, "Francois Audet" > wrote: > > > > Thanks Robert/Jonathan, > > > > On your point 3 below, we already had agreed in a previous > > discussions that "port preservation MAY be used". So I > think we are > > covered. > > > > I think everybody agrees that recommending using the > dynamic range > > first is a good idea. > > > > The suttle point yet to settle is after using all the > dynamic range, > > should we recommend: > > > > 1. Using only the registered range (never the > well-known range) > > 2. Using the registered range first, and then the well-know > > range upon exhaustion > > 3. Using either the registered or weel-known (don't > > differentiate between the two) > > > > I don't think anybody is arguing for 1. I think > Jonathan is arguing > > for 3 and I'm OK with it. > > If anybody has a preference, please let me know, > otherwise I'll go > > for 3. > > > > > > > > -----Original Message----- > > *From:* ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] > *On Behalf Of > > *Robert Sanders > > *Sent:* Tuesday, October 05, 2004 14:14 > > *To:* Jonathan Rosenberg > > *Cc:* Behave > > *Subject:* Re: [Ietf-behave] port-type preservation? > > > > Jonathan Rosenberg wrote: > > > > > > So, my point was, if you believe that this is a problem > > (and one might argue that it is not), then I > see exactly > > the same problem for the registered ports. If > a NAT maps a > > random UDP session onto 5060, then packets in > and out of the > > NAT will be mis-classified by anything that > happens to be > > listening as SIP. > > > > True, and various firewalls and "Intrusion > Prevention" devices > > will react badly to traffic appearing to be from certain > > services that does not conform to its expectation of that > > protocol. For example, our office's Checkpoints will drop > > malformed UDP packets from/to port 5060. (As a > matter of fact, > > it will drop many well-formed and valid SIP packets > from that > > port, but that's a different story.) This is not > Checkpoint's > > ALG; we have that disabled. > > > > > > > > Now, one might argue that this whole > misclassification is > > nonsense, and that in an era of NAT and > firewall bypassing > > by tunnelling over port 443, anyone who is > relying on ports > > for traffic classification is getting what they > deserve. I > > believe there is still a fair amount of useful traffic > > classification by port that is happening, but YMMV. > > > > I think that port-based traffic classification at the > > enterprise edge for security purposes is a > significant issue, > > which can be alleviated by using dynamic ports. The > > intersection between applications common enough to deserve > > application-specific classification or filtering, and those > > apps which use "well known" ports from the dynamic range, > > should be miniscule. > > > > If NATs only map ports into the dynamic range, > then there is > > the potential scarcity issue on very large NATs mentioned > > before. If they only prefer the dynamic range, then the > > behavior might be unpredictable (from a single > host's point of > > view) on very large NATs which have exhausted their dynamic > > range ports. However, prefer-dynamic is at least as > > predictable as having the NAT randomly map into the entire > > registered+dynamic range, and may avoid falsely > triggering some > > security checks. > > > > So I'd propose this modification of the rules that Francois > > suggested: > > > > > > (1) Bindings which alter the source port MUST NOT > be assigned > > from the Well-known port range (0-1023). > > > > > > (2) It is RECOMMENDED that a NAT assign bindings from the > > Dynamic port range first, before using ports from the > > registered range. > > (3) A NAT MAY preserve a source port exactly in a > binding, even > > if that port is from the well-known or registered range. > > > > Rule 3 covers the Linux/Netfilter behavior, which > is a useful > > one for any protocol which can use random source ports. > > > > regards, > > -- Robert > > > > P.S. By the way, for those who are wondering who I > am, I'm one > > of the folks involved in implementing EarthLink's recently > > announced free (Free World Dial-like) VoIP service. My > > concerns right now are dominated by voice/video > and IM, plus a > > few other apps such as p2p sharing and gaming. > > > > > > > -------------------------------------------------------------- > ---------- > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > From jdrosen@dynamicsoft.com Thu, 7 Oct 2004 10:05:19 -0700 (PDT) From: Jonathan Rosenberg Date: Thu, 7 Oct 2004 10:05:19 -0700 (PDT) Subject: [Ietf-behave] TCP without relays Message-ID: <41657745.5020601@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain Mostly we've been discussing UDP issues, and I wanted to raise a TCP issue that I think is relatively important. One of the objectives in the UDP work has been to allow it to be possible for protocols like STUN and TEREDO to work through NAT without requiring an external relay to act as a rendezvous point. Today, that's not really possible for TCP. There are hacks that people have tried, relying on simultaneous opens, to get this behavior to work for TCP, but they are extremely unreliable afaik. However, I think it would be a tremendous accomplishment if we could allow for clients to establish direct TCP connections to each other in a reliable way. One of my real concerns are mumblings that I hear about p2p file sharing folks using UDP for file transfer, because they can use STUN to get UDP traffic to work directly, but not TCP. Suffice it to say, widespread usage of UDP protocols for large file transfer on the Internet would be nothing short of catastrophic, and must be avoided. If there were a way to offer up a TCP-based solution, it would hopefully provide a way out. Frankly, I'm not much of an expert of existing NAT treatment of TCP, and in particular, the state machines that they maintain and the specific behaviors of those machines which are problematic. Perhaps someone could contribute some experience here to help work on this problem? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From baford@mit.edu Thu, 7 Oct 2004 11:54:07 -0700 (PDT) From: Bryan Ford Date: Thu, 7 Oct 2004 11:54:07 -0700 (PDT) Subject: Re: [Ietf-behave] TCP without relays In-Reply-To: <41657745.5020601@dynamicsoft.com> Message-ID: <200410071454.06022.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 07 October 2004 13:05, Jonathan Rosenberg wrote: > Mostly we've been discussing UDP issues, and I wanted to raise a TCP > issue that I think is relatively important. > > One of the objectives in the UDP work has been to allow it to be > possible for protocols like STUN and TEREDO to work through NAT without > requiring an external relay to act as a rendezvous point. Today, that's > not really possible for TCP. There are hacks that people have tried, > relying on simultaneous opens, to get this behavior to work for TCP, but > they are extremely unreliable afaik. I've actually done some experiments in this direction, and it looks like the situation may not be as grim as I and others previously thought it was. There appear to be two main challenges to implementing NAT hole punching for TCP: 1. To make TCP NAT hole punching work reliably, the NAT must NOT respond to unsolicited incoming TCP connection attempts (i.e., incoming SYN packets) by sending back an RST - instead, the NAT must just silently drop the incoming SYN. If the NAT silently drops incoming SYNs _and_ preserves port number identities (i.e., has "cone NAT" rather than "symmetric NAT" port allocation behavior), then TCP NAT hole punching can be done reliably and is no more timing-sensitive than UDP hole punching is. My impression some time ago was that sending back an RST was common behavior for NATs, but on the basis of more recent experiments I'm suspecting that the more hole-punching-friendly behavior of just dropping unsolicited incoming SYNs on the floor might actually be much more common, making TCP-based NAT hole punching actually more-or-less practical. 2. Implementing TCP-based NAT hole punching in applications involves the use of obscure sockets API features that aren't exercised often and whose details therefore are apparently not very well standardized or portable. In particular, each P2P application endpoint has to allocate a TCP listen socket _and_ potentially several outgoing sockets all bound to the same IP address/port on the local host. In addition, the app has to manage all of these sockets in a nontrivial asynchronous fashion. All of the important OS's I know of - e.g., Win32, linux, *bsd, OS X - support this functionality, but they all do it in subtly and annoyingly different ways. This is obviously not an issue of NAT behavior, and is therefore not directly in the scope of this group - it's just an annoying issue for P2P apps that want to be portable, and perhaps calls for better POSIX network API standardization. So in short, I now think that NAT hole punching for TCP is feasible and certainly should be addressed in this group, though my experimentation so far is limited and certainly not conclusive, especially as far as evaluating the behavior of existing NATs. You can find my current NAT hole punching test code for both TCP and UDP on http://midcom-p2p.sourceforge.net/, although be warned that the NAT Check servers are currently broken (and it looks like the results database might now be broken too). I just haven't had time lately to look into it in more detail. Cheers, Bryan From fluffy@cisco.com Mon, 11 Oct 2004 03:02:41 -0700 (PDT) From: Cullen Jennings Date: Mon, 11 Oct 2004 03:02:41 -0700 (PDT) Subject: Re: [Ietf-behave] TCP without relays In-Reply-To: <200410071454.06022.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I'm still not up to speed on this so let me ask things that are probably obvious.... A is trying to set up a TCP connection to B and B is behind a NAT. We need B to be able to "punch a hole" or more specifically be able to get the NAT to create a mapping such that a SYN packet received by the NAT will get forwarded to B. B also needs to be able to find out the public address/port on the NAT that A needs to sent to. Is that a fair way of describing the problem? In the TCP whole punching approach, how does B find out the port that the NAT allocated? Does it just assume that port preservation worked? I'm going to propose something here which I suspect is a really bad hack and not a good idea but, well perhaps it will lead to a better idea. Build NAT such that when a SYN arrived an the public interface and there was no TCP binding for it, the NAT looks at the UDP bindings and forwards the SYN to a device that the UDP binding for that port. So in the case above, B could open UDP port 5060 and be listening on TCP port 5060 then do something like STUN to punch a UDP hole in the NAT and find out that the NAT mapped this to, say address 1.2.3.4:6000, Now A sends a TCP SYN to 1.2.3.4:6000. The NAT looks at it's UDP binding table and sends this as a TCP SYN to port 5060 on B. Everything else happens as normal from this point on. Lots of details hand waived here but you get the idea. I have been thinking of other things that allow a STUN like operation using TCP packets but I have a hard time imagining how to get these to interact with existing client stacks in a clean way. Cullen On 10/7/04 11:54 AM, "Bryan Ford" wrote: > On Thursday 07 October 2004 13:05, Jonathan Rosenberg wrote: >> Mostly we've been discussing UDP issues, and I wanted to raise a TCP >> issue that I think is relatively important. >> >> One of the objectives in the UDP work has been to allow it to be >> possible for protocols like STUN and TEREDO to work through NAT without >> requiring an external relay to act as a rendezvous point. Today, that's >> not really possible for TCP. There are hacks that people have tried, >> relying on simultaneous opens, to get this behavior to work for TCP, but >> they are extremely unreliable afaik. > > I've actually done some experiments in this direction, and it looks like the > situation may not be as grim as I and others previously thought it was. > There appear to be two main challenges to implementing NAT hole punching for > TCP: > > 1. To make TCP NAT hole punching work reliably, the NAT must NOT respond to > unsolicited incoming TCP connection attempts (i.e., incoming SYN packets) by > sending back an RST - instead, the NAT must just silently drop the incoming > SYN. If the NAT silently drops incoming SYNs _and_ preserves port number > identities (i.e., has "cone NAT" rather than "symmetric NAT" port allocation > behavior), then TCP NAT hole punching can be done reliably and is no more > timing-sensitive than UDP hole punching is. My impression some time ago was > that sending back an RST was common behavior for NATs, but on the basis of > more recent experiments I'm suspecting that the more hole-punching-friendly > behavior of just dropping unsolicited incoming SYNs on the floor might > actually be much more common, making TCP-based NAT hole punching actually > more-or-less practical. > > 2. Implementing TCP-based NAT hole punching in applications involves the use > of obscure sockets API features that aren't exercised often and whose details > therefore are apparently not very well standardized or portable. In > particular, each P2P application endpoint has to allocate a TCP listen socket > _and_ potentially several outgoing sockets all bound to the same IP > address/port on the local host. In addition, the app has to manage all of > these sockets in a nontrivial asynchronous fashion. All of the important > OS's I know of - e.g., Win32, linux, *bsd, OS X - support this functionality, > but they all do it in subtly and annoyingly different ways. This is > obviously not an issue of NAT behavior, and is therefore not directly in the > scope of this group - it's just an annoying issue for P2P apps that want to > be portable, and perhaps calls for better POSIX network API standardization. > > So in short, I now think that NAT hole punching for TCP is feasible and > certainly should be addressed in this group, though my experimentation so far > is limited and certainly not conclusive, especially as far as evaluating the > behavior of existing NATs. You can find my current NAT hole punching test > code for both TCP and UDP on http://midcom-p2p.sourceforge.net/, although be > warned that the NAT Check servers are currently broken (and it looks like the > results database might now be broken too). I just haven't had time lately to > look into it in more detail. > > Cheers, > Bryan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From spencer@mcsr-labs.org Mon, 11 Oct 2004 05:32:02 -0700 (PDT) From: "Spencer Dawkins" Date: Mon, 11 Oct 2004 05:32:02 -0700 (PDT) Subject: Re: [Ietf-behave] TCP without relays In-Reply-To: Message-ID: <166101c4af8e$5cde5cf0$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain Hi, Cullen, I haven't seen this mentioned previously, so I'm wondering - when NATs allocate a new port number, do they take the transport protocol into account? I knew that IANA allocates both UDP and TCP for registered ports, even though most application protocols only use one or the other (DNS and SIP being the most obvious exceptions I can think of off the top of my head) and I'd always semi-wondered why - could we take advantage of this obscure fact to justify asking NATs to ignore the transport protocol in port mapping, so STUN would work, and then your host with modified applications but no modified transports uses TCP as normal (based on your question below, is this the goal?)? ... and one wonders what NATs do with SCTP, and what they will do with DCCP, but I'll follow up with Aaron and Lyndon and report back ... Spencer I'm still not up to speed on this so let me ask things that are probably obvious.... A is trying to set up a TCP connection to B and B is behind a NAT. We need B to be able to "punch a hole" or more specifically be able to get the NAT to create a mapping such that a SYN packet received by the NAT will get forwarded to B. B also needs to be able to find out the public address/port on the NAT that A needs to sent to. Is that a fair way of describing the problem? In the TCP whole punching approach, how does B find out the port that the NAT allocated? Does it just assume that port preservation worked? I'm going to propose something here which I suspect is a really bad hack and not a good idea but, well perhaps it will lead to a better idea. Build NAT such that when a SYN arrived an the public interface and there was no TCP binding for it, the NAT looks at the UDP bindings and forwards the SYN to a device that the UDP binding for that port. So in the case above, B could open UDP port 5060 and be listening on TCP port 5060 then do something like STUN to punch a UDP hole in the NAT and find out that the NAT mapped this to, say address 1.2.3.4:6000, Now A sends a TCP SYN to 1.2.3.4:6000. The NAT looks at it's UDP binding table and sends this as a TCP SYN to port 5060 on B. Everything else happens as normal from this point on. Lots of details hand waived here but you get the idea. I have been thinking of other things that allow a STUN like operation using TCP packets but I have a hard time imagining how to get these to interact with existing client stacks in a clean way. Cullen From baford@mit.edu Mon, 11 Oct 2004 06:49:32 -0700 (PDT) From: Bryan Ford Date: Mon, 11 Oct 2004 06:49:32 -0700 (PDT) Subject: Re: [Ietf-behave] TCP without relays In-Reply-To: Message-ID: <200410110949.31441.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Sunday 10 October 2004 13:25, Cullen Jennings wrote: > I'm still not up to speed on this so let me ask things that are probably > obvious.... > > A is trying to set up a TCP connection to B and B is behind a NAT. We need > B to be able to "punch a hole" or more specifically be able to get the NAT > to create a mapping such that a SYN packet received by the NAT will get > forwarded to B. B also needs to be able to find out the public address/port > on the NAT that A needs to sent to. Is that a fair way of describing the > problem? > > In the TCP whole punching approach, how does B find out the port that the > NAT allocated? Does it just assume that port preservation worked? Suppose both A and B are behind NATs, and C is a rendezvous server. 1. Both A and B have active TCP connections to C. C knows both A's (public IP,port#) for the A-C connection and B's (public IP,port#) for the B-C connection. 2. In addition to these connections to C, both A and B have active _listen_ sockets on _exactly the same private local TCP port numbers_ as the local port numbers they are using for the A-C and B-C connections, respectively. (Setting this up requires the use of SO_REUSEADDR/SO_REUSEPORT.) 3. A asks C for help setting up a connection to B. C returns to A the (public IP,port#) for B, and also forwards a request to B with the (public IP,port#) of A. We're still talking about the same port numbers as the ones being used for the existing A-C and B-C connections. 4. A initiates a new outgoing TCP connection to B's (public IP,port#) pair _from the same private TCP port number that its existing A-C connection and its existing listen socket use_, and B likewise initiates a new outgoing TCP connection _from the same local TCP port number as its other sockets_ to A's (public IP,port#) pair. Again, SO_REUSEADDR/SO_REUSEPORT required. 5. The SYN packets for each outgoing TCP connection will punch a hole in the local firewall to the other client's (public IP,port#) pair. Assuming the NAT preserves port identities (i.e., is a cone NAT and not a symmetric NAT), the NAT will assign the same (public IP,port#) pairs for the new A-B and B-A connections as it did for the original A-C and B-C connections. One or more SYNs might get dropped at the opposite firewall depending on the timing, but before long (assuming neither NAT sends back an RST), both holes will have been punched and the SYNs will get through all the way. 6. Now one of two things might happen, depending on the timing and the operating systems involved. Case (a): One client's (say A's) SYN reaches the other client (B), and since B has an active listen socket at the targetted port, B accept()s this connection, and we get a usable TCP connection established in more or less the usual symmetric fashion. But now since B's not-yet-established outgoing connection attempt to A was trying to use exactly the same (src IP, src port, dest IP, dest port) tuple as this new TCP connection that was just established, B's outgoing TCP connection attempt fails with a "port in use" or similar error. No matter; we have the TCP connection we want. Case (b): One client's (say A's) SYN reaches the other client (B), and B's OS notices that it also has an outstanding, outgoing connection attempt to A with exactly matching IP addresses and port numbers. B therefore recognizes that a "simultaneous TCP open" is being attempted (as per the TCP spec), and establishes an active TCP connection in that fashion. From the viewpoint of A's and B's application code, _both_ of their outgoing TCP connection attempts succeeded, forming a single connection, and nothing at all happened with their listen sockets. Again, we have the TCP connection we want. In my testing, case (a) is the usual behavior under Linux, while case (b) is usual for BSD. Either way it works though. I can't remember what the usual case was for Windows, but I think it worked too in one way or another. I tried to get it working on Mac OS X, but ran into some stupid API incompatibilities with my code that I just didn't have time to fix - I think it should work fine too once those API portability issues are resolved. The main point to notice here is that what is happening is really _exactly_ the same as for UDP hole punching, just using TCP instead, with a lot of help from the SO_REUSEADDR/SO_REUSEPORT options. Which is really what we want. And the success of this trick for TCP depends on _exactly_ the same conditions as the success of the trick for UDP (namely cone NAT behavior), with the minor additional proviso that firewalls must simply drop unrecognized incoming SYNs on the floor and not send back RSTs. Which apparently a lot of firewalls if not most already do. > I'm going to propose something here which I suspect is a really bad hack > and not a good idea but, well perhaps it will lead to a better idea. Build > NAT such that when a SYN arrived an the public interface and there was no > TCP binding for it, the NAT looks at the UDP bindings and forwards the SYN > to a device that the UDP binding for that port. So in the case above, B > could open UDP port 5060 and be listening on TCP port 5060 then do > something like STUN to punch a UDP hole in the NAT and find out that the > NAT mapped this to, say address 1.2.3.4:6000, Now A sends a TCP SYN to > 1.2.3.4:6000. The NAT looks at it's UDP binding table and sends this as a > TCP SYN to port 5060 on B. Everything else happens as normal from this > point on. Lots of details hand waived here but you get the idea. I thought of hacks like that too at some point (I think some existing NATs even couple the TCP and UDP port spaces, so this hack might even work already), but given that a cleaner alternative is available I really don't think this route should be taken. Bryan From audet@nortelnetworks.com Mon, 11 Oct 2004 09:29:39 -0700 (PDT) From: "Francois Audet" Date: Mon, 11 Oct 2004 09:29:39 -0700 (PDT) Subject: RE: [Ietf-behave] TCP without relays Message-ID: <1ECE0EB50388174790F9694F77522CCFC3836A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] TCP without relays > The main point to notice here is that what is happening is > really _exactly_ > the same as for UDP hole punching, just using TCP instead, > with a lot of help > from the SO_REUSEADDR/SO_REUSEPORT options. Which is really > what we want. > And the success of this trick for TCP depends on _exactly_ the same > conditions as the success of the trick for UDP (namely cone > NAT behavior), > with the minor additional proviso that firewalls must simply drop > unrecognized incoming SYNs on the floor and not send back > RSTs. Which > apparently a lot of firewalls if not most already do. I assume that likewise, we have the same limitations with "symmetric NATs" as we have with UDP, right? From baford@mit.edu Mon, 11 Oct 2004 10:03:23 -0700 (PDT) From: Bryan Ford Date: Mon, 11 Oct 2004 10:03:23 -0700 (PDT) Subject: Re: [Ietf-behave] TCP without relays In-Reply-To: <1ECE0EB50388174790F9694F77522CCFC3836A@zrc2hxm0.corp.nortel.com> Message-ID: <200410111303.22671.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Monday 11 October 2004 12:28, Francois Audet wrote: > > The main point to notice here is that what is happening is > > really _exactly_ > > the same as for UDP hole punching, just using TCP instead, > > with a lot of help > > from the SO_REUSEADDR/SO_REUSEPORT options. Which is really > > what we want. > > And the success of this trick for TCP depends on _exactly_ the same > > conditions as the success of the trick for UDP (namely cone > > NAT behavior), > > with the minor additional proviso that firewalls must simply drop > > unrecognized incoming SYNs on the floor and not send back > > RSTs. Which > > apparently a lot of firewalls if not most already do. > > I assume that likewise, we have the same limitations with "symmetric > NATs" as we have with UDP, right? Exactly. Symmetric NAT == EVIL. Bryan From fluffy@cisco.com Tue, 12 Oct 2004 02:33:57 -0700 (PDT) From: Cullen Jennings Date: Tue, 12 Oct 2004 02:33:57 -0700 (PDT) Subject: [Ietf-behave] Paper on TCP traversal Message-ID: MIME-Version: 1.0 Content-Type: text/plain Another paper with some discussion on TCP connections through NAT. http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf Thanks to Nagendra Modadugu for pointing this out to me. From jdrosen@dynamicsoft.com Sat, 16 Oct 2004 21:05:20 -0700 (PDT) From: Jonathan Rosenberg Date: Sat, 16 Oct 2004 21:05:20 -0700 (PDT) Subject: [Ietf-behave] updated rfc3489bis Message-ID: <4171EF7E.1020003@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain Folks, I've just submitted an updated rfc3489bis draft. Until it appears in the arhives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-behave-rfc3489bis-00.txt Besides the filename change to reflect its status as a WG item (it is on the charter for completion in July 2005), the only other change is the addition of a new attribute, SERVER, which is a textual description of the server software and version, similar to the SIP and HTTP Server field. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From fluffy@cisco.com Sun, 17 Oct 2004 04:48:05 -0700 (PDT) From: Cullen Jennings Date: Sun, 17 Oct 2004 04:48:05 -0700 (PDT) Subject: [Ietf-behave] New draft on UDP unicast behavior Message-ID: MIME-Version: 1.0 Content-Type: text/plain Until it gets posted, you can find it at http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-nat-00.ht ml or http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-nat-00.tx t From ssenthil@cisco.com Mon, 18 Oct 2004 14:29:37 -0700 (PDT) From: Senthil Sivakumar Date: Mon, 18 Oct 2004 14:29:37 -0700 (PDT) Subject: Re: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: Message-ID: <4.3.2.7.2.20041018142906.031c7d18@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Some comments. A large portion of this document seems to talk about the generic behavior of NAT and could very well be extended to TCP (or other layer 4 protocols that have a L4 identifier). Any specific reasons to restrict it to UDP only? Section 3.1 There is another flavor of NAT behavior in the IP address pooling case. NATs would overload on one address for several internal clients whenever possible. But the NAT uses a different address for for the same host applications that do not have port information. (DNS for example). This is neither an arbitrary behavior nor a strict behavior. It is somewhat ?adaptive?, IMO. Section 6: Is different ALG behaviors based on UDP is out of scope? General comment: NATs have different behavior based on what it is configured to do. So the port preservation and filtering Section 11: General comments. Are the requirements mentioned in this section the default behavior of NATs? I don?t think that would be acceptable to all vendors. The default behavior is very much dependent on a particular configuration of NAT. Changing existing behavior is always a challenge, so you could say some thing like ?a NAT should be able to behave in the mode specified by IETF?, where the vendors could still preserve their current behavior and provide the new behavior based on what mode is turned on. I think it could be argued that it would again make NATs non- deterministic, but that would give NAT vendors a motivation to follow the new behavior without having to drastically change the existing behavior. Specific ones. REQ-2b: A NAT MUST NOT have an "IP address pooling" behavior of "No". I could not figure out what the ?IP address pooling behavior of ?No? is. Did you mean to say ?arbitrary? ? REQ-3c: If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023. We tried this and atleast one application (rcp) is broken when we do this, where the server expects the source port to be in the low range. So there may be application dependencies with this behavior. REQ-5: A dynamic NAT UDP binding timer MUST NOT expire in less than 2 minutes. What do you mean by dynamic NAT UDP binding? There are applications that dictate how long the binding stays and what happens if the application?s timeout is less than 2 minutes. REQ-10: A NAT MUST have the capability to turn off individually all ALGs it supports, except for DNS and IPsec. Can we say that all the ALG?s working in the well known port range should be on by default? And all ALG?s listening on reserved ports and ephemeral ports should be off by default. REQ-10a: Any NAT ALG for SIP MUST be turned off by default. Section 12. General Comments. NATs can store the out-of-order fragments for a period of time until the first fragment arrives. This timeout could be a tunable one. I would like to see that this document recommending the handling out-of-order fragments. Minor ones: REQ-13 and REQ-13: should be Req-13 and Req-14. Senthil At 07:48 AM 10/17/2004 -0400, Cullen Jennings wrote: Until it gets posted, you can find it at http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-nat-00.ht ml or http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-nat-00.tx t _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortelnetworks.com Mon, 18 Oct 2004 16:58:12 -0700 (PDT) From: "Francois Audet" Date: Mon, 18 Oct 2004 16:58:12 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior Message-ID: <1ECE0EB50388174790F9694F77522CCFD4DB6A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message Thanks Senthil. See below for answers.
Some comments.A large portion of this document seems to talk about the generic behavior of NAT and could very well be extended to TCP (or other layer 4 protocols that have a L4 identifier).Any specific reasons to restrict it to UDP only?  Yes. Another document will look at TCP and other transport. The scope of this document is specifically restricted to UDP. This was discussed earlier and it was a concensus to look initially only at UDP for this document.
 Section 3.1 There is another flavor of NAT behavior in the IP address pooling case.NATs would overload on one address for several internal clients whenever possible. But the NAT uses a different address for for the same host applications that do not have port information. (DNS for example). This is neither an arbitrary behavior nor a strict behavior. It is somewhat “adaptive”, IMO.  I'm not sure I understand your comment. What do you mean by "applications that do not have port information like DNS"? 
Section 6:Is different ALG behaviors based on UDP is out of scope? Yes.
 General comment:NATs have different behavior based on what it is configured to do. So the portpreservation and filtering  Your sentence is incomplete...
 Section 11:General comments.Are the requirements mentioned in this section the default behavior of NATs? I don’t think that would be acceptable to all vendors. The default behavior is very much dependent on a particular configuration of NAT. Changing existing behavior is always a challenge, so you could say some thing like “a NAT should be able to behave in the mode specified by IETF”, where the vendors could still preserve their current behavior and provide the new behavior based on what mode is turned on. I think it could be argued that it would again make NATs non- deterministic,  but that would give NAT vendors a motivation to follow the new behavior without having to drastically change the existing behavior.  Indeed, I don't see any reason why a vendor woulnd't be able to do what you just describe. I would even say that for "backward compatibility", vendors will certainly be enclined to do what you just describe. They could decide to have a new "RFC XXX conformance" mode.
 Specific ones.REQ-2b: A NAT MUST NOT have an "IP address pooling" behavior of         "No".I could not figure out what the “IP address pooling behavior of “No” is. Did you mean to say “arbitrary” ? Correct. This is a typo. I will make the change.
 REQ-3c: If the NAT changes the source port, it MUST NOT         allocate the new port from within the range of 0-1023.We tried this and atleast one application (rcp) is broken when we do this, where the server expects the source port to be in the low range.  So there may be application dependencies with this behavior.  Hum. This is kind of interesting. I assume you are talking about port 469 "Radio Control Protocol"? It seems to me that RCP would then not work with any NAT unless there is some sort of ALG.   Is this a weakness of RCP itself?
 REQ-5: A dynamic NAT UDP binding timer MUST NOT expire in less      than 2 minutes.What do you mean by dynamic NAT UDP binding? There are applications that dictate how long the binding stays and what happens if the application’s timeout is less than 2 minutes.     I'll remove the word "Dynamic". It was "dynamic" as opposed to "static NAT binding" (in which case there is obviously no timeouts).   If applications are using their own timeouts, then by definition they require their own ALG.
 REQ-10: A NAT MUST have the capability to turn off individually      all ALGs it supports, except for DNS and IPsec.Can we say that all the ALG’s working in the well known port range should be on by default? And all ALG’s listening on reserved ports and ephemeral ports should be off by default.  Perhaps our wording is a little bit strong. Their might be some other protocols that require ALGs that we can't think of.   Would replacing the "MUST" by a "SHOULD" be appropriate?   Should we instead replace "DNS and IPsec" with something like "protocols who require ALGs such as DNS and IPsec"?
          REQ-10a: Any NAT ALG for SIP MUST be turned off by default.Section 12.General Comments. NATs can store the out-of-order fragments for a period of time until the first fragment arrives. This timeout could be a tunable one. I would like to see that this document recommending the handling out-of-order fragments.   I assume you would like section 10 to cover the timeout for this? Any suggestions on what it should say?
 Minor ones:REQ-13 and REQ-13: should be Req-13 and Req-14.  I'm not sure what happened here for this one as I had made that correction before. I assume the wrong version was posted.
 Senthil From ssenthil@cisco.com Mon, 18 Oct 2004 17:31:29 -0700 (PDT) From: Senthil Sivakumar Date: Mon, 18 Oct 2004 17:31:29 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <1ECE0EB50388174790F9694F77522CCFD4DB6A@zrc2hxm0.corp.norte l.com> Message-ID: <4.3.2.7.2.20041018170716.031c7438@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Inline. At 07:57 PM 10/18/2004 -0400, Francois Audet wrote: Thanks Senthil. See below for answers. Some comments. A large portion of this document seems to talk about the generic behavior of NAT and could very well be extended to TCP (or other layer 4 protocols that have a L4 identifier). Any specific reasons to restrict it to UDP only? Yes. Another document will look at TCP and other transport. The scope of this document is specifically restricted to UDP. This was discussed earlier and it was a concensus to look initially only at UDP for this document. Section 3.1 There is another flavor of NAT behavior in the IP address pooling case. NATs would overload on one address for several internal clients whenever possible. But the NAT uses a different address for for the same host applications that do not have port information. (DNS for example). This is neither an arbitrary behavior nor a strict behavior. It is somewhat adaptive , IMO. I'm not sure I understand your comment. What do you mean by "applications that do not have port information like DNS"? Some applications embed port and address in the payload, some just the address. When you are doing PAT the applications that does not embed port (like DNS), NATs are forced to use a new address from the address pool. Section 6: Is different ALG behaviors based on UDP is out of scope? Yes. General comment: NATs have different behavior based on what it is configured to do. So the port preservation and filtering Your sentence is incomplete... Section 11: General comments. Are the requirements mentioned in this section the default behavior of NATs? I don t think that would be acceptable to all vendors. The default behavior is very much dependent on a particular configuration of NAT. Changing existing behavior is always a challenge, so you could say some thing like a NAT should be able to behave in the mode specified by IETF , where the vendors could still preserve their current behavior and provide the new behavior based on what mode is turned on. I think it could be argued that it would again make NATs non- deterministic, but that would give NAT vendors a motivation to follow the new behavior without having to drastically change the existing behavior. Indeed, I don't see any reason why a vendor woulnd't be able to do what you just describe. I would even say that for "backward compatibility", vendors will certainly be enclined to do what you just describe. They could decide to have a new "RFC XXX conformance" mode. Changing an existing default behavior is not an easy task because it upsets a lot of customers. So there has to be a transitional path where you support the new behavior and slowly move them all to the new behavior. Specific ones. REQ-2b: A NAT MUST NOT have an "IP address pooling" behavior of "No". I could not figure out what the IP address pooling behavior of No is. Did you mean to say arbitrary ? Correct. This is a typo. I will make the change. REQ-3c: If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023. We tried this and atleast one application (rcp) is broken when we do this, where the server expects the source port to be in the low range. So there may be application dependencies with this behavior. Hum. This is kind of interesting. I assume you are talking about port 469 "Radio Control Protocol"? It seems to me that RCP would then not work with any NAT unless there is some sort of ALG. No, when you do a remote copy behind a NAT (doing overloading). A rcp client uses the source port < 1024, and the server port is rshell port 514. Is this a weakness of RCP itself? I could not find any information in the RFC that mandates this, but it could very well be an implementation issue. I have seen this with Solaris. REQ-5: A dynamic NAT UDP binding timer MUST NOT expire in less than 2 minutes. What do you mean by dynamic NAT UDP binding? There are applications that dictate how long the binding stays and what happens if the application s timeout is less than 2 minutes. I'll remove the word "Dynamic". It was "dynamic" as opposed to "static NAT binding" (in which case there is obviously no timeouts). If applications are using their own timeouts, then by definition they require their own ALG. Right, so the ALGs would have to use the timeouts indicated in the message itself, which might be less than the timeout specified above. REQ-10: A NAT MUST have the capability to turn off individually all ALGs it supports, except for DNS and IPsec. Can we say that all the ALG s working in the well known port range should be on by default? And all ALG s listening on reserved ports and ephemeral ports should be off by default. Perhaps our wording is a little bit strong. Their might be some other protocols that require ALGs that we can't think of. Right, I think it would vary from vendor to vendor, so it will be nice if we could word it in a generic way. Would replacing the "MUST" by a "SHOULD" be appropriate? I agree. Should we instead replace "DNS and IPsec" with something like "protocols who require ALGs such as DNS and IPsec"? Ok. REQ-10a: Any NAT ALG for SIP MUST be turned off by default. Section 12. General Comments. NATs can store the out-of-order fragments for a period of time until the first fragment arrives. This timeout could be a tunable one. I would like to see that this document recommending the handling out-of-order fragments. I assume you would like section 10 to cover the timeout for this? Any suggestions on what it should say? Yes, section 10 would be appropriate. The text could be something like, "It is RECOMMENDED that NATs doing PAT should support out-of-order fragments. This requires the NAT to store the non-initial fragments until the first fragment arrives, which contains the actual L4 information. Saving the out-of-order fragments potentially opens up the NAT to DoS attacks and hence NATs should store the fragments only wait for a period of time for the initial fragment to arrive. If the initial fragment does not arrive within that time period, the NAT should discard all the out-of-order fragments. This fragmentation timeout could be a configurable parameter. The default is suggested to be 20 seconds". Senthil Minor ones: REQ-13 and REQ-13: should be Req-13 and Req-14. I'm not sure what happened here for this one as I had made that correction before. I assume the wrong version was posted. Senthil From dwing@cisco.com Tue, 19 Oct 2004 21:17:24 -0700 (PDT) From: "Dan Wing" Date: Tue, 19 Oct 2004 21:17:24 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <4.3.2.7.2.20041018170716.031c7438@mira-sjcd-2.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I'm leaving this in HTML in the hopes it's still somewhat legible... Comments inline.
-----Original Message-----From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Senthil SivakumarSent: Monday, October 18, 2004 5:32 PMTo: Francois AudetCc: 'Behave'Subject: RE: [Ietf-behave] New draft on UDP unicast behavior Inline.At 07:57 PM 10/18/2004 -0400, Francois Audet wrote: Thanks Senthil. See below for answers. Some comments. A large portion of this document seems to talk about the generic behavior of NAT and could very well be extended to TCP (or other layer 4 protocols that have a L4 identifier). Any specific reasons to restrict it to UDP only? Yes. Another document will look at TCP and other transport. The scope of this document is specifically restricted to UDP. This was discussed earlier and it was a concensus to look initially only at UDP for this document. Section 3.1 There is another flavor of NAT behavior in the IP address pooling case. NATs would overload on one address for several internal clients whenever possible. But the NAT uses a different address for for the same host applications that do not have port information. (DNS for example). This is neither an arbitrary behavior nor a strict behavior. It is somewhat adaptive , IMO. I'm not sure I understand your comment. What do you mean by "applications that do not have port information like DNS"? Some applications embed port and address in the payload, some just the address. When you are doing PATthe applications that does not embed port (like DNS), NATs are forced to use a new address from the addresspool. Help me understand if I'm interpreting your statement correctly. Are you're saying: DNS queries don't have the source UDP port in them, thus NATs have to use different source UDP ports for each DNS query so the NAT can successfully demultiplex the DNS answers. ?
Section 6: Is different ALG behaviors based on UDP is out of scope?Yes. General comment: NATs have different behavior based on what it is configured to do. So the port preservation and filtering Your sentence is incomplete... Section 11: General comments. Are the requirements mentioned in this section the default behavior of NATs? I don t think that would be acceptable to all vendors. The default behavior is very much dependent on a particular configuration of NAT. Changing existing behavior is always a challenge, so you could say some thing like a NAT should be able to behave in the mode specified by IETF , where the vendors could still preserve their current behavior and provide the new behavior based on what mode is turned on. I think it could be argued that it would again make NATs non- deterministic, but that would give NAT vendors a motivation to follow the new behavior without having to drastically change the existing behavior. Indeed, I don't see any reason why a vendor woulnd't be able to do what you just describe. I would even say that for "backward compatibility", vendors will certainly be enclined to do what you just describe. They could decide to have a new "RFC XXX conformance" mode.Changing an existing default behavior is not an easy task because it upsets a lot of customers. Sothere has to be a transitional path where you support the new behavior and slowly move them allto the new behavior. Specific ones. REQ-2b: A NAT MUST NOT have an "IP address pooling" behavior of "No". I could not figure out what the IP address pooling behavior of No is. Did you mean to say arbitrary ?Correct. This is a typo. I will make the change. REQ-3c: If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023. We tried this and atleast one application (rcp) is broken when we do this, where the server expects the source port to be in the low range. So there may be application dependencies with this behavior. Hum. This is kind of interesting. I assume you are talking about port 469 "Radio Control Protocol"? It seems to me that RCP would then not work with any NAT unless there is some sort of ALG.No, when you do a remote copy behind a NAT (doing overloading). A rcp client uses the source port < 1024,and the server port is rshell port 514. Is this a weakness of RCP itself? I could not find any information in the RFC that mandates this, but it could very wellbe an implementation issue. I have seen this with Solaris. I'm familiar withRCP; thanks for pointing out that application's use ofports below 1024! I thinkwe should discuss the R protocols brieflyin the document, but also mention that they're essentially obsolete due to their poor security model.
REQ-5: A dynamic NAT UDP binding timer MUST NOT expire in less than 2 minutes. What do you mean by dynamic NAT UDP binding? There are applications that dictate how long the binding stays and what happens if the application s timeout is less than 2 minutes. I'll remove the word "Dynamic". It was "dynamic" as opposed to "static NAT binding" (in which case there is obviously no timeouts).If applications are using their own timeouts, then by definition they require their own ALG. Right, so the ALGs would have to use the timeouts indicated in the message itself, which might beless than the timeout specified above. ALGs are out of scope of this document, though.
REQ-10: A NAT MUST have the capability to turn off individually all ALGs it supports, except for DNS and IPsec. What is this DNS ALG -- is it an RFC2694 ALG? If it is, the Draft needs to be specific. If it isn't, the Draft needs to describe the specific behavior of this DNS "ALG". As this draft is only supposed to cover UDP, I don't understand the need for an IPsec ALG in REQ-10.
Can we say that all the ALG s working in the well known port range should be on by default? And all ALG s listening on reserved ports and ephemeral ports should be off by default. Perhaps our wording is a little bit strong. Their might be some other protocols that require ALGs that we can't think of. Right, I think it would vary from vendor to vendor, so it will be nice if we could word it in a generic way. Would replacing the "MUST" by a "SHOULD" be appropriate? I agree. If we use SHOULD, we need to explain in the Draft why the requirementisn't a MUST; otherwise implementors will ignore the SHOULD because they don't understand the implications of their decision.
Should we instead replace "DNS and IPsec" with something like "protocols who require ALGs such as DNS and IPsec"? Ok. We need to describe the functions of these ALGs, though, as I mentioned earlier.
REQ-10a: Any NAT ALG for SIP MUST be turned off by default. Section 12. General Comments. NATs can store the out-of-order fragments for a period of time until the first fragment arrives. This timeout could be a tunable one. I would like to see that this document recommending the handling out-of-order fragments. I assume you would like section 10 to cover the timeout for this? Any suggestions on what it should say? Yes, section 10 would be appropriate. The text could be something like,"It is RECOMMENDED that NATs doing PAT should support out-of-order fragments. This requires the NAT to store the non-initial fragments until the first fragment arrives,which contains the actual L4 information. Saving the out-of-order fragments potentiallyopens up the NAT to DoS attacks and hence NATs should store the fragments onlywait for a period of time for the initial fragment to arrive. If the initial fragment does notarrive within that time period, the NAT should discard all the out-of-order fragments. This fragmentation timeout could be a configurable parameter. The default is suggestedto be 20 seconds". An additional threshold should be a certain percentage of free memory on the NAT, too. We should be clear if we recommend the NAT send the packets to the host in the same order they were received, or if it should attempt to reconstitute them, or what. -d
Senthil Minor ones: REQ-13 and REQ-13: should be Req-13 and Req-14. I'm not sure what happened here for this one as I had made that correction before. I assume the wrong version was posted. Senthil From ssenthil@cisco.com Tue, 19 Oct 2004 22:13:43 -0700 (PDT) From: Senthil Sivakumar Date: Tue, 19 Oct 2004 22:13:43 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <4.3.2.7.2.20041018170716.031c7438@mira-sjcd-2.cisco.com> Message-ID: <4.3.2.7.2.20041019215700.02bbeed8@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain At 09:17 PM 10/19/2004 -0700, Dan Wing wrote: I'm leaving this in HTML in the hopes it's still somewhat legible... Comments inline. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Senthil Sivakumar Sent: Monday, October 18, 2004 5:32 PM To: Francois Audet Cc: 'Behave' Subject: RE: [Ietf-behave] New draft on UDP unicast behavior Inline. At 07:57 PM 10/18/2004 -0400, Francois Audet wrote: Thanks Senthil. See below for answers. Some comments. A large portion of this document seems to talk about the generic behavior of NAT and could very well be extended to TCP (or other layer 4 protocols that have a L4 identifier). Any specific reasons to restrict it to UDP only? Yes. Another document will look at TCP and other transport. The scope of this document is specifically restricted to UDP. This was discussed earlier and it was a concensus to look initially only at UDP for this document. Section 3.1 There is another flavor of NAT behavior in the IP address pooling case. NATs would overload on one address for several internal clients whenever possible. But the NAT uses a different address for for the same host applications that do not have port information. (DNS for example). This is neither an arbitrary behavior nor a strict behavior. It is somewhat adaptive , IMO. I'm not sure I understand your comment. What do you mean by "applications that do not have port information like DNS"? Some applications embed port and address in the payload, some just the address. When you are doing PAT the applications that does not embed port (like DNS), NATs are forced to use a new address from the address pool. Help me understand if I'm interpreting your statement correctly. Are you're saying: DNS queries don't have the source UDP port in them, thus NATs have to use different source UDP ports for each DNS query so the NAT can successfully demultiplex the DNS answers. ? Nope, I am saying that the DNS replies embed just the IP addresses and not ports. When NAT is operating as a PAT, it cannot overload on the address only, it also needs the port. But now, I realize that ALGs are out of the scope of this document this is may not be a relevant discussion in this document, since we are discussing the DNS ALG here. Section 6: Is different ALG behaviors based on UDP is out of scope? Yes. General comment: NATs have different behavior based on what it is configured to do. So the port preservation and filtering Your sentence is incomplete... Section 11: General comments. Are the requirements mentioned in this section the default behavior of NATs? I don t think that would be acceptable to all vendors. The default behavior is very much dependent on a particular configuration of NAT. Changing existing behavior is always a challenge, so you could say some thing like a NAT should be able to behave in the mode specified by IETF , where the vendors could still preserve their current behavior and provide the new behavior based on what mode is turned on. I think it could be argued that it would again make NATs non- deterministic, but that would give NAT vendors a motivation to follow the new behavior without having to drastically change the existing behavior. Indeed, I don't see any reason why a vendor woulnd't be able to do what you just describe. I would even say that for "backward compatibility", vendors will certainly be enclined to do what you just describe. They could decide to have a new "RFC XXX conformance" mode. Changing an existing default behavior is not an easy task because it upsets a lot of customers. So there has to be a transitional path where you support the new behavior and slowly move them all to the new behavior. Specific ones. REQ-2b: A NAT MUST NOT have an "IP address pooling" behavior of "No". I could not figure out what the IP address pooling behavior of No is. Did you mean to say arbitrary ? Correct. This is a typo. I will make the change. REQ-3c: If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023. We tried this and atleast one application (rcp) is broken when we do this, where the server expects the source port to be in the low range. So there may be application dependencies with this behavior. Hum. This is kind of interesting. I assume you are talking about port 469 "Radio Control Protocol"? It seems to me that RCP would then not work with any NAT unless there is some sort of ALG. No, when you do a remote copy behind a NAT (doing overloading). A rcp client uses the source port < 1024, and the server port is rshell port 514. Is this a weakness of RCP itself? I could not find any information in the RFC that mandates this, but it could very well be an implementation issue. I have seen this with Solaris. I'm familiar with RCP; thanks for pointing out that application's use of ports below 1024! I think we should discuss the R protocols briefly in the document, but also mention that they're essentially obsolete due to their poor security model. Believe me, there are a lot of people using it and they will complain.. REQ-5: A dynamic NAT UDP binding timer MUST NOT expire in less than 2 minutes. What do you mean by dynamic NAT UDP binding? There are applications that dictate how long the binding stays and what happens if the application s timeout is less than 2 minutes. I'll remove the word "Dynamic". It was "dynamic" as opposed to "static NAT binding" (in which case there is obviously no timeouts). If applications are using their own timeouts, then by definition they require their own ALG. Right, so the ALGs would have to use the timeouts indicated in the message itself, which might be less than the timeout specified above. ALGs are out of scope of this document, though. REQ-10: A NAT MUST have the capability to turn off individually all ALGs it supports, except for DNS and IPsec. What is this DNS ALG -- is it an RFC2694 ALG? If it is, the Draft needs to be specific. If it isn't, the Draft needs to describe the specific behavior of this DNS "ALG". Yes it is the one defined in 2694. But that is why I thought being more generic might be a good idea without naming any ALG in particular. As this draft is only supposed to cover UDP, I don't understand the need for an IPsec ALG in REQ-10. Can we say that all the ALG s working in the well known port range should be on by default? And all ALG s listening on reserved ports and ephemeral ports should be off by default. Perhaps our wording is a little bit strong. Their might be some other protocols that require ALGs that we can't think of. Right, I think it would vary from vendor to vendor, so it will be nice if we could word it in a generic way. Would replacing the "MUST" by a "SHOULD" be appropriate? I agree. If we use SHOULD, we need to explain in the Draft why the requirement isn't a MUST; otherwise implementors will ignore the SHOULD because they don't understand the implications of their decision. Should we instead replace "DNS and IPsec" with something like "protocols who require ALGs such as DNS and IPsec"? Ok. We need to describe the functions of these ALGs, though, as I mentioned earlier. Or don't call out these ALGs specifically. Just say that "all ALGs supported by the NAT should be off by default except for the ones that listen on well-known ports." REQ-10a: Any NAT ALG for SIP MUST be turned off by default. Section 12. General Comments. NATs can store the out-of-order fragments for a period of time until the first fragment arrives. This timeout could be a tunable one. I would like to see that this document recommending the handling out-of-order fragments. I assume you would like section 10 to cover the timeout for this? Any suggestions on what it should say? Yes, section 10 would be appropriate. The text could be something like, "It is RECOMMENDED that NATs doing PAT should support out-of-order fragments. This requires the NAT to store the non-initial fragments until the first fragment arrives, which contains the actual L4 information. Saving the out-of-order fragments potentially opens up the NAT to DoS attacks and hence NATs should store the fragments only wait for a period of time for the initial fragment to arrive. If the initial fragment does not arrive within that time period, the NAT should discard all the out-of-order fragments. This fragmentation timeout could be a configurable parameter. The default is suggested to be 20 seconds". An additional threshold should be a certain percentage of free memory on the NAT, too. We should be clear if we recommend the NAT send the packets to the host in the same order they were received, or if it should attempt to reconstitute them, or what. I think they should be sent out in proper order but there should be no attempt to reassemble them. A couple of reasons I could think of are that 1. reassembled fragments might again be fragmented. 2. reassembling is really a host functionality and a middle box should not be required to do that. Senthil -d Senthil Minor ones: REQ-13 and REQ-13: should be Req-13 and Req-14. I'm not sure what happened here for this one as I had made that correction before. I assume the wrong version was posted. Senthil From dwing@cisco.com Wed, 20 Oct 2004 09:48:06 -0700 (PDT) From: "Dan Wing" Date: Wed, 20 Oct 2004 09:48:06 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <4.3.2.7.2.20041019215700.02bbeed8@mira-sjcd-2.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Converted to ASCII to make this thread easier to follow, and removed previous bits and pieces of the thread. Senthil Sivakumar wrote: >>Dan Wing wrote: >> >>Help me understand if I'm interpreting your statement correctly. Are you're saying: >> >> DNS queries don't have the source UDP port in them, >> thus NATs have to use different source UDP ports for >> each DNS query so the NAT can successfully demultiplex >> the DNS answers. >> >> ? > > Nope, I am saying that the DNS replies embed just the IP addresses and > not ports. When NAT is operating as a PAT, it cannot overload on the > address only, it also needs the port. But now, I realize that ALGs > are out of the scope of this document this is may not be a relevant > discussion in this document, since we are discussing the DNS ALG here. ... >> I'm familiar with RCP; thanks for pointing out that application's >> use of ports below 1024! >> >> I think we should discuss the R protocols briefly in the document, but >> also mention that they're essentially obsolete due to their poor >> security model. > > Believe me, there are a lot of people using it and they will complain.. All of the R-Services (rlogin, rsh, rexec, rwho) run over TCP, though, don't they? So I believe they're out of scope for this document. Other than NFS's and RPC's similar reliance on ports < 1024, I'm not aware of any UDP-based application that expects the UDP source port to be < 1024. >>> REQ-10: A NAT MUST have the capability to turn off individually >>> all ALGs it supports, except for DNS and IPsec. >> >> What is this DNS ALG -- is it an RFC2694 ALG? If it is, the Draft >> needs to be specific. If it isn't, the Draft needs to describe >> the specific behavior of this DNS "ALG". > > Yes it is the one defined in 2694. But that is why I thought being > more generic might be a good idea without naming any ALG in particular. The charter of BEHAVE is to make NATs more consistent in their behavior so applications can rely on the NAT's behavior. If an application doesn't know how the NAT will interfere with a certain application (such as DNS), we haven't achieved our goal. So we need to be explicit. >> We need to describe the functions of these ALGs, though, as >> I mentioned earlier. > > Or don't call out these ALGs specifically. Just say that "all > ALGs supported by the NAT should be off by default except for > the ones that listen on well-known ports." I disagree. We need to enumerate the ones we "like" -- if there are any -- and describe their proper behavior. Defining the Proper Behavior, and the fact that all protocols evolve (DNS SRV RR, as a good example), is why we don't want to get involved in defining 'proper' ALG behavior, and is also why ALGs are nearly always a really, really bad idea. There is also a lot of intellectual property around ALGs and each vendor believes their method is better than other methods, because each belives their method provides more transparancy than competitors'. >> We should be clear if we recommend the NAT send the packets to the >> host in the same order they were received, or if it should attempt to >> reconstitute them, or what. > > I think they should be sent out in proper order but there should be > no attempt to reassemble them. A couple of reasons I could think of > are that > > 1. Reassembled fragments might again be fragmented. > 2. Reassembling is really a host functionality and a middle box should > not be required to do that. Sure, that sounds reasonable to add to the I-D. I personally don't expect the packets will get fragmented again unless they exceed 1500 bytes, but it's not worth worrying about too much either way. -d From ssenthil@cisco.com Wed, 20 Oct 2004 11:09:31 -0700 (PDT) From: Senthil Sivakumar Date: Wed, 20 Oct 2004 11:09:31 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <4.3.2.7.2.20041019215700.02bbeed8@mira-sjcd-2.cisco.com> Message-ID: <4.3.2.7.2.20041020105745.03271a98@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain At 09:48 AM 10/20/2004 -0700, Dan Wing wrote: Converted to ASCII to make this thread easier to follow, and removed previous bits and pieces of the thread. Senthil Sivakumar wrote: >>Dan Wing wrote: >> >>Help me understand if I'm interpreting your statement correctly. Are you're saying: >> >> DNS queries don't have the source UDP port in them, >> thus NATs have to use different source UDP ports for >> each DNS query so the NAT can successfully demultiplex >> the DNS answers. >> >> ? > > Nope, I am saying that the DNS replies embed just the IP addresses and > not ports. When NAT is operating as a PAT, it cannot overload on the > address only, it also needs the port. But now, I realize that ALGs > are out of the scope of this document this is may not be a relevant > discussion in this document, since we are discussing the DNS ALG here. ... >> I'm familiar with RCP; thanks for pointing out that application's >> use of ports below 1024! >> >> I think we should discuss the R protocols briefly in the document, but >> also mention that they're essentially obsolete due to their poor >> security model. > > Believe me, there are a lot of people using it and they will complain.. All of the R-Services (rlogin, rsh, rexec, rwho) run over TCP, though, don't they? So I believe they're out of scope for this document. Yes you are right most of them are TCP based, but the point I am trying to make is that there are weird behaving applications like these that existed for a long time that may not work with the proposed behavior. Other than NFS's and RPC's similar reliance on ports < 1024, I'm not aware of any UDP-based application that expects the UDP source port to be < 1024. Me neither, at this time. >>> REQ-10: A NAT MUST have the capability to turn off individually >>> all ALGs it supports, except for DNS and IPsec. >> >> What is this DNS ALG -- is it an RFC2694 ALG? If it is, the Draft >> needs to be specific. If it isn't, the Draft needs to describe >> the specific behavior of this DNS "ALG". > > Yes it is the one defined in 2694. But that is why I thought being > more generic might be a good idea without naming any ALG in particular. The charter of BEHAVE is to make NATs more consistent in their behavior so applications can rely on the NAT's behavior. If an application doesn't know how the NAT will interfere with a certain application (such as DNS), we haven't achieved our goal. So we need to be explicit. So, how should we be explicit here ? I made a comment that a lot of text in this document is generic NAT behavior and nothing to do with UDP only. Req 10 above is one such requirement. I don't see why do we have to name any ALGs or discuss their functions. Also, I am told that ALGs are out of the scope of this document. >> We need to describe the functions of these ALGs, though, as >> I mentioned earlier. > > Or don't call out these ALGs specifically. Just say that "all > ALGs supported by the NAT should be off by default except for > the ones that listen on well-known ports." I disagree. We need to enumerate the ones we "like" -- if there are any -- and describe their proper behavior. I don't understand what you are disagreeing with here, is it the recommendation that the ALGs listening on the well known ports should be on by default? Defining the Proper Behavior, and the fact that all protocols evolve (DNS SRV RR, as a good example), is why we don't want to get involved in defining 'proper' ALG behavior, and is also why ALGs are nearly always a really, really bad idea. I don't suggest that we need to define the behavior of ALG by any means. Senthil There is also a lot of intellectual property around ALGs and each vendor believes their method is better than other methods, because each belives their method provides more transparancy than competitors'. >> We should be clear if we recommend the NAT send the packets to the >> host in the same order they were received, or if it should attempt to >> reconstitute them, or what. > > I think they should be sent out in proper order but there should be > no attempt to reassemble them. A couple of reasons I could think of > are that > > 1. Reassembled fragments might again be fragmented. > 2. Reassembling is really a host functionality and a middle box should > not be required to do that. Sure, that sounds reasonable to add to the I-D. I personally don't expect the packets will get fragmented again unless they exceed 1500 bytes, but it's not worth worrying about too much either way. -d From dwing@cisco.com Wed, 20 Oct 2004 12:02:40 -0700 (PDT) From: "Dan Wing" Date: Wed, 20 Oct 2004 12:02:40 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <4.3.2.7.2.20041020105745.03271a98@mira-sjcd-2.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > > >> I'm familiar with RCP; thanks for pointing out that application's > > >> use of ports below 1024! > > >> > > >> I think we should discuss the R protocols briefly in the > > >> document, but > > >> also mention that they're essentially obsolete due to their poor > > >> security model. > > > > > > Believe me, there are a lot of people using it and they will > > > complain.. > > > >All of the R-Services (rlogin, rsh, rexec, rwho) run over TCP, though, > >don't they? So I believe they're out of scope for this document. > > Yes you are right most of them are TCP based, but the point I am > trying to make is that there are weird behaving applications like these > that existed for a long time that may not work with the proposed > behavior. > > > >Other than NFS's and RPC's similar reliance on ports < 1024, I'm not > >aware of any UDP-based application that expects the UDP source port to > >be < 1024. > > Me neither, at this time. Okay, I see your point. It agree it might be useful to encourage NATs to preserve the source UDP port if it's below 1024, just in the event there are non-standard applications that use this as a (weak) distributed authentication mechanism. At the same time, it would be good to encourage UDP applications to quit doing this stuff. However, that pedagogy around application design probably doesn't belong in -ietf-behave-nat-. > > >>> REQ-10: A NAT MUST have the capability to turn off individually > > >>> all ALGs it supports, except for DNS and IPsec. > > >> > > >> What is this DNS ALG -- is it an RFC2694 ALG? If it is, the Draft > > >> needs to be specific. If it isn't, the Draft needs to describe > > >> the specific behavior of this DNS "ALG". > > > > > > Yes it is the one defined in 2694. But that is why I thought being > > > more generic might be a good idea without naming any ALG in > particular. > > > >The charter of BEHAVE is to make NATs more consistent in their behavior > >so applications can rely on the NAT's behavior. If an application > >doesn't know how the NAT will interfere with a certain application (such > >as DNS), we haven't achieved our goal. So we need to be explicit. > > So, how should we be explicit here ? I made a comment that a lot of text > in this document is generic NAT behavior and nothing to do with > UDP only. Req 10 above is one such requirement. I don't see why do > we have to name any ALGs or discuss their functions. Also, I am told > that ALGs are out of the scope of this document. I don't see the need for either a DNS or IPsec ALG in a NAT, but perhaps I'm missing something. The only interesting thing around some protocols is the NAT could expect a single outgoing UDP message will elicit a single UDP response, and the NAT could then immediately close its NAT binding (and free up the associated resources). This seems a bit risky in the event the application evolves so that a single outgoing UDP messages causes more than one incoming UDP message, but that kind of evolution seems unlikely for protocols such as DNS and NTP. I guess what I'm saying is we should soften the MUST for the two minute UDP timeout to a SHOULD and explain the few permitted exceptions to the two minute rule. Beyond that, I don't see any use for application awareness for DNS in a NAT. > > >> We need to describe the functions of these ALGs, though, as > > >> I mentioned earlier. > > > > > > Or don't call out these ALGs specifically. Just say that "all > > > ALGs supported by the NAT should be off by default except for > > > the ones that listen on well-known ports." > > > >I disagree. > > > >We need to enumerate the ones we "like" -- if there are any -- and > >describe their proper behavior. > > I don't understand what you are disagreeing with here, is it the > recommendation that the ALGs listening on the well known ports > should be on by default? To meet BEHAVE's goals, I don't see how we can allow ALGs in a NAT unless we enumerate what each application layer gateway's permitted behavior is for each application. For an example of how an underspecified ALG can do harm, let's say some NAT vendors all use 192.168.1.* as the local network interface on their NAT, and both vendors have a DNS ALG (which is permitted if BEHAVE says that ALGs can exist on well-known ports), and: * vendor A's DNS ALG rewrites any incoming DNS response that references 192.168.1.* as NXDOMAIN, because there aren't any configured servers on this NAT. * vendor B's DNS ALG rewrites incoming DNS SRV resource records that reference 192.168.1.* as the NAT's public IP address, and creates an associated binding on the NAT which maps to the internal host and internal port that that was specified in the SRV. * vendor C does a the same thing to vendor C, but also examines TXT records looking for 192.168.1.* address and port combinations and rewrites them and installs a NAT binding. > >Defining the Proper Behavior, and the fact that all protocols evolve > >(DNS SRV RR, as a good example), is why we don't want to get involved in > >defining 'proper' ALG behavior, and is also why ALGs are nearly always a > >really, really bad idea. > > I don't suggest that we need to define the behavior of ALG by any means. I'm saying that *if* the BEHAVE document explicitly or implicitly allows an ALG, the BEHAVE document needs to define the proper behavior of those ALGs. I'm not convinced that BEHAVE needs to allow an ALG, though. -d > Senthil > > >There is also a lot of intellectual property around ALGs and each vendor > >believes their method is better than other methods, because each belives > >their method provides more transparancy than competitors'. > > > > >> We should be clear if we recommend the NAT send the packets to the > > >> host in the same order they were received, or if it should attempt to > > >> reconstitute them, or what. > > > > > > I think they should be sent out in proper order but there should be > > > no attempt to reassemble them. A couple of reasons I could think of > > > are that > > > > > > 1. Reassembled fragments might again be fragmented. > > > 2. Reassembling is really a host functionality and a middle box should > > > not be required to do that. > > > >Sure, that sounds reasonable to add to the I-D. I personally > don't expect > >the packets will get fragmented again unless they exceed 1500 bytes, but > >it's not worth worrying about too much either way. > > > >-d > From audet@nortelnetworks.com Wed, 20 Oct 2004 14:54:44 -0700 (PDT) From: "Francois Audet" Date: Wed, 20 Oct 2004 14:54:44 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior Message-ID: <1ECE0EB50388174790F9694F77522CCFD4E8EB@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New draft on UDP unicast behavior Hi guys, Let's try to summarize the latest issues from the email exchange. REQ-3c: If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023. I assume that the proposal is to change it to something like "If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023 unless the original port was within that range, in which case the NAT MAY allocate the new port from within the 0-1023 range. The rationale would be for applications such as rcp which bizarely use the source port for some weak authentication. While I don't really care, I am not terribly keen on this idea. Seems to me that it is extremely unlikely that rcp would work with any commercial NAT today as I have a hard time believing that NATs would preserve the well-known port range today. Any other views on this topic? REQ-10: A NAT MUST have the capability to turn off individually all ALGs it supports, except for DNS and IPsec. This definitively needs tweaking. The question is do we make it more or less explicit. Do we say "A NAT MUST have the capability to turn off individually all ALGs it supports." (full stop). Or do we say "A NAT MUST have the capability to turn off individually all ALGs it supports unless there is a clear reason for not doing so described in an IETF RFC" (or something like that). Any views of which approach is best? From dwing@cisco.com Wed, 20 Oct 2004 15:38:32 -0700 (PDT) From: "Dan Wing" Date: Wed, 20 Oct 2004 15:38:32 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <1ECE0EB50388174790F9694F77522CCFD4E8EB@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New draft on UDP unicast behavior
-----Original Message-----From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx]Sent: Wednesday, October 20, 2004 2:55 PMTo: 'Dan Wing'; 'Senthil Sivakumar'Cc: 'Behave'Subject: RE: [Ietf-behave] New draft on UDP unicast behavior Hi guys, Let's try to summarize the latest issues from the email exchange. REQ-3c: If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023. I assume that the proposal is to change it to something like "If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023 unless the original port was within that range, in which case the NAT MAY allocate the new port from within the 0-1023 range. More straightforward wording, with the same meaning, might be: 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. In that way this requirement doesn't talk about changing the source port; we can talk about that in another requirement.
The rationale would be for applications such as rcp which bizarely use the source port for some weak authentication. RCP runs over TCP, so RCP isn't a good justification for this UDP-focused document. However, NFS and RPC run over UDP. A good cite is RFC2623, "NFS Version 2 and Version 3 Security Issues and the NFS Protocol'sUse of RPCSEC_GSS and Kerberos V5", notably section 2.1.
While I don't really care, I am not terribly keen on this idea. Seems to me that it is extremely unlikely that rcp would work with any commercial NAT today as I have a hard time believing that NATs would preserve the well-known port range today. Any other views on this topic? Furthermore,such a behavior in a NAT allows any device behind the NAT to pretend to be theclient that's authorizedin the .rhosts file. This seems like an idea worse than normal r-servicesunless you trust any and all devices behind the NAT tobe friendly. Oh, and you also need to trust that nobody else will get that NAT's IP address (which is one of the weaknesses of r-services authentication). To bring us back to UDP, though, NFS and RPC have a similar weakness.
REQ-10: A NAT MUST have the capability to turn off individually all ALGs it supports, except for DNS and IPsec. This definitively needs tweaking. The question is do we make it more or less explicit. Do we say "A NAT MUST have the capability to turn off individually all ALGs it supports." (full stop). Or do we say "A NAT MUST have the capability to turn off individually all ALGs it supports unless there is a clear reason for not doing so described in an IETF RFC" (or something like that). Any views of which approach is best? I haven't seen any arguments for, or descriptions of, UDP ALGs that are necessary for a NAT to function. Without such argumentsthe textshould recommend ALGs be turned off in the default configuration -- that is, the NAT shouldn't require the user go into a screen or enter a command to disable any ALG, but rather the user should have to _enable_ an ALG explicitly if the user needs an ALG for their application to work over the NAT. Once we begin tackling TCP in a separate document, we will undoubtably uncover a few needs for ALGs (FTP comes to mind). -d From audet@nortelnetworks.com Wed, 20 Oct 2004 15:52:35 -0700 (PDT) From: "Francois Audet" Date: Wed, 20 Oct 2004 15:52:35 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior Message-ID: <1ECE0EB50388174790F9694F77522CCFD4E944@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message Hi Dan, If I understand correctly, you want REQ-10 to be: REQ-10: NAT MUST have the capability to turn off individually all ALGs it supports. REQ-10a: as per the current text REQ-10-b: It is RECOMMENDED that all ALGs be turned off by default. I'm OK with 3c's re-wording. I assume that you are arguing for a reference to RFC 2623 in the justification section for requirement 3c, correct?
-----Original Message-----From: Dan Wing [mailto:dwing@xxxxxxxxx] Sent: Wednesday, October 20, 2004 15:38To: Audet, Francois [SC100:9T51:EXCH]; 'Senthil Sivakumar'Cc: 'Behave'Subject: RE: [Ietf-behave] New draft on UDP unicast behavior
-----Original Message-----From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx]Sent: Wednesday, October 20, 2004 2:55 PMTo: 'Dan Wing'; 'Senthil Sivakumar'Cc: 'Behave'Subject: RE: [Ietf-behave] New draft on UDP unicast behavior Hi guys, Let's try to summarize the latest issues from the email exchange. REQ-3c: If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023. I assume that the proposal is to change it to something like "If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023 unless the original port was within that range, in which case the NAT MAY allocate the new port from within the 0-1023 range. More straightforward wording, with the same meaning, might be: 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. In that way this requirement doesn't talk about changing the source port; we can talk about that in another requirement.
The rationale would be for applications such as rcp which bizarely use the source port for some weak authentication. RCP runs over TCP, so RCP isn't a good justification for this UDP-focused document. However, NFS and RPC run over UDP. A good cite is RFC2623, "NFS Version 2 and Version 3 Security Issues and the NFS Protocol'sUse of RPCSEC_GSS and Kerberos V5", notably section 2.1.
While I don't really care, I am not terribly keen on this idea. Seems to me that it is extremely unlikely that rcp would work with any commercial NAT today as I have a hard time believing that NATs would preserve the well-known port range today. Any other views on this topic? Furthermore,such a behavior in a NAT allows any device behind the NAT to pretend to be theclient that's authorizedin the .rhosts file. This seems like an idea worse than normal r-servicesunless you trust any and all devices behind the NAT tobe friendly. Oh, and you also need to trust that nobody else will get that NAT's IP address (which is one of the weaknesses of r-services authentication). To bring us back to UDP, though, NFS and RPC have a similar weakness.
REQ-10: A NAT MUST have the capability to turn off individually all ALGs it supports, except for DNS and IPsec. This definitively needs tweaking. The question is do we make it more or less explicit. Do we say "A NAT MUST have the capability to turn off individually all ALGs it supports." (full stop). Or do we say "A NAT MUST have the capability to turn off individually all ALGs it supports unless there is a clear reason for not doing so described in an IETF RFC" (or something like that). Any views of which approach is best? I haven't seen any arguments for, or descriptions of, UDP ALGs that are necessary for a NAT to function. Without such argumentsthe textshould recommend ALGs be turned off in the default configuration -- that is, the NAT shouldn't require the user go into a screen or enter a command to disable any ALG, but rather the user should have to _enable_ an ALG explicitly if the user needs an ALG for their application to work over the NAT. Once we begin tackling TCP in a separate document, we will undoubtably uncover a few needs for ALGs (FTP comes to mind). -d From dwing@cisco.com Wed, 20 Oct 2004 16:34:27 -0700 (PDT) From: "Dan Wing" Date: Wed, 20 Oct 2004 16:34:27 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <1ECE0EB50388174790F9694F77522CCFD4E944@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > If I understand correctly, you want REQ-10 to be: > > REQ-10: NAT MUST have the capability to turn off individually > all ALGs it supports. > REQ-10a: as per the current text > REQ-10-b: It is RECOMMENDED that all ALGs be turned off > by default. No, I'm asking that REQ-10-b say that _all_ ALGs must be turned off by default. (As you know, "Recommended" is a synonym for "Should" in RFC2119). In draft-ietf-behave-nat-01, REQ-10 currently reads: : REQ-10: A NAT MUST have the capability to turn off : individually all ALGs it supports, except for DNS and IPsec. : : REQ-10a: Any NAT ALG for SIP MUST be turned off by default. I am suggesting replacing it with the following text: : REQ-10: If a NAT includes ALGs, all of those ALGs MUST be : disabled by default. : : REQ-10a: If a NAT includes ALGs, it is RECOMMENDED that : the NAT allow the user to enable or disable each : ALG separately. This requirement allows the user : to enable ALGs which are necessary to aid operation : of some applications without enabling ALGs which : interfere with operation of other applications. > I'm OK with 3c's re-wording. I assume that you are arguing for > a reference to RFC 2623 in the justification section for requirement > 3c, correct? Right. A non-normative reference to RFC2623 should be sufficient to explain why REQ-3C recommends preserving the well-known port range for the source UDP port. -d -----Original Message----- From: Dan Wing [mailto:dwing@xxxxxxxxx] Sent: Wednesday, October 20, 2004 15:38 To: Audet, Francois [SC100:9T51:EXCH]; 'Senthil Sivakumar' Cc: 'Behave' Subject: RE: [Ietf-behave] New draft on UDP unicast behavior -----Original Message----- From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx] Sent: Wednesday, October 20, 2004 2:55 PM To: 'Dan Wing'; 'Senthil Sivakumar' Cc: 'Behave' Subject: RE: [Ietf-behave] New draft on UDP unicast behavior Hi guys, Let's try to summarize the latest issues from the email exchange. REQ-3c: If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023. I assume that the proposal is to change it to something like "If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023 unless the original port was within that range, in which case the NAT MAY allocate the new port from within the 0-1023 range. More straightforward wording, with the same meaning, might be: 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. In that way this requirement doesn't talk about changing the source port; we can talk about that in another requirement. The rationale would be for applications such as rcp which bizarely use the source port for some weak authentication. RCP runs over TCP, so RCP isn't a good justification for this UDP-focused document. However, NFS and RPC run over UDP. A good cite is RFC2623, "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", notably section 2.1. While I don't really care, I am not terribly keen on this idea. Seems to me that it is extremely unlikely that rcp would work with any commercial NAT today as I have a hard time believing that NATs would preserve the well-known port range today. Any other views on this topic? Furthermore, such a behavior in a NAT allows any device behind the NAT to pretend to be the client that's authorized in the .rhosts file. This seems like an idea worse than normal r-services unless you trust any and all devices behind the NAT to be friendly. Oh, and you also need to trust that nobody else will get that NAT's IP address (which is one of the weaknesses of r-services authentication). To bring us back to UDP, though, NFS and RPC have a similar weakness. REQ-10: A NAT MUST have the capability to turn off individually all ALGs it supports, except for DNS and IPsec. This definitively needs tweaking. The question is do we make it more or less explicit. Do we say "A NAT MUST have the capability to turn off individually all ALGs it supports." (full stop). Or do we say "A NAT MUST have the capability to turn off individually all ALGs it supports unless there is a clear reason for not doing so described in an IETF RFC" (or something like that). Any views of which approach is best? I haven't seen any arguments for, or descriptions of, UDP ALGs that are necessary for a NAT to function. Without such arguments the text should recommend ALGs be turned off in the default configuration -- that is, the NAT shouldn't require the user go into a screen or enter a command to disable any ALG, but rather the user should have to _enable_ an ALG explicitly if the user needs an ALG for their application to work over the NAT. Once we begin tackling TCP in a separate document, we will undoubtably uncover a few needs for ALGs (FTP comes to mind). -d From ssenthil@cisco.com Wed, 20 Oct 2004 16:40:45 -0700 (PDT) From: Senthil Sivakumar Date: Wed, 20 Oct 2004 16:40:45 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <1ECE0EB50388174790F9694F77522CCFD4E8EB@zrc2hxm0.corp.norte l.com> Message-ID: <4.3.2.7.2.20041020163627.03308968@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain At 05:54 PM 10/20/2004 -0400, Francois Audet wrote: Hi guys, Let's try to summarize the latest issues from the email exchange. REQ-3c: If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023. I assume that the proposal is to change it to something like "If the NAT changes the source port, it MUST NOT allocate the new port from within the range of 0-1023 unless the original port was within that range, in which case the NAT MAY allocate the new port from within the 0-1023 range. The rationale would be for applications such as rcp which bizarely use the source port for some weak authentication. While I don't really care, I am not terribly keen on this idea. Seems to me that it is extremely unlikely that rcp would work with any commercial NAT today as I have a hard time believing that NATs would preserve the well-known port range today. There are NATs that do that today.. Any other views on this topic? REQ-10: A NAT MUST have the capability to turn off individually all ALGs it supports, except for DNS and IPsec. This definitively needs tweaking. The question is do we make it more or less explicit. Do we say "A NAT MUST have the capability to turn off individually all ALGs it supports." (full stop). Or do we say "A NAT MUST have the capability to turn off individually all ALGs it supports unless there is a clear reason for not doing so described in an IETF RFC" (or something like that). I would vote for the first one, I don't see any reason where NATs must have to support an ALG. Senthil Any views of which approach is best? From audet@nortelnetworks.com Wed, 20 Oct 2004 16:50:50 -0700 (PDT) From: "Francois Audet" Date: Wed, 20 Oct 2004 16:50:50 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior Message-ID: <1ECE0EB50388174790F9694F77522CCFD4E972@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New draft on UDP unicast behavior OK, I think we have concensus on the following. 11 - Requirements REQ-3c: 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-10: If a NAT includes ALGs, all of those ALGs MUST be disabled by default. REQ-10a: If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the user to enable or disable each ALG separately. 11.1 - Requirements discussion REQ-3c: Certain applications expect the source UDP port to be in the well-known range. See RFC 2623 for an example. REQ-10: NAT ALGs may interfere with UNSAF methods. REQ-10a: This requirement allows the user to enable ALGs which are necessary to aid operation of some applications without enabling ALGs which interfere with operation of other applications. From dwing@cisco.com Wed, 20 Oct 2004 17:02:32 -0700 (PDT) From: "Dan Wing" Date: Wed, 20 Oct 2004 17:02:32 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <1ECE0EB50388174790F9694F77522CCFD4E972@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New draft on UDP unicast behavior Looks good to me. -d
-----Original Message-----From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx]Sent: Wednesday, October 20, 2004 4:51 PMTo: 'Senthil Sivakumar'; 'Dan Wing'Cc: 'Behave'Subject: RE: [Ietf-behave] New draft on UDP unicast behavior OK, I think we have concensus on the following. 11 - Requirements REQ-3c: 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-10: If a NAT includes ALGs, all of those ALGs MUST be disabled by default. REQ-10a: If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the user to enable or disable each ALG separately. 11.1 - Requirements discussion REQ-3c: Certain applications expect the source UDP port to be in the well-known range. See RFC 2623 for an example. REQ-10: NAT ALGs may interfere with UNSAF methods. REQ-10a: This requirement allows the user to enable ALGs which are necessary to aid operation of some applications without enabling ALGs which interfere with operation of other applications. From kbiswas@cisco.com Wed, 20 Oct 2004 17:50:59 -0700 (PDT) From: Kaushik Biswas Date: Wed, 20 Oct 2004 17:50:59 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <1ECE0EB50388174790F9694F77522CCFD4E972@zrc2hxm0.corp.norte l.com> Message-ID: <4.3.2.7.2.20041020172354.02460a88@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain In addition, couple of points: (1) Why should hairpinning be a must: REQ-9: A NAT MUST support "Hairpinning" behavior. Hairpinning allows two endpoints on the internal side of the NAT to communicate even if they only use each other's external IP addresses and ports. This may be a nice-to-have support in a NAT, but why should it be a must. The inside host A should be trying to reach the inside host B, via the private-address and not via the NAT'd address of B. Why come through NAT and add an extra-hit in processing-time. (2) Also, why don't we mandate the RTP/RTCP port-allocation to be successive. For eg: if the request is for the embedded media-port = 20000, then NAT should allocate n-successive ports. If NAT is supporting port-preservation then 20000, 20001,..., should be allocated. If it is not supporting port-preservation then the next n-successive free ports in the range 1024 - 65535. Thanks, Kaushik At 07:50 PM 10/20/2004 -0400, Francois Audet wrote: OK, I think we have concensus on the following. 11 - Requirements REQ-3c: 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-10: If a NAT includes ALGs, all of those ALGs MUST be disabled by default. REQ-10a: If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the user to enable or disable each ALG separately. 11.1 - Requirements discussion REQ-3c: Certain applications expect the source UDP port to be in the well-known range. See RFC 2623 for an example. REQ-10: NAT ALGs may interfere with UNSAF methods. REQ-10a: This requirement allows the user to enable ALGs which are necessary to aid operation of some applications without enabling ALGs which interfere with operation of other applications. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From sg266@cornell.edu Wed, 20 Oct 2004 18:12:49 -0700 (PDT) From: Saikat Guha Date: Wed, 20 Oct 2004 18:12:49 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <4.3.2.7.2.20041020172354.02460a88@mira-sjcd-3.cisco.com> Message-ID: <1098321110.31935.19.camel@broomhilde.guha.cc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630132.multipart/signed" --Boundary..27398.1163630132.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2004-10-20 at 20:50, Kaushik Biswas wrote: > (1) Why should hairpinning be a must: > REQ-9: A NAT MUST support "Hairpinning" behavior. Hairpinning allows > two endpoints on the internal side of the NAT to communicate even if > they only use each other's external IP addresses and ports. > > This may be a nice-to-have support in a NAT, but why should it be a > must. > > The inside host A should be trying to reach the inside host B, via the > private-address and not via the NAT'd address of B. Why come through > NAT and add an extra-hit in processing-time. 1) Rendezvous services located upstream from the NAT cannot help A and B discover each other's private addresses. This is the case with online gaming networks, P2P networks etc. ICE tries to help by, in some sense, probing for rendezvous services inside the NAT'ed network but it does not solve all possible scenarios. 2) Consider the scenario with NATs N,M,O and hosts A, B +--- O ---- B global -- N --| internet +--- M ---- A A and B cannot communicate without hairpinning through N since their bindings at M/O cannot, in general, be determined. -- Saikat Guha https://www.guha.cc/~saikat Attachment: signature.asc --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="pgp00011.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00011.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi42IChHTlUv TGludXgpCgppRDhEQlFCQmR3elduRmx0cWk2OTEvb1JBalhaQUo5QWlncHVxT2cxQXZVVkhRaWxr TGRCbmZjZ2xRQ2ZWREZrCm5Wc0cvc3gzRUZoS1IxZElCK3k3MVBnPQo9MHhxUAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630132.multipart/signed-- From audet@nortelnetworks.com Wed, 20 Oct 2004 18:41:26 -0700 (PDT) From: "Francois Audet" Date: Wed, 20 Oct 2004 18:41:26 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior Message-ID: <1ECE0EB50388174790F9694F77522CCFD4E99C@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New draft on UDP unicast behavior I guess I was beaten to it... Thanks Saikat! Indeed, the reason we gave hairpinning a MUST is that it "fixes" problems that happen when applications don't use ICE. There are certainly other examples. Of course, doing ICE will ensure that you always have the optimum path. Your suggestion (2) is something that we discussed earlier, and decided against because there were too many cases where it didn't help and where it may break the deterministic behavior rule. Please see the archive: http://list.sipfoundry.org/archive/ietf-behave/maillist.html#00129 -----Original Message----- From: Kaushik Biswas [mailto:kbiswas@xxxxxxxxx] Sent: Wednesday, October 20, 2004 17:51 To: Audet, Francois [SC100:9T51:EXCH] Cc: 'Senthil Sivakumar'; 'Dan Wing'; 'Behave' Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In addition, couple of points: (1) Why should hairpinning be a must: REQ-9: A NAT MUST support "Hairpinning" behavior. Hairpinning allows two endpoints on the internal side of the NAT to communicate even if they only use each other's external IP addresses and ports. This may be a nice-to-have support in a NAT, but why should it be a must. The inside host A should be trying to reach the inside host B, via the private-address and not via the NAT'd address of B. Why come through NAT and add an extra-hit in processing-time. (2) Also, why don't we mandate the RTP/RTCP port-allocation to be successive. For eg: if the request is for the embedded media-port = 20000, then NAT should allocate n-successive ports. If NAT is supporting port-preservation then 20000, 20001,..., should be allocated. If it is not supporting port-preservation then the next n-successive free ports in the range 1024 - 65535. Thanks, Kaushik At 07:50 PM 10/20/2004 -0400, Francois Audet wrote: OK, I think we have concensus on the following. 11 - Requirements REQ-3c: 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-10: If a NAT includes ALGs, all of those ALGs MUST be disabled by default. REQ-10a: If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the user to enable or disable each ALG separately. 11.1 - Requirements discussion REQ-3c: Certain applications expect the source UDP port to be in the well-known range. See RFC 2623 for an example. REQ-10: NAT ALGs may interfere with UNSAF methods. REQ-10a: This requirement allows the user to enable ALGs which are necessary to aid operation of some applications without enabling ALGs which interfere with operation of other applications. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Wed, 20 Oct 2004 19:29:18 -0700 (PDT) From: "Dan Wing" Date: Wed, 20 Oct 2004 19:29:18 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <4.3.2.7.2.20041020172354.02460a88@mira-sjcd-3.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain
-----Original Message-----From: Kaushik Biswas [mailto:kbiswas@xxxxxxxxx]Sent: Wednesday, October 20, 2004 5:51 PMTo: Francois AudetCc: 'Senthil Sivakumar'; 'Dan Wing'; 'Behave'Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In addition, couple of points:(1) Why should hairpinning be a must:REQ-9: A NAT MUST support "Hairpinning" behavior. Hairpinning allows two endpoints on the internal side of the NAT to communicate even if they only use each other's external IP addresses and ports. This may be a nice-to-have support in a NAT, but why should it be a must.The inside host A should be trying to reach the inside host B, via the private-address and not via the NAT'd address of B. Why come through NAT and add an extra-hit in processing-time. Because it's not always possible for host A to learn host B's private address (that is, the address behind the NAT), because both A and B are using a server on the public side of the NAT to find each other. A good example are two people playing a realtime game, in the same house, with an Internet-based server -- unless the game's signaling protocol supports two hosts behind the same NAT finding each other, the game won't work. ICE provides this functionality for SIP, and of course the ideas in ICE could be used by other applications such as online games. But instead of requiring the applications have this extra overhead, it's easy for the NATs to simply handle hairpinning -- and in the last 2-3 years most NATs support hairpinning. So, to get such applications to work we either need all of the applications to do something akin to ICE (that is, signal both the private IP address and UDP port as well as the public IP address and UDP port), or we need NATs to handle hairpinning and the applications can continue advertising just the public IP address and UDP port. Obviously it's more _efficient_ for applications to not route packets through the NAT, but it's best to get things to work first and then optimize.
(2) Also, why don't we mandate the RTP/RTCP port-allocation to be successive. For eg: if the request is for the embedded media-port = 20000, then NAT should allocate n-successive ports. If NAT is supporting port-preservation then 20000, 20001,..., should be allocated. If it is not supporting port-preservation then the next n-successive free ports in the range 1024 - 65535. It's impossible for the NAT to determine if a UDP packet is an RTP packet and will wantthe associated port+1. Also, both RFC3550 (RTP) and draft-ietf-mmusic-anat-01.txt no longer require that RCTP=RTP+1 -- primarily to make it easier for RTP to traverse NATs. -d
Thanks,KaushikAt 07:50 PM 10/20/2004 -0400, Francois Audet wrote: OK, I think we have concensus on the following. 11 - Requirements REQ-3c: 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-10: If a NAT includes ALGs, all of those ALGs MUST be disabled by default. REQ-10a: If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the user to enable or disable each ALG separately. 11.1 - Requirements discussion REQ-3c: Certain applications expect the source UDP port to be in the well-known range. See RFC 2623 for an example. REQ-10: NAT ALGs may interfere with UNSAF methods. REQ-10a: This requirement allows the user to enable ALGs which are necessary to aid operation of some applications without enabling ALGs which interfere with operation of other applications. _______________________________________________Ietf-behave mailing listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Thu, 21 Oct 2004 10:28:30 -0700 (PDT) From: "Dan Wing" Date: Thu, 21 Oct 2004 10:28:30 -0700 (PDT) Subject: [Ietf-behave] draft-wing-behave-multicast Message-ID: MIME-Version: 1.0 Content-Type: text/plain draft-wing-behave-multicast, "IGMP Proxy Behavior" is now available at: http://www.ietf.org/internet-drafts/draft-wing-behave-multicast-00.txt -d From ml-behave@ringle.org Thu, 21 Oct 2004 11:04:18 -0700 (PDT) From: Jon Ringle Date: Thu, 21 Oct 2004 11:04:18 -0700 (PDT) Subject: [Ietf-behave] minimal STUN server Message-ID: <200410211404.15495.ml-behave@ringle.org> MIME-Version: 1.0 Content-Type: text/plain Hello, It seems to me that the algorithm that STUN uses to discover the NAT type is not as useful and brittle especially when behind a non-deterministic NAT. This sentiment seems to be reflected in draft-rosenberg-rfc3489bis-00. As such, it also seems to me that some of the requirements needed for a STUN server can be made optional. In particular, the requirement that a Bind response MUST have a CHANGED-ADDRESS attribute doesn't make sense when a STUN server will only be used for it's reflective property to learn about a NAT binding. Could I suggest that the Bind response MAY or SHOULD have a CHANGED-ADDRESS attribute. A STUN client that wishes to use a STUN server for the purpose of NAT type classification could use the presence or absence of the CHANGED-ADDRESS attribute in the Bind response to determine if this STUN server is capable of being used for NAT classification. This would reduce the resource requirements of a STUN server. It would also make ICE peer STUN server a compliant implementation. Jon From fluffy@cisco.com Sun, 24 Oct 2004 15:46:21 -0700 (PDT) From: Cullen Jennings Date: Sun, 24 Oct 2004 15:46:21 -0700 (PDT) Subject: [Ietf-behave] Re: [midcom] Results on draft-jennings-midcom-stun-results-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain This may just be broken in win stun - I'm not sure. WinStun does several test in parallel and that results in one of the test interfering with a later one. To avoid these interferences, it uses different ports for some of the test. I have not looked at it in a long time. More resent version of the command line version of this support using multiple IP address (on the client) - you need 3 ip address now to differentiate all the various types of NATs that have been encountered. Cullen PS - moved this thread to behave list ... On 9/4/04 7:47 PM, "Tony Yat-Tung Cheung" wrote: > Hi, > > Thanks. I also see that the discovery algorithm has be removed from > draft-rosenberg-rfc3489bis-00. So I think the discovery algorithm will > not be standardized in any time soon then. > > Still, I am interested in know the original algorithm in RFC 3489. I > found that the implementation of WinStun uses a certain source port to > send Test I, but a different source port to send Test II and Test III. > Other implementation uses the same port to send all STUN requests for > discovery. They each yield different result for the same NAT I have > tried them on. > > In my opinion, the STUN discovery should follow the application (such > as RTP) closely. > So I think all STUN requests should be sent from the same source port. > > Thank you. > > Best Regards, > Tony Yat-Tung Cheung > > On 5 Sep 04, at 2:47 AM, Christian Huitema wrote: > >> >>> I also have a question on the NAT discovery in RFC 3489. For the NAT >>> discovery procedure, should all STUN requests be sent from the same >>> source port? >> >> The main value of STUN is to unambiguously define the message formats >> used in the protocol, and the server responses to these messages. The >> discovery algorithm is, IMHO, less useful. >> >> The algorithm in RFC 3489 is based on a categorization of NAT that was >> state of the art three years ago. As our knowledge progresses, we may >> expect implementers to try better algorithms. As long as they don't >> change message formats and server behavior, this will not break >> interoperability. >> >> -- Christian Huitema > > > _______________________________________________ > midcom mailing list > midcom@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/midcom From fluffy@cisco.com Mon, 25 Oct 2004 06:07:37 -0700 (PDT) From: Cullen Jennings Date: Mon, 25 Oct 2004 06:07:37 -0700 (PDT) Subject: [Ietf-behave] multicast question Message-ID: MIME-Version: 1.0 Content-Type: text/plain If a NAT did nothing but take IGMP packets from inside and sent them to outside with no modification, and it took all traffic to a multicast address from the outside and forwarded it to inside interface with no modification, would it meet the requirements of this draft? Cullen From fluffy@cisco.com Mon, 25 Oct 2004 06:07:37 -0700 (PDT) From: Cullen Jennings Date: Mon, 25 Oct 2004 06:07:37 -0700 (PDT) Subject: [Ietf-behave] Few more NAT test results Message-ID: MIME-Version: 1.0 Content-Type: text/plain Until it shows up in the archives .... http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-midcom-stun- results-02.html I will move the name of this to behave at some point but, truth is, I missed the 00 deadline. From fluffy@cisco.com Mon, 25 Oct 2004 06:59:06 -0700 (PDT) From: Cullen Jennings Date: Mon, 25 Oct 2004 06:59:06 -0700 (PDT) Subject: Re: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <1ECE0EB50388174790F9694F77522CCFD4DB6A@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 10/18/04 7:57 PM, "Francois Audet" wrote: >> REQ-2b: A NAT MUST NOT have an "IP address pooling" behavior of >> "No". >> I could not figure out what the IP address pooling behavior of No is. >> Did you mean to say arbitrary ? > Correct. This is a typo. I will make the change. My apologies to Francois on this - he had already fixed this in a revision and I lost the change (and some others) in a merge. Cullen From fluffy@cisco.com Mon, 25 Oct 2004 06:59:07 -0700 (PDT) From: Cullen Jennings Date: Mon, 25 Oct 2004 06:59:07 -0700 (PDT) Subject: Re: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <4.3.2.7.2.20041020172354.02460a88@mira-sjcd-3.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 10/20/04 8:50 PM, "Kaushik Biswas" wrote: > > (2) Also, why don't we mandate the RTP/RTCP port-allocation to be successive. > For eg: if the request is for the embedded media-port = 20000, then NAT should > allocate n-successive ports. If NAT is supporting port-preservation then > 20000, 20001,..., should be allocated. We have talked about this a few times. No NATs today that I am aware of do this and it is only needed for RTP. The endpoints that do RTP are going to have to change anyways to do things like STUN and ICE to work with the behave compliant NATs. It seems very easy for them to also signal the RTCP port they are going to use. (It's well defined how to do this). I viewed it as far more likely that the RTP devices would bother to make the changes to signal RTCP ports that the likelihood that NAT vendors would do consecutive allocations. Cullen (with an individual contributor hat on) From fluffy@cisco.com Mon, 25 Oct 2004 06:59:07 -0700 (PDT) From: Cullen Jennings Date: Mon, 25 Oct 2004 06:59:07 -0700 (PDT) Subject: [Ietf-behave] ICMP Behavior Message-ID: MIME-Version: 1.0 Content-Type: text/plain What do we want the document about ICMP handling in NATs to say? From fluffy@cisco.com Mon, 25 Oct 2004 06:59:08 -0700 (PDT) From: Cullen Jennings Date: Mon, 25 Oct 2004 06:59:08 -0700 (PDT) Subject: [Ietf-behave] TCP behavior Message-ID: MIME-Version: 1.0 Content-Type: text/plain Ignoring the separate topic of how to make two devices both behind different NATs connect with a TCP connection, what do we want the TCP document to say about how NATs should behave? From fluffy@cisco.com Mon, 25 Oct 2004 06:59:08 -0700 (PDT) From: Cullen Jennings Date: Mon, 25 Oct 2004 06:59:08 -0700 (PDT) Subject: [Ietf-behave] Test programs for ICMP and TCP Message-ID: MIME-Version: 1.0 Content-Type: text/plain Is anyone interested in writing some program to test the ICMP and TCP behavior of NATs so we can collect data about how current systems work? Anyone familiar with what NATCHECK can do in this area? Open source would be nicer :-) Cullen From fluffy@cisco.com Mon, 25 Oct 2004 06:59:10 -0700 (PDT) From: Cullen Jennings Date: Mon, 25 Oct 2004 06:59:10 -0700 (PDT) Subject: [Ietf-behave] BEHAVE Status - October 25 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Here is a brief summary of where I see things - I'm using this to track the work so if you have things you wish someone would do, let me know. Of if you see some things on here that you might be able to do that would be even better. Work in progress * Using STUN for testing - Goal Mar 05 Not much happening on this. Rohan might do some work on this - no ETA Would be good to get some other volunteers on this one. * UDP Unicast Behavior - Goal May 05 Good work moving forward - Francois leading work See draft-ietf-behave-nat-00 * UDP Multicast Behavior - Goal May 05 Good work moving forward - Dan leading See draft-wing-behave-multicast-00 * Revisions to STUN - Goal Jul 05 Good work moving forward - Jonathan leading work See draft-ietf-behave-rfc3489bis-00 * TCP Behavior - Goal Sep 05 Some thought starting in this area. How to get TCP connections from between two machines both behind NATs? Would be nice to test more NATs and see how they perform today. Would be nice to get good explanation of existing NAT TCP state machines. Also need to figure out more mundane timers issues. * ICMP behavior - Goal Nov 05 Not too much happening here yet but some work. Nice to get test results of exiting NATs * Design Techniques - Goal Dec 05 Not much happening. Lots to start from. * NAT Test Results - Goal TBD Nice to get test results checking recommendations Nice to get TCP timeout test results Nice to get ICMP results Nice to get some multicast results Nice to see change from Jan 04 to Jan 05 Cullen has been doing some of this - I need help See draft-jennings-midcom-stun-results-02 New Drafts Since Last IETF draft-ietf-behave-nat-00 draft-ietf-behave-rfc3489bis-00 draft-wing-behave-multicast-00 draft-jennings-midcom-stun-results-02 Possible Topics for Agenda Time Any issues in UDP Unicast work Any issues in Multicast work Any issues in STUN bis Nail the source port range preservation topic TCP Issues other than P2P connection approaches TCP P2P connection approaches TODO Items Chairs - move the mailing list to IETF Chairs - figure out agenda for IETF 61 From dwing@cisco.com Mon, 25 Oct 2004 09:43:55 -0700 (PDT) From: "Dan Wing" Date: Mon, 25 Oct 2004 09:43:55 -0700 (PDT) Subject: [Ietf-behave] RE: multicast question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain > If a NAT did nothing but take IGMP packets from inside and sent them to > outside with no modification, The source IP address would be wrong, as it would be the RFC1918 address. Requirement 4.2 in the I-D states the outgoing packet must have the NAT's public IP address: 4.2 IGMP Packets Sent Towards WAN Interface The IGMP packets sent by the NAT MUST follow the requirements in RFC3376 section 4 [3], specificially the TTL MUST be 1, IP precedence MUST be Internetwork Control (Type of Service 0xc0), and it MUST carry the IP Router Alert option. The IGMP packets sent by the NAT towards the WAN MUST use the NAT's public IP address as the source IP address. > and it took all traffic to a multicast address > from the outside and forwarded it to inside interface with no > modification, That part is fine. The draft requires handling the multicast packets in that fashion. > would it meet the requirements of this draft? -d From baford@mit.edu Mon, 25 Oct 2004 12:12:10 -0700 (PDT) From: Bryan Ford Date: Mon, 25 Oct 2004 12:12:10 -0700 (PDT) Subject: Re: [Ietf-behave] Test programs for ICMP and TCP In-Reply-To: Message-ID: <200410251512.09863.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Monday 25 October 2004 09:58, Cullen Jennings wrote: > Is anyone interested in writing some program to test the ICMP and TCP > behavior of NATs so we can collect data about how current systems work? > Anyone familiar with what NATCHECK can do in this area? Open source would > be nicer :-) Are you referring to _my_ "NAT Check", or someone else's? (Is there another one?) Because mine _is_ open source - you can get all the code on its home page, http://midcom-p2p.sourceforge.net/. It certainly could use some more work, and anyone with time is welcome to work on it; I just haven't had time myself recently. Bryan > > Cullen > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From ThomasGal@LumenVox.com Mon, 25 Oct 2004 13:55:01 -0700 (PDT) From: "Thomas Gal" Date: Mon, 25 Oct 2004 13:55:01 -0700 (PDT) Subject: RE: [Ietf-behave] Test programs for ICMP and TCP In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB0263ABF1@svr-exc.domain.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain That could be interesting. I've just been following the list, but if someone were to deliniate what to send, and what to keep track of to quantify "behavior" if any beyond responds/norespond I wouldn't mind. I saw http://bgp.lcs.mit.edu/~dga/view.cgi but I'm not sure if that's the same kind of data that is pertinent to this group or we'd want more information since we're trying to quantify the behavior of a NAT in most all situations. -Tom thomasgal@xxxxxxxxxxxx > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Cullen Jennings > Sent: Monday, October 25, 2004 6:58 AM > To: Behave > Subject: [Ietf-behave] Test programs for ICMP and TCP > > > Is anyone interested in writing some program to test the ICMP > and TCP behavior of NATs so we can collect data about how > current systems work? > Anyone familiar with what NATCHECK can do in this area? Open > source would be nicer :-) > > Cullen > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From dwing@cisco.com Mon, 25 Oct 2004 14:05:17 -0700 (PDT) From: "Dan Wing" Date: Mon, 25 Oct 2004 14:05:17 -0700 (PDT) Subject: RE: [Ietf-behave] TCP behavior In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Off the top of my head: * preserve TCP options * don't require TCP keepalives to keep the connection option * don't reuse a TCP source port until at least TIME_WAIT seconds expire * use well-known source port range if source TCP connection was also in well-known range * consider draft-gont-* * consider draft-ietf-tcpm-tcpsecure * ICMP (both directions) * Path MTU Discovery (both directions) * fragmented TCP packets -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Cullen > Jennings > Sent: Monday, October 25, 2004 6:56 AM > To: Behave > Subject: [Ietf-behave] TCP behavior > > > > Ignoring the separate topic of how to make two devices both > behind different > NATs connect with a TCP connection, what do we want the TCP > document to say > about how NATs should behave? > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Mon, 25 Oct 2004 14:05:56 -0700 (PDT) From: "Dan Wing" Date: Mon, 25 Oct 2004 14:05:56 -0700 (PDT) Subject: RE: [Ietf-behave] ICMP Behavior In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain I'm not sure how we could separate ICMP handling from the handling of TCP, UDP, SCTP, IPsec, ...? -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Cullen > Jennings > Sent: Monday, October 25, 2004 6:56 AM > To: Behave > Subject: [Ietf-behave] ICMP Behavior > > > > What do we want the document about ICMP handling in NATs to say? > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From ssenthil@cisco.com Mon, 25 Oct 2004 14:24:55 -0700 (PDT) From: Senthil Sivakumar Date: Mon, 25 Oct 2004 14:24:55 -0700 (PDT) Subject: Re: [Ietf-behave] ICMP Behavior In-Reply-To: Message-ID: <4.3.2.7.2.20041025141701.02ec8a30@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain My suggestions would be to address the following: 1. ICMP identifier being used as identifiers for demux in pings. How should we handle them? Any different than TCP/UDP ports? 2. ICMP Error handling by NATs. Handling the embedded IP/TCP/UDP headers. 3. What ICMP errors MUST and SHOULD be handled by NATs? 4. Timer handling for ICMP. Whether to refresh the timer for the outside to inside echo req/replies? Senthil At 06:56 AM 10/25/2004 -0700, Cullen Jennings wrote: What do we want the document about ICMP handling in NATs to say? _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From sg266@cornell.edu Mon, 25 Oct 2004 15:18:06 -0700 (PDT) From: Saikat Guha Date: Mon, 25 Oct 2004 15:18:06 -0700 (PDT) Subject: Re: [Ietf-behave] Test programs for ICMP and TCP In-Reply-To: Message-ID: <1098742676.5558.15.camel@broomhilde.guha.cc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630132.multipart/signed" --Boundary..27398.1163630132.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2004-10-25 at 15:12, Bryan Ford wrote: > On Monday 25 October 2004 09:58, Cullen Jennings wrote: > > Is anyone interested in writing some program to test the ICMP and TCP > > behavior of NATs so we can collect data about how current systems work? > Is there another one? I am working on something along the same lines. http://www.cs.cornell.edu/~saikat/NATs.html (source is available on request). It tests for TCP behaviour when connection establishment differs from the 3-way handshake (i.e. symmetric open, icmp errors, etc). Preliminary results from 20 or so NATs are at http://www.cs.cornell.edu/~saikat/nat-behave.ps. The code/service will be part of a broader library implementing STUNT and NUTSS (http://www.cs.cornell.edu/~saikat/nutss.pdf) allowing tcp between two nat'ed hosts etc. -- Saikat Guha https://www.guha.cc/~saikat Attachment: signature.asc --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="pgp00012.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00012.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi42IChHTlUv TGludXgpCgppRDhEQlFCQmZYdVRuRmx0cWk2OTEvb1JBdUpXQUpzRVhneUFzeGxNd0lteDZPTE1Q NzBGcWlQVVFnQ2ZlR3BCCnRUTnQ1RkxtMXlWOUZxZHM0a2VQbDM0PQo9UmRjMwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630132.multipart/signed-- From kbiswas@cisco.com Mon, 25 Oct 2004 17:54:29 -0700 (PDT) From: Kaushik Biswas Date: Mon, 25 Oct 2004 17:54:29 -0700 (PDT) Subject: RE: [Ietf-behave] TCP behavior In-Reply-To: Message-ID: <4.3.2.7.2.20041025173452.0268b4f8@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain in addition: - make NAT entry-timers to fall-back to a lower value when RST/FIN-ACKs seen, - support TCP-segments handling. This is in addition to fragmentation support which Dan has already mentioned. An eg, using H323 : Packet 1: IP-hdr----TCP-hdr----TPKT-hdr1 + TPKT-data1 + TPKT-hdr2 Packet 2: IP-hdr-----TCP-hdr----TPKT-data2 Both these packet are not IP fragments, but if the TCP MSS is lower, then the payload carried in the TCP-data will be split into 2 packets (TCP-segments). NATs should be able to handle this. Thanks, Kaushik At 02:05 PM 10/25/2004 -0700, Dan Wing wrote: Off the top of my head: * preserve TCP options * don't require TCP keepalives to keep the connection option * don't reuse a TCP source port until at least TIME_WAIT seconds expire * use well-known source port range if source TCP connection was also in well-known range * consider draft-gont-* * consider draft-ietf-tcpm-tcpsecure * ICMP (both directions) * Path MTU Discovery (both directions) * fragmented TCP packets -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Cullen > Jennings > Sent: Monday, October 25, 2004 6:56 AM > To: Behave > Subject: [Ietf-behave] TCP behavior > > > > Ignoring the separate topic of how to make two devices both > behind different > NATs connect with a TCP connection, what do we want the TCP > document to say > about how NATs should behave? > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From kbiswas@cisco.com Mon, 25 Oct 2004 18:01:04 -0700 (PDT) From: Kaushik Biswas Date: Mon, 25 Oct 2004 18:01:04 -0700 (PDT) Subject: Re: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <4.3.2.7.2.20041020172354.02460a88@mira-sjcd-3.cisco.com> Message-ID: <4.3.2.7.2.20041025175445.02654008@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain At 06:39 AM 10/25/2004 -0700, Cullen Jennings wrote: On 10/20/04 8:50 PM, "Kaushik Biswas" wrote: > > (2) Also, why don't we mandate the RTP/RTCP port-allocation to be successive. > For eg: if the request is for the embedded media-port = 20000, then NAT should > allocate n-successive ports. If NAT is supporting port-preservation then > 20000, 20001,..., should be allocated. We have talked about this a few times. No NATs today that I am aware of do this Couple of NATs do this, and this is one of the overheads which NATs had to incur in packet-processing path so as to ensure that the allocated RTP/RTCP ports are consecutive. It would be a welcome change for NATs if this restriction is gone -- I mean the end-points not mandating these ports to be consecutive. Thanks, Kaushik and it is only needed for RTP. The endpoints that do RTP are going to have to change anyways to do things like STUN and ICE to work with the behave compliant NATs. It seems very easy for them to also signal the RTCP port they are going to use. (It's well defined how to do this). I viewed it as far more likely that the RTP devices would bother to make the changes to signal RTCP ports that the likelihood that NAT vendors would do consecutive allocations. Cullen (with an individual contributor hat on) From dwing@cisco.com Mon, 25 Oct 2004 23:31:07 -0700 (PDT) From: "Dan Wing" Date: Mon, 25 Oct 2004 23:31:07 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <4.3.2.7.2.20041025175445.02654008@mira-sjcd-3.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > Couple of NATs do this, and this is one of the overheads which > NATs had to > incur in packet-processing path so as to ensure that the > allocated RTP/RTCP > ports are consecutive. It would be a welcome change for NATs if this > restriction is gone -- I mean the end-points not mandating these ports to > be consecutive. BEHAVE needs a "how a UDP application can use a BEHAVE-capable NAT" document, which would provide guidance. For example, it could explain things such as: - use symmetric UDP behavior (for RTP applications, this would be draft-wing-mmusic-symmetric-rtprtcp-01). - use RFC3605 ("Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)") - keep NAT bindings alive by sending UDP messages from inside-to- outside - learn public NAT bindings using STUN - know when STUN isn't necessary (for example, many folks think STUN is necessary for SIP signaling itself, but STUN is for the media stream). - leak RTP and RTCP packets early (either RTP No-Op packets, silence packets, STUN packets to the peer, STUN packets to the STUN server) - when on hold or silence suppression, leak media to keep NAT binding open many of these apply to VoIP applications, but many also apply to any other application behind a BEHAVE NAT that wants to use UDP as its transport. I would like to see such a document added to the WG's agenda. -d From sandersr@corp.earthlink.net Tue, 26 Oct 2004 01:39:11 -0700 (PDT) From: Robert Sanders Date: Tue, 26 Oct 2004 01:39:11 -0700 (PDT) Subject: Re: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: Message-ID: <417E0D23.3050301@corp.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain Dan Wing wrote: BEHAVE needs a "how a UDP application can use a BEHAVE-capable NAT" document, which would provide guidance. If this usage differs from how the UDP application might use a non-BEHAVE-capable NAT, or from the scenarios described in draft-ietf-sipping-nat-scenarios et cetera, it would also be useful to show how an application might *detect* a well-BEHAVEd NAT. I know that NAT type detection has been deprecated in RFC3489bis, and that the problem of detection has become more complex than originally estimated. Requiring more than one internal IP address to fully disambiguate the behavior of "non-deterministic" NATs is problematic. So perhaps precise detection is not feasible in many cases. The question I have is whether the purpose of BEHAVE is to specify an ideal NAT's behavior and then to provide usage guidelines for applications working through a compliant set of NATs, or to recommend NAT behaviors that increase the efficiency or reliability of existing techniques. If it's the latter case then BEHAVE shouldn't need its own usage document. Any application which wishes to function through non well-BEHAVEd NATs, or through non-traditional NAT scenarios such as twice NAT, couldn't limit itself to techniques dependent upon BEHAVE compliance. regards, -- Robert From dwing@cisco.com Wed, 27 Oct 2004 17:58:24 -0700 (PDT) From: "Dan Wing" Date: Wed, 27 Oct 2004 17:58:24 -0700 (PDT) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <417E0D23.3050301@corp.earthlink.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > Dan Wing wrote: > > >BEHAVE needs a "how a UDP application can use a BEHAVE-capable NAT" > >document, which would provide guidance. > > If this usage differs from how the UDP application might use a > non-BEHAVE-capable NAT, or from the scenarios described in > draft-ietf-sipping-nat-scenarios et cetera, it would also be useful to > show how an application might *detect* a well-BEHAVEd NAT. draft-ietf-sipping-nat-scenarios discusses all the scenarios; a BEHAVE NAT isn't applicable to many of them. Perhaps all that's needed is an update to draft-ietf-sipping-nat-scenarios to describe which sections apply to BEHAVE NATs. > I know that NAT type detection has been deprecated in RFC3489bis, Right. > and > that the problem of detection has become more complex than originally > estimated. Requiring more than one internal IP address to fully > disambiguate the behavior of "non-deterministic" NATs is problematic. > So perhaps precise detection is not feasible in many cases. I agree. What's useful is for product datasheets on NATs to say "this is a BEHAVE-compliant NAT for UDP, multicast, and TCP", and for a SIP phone to say "works behind a BEHAVE-compliant UDP NAT", and for a multiplayer game to say "works behind a BEHAVE-compliant UDP and TCP NAT", for example. > The question I have is whether the purpose of BEHAVE is to specify an > ideal NAT's behavior and then to provide usage guidelines for > applications working through a compliant set of NATs, or to recommend > NAT behaviors that increase the efficiency or reliability of existing > techniques. If it's the latter case then BEHAVE shouldn't need its own > usage document. I'm not sure which case it is, honestly. For example, BEHAVE won't allow Symmetric NATs (as defined by RFC3489) because such NATs don't allow peer-to-peer UDP connectivity and require a media relay. I don't know the BEHAVE requirement which outlaws Symmetric NATs would be considered 'ideal behavior' or 'increased efficiency'. > Any application which wishes to function through non > well-BEHAVEd NATs, or through non-traditional NAT scenarios such as > twice NAT, couldn't limit itself to techniques dependent upon BEHAVE > compliance. -d From magnus.westerlund@ericsson.com Thu, 28 Oct 2004 07:27:17 -0700 (PDT) From: Magnus Westerlund Date: Thu, 28 Oct 2004 07:27:17 -0700 (PDT) Subject: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior description Message-ID: <418101C3.7030109@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, In Section 3.2, there is a talk about port parity preserving. - First I think the description on what is required by RTP is a bit unclear. I think it should be clarified that for RTP sessions that do not have explicit signalling of RTCP ports, the RTP ports needs to use an even port and RTCP the next port number, which is odd. Thus simple preserving the parity is not sufficient as this could result in RTP port: 2040 -> 4126 RTCP port: 2041 -> 4789 which would still not help the RTP based application to get working RTCP traffic. - I am lacking experience from deployed scenarios, do the parity preservation actually help? Also is there any other UDP user that benefit from this? I trying to understand if REQ-4 actually provide any benefit. However I do agree with the previous discussion that trying to do something smarter would be difficult and probably create worse problems. The main argument is that transmission of RTP and RTCP are not closely dependent, and the either could proceed the other with at least seconds, up to minutes or never in cases when a receiver do only later or not at all transmit RTP packets. Cheers Magnus Westerlund AVT Chair Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From audet@nortelnetworks.com Thu, 28 Oct 2004 09:52:19 -0700 (PDT) From: "Francois Audet" Date: Thu, 28 Oct 2004 09:52:19 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Message-ID: <1ECE0EB50388174790F9694F77522CCFE4440A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior description > Hi, > > In Section 3.2, there is a talk about port parity preserving. > > - First I think the description on what is required by RTP is a bit > unclear. I think it should be clarified that for RTP sessions that do > not have explicit signalling of RTCP ports, the RTP ports > needs to use > an even port and RTCP the next port number, which is odd. Thus simple > preserving the parity is not sufficient as this could result in RTP > port: 2040 -> 4126 RTCP port: 2041 -> 4789 which would still not help > the RTP based application to get working RTCP traffic. > > - I am lacking experience from deployed scenarios, do the parity > preservation actually help? Also is there any other UDP user that > benefit from this? I trying to understand if REQ-4 actually > provide any > benefit. Yeah, we did discuss this earlier. It's all on the archive. Basically we can't really do anything that will absolutely ensure that the port are contiguous in all cases, so there is no point in defining a rule that does not result in deterministic behavior. If an application is not smart enought to negotiate the RTP and RTCP separately, the worst case scenario is that RTCP won't go through which is not "good" but at least the call still works. The parity problem is slightly different. The reason is described in the archives. Basically, depending on how you read the RTP standard, you might end-up with applications adjusting the port number unilaterally to the parity it expects, which would be a problem. Perhaps we should explain the reasonning in the document in the next release. > However I do agree with the previous discussion that trying to do > something smarter would be difficult and probably create > worse problems. > The main argument is that transmission of RTP and RTCP are > not closely > dependent, and the either could proceed the other with at > least seconds, > up to minutes or never in cases when a receiver do only later > or not at > all transmit RTP packets. > > Cheers > > Magnus Westerlund > AVT Chair > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortelnetworks.com Thu, 28 Oct 2004 10:10:08 -0700 (PDT) From: "Francois Audet" Date: Thu, 28 Oct 2004 10:10:08 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Message-ID: <1ECE0EB50388174790F9694F77522CCFE4443C@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior description Actually, I checked in draft-ietf-behave-nat-00 and it does already explain the port parity problem I described below. See paragraph 6 of 3.2. There is no talk about port sequence preservation. There is no discussion about that in the document. Perhaps we need to have something along those lines: Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. These NATs do things like sequential assignment, port reservation and so forth. Sequential port assignment assumes that the application will open a binding for RTP first and then open a binding for RTCP. It is not practical to enforce this requirement on all applications. Furthermore, there is a glare problem if many applications (or endpoints) are trying to open binding simultaneously. Port reservation is also problematic since it is wasteful, especially considering that a NAT can not reliably distinguish between RTP over UDP and other UDP traffic that does not have a contiguity rule. For those reasons, it would be too complex to attempt to preserve the contiguity rule by suggesting specific NAT behavior, and it would certainly break the deterministic behavior rule. I'm not sure if we need to put a requirement REQ-4c for this because it seems to me to be more of an application rule instead ("An application shall not assume that port contiguity will be preserved") which is out of scope of this document. If we did, the rule would say something like "It is RECOMMENDED that a NAT does not attempt to preserve the RTCP=RTP+1 port contiguity rule". What do people think? > -----Original Message----- > From: Audet, Francois [SC100:9T51:EXCH] > Sent: Thursday, October 28, 2004 09:52 > To: 'Magnus Westerlund'; 'Behave WG' > Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP > behavior description > > > > > Hi, > > > > In Section 3.2, there is a talk about port parity preserving. > > > > - First I think the description on what is required by RTP is a bit > > unclear. I think it should be clarified that for RTP > sessions that do > > not have explicit signalling of RTCP ports, the RTP ports > > needs to use > > an even port and RTCP the next port number, which is odd. > Thus simple > > preserving the parity is not sufficient as this could result in RTP > > port: 2040 -> 4126 RTCP port: 2041 -> 4789 which would > still not help > > the RTP based application to get working RTCP traffic. > > > > - I am lacking experience from deployed scenarios, do the parity > > preservation actually help? Also is there any other UDP user that > > benefit from this? I trying to understand if REQ-4 actually > > provide any > > benefit. > > Yeah, we did discuss this earlier. It's all on the archive. > > Basically we can't really do anything that will absolutely > ensure that the port are contiguous in all cases, so there is > no point in defining a rule that does not result in > deterministic behavior. If an application is not smart enought to > negotiate the RTP and RTCP separately, the worst case > scenario is that RTCP won't go through which is not "good" > but at least the call still works. > > The parity problem is slightly different. The reason is > described in the archives. Basically, depending on how you > read the RTP standard, you might end-up with applications > adjusting the port number unilaterally to the parity it > expects, which would be a problem. > > Perhaps we should explain the reasonning in the document in > the next release. > > > > However I do agree with the previous discussion that trying to do > > something smarter would be difficult and probably create > > worse problems. > > The main argument is that transmission of RTP and RTCP are > > not closely > > dependent, and the either could proceed the other with at > > least seconds, > > up to minutes or never in cases when a receiver do only later > > or not at > > all transmit RTP packets. > > > > Cheers > > > > Magnus Westerlund > > AVT Chair > > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > From ssenthil@cisco.com Thu, 28 Oct 2004 10:30:19 -0700 (PDT) From: Senthil Sivakumar Date: Thu, 28 Oct 2004 10:30:19 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion In-Reply-To: <1ECE0EB50388174790F9694F77522CCFE4443C@zrc2hxm0.corp.norte l.com> Message-ID: <4.3.2.7.2.20041028102027.02dfc8a0@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain At 01:09 PM 10/28/2004 -0400, Francois Audet wrote: Actually, I checked in draft-ietf-behave-nat-00 and it does already explain the port parity problem I described below. See paragraph 6 of 3.2. There is no talk about port sequence preservation. There is no discussion about that in the document. Perhaps we need to have something along those lines: Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. These NATs do things like sequential assignment, port reservation and so forth. Sequential port assignment assumes that the application will open a binding for RTP first and then open a binding for RTCP. It is not practical to enforce this requirement on all applications. Furthermore, there is a glare problem if many applications (or endpoints) are trying to open binding simultaneously. Port reservation is also problematic since it is wasteful, especially considering that a NAT can not reliably distinguish between RTP over UDP and other UDP traffic that does not have a contiguity rule. Did you mean port reservation is wasteful because NATs would reserve some ports that is never used? If so, that is true but only until a timeout happens. That may not be a huge issue, IMO. Secondly, NAT is told (by an ALG) that it need to allocate two consecutive ports, so in that sense it is aware that some protocol requires consecutive ports. For those reasons, it would be too complex to attempt to preserve the contiguity rule by suggesting specific NAT behavior, and it would certainly break the deterministic behavior rule. I'm not sure if we need to put a requirement REQ-4c for this because it seems to me to be more of an application rule instead ("An application shall not assume that port contiguity will be preserved") which is out of scope of this document. If we did, the rule would say something like "It is RECOMMENDED that a NAT does not attempt to preserve the RTCP=RTP+1 port contiguity rule". Adding this recommendation would cause some applications not to work well behind NATs anymore. Maybe it should be an option where the NATs can work in both modes one is to preserve the ports and another one not needed to preserve, with the default being don't preserve. Senthil What do people think? > -----Original Message----- > From: Audet, Francois [SC100:9T51:EXCH] > Sent: Thursday, October 28, 2004 09:52 > To: 'Magnus Westerlund'; 'Behave WG' > Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP > behavior description > > > > > Hi, > > > > In Section 3.2, there is a talk about port parity preserving. > > > > - First I think the description on what is required by RTP is a bit > > unclear. I think it should be clarified that for RTP > sessions that do > > not have explicit signalling of RTCP ports, the RTP ports > > needs to use > > an even port and RTCP the next port number, which is odd. > Thus simple > > preserving the parity is not sufficient as this could result in RTP > > port: 2040 -> 4126 RTCP port: 2041 -> 4789 which would > still not help > > the RTP based application to get working RTCP traffic. > > > > - I am lacking experience from deployed scenarios, do the parity > > preservation actually help? Also is there any other UDP user that > > benefit from this? I trying to understand if REQ-4 actually > > provide any > > benefit. > > Yeah, we did discuss this earlier. It's all on the archive. > > Basically we can't really do anything that will absolutely > ensure that the port are contiguous in all cases, so there is > no point in defining a rule that does not result in > deterministic behavior. If an application is not smart enought to > negotiate the RTP and RTCP separately, the worst case > scenario is that RTCP won't go through which is not "good" > but at least the call still works. > > The parity problem is slightly different. The reason is > described in the archives. Basically, depending on how you > read the RTP standard, you might end-up with applications > adjusting the port number unilaterally to the parity it > expects, which would be a problem. > > Perhaps we should explain the reasonning in the document in > the next release. > > > > However I do agree with the previous discussion that trying to do > > something smarter would be difficult and probably create > > worse problems. > > The main argument is that transmission of RTP and RTCP are > > not closely > > dependent, and the either could proceed the other with at > > least seconds, > > up to minutes or never in cases when a receiver do only later > > or not at > > all transmit RTP packets. > > > > Cheers > > > > Magnus Westerlund > > AVT Chair > > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortelnetworks.com Thu, 28 Oct 2004 10:31:27 -0700 (PDT) From: "Francois Audet" Date: Thu, 28 Oct 2004 10:31:27 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Message-ID: <1ECE0EB50388174790F9694F77522CCFE44462@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior description > - I am lacking experience from deployed scenarios, do the parity > preservation actually help? Also is there any other UDP user that > benefit from this? I trying to understand if REQ-4 actually > provide any > benefit. To answer this particular point, "yes". I have seen SIP applications that interpreted the following paragraph from RFC 3550 as saying that they should uniterally adjust the value of the UDP portnegotiated in SIP/SDP to fit the parity rule: RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number. For applications that take a single port number as a parameter and derive the RTP and RTCP port pair from that number, if an odd number is supplied then the application SHOULD replace that number with the next lower (even) number to use as the base of the port pair. For applications in which the RTP and RTCP destination port numbers are specified via explicit, separate parameters (using a signaling protocol or other means), the application MAY disregard the restrictions that the port numbers be even/odd and consecutive although the use of an even/odd port pair is still encouraged. The RTP and RTCP port numbers MUST NOT be the same since RTP relies on the port numbers to demultiplex the RTP data and RTCP control streams. The parity rule is thus a very inexpensive way to deal with this particular problem. The port sequencing rule is much harder to fix. You really need the application itself to account for it, which will be done in another "application guidelines" document. From dwing@cisco.com Thu, 28 Oct 2004 12:17:40 -0700 (PDT) From: "Dan Wing" Date: Thu, 28 Oct 2004 12:17:40 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion In-Reply-To: <1ECE0EB50388174790F9694F77522CCFE44462@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > I have seen SIP applications that interpreted the following paragraph > from RFC 3550 as saying that they should uniterally adjust the value > of the UDP portnegotiated in SIP/SDP to fit the parity rule: > ... > For applications that take a single port number as a parameter and > derive the RTP and RTCP port pair from that number, if an odd number > is supplied then the application SHOULD replace that number with the > next lower (even) number to use as the base of the port pair. ... I would interpret it that way, too. I'm frankly surprised that RFC3550 says that, because it really means "if an even port is signaled, it's wrong and you should ignore that port and instead use the next-lower odd port". I guess it's good that there are exceptions all around the sentence, but it makes an implementation unnecessarily complex. The text in RFC3550 appears derived from this text in RFC1889, which states: ... For UDP and similar protocols, RTP uses an even port number and the corresponding RTCP stream uses the next higher (odd) port number. If an application is supplied with an odd number for use as the RTP port, it should replace this number with the next lower (even) number. ... and doesn't have exceptions around it. So RFC1889-compliant devices are what are causing the problem here (that is, devices which don't have separate signaling for the RTCP port [RFC3605]). > The parity rule is thus a very inexpensive way to deal with this > particular problem. I agree that additional text needs to be added to BEHAVE to explain why the parity rule is helpful with RTP. -d From ml-behave@ringle.org Thu, 28 Oct 2004 12:32:10 -0700 (PDT) From: Jon Ringle Date: Thu, 28 Oct 2004 12:32:10 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion In-Reply-To: Message-ID: <200410281532.07863.ml-behave@ringle.org> MIME-Version: 1.0 Content-Type: text/plain I seems to me that it would be better for legacy RFC1889 devices to change their behaviour so that there is a separately advertised RTCP port. Quite frankly, I fail to see what the motivation is behind having RTP and RTCP to have port parity and RTCP=RTP+1 constraints. If the signaling protocol advertises the RTP and RTCP independantly, why does RTP/RTCP need to have a port parity at all (other than for legacy compatability)? To me, this looks like an anti-pattern that shouldn't be encouraged by BEHAVE, and puts unnecessary processing and book keeping on the shoulders of a NAT device, just to accomodate a single application: RTP/RTCP. Are there any other protocols that practice this NAT unfriendly attribute? Jon On Thursday 28 October 2004 03:17 pm, Dan Wing wrote: > > I have seen SIP applications that interpreted the following paragraph > > from RFC 3550 as saying that they should uniterally adjust the value > > of the UDP portnegotiated in SIP/SDP to fit the parity rule: > > ... > > > For applications that take a single port number as a parameter and > > derive the RTP and RTCP port pair from that number, if an odd number > > is supplied then the application SHOULD replace that number with the > > next lower (even) number to use as the base of the port pair. > > ... > > I would interpret it that way, too. > > I'm frankly surprised that RFC3550 says that, because it really means > "if an even port is signaled, it's wrong and you should ignore that > port and instead use the next-lower odd port". I guess it's good that > there are exceptions all around the sentence, but it makes an > implementation unnecessarily complex. The text in RFC3550 appears derived > from this text in RFC1889, which states: > > ... > For UDP and similar protocols, RTP > uses an even port number and the corresponding RTCP stream uses the > next higher (odd) port number. If an application is supplied with an > odd number for use as the RTP port, it should replace this number > with the next lower (even) number. > ... > > and doesn't have exceptions around it. So RFC1889-compliant devices > are what are causing the problem here (that is, devices which don't > have separate signaling for the RTCP port [RFC3605]). > > > The parity rule is thus a very inexpensive way to deal with this > > particular problem. > > I agree that additional text needs to be added to BEHAVE to explain > why the parity rule is helpful with RTP. > > -d > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From magnus.westerlund@ericsson.com Fri, 29 Oct 2004 02:04:12 -0700 (PDT) From: Magnus Westerlund Date: Fri, 29 Oct 2004 02:04:12 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion In-Reply-To: <200410281532.07863.ml-behave@ringle.org> Message-ID: <41820753.9000007@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, I agree that explicit signalling of the RTCP port should be encouraged. However there is quite a large number of applications out there that do follow the even-odd rule and the RTCP signalling mechanism for SIP/SDP is quite new. There are also several other applications and their signalling protocol that do not yet support explicit RTCP port signalling. One of them is RTSP, where we are working on an update to resolve the issue, but it is not yet available. Based on the less fortunate formulation about replacing an odd port in RFC 3550, I think that recommending port parity is the right choice. At least it avoids that problem. However I would like to point out that failure of the RTCP should result in that many application should throttle down its own transmission. There is a requirement on congestion control for RTP that is not that well followed, and a very basic mechanism for not being totally ignorant of the network condition is to actually use RTCP. But I think the right future is explicit signalling and probably ICE. Cheers Magnus Jon Ringle wrote: I seems to me that it would be better for legacy RFC1889 devices to change their behaviour so that there is a separately advertised RTCP port. Quite frankly, I fail to see what the motivation is behind having RTP and RTCP to have port parity and RTCP=RTP+1 constraints. If the signaling protocol advertises the RTP and RTCP independantly, why does RTP/RTCP need to have a port parity at all (other than for legacy compatability)? To me, this looks like an anti-pattern that shouldn't be encouraged by BEHAVE, and puts unnecessary processing and book keeping on the shoulders of a NAT device, just to accomodate a single application: RTP/RTCP. Are there any other protocols that practice this NAT unfriendly attribute? Jon -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From ml-behave@ringle.org Fri, 29 Oct 2004 06:22:15 -0700 (PDT) From: Jon Ringle Date: Fri, 29 Oct 2004 06:22:15 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion In-Reply-To: <200410281532.07863.ml-behave@ringle.org> Message-ID: <200410290922.10704.ml-behave@ringle.org> MIME-Version: 1.0 Content-Type: text/plain By specifying that a BEHAVE-compliant NAT has a means to provide port parity and +1 reservation, then BEHAVE does NOT encourage a change by applications requiring such behaviour. Not only should there be a notion of BEHAVE-compliant NATs, but also BEHAVE-compliant applications. I don't think it's unreasonable to say that an application is not BEHAVE-compliant if it requires port parity/+1 reservation. Such an application would become BEHAVE-compliant once such restriction are removed by the application. I agree that ICE is providing a path that applications could follow to become BEHAVE-compliant. Jon On Friday 29 October 2004 05:03 am, Magnus Westerlund wrote: > Hi, > > I agree that explicit signalling of the RTCP port should be encouraged. > However there is quite a large number of applications out there that do > follow the even-odd rule and the RTCP signalling mechanism for SIP/SDP > is quite new. There are also several other applications and their > signalling protocol that do not yet support explicit RTCP port > signalling. One of them is RTSP, where we are working on an update to > resolve the issue, but it is not yet available. > > Based on the less fortunate formulation about replacing an odd port in > RFC 3550, I think that recommending port parity is the right choice. At > least it avoids that problem. > > However I would like to point out that failure of the RTCP should result > in that many application should throttle down its own transmission. > There is a requirement on congestion control for RTP that is not that > well followed, and a very basic mechanism for not being totally ignorant > of the network condition is to actually use RTCP. But I think the right > future is explicit signalling and probably ICE. > > Cheers > > Magnus > > Jon Ringle wrote: > > I seems to me that it would be better for legacy RFC1889 devices to > > change their behaviour so that there is a separately advertised RTCP > > port. Quite frankly, I fail to see what the motivation is behind having > > RTP and RTCP to have port parity and RTCP=RTP+1 constraints. If the > > signaling protocol advertises the RTP and RTCP independantly, why does > > RTP/RTCP need to have a port parity at all (other than for legacy > > compatability)? To me, this looks like an anti-pattern that shouldn't be > > encouraged by BEHAVE, and puts unnecessary processing and book keeping on > > the shoulders of a NAT device, just to accomodate a single application: > > RTP/RTCP. Are there any other protocols that practice this NAT unfriendly > > attribute? > > > > Jon From mshore@cisco.com Fri, 29 Oct 2004 06:35:44 -0700 (PDT) From: Melinda Shore Date: Fri, 29 Oct 2004 06:35:44 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion In-Reply-To: <200410290922.10704.ml-behave@ringle.org> Message-ID: <5A6BF042-29AF-11D9-BDC6-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Friday, October 29, 2004, at 09:22 AM, Jon Ringle wrote: Not only should there be a notion of BEHAVE-compliant NATs, but also BEHAVE-compliant applications. I don't think it's unreasonable to say that an application is not BEHAVE-compliant if it requires port parity/+1 reservation. Such an application would become BEHAVE-compliant once such restriction are removed by the application. If we could go back and change every protocol that has NAT problems, it would probably make more sense to change them so that they have no NAT problems rather than having a different set of NAT problems. My sense is that the working group is focused on defining a set of friendlier NAT behaviors and that defining new, desirable application behavior is quite, quite, quite far out-of-scope. However, it seems reasonable to me to describe the limitations of the behaviors defined by the working group, and this might be an example. Melinda From magnus.westerlund@ericsson.com Fri, 29 Oct 2004 08:19:15 -0700 (PDT) From: Magnus Westerlund Date: Fri, 29 Oct 2004 08:19:15 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion In-Reply-To: <200410290922.10704.ml-behave@ringle.org> Message-ID: <41825F71.30008@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi Jon, Jon Ringle wrote: By specifying that a BEHAVE-compliant NAT has a means to provide port parity and +1 reservation, then BEHAVE does NOT encourage a change by applications requiring such behaviour. I will clarify that I don't think it will be good, even to try, to put a requirement that RTP and RTCP is kept together. That is to complex and to brittle to work. However to avoid any clients from failing into the pitfall of renumbering their RTP port number to an even number, I think that preserving port parity makes sense. However, port parity is NOT enough to make RTP work over a BEHAVE-compliant NAT. An application will be required to have further traversal mechanisms. Thus, any application will need to adopt a explicit RTCP port signalling rule. Removing the port parity rule, will only result in that NATs break even more sessions. If there is very little cost associated with the requirement I don't see a reason, why one can avoid having these failing. There will be sufficient amount of sessions failing anyway that transition to applications with traversal capacity will be used. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From audet@nortelnetworks.com Fri, 29 Oct 2004 09:51:28 -0700 (PDT) From: "Francois Audet" Date: Fri, 29 Oct 2004 09:51:28 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Message-ID: <1ECE0EB50388174790F9694F77522CCFE44AE9@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Ok, it seems to me that we are all completely in agreement. How about adding the following text right after the paragraph on port parity in section 3.2 (this is a slighly modified version of what I proposed earlier this week): Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. These NATs do things like sequential assignment, port reservation and so forth. Sequential port assignment assumes that the application will open a binding for RTP first and then open a binding for RTCP. It is not practical to enforce this requirement on all applications. Furthermore, there is a glare problem if many applications (or endpoints) are trying to open binding simultaneously. Port reservation is also problematic since it is wasteful, especially considering that a NAT can not reliably distinguish between RTP over UDP and other UDP packets where there is no contiguity rule. For those reasons, it would be too complex to attempt to preserve the contiguity rule by suggesting specific NAT behavior, and it would certainly break the deterministic behavior rule. In order to support both RTP and RTCP, it will therefore be necessary that applications follows rules to negotiate both RTP and RTCP separately, and account for the very real possibility that the RTCP=RTP+1 rule will be broken. As this is an application requirement, it is outside of the scope of this document to discuss it further. Is this good? Any suggested improvements? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Magnus Westerlund > Sent: Friday, October 29, 2004 08:19 > To: ml-behave@xxxxxxxxxx > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP > behavior descript ion > > > Hi Jon, > > Jon Ringle wrote: > > > By specifying that a BEHAVE-compliant NAT has a means to > provide port > > parity > > and +1 reservation, then BEHAVE does NOT encourage a change > by applications > > requiring such behaviour. > > I will clarify that I don't think it will be good, even to > try, to put a > requirement that RTP and RTCP is kept together. That is to > complex and > to brittle to work. However to avoid any clients from failing > into the > pitfall of renumbering their RTP port number to an even > number, I think > that preserving port parity makes sense. However, port parity is NOT > enough to make RTP work over a BEHAVE-compliant NAT. An > application will > be required to have further traversal mechanisms. Thus, any > application > will need to adopt a explicit RTCP port signalling rule. > > Removing the port parity rule, will only result in that NATs > break even > more sessions. If there is very little cost associated with the > requirement I don't see a reason, why one can avoid having these > failing. There will be sufficient amount of sessions failing > anyway that > transition to applications with traversal capacity will be used. > > Best Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@xxxxxxxxxxxx > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From mshore@cisco.com Fri, 29 Oct 2004 10:11:51 -0700 (PDT) From: Melinda Shore Date: Fri, 29 Oct 2004 10:11:51 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion In-Reply-To: <1ECE0EB50388174790F9694F77522CCFE44AE9@zrc2hxm0.corp.nortel.com> Message-ID: <8C64FFE4-29CD-11D9-BDC6-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Friday, October 29, 2004, at 12:51 PM, Francois Audet wrote: Is this good? Any suggested improvements? Works for me. Melinda From ml-behave@ringle.org Fri, 29 Oct 2004 10:23:12 -0700 (PDT) From: Jon Ringle Date: Fri, 29 Oct 2004 10:23:12 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion In-Reply-To: <1ECE0EB50388174790F9694F77522CCFE44AE9@zrc2hxm0.corp.nortel.com> Message-ID: <200410291323.10018.ml-behave@ringle.org> MIME-Version: 1.0 Content-Type: text/plain On Friday 29 October 2004 12:51 pm, Francois Audet wrote: > Is this good? Any suggested improvements? I think this text is good. I'd just like to point out that as soon as an application negotiates RTP and RTCP independantly, there is no technical requirement by that application to maintain port parity. But since maintaining port parity by a NAT shouldn't be difficult, I see no problem in keeping that. Having the +1 reservation requirement is frought with potential problems, as you've pointed out and race conditions. Jon From baford@mit.edu Fri, 29 Oct 2004 10:30:10 -0700 (PDT) From: Bryan Ford Date: Fri, 29 Oct 2004 10:30:10 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion In-Reply-To: <5A6BF042-29AF-11D9-BDC6-000A95E35274@cisco.com> Message-ID: <200410291330.09453.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Friday 29 October 2004 09:35, Melinda Shore wrote: > On Friday, October 29, 2004, at 09:22 AM, Jon Ringle wrote: > > Not only should there be a notion of BEHAVE-compliant NATs, but also > > BEHAVE-compliant applications. I don't think it's unreasonable to say > > that an > > application is not BEHAVE-compliant if it requires port parity/+1 > > reservation. Such an application would become BEHAVE-compliant once > > such > > restriction are removed by the application. > > If we could go back and change every protocol that has NAT problems, > it would probably make more sense to change them so that they have > no NAT problems rather than having a different set of NAT problems. > My sense is that the working group is focused on defining a set > of friendlier NAT behaviors and that defining new, desirable application > behavior is quite, quite, quite far out-of-scope. It does not seem at all out of scope to me that the BEHAVE group should define a set of design guidelines for new or updated applications that will ensure that they work robustly and deterministically over BEHAVE-compliant NATs. If this information is only available encoded in a form oriented entirely toward NAT implementors, then application protocol designers are much less likely to read it or to understand how to make their applications work robustly over NATs. This group needs to address both sides of the equation in order to solve the overall problem it was formed to solve. Bryan From audet@nortelnetworks.com Fri, 29 Oct 2004 11:51:15 -0700 (PDT) From: "Francois Audet" Date: Fri, 29 Oct 2004 11:51:15 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Message-ID: <1ECE0EB50388174790F9694F77522CCFE44BDB@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Agreed. When we do the "application requirement" document, we should explain this further. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jon Ringle > Sent: Friday, October 29, 2004 10:23 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP > behavior descript ion > > > On Friday 29 October 2004 12:51 pm, Francois Audet wrote: > > Is this good? Any suggested improvements? > > I think this text is good. I'd just like to point out that as > soon as an > application negotiates RTP and RTCP independantly, there is > no technical > requirement by that application to maintain port parity. But since > maintaining port parity by a NAT shouldn't be difficult, I > see no problem in > keeping that. > > Having the +1 reservation requirement is frought with > potential problems, as > you've pointed out and race conditions. > > Jon > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortelnetworks.com Fri, 29 Oct 2004 11:52:33 -0700 (PDT) From: "Francois Audet" Date: Fri, 29 Oct 2004 11:52:33 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Message-ID: <1ECE0EB50388174790F9694F77522CCFE44BE2@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Hi Bryan, It's out of scope of THIS document. It's in the scope of the Application Document which we will tackle next. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Bryan Ford > Sent: Friday, October 29, 2004 10:30 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP > behavior descript ion > > > On Friday 29 October 2004 09:35, Melinda Shore wrote: > > On Friday, October 29, 2004, at 09:22 AM, Jon Ringle wrote: > > > Not only should there be a notion of BEHAVE-compliant > NATs, but also > > > BEHAVE-compliant applications. I don't think it's unreasonable to > > > say that an application is not BEHAVE-compliant if it > requires port > > > parity/+1 reservation. Such an application would become > > > BEHAVE-compliant once such > > > restriction are removed by the application. > > > > If we could go back and change every protocol that has NAT > problems, > > it would probably make more sense to change them so that > they have no > > NAT problems rather than having a different set of NAT problems. My > > sense is that the working group is focused on defining a set of > > friendlier NAT behaviors and that defining new, desirable > application > > behavior is quite, quite, quite far out-of-scope. > > It does not seem at all out of scope to me that the BEHAVE > group should define > a set of design guidelines for new or updated applications > that will ensure > that they work robustly and deterministically over > BEHAVE-compliant NATs. If > this information is only available encoded in a form oriented > entirely toward > NAT implementors, then application protocol designers are > much less likely to > read it or to understand how to make their applications work > robustly over > NATs. This group needs to address both sides of the equation > in order to > solve the overall problem it was formed to solve. > > Bryan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortelnetworks.com Mon, 1 Nov 2004 08:40:42 -0800 (PST) From: "Francois Audet" Date: Mon, 1 Nov 2004 08:40:42 -0800 (PST) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Message-ID: <1ECE0EB50388174790F9694F77522CCFEADB89@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion The problem is that the "correction" in RFC 3550 (which supercedes RFC 1889) failed to fix the problem. Therefore there is still an issue with RTP/RTCP. RTP/RTCP is also very widespread and many of the applications that use it assume that the rule is true. The parity rule in the NAT does not add undue complexity to a NAT. It is quite trivial. We've already decided against the RTCP=RTP+1 rule because that was too complex for a NAT. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jon Ringle > Sent: Thursday, October 28, 2004 12:32 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP > behavior descript ion > > > I seems to me that it would be better for legacy RFC1889 > devices to change > their behaviour so that there is a separately advertised RTCP > port. Quite > frankly, I fail to see what the motivation is behind having > RTP and RTCP to > have port parity and RTCP=RTP+1 constraints. If the signaling > protocol > advertises the RTP and RTCP independantly, why does RTP/RTCP > need to have a > port parity at all (other than for legacy compatability)? To > me, this looks > like an anti-pattern that shouldn't be encouraged by BEHAVE, and puts > unnecessary processing and book keeping on the shoulders of a > NAT device, > just to accomodate a single application: RTP/RTCP. Are there > any other > protocols that practice this NAT unfriendly attribute? > > Jon > > On Thursday 28 October 2004 03:17 pm, Dan Wing wrote: > > > I have seen SIP applications that interpreted the following > > > paragraph from RFC 3550 as saying that they should > uniterally adjust > > > the value of the UDP portnegotiated in SIP/SDP to fit the parity > > > rule: > > > > ... > > > > > For applications that take a single port number as a > parameter and > > > derive the RTP and RTCP port pair from that number, if > an odd number > > > is supplied then the application SHOULD replace that > number with the > > > next lower (even) number to use as the base of the port pair. > > > > ... > > > > I would interpret it that way, too. > > > > I'm frankly surprised that RFC3550 says that, because it > really means > > "if an even port is signaled, it's wrong and you should ignore that > > port and instead use the next-lower odd port". I guess > it's good that > > there are exceptions all around the sentence, but it makes an > > implementation unnecessarily complex. The text in RFC3550 appears > > derived from this text in RFC1889, which states: > > > > ... > > For UDP and similar protocols, RTP > > uses an even port number and the corresponding RTCP > stream uses the > > next higher (odd) port number. If an application is > supplied with an > > odd number for use as the RTP port, it should replace this number > > with the next lower (even) number. > > ... > > > > and doesn't have exceptions around it. So > RFC1889-compliant devices > > are what are causing the problem here (that is, devices which don't > > have separate signaling for the RTCP port [RFC3605]). > > > > > The parity rule is thus a very inexpensive way to deal with this > > > particular problem. > > > > I agree that additional text needs to be added to BEHAVE to explain > > why the parity rule is helpful with RTP. > > > > -d > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From fluffy@cisco.com Mon, 1 Nov 2004 16:20:29 -0800 (PST) From: Cullen Jennings Date: Mon, 1 Nov 2004 16:20:29 -0800 (PST) Subject: [Ietf-behave] Draft Agenda for BEHAVE Message-ID: MIME-Version: 1.0 Content-Type: text/plain Behavior Engineering for Hindrance Avoidance WG (behave) TUESDAY, November 9, 2004, 1415-1515 ======================================================== CHAIRS: Jiri Kuthan Cullen Jennings AGENDA: (Last revised Nov. 1) 1. Agenda Bashing, Bluesheets, Note-takers 5 min 2. WG status update Chairs 5 min draft-ietf-behave-rfc3489bis-00 3. UDP Unicast Behavior Francois AUDET 15 min draft-ietf-behave-nat-00 4. UDP Multicast Behavior Dan Wing 10 min draft-wing-behave-multicast-00 5. TCP Behavior Nagendra 10 min 6. Open Issues Jiri Kuthan 10 min 7. Other Topics TBD 0 min 8. Next steps Chairs 5 min From spencer@mcsr-labs.org Tue, 2 Nov 2004 05:25:14 -0800 (PST) From: "Spencer Dawkins" Date: Tue, 2 Nov 2004 05:25:14 -0800 (PST) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion In-Reply-To: <1ECE0EB50388174790F9694F77522CCFE44BE2@zrc2hxm0.corp.nortel.com> Message-ID: <041801c4c0df$7bb00630$0200a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion I am confused. This may not be news, but ... Looking at the current charter for Behave, the closest thing to "the Application Document" that I see a milestone for is Dec 05 Produce a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches Is this the same thing (doesn't sound like it to me), or is "the Application Document which we will tackle next" out of scope for the existing charter? The document being discussed below sounds more like "a BCP that discusses application protocol design techniques for avoiding issues with NAT traversal" - ALSO a worthy goal, just a different one. Spencer
----- Original Message -----
From: Francois Audet To: 'Bryan Ford' ; 'ietf-behave@xxxxxxxxxxxxxxxxxxx' Sent: Friday, October 29, 2004 12:52 PM Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Hi Bryan, It's out of scope of THIS document. It's in the scope of the Application Document which we will tackle next. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Bryan Ford > Sent: Friday, October 29, 2004 10:30 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP > behavior descript ion > > > On Friday 29 October 2004 09:35, Melinda Shore wrote: > > On Friday, October 29, 2004, at 09:22 AM, Jon Ringle wrote: > > > Not only should there be a notion of BEHAVE-compliant > NATs, but also > > > BEHAVE-compliant applications. I don't think it's unreasonable to > > > say that an application is not BEHAVE-compliant if it > requires port > > > parity/+1 reservation. Such an application would become > > > BEHAVE-compliant once such > > > restriction are removed by the application. > > > > If we could go back and change every protocol that has NAT > problems, > > it would probably make more sense to change them so that > they have no > > NAT problems rather than having a different set of NAT problems. My > > sense is that the working group is focused on defining a set of > > friendlier NAT behaviors and that defining new, desirable > application > > behavior is quite, quite, quite far out-of-scope. > > It does not seem at all out of scope to me that the BEHAVE > group should define > a set of design guidelines for new or updated applications > that will ensure > that they work robustly and deterministically over > BEHAVE-compliant NATs. If > this information is only available encoded in a form oriented > entirely toward > NAT implementors, then application protocol designers are > much less likely to > read it or to understand how to make their applications work > robustly over > NATs. This group needs to address both sides of the equation > in order to > solve the overall problem it was formed to solve. > > Bryan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________Ietf-behave mailing listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortelnetworks.com Tue, 2 Nov 2004 08:21:57 -0800 (PST) From: "Francois Audet" Date: Tue, 2 Nov 2004 08:21:57 -0800 (PST) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Message-ID: <1ECE0EB50388174790F9694F77522CCFEAE1F6@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message Yes, this document (Dec 05) is the one what should describe things like "Don't expect RTP to be necessary even, and RTCP to be necessary odd, and that RTCP=RTP+1, and negotiate them separately both for IP address and port".
-----Original Message-----From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Spencer DawkinsSent: Tuesday, November 02, 2004 05:25To: ietf-behave@xxxxxxxxxxxxxxxxxxxSubject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion I am confused. This may not be news, but ... Looking at the current charter for Behave, the closest thing to "the Application Document" that I see a milestone for is Dec 05 Produce a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches Is this the same thing (doesn't sound like it to me), or is "the Application Document which we will tackle next" out of scope for the existing charter? The document being discussed below sounds more like "a BCP that discusses application protocol design techniques for avoiding issues with NAT traversal" - ALSO a worthy goal, just a different one. Spencer
----- Original Message -----
From: Francois Audet To: 'Bryan Ford' ; 'ietf-behave@xxxxxxxxxxxxxxxxxxx' Sent: Friday, October 29, 2004 12:52 PM Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion Hi Bryan, It's out of scope of THIS document. It's in the scope of the Application Document which we will tackle next. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Bryan Ford > Sent: Friday, October 29, 2004 10:30 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP > behavior descript ion > > > On Friday 29 October 2004 09:35, Melinda Shore wrote: > > On Friday, October 29, 2004, at 09:22 AM, Jon Ringle wrote: > > > Not only should there be a notion of BEHAVE-compliant > NATs, but also > > > BEHAVE-compliant applications. I don't think it's unreasonable to > > > say that an application is not BEHAVE-compliant if it > requires port > > > parity/+1 reservation. Such an application would become > > > BEHAVE-compliant once such > > > restriction are removed by the application. > > > > If we could go back and change every protocol that has NAT > problems, > > it would probably make more sense to change them so that > they have no > > NAT problems rather than having a different set of NAT problems. My > > sense is that the working group is focused on defining a set of > > friendlier NAT behaviors and that defining new, desirable > application > > behavior is quite, quite, quite far out-of-scope. > > It does not seem at all out of scope to me that the BEHAVE > group should define > a set of design guidelines for new or updated applications > that will ensure > that they work robustly and deterministically over > BEHAVE-compliant NATs. If > this information is only available encoded in a form oriented > entirely toward > NAT implementors, then application protocol designers are > much less likely to > read it or to understand how to make their applications work > robustly over > NATs. This group needs to address both sides of the equation > in order to > solve the overall problem it was formed to solve. > > Bryan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________Ietf-behave mailing listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave From spencer@mcsr-labs.org Sat, 6 Nov 2004 19:06:21 -0800 (PST) From: "Spencer Dawkins" Date: Sat, 6 Nov 2004 19:06:21 -0800 (PST) Subject: [Ietf-behave] Agenda item background? Message-ID: <00a801c4c476$d49de880$4f57430a@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain Is there any suggested reading for these items on the agenda? 5. TCP Behavior Nagendra 10 min 6. Open Issues Jiri Kuthan 10 min Thanks! Spencer From baford@mit.edu Sun, 7 Nov 2004 09:53:19 -0800 (PST) From: Bryan Ford Date: Sun, 7 Nov 2004 09:53:19 -0800 (PST) Subject: Re: [Ietf-behave] Agenda item background? In-Reply-To: <00a801c4c476$d49de880$4f57430a@DFNJGL21> Message-ID: <200411071253.18062.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Saturday 06 November 2004 22:06, Spencer Dawkins wrote: > Is there any suggested reading for these items on the agenda? > > 5. TCP Behavior Nagendra 10 min > > 6. Open Issues Jiri Kuthan 10 min I won't be able to be there myself, but mind if I suggest the following paper anyway? It's based on my previous Internet-Draft work with Pyda Srisuresh and Dan Kegel, but heavily revised recently to include discussion of TCP, along with a summary of preliminary results gathered using NAT Check: Peer-to-Peer Communication Across Network Address Translators, Bryan Ford, Pyda Srisuresh, and Dan Kegel, November 7, 2004. PDF: http://www.brynosaurus.com/pub/os/nat.pdf PS: http://www.brynosaurus.com/pub/os/nat.ps.gz Cheers, Bryan From fluffy@cisco.com Sun, 7 Nov 2004 21:19:40 -0800 (PST) From: Cullen Jennings Date: Sun, 7 Nov 2004 21:19:40 -0800 (PST) Subject: Re: [Ietf-behave] Agenda item background? In-Reply-To: <00a801c4c476$d49de880$4f57430a@DFNJGL21> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Good question - sorry for not having this on the agenda sooner. On 11/6/04 7:06 PM, "Spencer Dawkins" wrote: > Is there any suggested reading for these items on the agenda? > > 5. TCP Behavior Nagendra 10 min This discussion was only going to talk about the various options that have been discussed in email on the list. I think the idea was very early working group direction on what paths to pursue of the various ideas that are floating around. > > 6. Open Issues Jiri Kuthan 10 min This would only be dealing with trying to close off open issues for the documents that are in items 1-4 in the agenda. > > Thanks! > > Spencer > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From casner@acm.org Mon, 8 Nov 2004 14:09:06 -0800 (PST) From: Stephen Casner Date: Mon, 8 Nov 2004 14:09:06 -0800 (PST) Subject: [Ietf-behave] RTP in draft-ietf-behave-nat-00 Message-ID: <20041108124517.K54037@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: text/plain draft-ietf-behave-nat-00 contains the following statement: There is some very unfortunate wording in RFC 3550 section 11, which can cause some problematic behavior in RTP clients. The wording could be interpreted as saying that if a client receives an odd port for sending RTP, it SHOULD change it to the next lower even number. This would obviously result in the loss of RTP/UDP. The actual text in RFC3550 is: For applications that take a single port number as a parameter and derive the RTP and RTCP port pair from that number, if an odd number is supplied then the application SHOULD replace that number with the next lower (even) number to use as the base of the port pair. For applications in which the RTP and RTCP destination port numbers are specified via explicit, separate parameters (using a signaling protocol or other means), the application MAY disregard the restrictions that the port numbers be even/odd and consecutive although the use of an even/odd port pair is still encouraged. The key here is that when a session description specifies only one port number to convey the RTP+RTCP port pair, then the recipient of that description needs to know how to determine the second port number from the first. It is critical that the sender and receiver (or receivers plural for multicast) do this the same way. Since the convention is to use an even port for RTP and an odd port for RTCP, the spec says that when the given port number is odd, the RTP SHOULD be the next lower (even) number, and the odd number SHOULD be the RTCP port. However, because of requirements imposed by NATs and other considerations, the second sentence in the above quote from RFC3550 was added. All the applications need to do is explicitly state the two port numbers, and then there is no restriction on the even/odd condition of the RTP port number. If your concern is that applications that do not implement RTCP will only have one number to specify, then I have four responses: - If the application uses SDP to specify the session and gives only one address, this still implies that RTCP will be sent, so the RTCP port needs to be inferred from the single port that is given. In this case, I claim it makes sense for the stated rules to apply. - If you need to be able to use an odd RTP port number in sessions specified with SDP, then specify another port for RTCP but don't use it. I believe it would be acceptable for that other port number to be zero. - If the application will specify its session some other way, and intends to specify only a single port with the implicatin that RTCP will not be sent, then the specification of that session description method can specify that the SHOULD above be overridden. - Designing out RTCP is bad. draft-ietf-behave-nat-00 also contains the following statement: NATs that use an "IP address pooling" behavior of "arbitrary" can cause issues for applications that use multiple ports from the same endpoint but have no way to negotiate IP addresses individually (e.g., RTP and RTCP ports). RFC 3605, "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)" specifies a means to negotiate an alternate IP address for RTCP as well as a port number. -- Steve From dwing@cisco.com Mon, 8 Nov 2004 14:35:41 -0800 (PST) From: "Dan Wing" Date: Mon, 8 Nov 2004 14:35:41 -0800 (PST) Subject: RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00 In-Reply-To: <20041108124517.K54037@oak.packetdesign.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Stephen, Thanks for reviewing the document. To your first point, I believe we resolved this, in a positive way, on the list; -00 doesn't yet reflect those changes. We decided to require NATs to preserve even and odd port numbers when they create their UDP bindings, as this provides the best interoperability for RTP applications that don't/can't provide explicit signaling of their RTCP port. To your second, a reference to RFC3605 will be added to the 'application behavior' document, which will describe how applications should behave. The current BEHAVE document just describes how NATs should behave. -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Stephen > Casner > Sent: Monday, November 08, 2004 1:56 PM > To: audet@xxxxxxxxxxxxxxxxxx; fluffy@xxxxxxxxx > Cc: AVT WG; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] RTP in draft-ietf-behave-nat-00 > > > draft-ietf-behave-nat-00 contains the following statement: > > There is some very unfortunate > wording in RFC 3550 section 11, which can cause some problematic > behavior in RTP clients. The wording could be interpreted as saying > that if a client receives an odd port for sending RTP, it SHOULD > change it to the next lower even number. This would obviously result > in the loss of RTP/UDP. > > The actual text in RFC3550 is: > > For applications that take a single port number as a parameter and > derive the RTP and RTCP port pair from that number, if an odd number > is supplied then the application SHOULD replace that number with the > next lower (even) number to use as the base of the port pair. For > applications in which the RTP and RTCP destination port numbers are > specified via explicit, separate parameters (using a signaling > protocol or other means), the application MAY disregard the > restrictions that the port numbers be even/odd and consecutive > although the use of an even/odd port pair is still encouraged. > > The key here is that when a session description specifies only one > port number to convey the RTP+RTCP port pair, then the recipient of > that description needs to know how to determine the second port number > from the first. It is critical that the sender and receiver (or > receivers plural for multicast) do this the same way. Since the > convention is to use an even port for RTP and an odd port for RTCP, > the spec says that when the given port number is odd, the RTP SHOULD > be the next lower (even) number, and the odd number SHOULD be the RTCP > port. > > However, because of requirements imposed by NATs and other > considerations, the second sentence in the above quote from RFC3550 > was added. All the applications need to do is explicitly state the > two port numbers, and then there is no restriction on the even/odd > condition of the RTP port number. > > If your concern is that applications that do not implement RTCP will > only have one number to specify, then I have four responses: > > - If the application uses SDP to specify the session and gives only > one address, this still implies that RTCP will be sent, so the > RTCP port needs to be inferred from the single port that is given. > In this case, I claim it makes sense for the stated rules to > apply. > > - If you need to be able to use an odd RTP port number in sessions > specified with SDP, then specify another port for RTCP but don't > use it. I believe it would be acceptable for that other port > number to be zero. > > - If the application will specify its session some other way, and > intends to specify only a single port with the implicatin that > RTCP will not be sent, then the specification of that session > description method can specify that the SHOULD above be > overridden. > > - Designing out RTCP is bad. > > > draft-ietf-behave-nat-00 also contains the following statement: > > NATs that use an "IP address pooling" behavior of "arbitrary" can > cause issues for applications that use multiple ports from the same > endpoint but have no way to negotiate IP addresses individually > (e.g., RTP and RTCP ports). > > RFC 3605, "Real Time Control Protocol (RTCP) attribute in Session > Description Protocol (SDP)" specifies a means to negotiate an > alternate IP address for RTCP as well as a port number. > > -- Steve > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortelnetworks.com Mon, 8 Nov 2004 17:19:16 -0800 (PST) From: "Francois Audet" Date: Mon, 8 Nov 2004 17:19:16 -0800 (PST) Subject: RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00 Message-ID: <1ECE0EB50388174790F9694F77522CCFF66368@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00 Dan is correct. We are not looking at implementations that don't support RTCP. This is not what we were trying to address. We were looking at applications that, upon receiving an instruction to send RTP to an odd address would interpret the RFC 3550 wording to say that it should send it to the the even address that is one lower than the one advertized (which would break protocols such as SIP/SDP). > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Monday, November 08, 2004 14:36 > To: Stephen Casner; Audet, Francois [SC100:9T51:EXCH]; > fluffy@xxxxxxxxx > Cc: AVT WG; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00 > > > Stephen, > > Thanks for reviewing the document. > > To your first point, > I believe we resolved this, in a positive way, on the list; > -00 doesn't yet reflect those changes. We decided to require > NATs to preserve even and odd port numbers when they create > their UDP bindings, as this provides the best > interoperability for RTP applications that don't/can't > provide explicit signaling of their RTCP port. > > To your second, a reference to RFC3605 will be added to the > 'application behavior' document, which will describe how > applications should behave. The current BEHAVE document just > describes how NATs should behave. > > -d > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf > Of Stephen > > Casner > > Sent: Monday, November 08, 2004 1:56 PM > > To: audet@xxxxxxxxxxxxxxxxxx; fluffy@xxxxxxxxx > > Cc: AVT WG; ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: [Ietf-behave] RTP in draft-ietf-behave-nat-00 > > > > > > draft-ietf-behave-nat-00 contains the following statement: > > > > There is some very unfortunate > > wording in RFC 3550 section 11, which can cause some problematic > > behavior in RTP clients. The wording could be > interpreted as saying > > that if a client receives an odd port for sending RTP, it SHOULD > > change it to the next lower even number. This would > obviously result > > in the loss of RTP/UDP. > > > > The actual text in RFC3550 is: > > > > For applications that take a single port number as a > parameter and > > derive the RTP and RTCP port pair from that number, if > an odd number > > is supplied then the application SHOULD replace that > number with the > > next lower (even) number to use as the base of the port > pair. For > > applications in which the RTP and RTCP destination port > numbers are > > specified via explicit, separate parameters (using a signaling > > protocol or other means), the application MAY disregard the > > restrictions that the port numbers be even/odd and consecutive > > although the use of an even/odd port pair is still encouraged. > > > > The key here is that when a session description specifies only one > > port number to convey the RTP+RTCP port pair, then the recipient of > > that description needs to know how to determine the second > port number > > from the first. It is critical that the sender and receiver (or > > receivers plural for multicast) do this the same way. Since the > > convention is to use an even port for RTP and an odd port for RTCP, > > the spec says that when the given port number is odd, the > RTP SHOULD > > be the next lower (even) number, and the odd number SHOULD > be the RTCP > > port. > > > > However, because of requirements imposed by NATs and other > > considerations, the second sentence in the above quote from RFC3550 > > was added. All the applications need to do is explicitly state the > > two port numbers, and then there is no restriction on the even/odd > > condition of the RTP port number. > > > > If your concern is that applications that do not implement > RTCP will > > only have one number to specify, then I have four responses: > > > > - If the application uses SDP to specify the session and > gives only > > one address, this still implies that RTCP will be sent, so the > > RTCP port needs to be inferred from the single port > that is given. > > In this case, I claim it makes sense for the stated rules to > > apply. > > > > - If you need to be able to use an odd RTP port number in sessions > > specified with SDP, then specify another port for RTCP but don't > > use it. I believe it would be acceptable for that other port > > number to be zero. > > > > - If the application will specify its session some other way, and > > intends to specify only a single port with the implicatin that > > RTCP will not be sent, then the specification of that session > > description method can specify that the SHOULD above be > > overridden. > > > > - Designing out RTCP is bad. > > > > > > draft-ietf-behave-nat-00 also contains the following statement: > > > > NATs that use an "IP address pooling" behavior of "arbitrary" can > > cause issues for applications that use multiple ports > from the same > > endpoint but have no way to negotiate IP addresses individually > > (e.g., RTP and RTCP ports). > > > > RFC 3605, "Real Time Control Protocol (RTCP) attribute in Session > > Description Protocol (SDP)" specifies a means to negotiate an > > alternate IP address for RTCP as well as a port number. > > > > -- Steve > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From casner@acm.org Mon, 8 Nov 2004 18:11:07 -0800 (PST) From: Stephen Casner Date: Mon, 8 Nov 2004 18:11:07 -0800 (PST) Subject: RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00 In-Reply-To: <1ECE0EB50388174790F9694F77522CCFF66368@zrc2hxm0.corp.nortel.com> Message-ID: <20041108174651.T54245@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: text/plain On Mon, 8 Nov 2004, Francois Audet wrote: > Dan is correct. > > We are not looking at implementations that don't support RTCP. This is not > what we were trying to address. Good. > We were looking at applications that, upon receiving an > instruction to send RTP to an odd address would interpret the RFC 3550 > wording to say that it should send it to the the even address that is > one lower than the one advertized (which would break protocols such > as SIP/SDP). If a SIP/SDP application receives instructions to send RTP to an odd address (that is, port) when the SDP does not include an a=rtcp attribute (RFC 3605) to specify the RTCP port separately, then indeed, RFC 3550 does say that the RTP should be sent to the even port that is one lower. But, I claim this SIP/SDP application is broken if it was expecting the application to send RTP on the odd port and RTCP on the next higher even port (or maybe the next lower even port, or even the odd port two higher). Do you disagree? -- Steve From audet@nortelnetworks.com Mon, 8 Nov 2004 18:40:03 -0800 (PST) From: "Francois Audet" Date: Mon, 8 Nov 2004 18:40:03 -0800 (PST) Subject: RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00 Message-ID: <1ECE0EB50388174790F9694F77522CCFF6638B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00 > If a SIP/SDP application receives instructions to send RTP to > an odd address (that is, port) when the SDP does not include > an a=rtcp attribute (RFC 3605) to specify the RTCP port > separately, then indeed, RFC 3550 does say that the RTP > should be sent to the even port that is one lower. But, I > claim this SIP/SDP application is broken if it was expecting > the application to send RTP on the odd port and RTCP on the > next higher even port (or maybe the next lower even port, or > even the odd port two higher). Do you disagree? No, I do not disagree. In fact, I completely agree with you. The simple odd/even rule that we are adding does NOT address the port contiguity rule (and we've added wording on that that you haven't seen yet for the next release). This is one of the many reason why the next thing we do after the NAT Behavior document (for UDP Unicast, then Multicast and TCP) is the "Application" document which will explain all this. I think it will be very important to have a review of the upcoming Application document from AVT (at least for those aspects related to RTP/RTCP. We will definitively seek your feedback. Again, really what we were looking at addressing is the "substract one to the odd port" statement (which one could read as applying even if both the RTP and RTCP ports are seperately negotiated). We are just ensuring that a NAT will not change the parity. From jdrosen@cisco.com Mon, 8 Nov 2004 21:06:49 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 8 Nov 2004 21:06:49 -0800 (PST) Subject: Re: [Ietf-behave] minimal STUN server In-Reply-To: <200410211404.15495.ml-behave@ringle.org> Message-ID: <41905063.1070102@cisco.com> MIME-Version: 1.0 Content-Type: text/plain inline. Jon Ringle wrote: Hello, It seems to me that the algorithm that STUN uses to discover the NAT type is not as useful and brittle especially when behind a non-deterministic NAT. This sentiment seems to be reflected in draft-rosenberg-rfc3489bis-00. Right. As such, it also seems to me that some of the requirements needed for a STUN server can be made optional. In particular, the requirement that a Bind response MUST have a CHANGED-ADDRESS attribute doesn't make sense when a STUN server will only be used for it's reflective property to learn about a NAT binding. Could I suggest that the Bind response MAY or SHOULD have a CHANGED-ADDRESS attribute. A STUN client that wishes to use a STUN server for the purpose of NAT type classification could use the presence or absence of the CHANGED-ADDRESS attribute in the Bind response to determine if this STUN server is capable of being used for NAT classification. I think something like this makes sense. I'm not sure I would do it this way, since I think it could lead to interop problems. How would we make sure that "regular" stun servers (as opposed to those listening on RTP or SIP ports as in ICE and the sipping outbound connection draft) include the CHANGED-ADDRESS attribute? As such, I'd propose to flip it around. The client could include something in its request which says, "hey, I don't need to do the detection, so don't bother to include CHANGED-ADDDRESS in the response". A server in a specialized environment where we have a way to say that clients which use it, would always say that they don't need CHANGED-ADDRESS, could not bother to use it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From ml-behave@ringle.org Tue, 9 Nov 2004 07:51:22 -0800 (PST) From: Jon Ringle Date: Tue, 9 Nov 2004 07:51:22 -0800 (PST) Subject: Re: [Ietf-behave] minimal STUN server In-Reply-To: <200410211404.15495.ml-behave@ringle.org> Message-ID: <200411091045.06083.ml-behave@ringle.org> MIME-Version: 1.0 Content-Type: text/plain Inline. On Tuesday 09 November 2004 12:06 am, Jonathan Rosenberg wrote: > Jon Ringle wrote: > > it also seems to me that some of the requirements needed for a STUN > > server can be made optional. In particular, the requirement that a Bind > > response MUST have a CHANGED-ADDRESS attribute doesn't make sense when a > > STUN server will only be used for it's reflective property to learn about > > a NAT binding. Could I suggest that the Bind response MAY or SHOULD have > > a CHANGED-ADDRESS attribute. A STUN client that wishes to use a STUN > > server for the purpose of NAT type classification could use the presence > > or absence of the CHANGED-ADDRESS attribute in the Bind response to > > determine if this STUN server is capable of being used for NAT > > classification. > > I think something like this makes sense. I'm not sure I would do it this > way, since I think it could lead to interop problems. How would we make > sure that "regular" stun servers (as opposed to those listening on RTP > or SIP ports as in ICE and the sipping outbound connection draft) > include the CHANGED-ADDRESS attribute? If a STUN server supports a set of alternate addresses A1:P1, A1:P2, A2:P1, A2:P2 (where A1 != A2 and P1 != P2) that server MUST advertised this fact by sending the CHANGED-ADDRESS attribute in the BindingResponse. This is how you make sure that "regular" stun servers will continue to work. If a STUN server does not support alternate addresses it MUST not include a CHANGED-ADDRESS attribute in the BindingResponse. This should cause the desired failure of STUN clients that are expecting the CHANGED-ADDRESS attribute, since a STUN client that is doing NAT classification cannot do so without the information provided by CHANGED-ADDRESS. > > As such, I'd propose to flip it around. The client could include > something in its request which says, "hey, I don't need to do the > detection, so don't bother to include CHANGED-ADDDRESS in the response". > > A server in a specialized environment where we have a way to say that > clients which use it, would always say that they don't need > CHANGED-ADDRESS, could not bother to use it. I think doing this is overkill, an unnecessary. I also just noticed that the -03 ICE draft says: "The CHANGED-ADDRESS attribute in a BindingResponse is set to the transport address on which the server is running." I presume that you are suggesting in this draft that the STUN server running on an ICE endpoint should set A2:P2 such that A2==A1 and P2==P1. The problem I see with this approach is that if this behaviour is placed upon a "regular" STUN server, then a STUN client using this STUN server for NAT classification may not notice that A1==A2, P1==P2. This could result in the misclassification of a NAT. Most NATs would probably appear to this STUN client to look like Full Cone. Jon From Qiaobing.Xie@motorola.com Wed, 10 Nov 2004 18:16:16 -0800 (PST) From: Qiaobing Xie Date: Wed, 10 Nov 2004 18:16:16 -0800 (PST) Subject: [Ietf-behave] NAT behave for SCTP (Re: I-D ACTION:draft-xie-tsvwg-sctp-nat-00.txt) Message-ID: <4192CBF3.3040406@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Hi, all, I'd like to get your feedback on this I-D. Our intention is to put together some guidelines and information for people who 1) want to run SCTP across NATs, and 2) want to make future NATs more SCTP friendly. This has been presented at tsvwg session today. regards, -Qiaobing > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SCTP NAT Transverse Considerations > Author(s) : Q. Xie, et al. > Filename : draft-xie-tsvwg-sctp-nat-00.txt > Pages : 8 > Date : 2004-7-14 > > This document provides guidelines and solutions for dealing with SCTP > association transversing NAT and similar middleboxes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-xie-tsvwg-sctp-nat-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ From dwing@cisco.com Thu, 11 Nov 2004 07:31:39 -0800 (PST) From: "Dan Wing" Date: Thu, 11 Nov 2004 07:31:39 -0800 (PST) Subject: RE: [AVT] RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Randell Jesup: > "Dan Wing" writes: > >To your first point, I believe we resolved this, in a positive > way, on the > >list; -00 doesn't yet reflect those changes. We decided to require NATs > >to preserve even and odd port numbers when they create their UDP > bindings, > >as this provides the best interoperability for RTP applications that > >don't/can't provide explicit signaling of their RTCP port. > > Ummm... > > And how will you "require" NATs to do this? This would mean that > all NATs would need to map all UDP traffic to the same oddness > (even->even, > odd->odd). While sure, the NAT vendors _could_ write code this > way (though > it may well break some current NAT-traversal code that tries to do > predictive mapping), there are millions of NATs out there that will never > implement this, and nothing to force new releases to do so. > > The even/odd port thing was (IMHO) a Bad Idea (in hindsight), I > assume meant to avoid having to figure out how to signal the > number for the > second port - and even for that even/odd wasn't really needed, all you > needed was contiguous. Other TCP/UDP protocols don't do these sorts of > things with port numbers (even/odd, or implied relationships between port > numbers) - it's much better to actually signal the ports to be used. > > We shouldn't compound it by "requiring" NATs maintain oddness > (after the horse is not only out of the barn, but 12 miles down the road). > We're apparently trying to avoid breaking "RTP applications that > don't/can't provide explicit signaling of their RTCP port" by putting a > requirement on NATs that will at best be phased in over years, > and at worst > totally ignored, instead of requiring RTP applications to specify both RTP > and RTCP ports. The effect will be that RTP applications that attempt to > rely on this NAT requirement will end up breaking in many situations, and > quite probably in unpredictable ways. (For example, many NATs try to > maintain port numbers inside->outside, but if the port is in use will then > allocate other non-contiguous port numbers of different oddness.) > > The original idea (even/odd pairs) wasn't a good one, and was > somewhat at odds with normal techniques in TCP/UDP, and certainly at odds > with any sort of NAT concept. (Note: just my opinion, of course) > > Of course, having a NAT preserve oddness (and contiguity!) will > improve the odds of an older RTP application working from behind it, so it > might be a *nice* thing to do in the NAT - but no one should be > counting on > it, and it's yet another complication in NAT design and limitation that > could cause it to run out of ports (in a large corporate-style NAT). I'll leave the draft-ietf-behave-nat authors to comment on the specific text they're considering; it's my understanding they are adding text which hits on your points above. > >To your second, a reference to RFC3605 will be added to the 'application > >behavior' document, which will describe how applications should behave. > >The current BEHAVE document just describes how NATs should behave. > > If BEHAVE is how they "should" behave, then my objections are > lessened - though we need to make sure that people don't use this document > as an excuse not to specify the RTCP port. Application behavior will be in the application document (not in draft-ietf-behave-nat); Francois and I are going to take a first cut at the application document in the next month or two. The application document is described as "Produce a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches" in the BEHAVE charter . -d From audet@nortelnetworks.com Thu, 11 Nov 2004 13:19:46 -0800 (PST) From: "Francois Audet" Date: Thu, 11 Nov 2004 13:19:46 -0800 (PST) Subject: RE: [AVT] RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00 Message-ID: <1ECE0EB50388174790F9694F77522CCFFBD076@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [AVT] RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00 Dan is correct. The intent is definitively NOT that application can rely on ports being odd or even. We will address your points in an upcoming version of the document and in the application draft. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Thursday, November 11, 2004 07:32 > To: Randell Jesup > Cc: Stephen Casner; Audet, Francois [SC100:9T51:EXCH]; > fluffy@xxxxxxxxx; AVT WG; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [AVT] RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00 > > > Randell Jesup: > > > "Dan Wing" writes: > > >To your first point, I believe we resolved this, in a positive > > way, on the > > >list; -00 doesn't yet reflect those changes. We decided > to require > > >NATs to preserve even and odd port numbers when they > create their UDP > > bindings, > > >as this provides the best interoperability for RTP > applications that > > >don't/can't provide explicit signaling of their RTCP port. > > > > Ummm... > > > > And how will you "require" NATs to do this? This > would mean > > that all NATs would need to map all UDP traffic to the same oddness > > (even->even, > > odd->odd). While sure, the NAT vendors _could_ write code this > > way (though > > it may well break some current NAT-traversal code that tries to do > > predictive mapping), there are millions of NATs out there that will > > never implement this, and nothing to force new releases to do so. > > > > The even/odd port thing was (IMHO) a Bad Idea (in > hindsight), > > I assume meant to avoid having to figure out how to signal > the number > > for the second port - and even for that even/odd wasn't > really needed, > > all you needed was contiguous. Other TCP/UDP protocols > don't do these > > sorts of things with port numbers (even/odd, or implied > relationships > > between port > > numbers) - it's much better to actually signal the ports to be used. > > > > We shouldn't compound it by "requiring" NATs > maintain oddness > > (after the horse is not only out of the barn, but 12 miles down the > > road). We're apparently trying to avoid breaking "RTP applications > > that don't/can't provide explicit signaling of their RTCP port" by > > putting a requirement on NATs that will at best be phased in over > > years, and at worst totally ignored, instead of requiring RTP > > applications to specify both RTP and RTCP ports. The > effect will be > > that RTP applications that attempt to rely on this NAT requirement > > will end up breaking in many situations, and quite probably in > > unpredictable ways. (For example, many NATs try to maintain port > > numbers inside->outside, but if the port is in use will > then allocate > > other non-contiguous port numbers of different oddness.) > > > > The original idea (even/odd pairs) wasn't a good > one, and was > > somewhat at odds with normal techniques in TCP/UDP, and > certainly at > > odds with any sort of NAT concept. (Note: just my opinion, > of course) > > > > Of course, having a NAT preserve oddness (and contiguity!) > > will improve the odds of an older RTP application working > from behind > > it, so it might be a *nice* thing to do in the NAT - but no > one should > > be counting on it, and it's yet another complication in NAT > design and > > limitation that could cause it to run out of ports (in a large > > corporate-style NAT). > > I'll leave the draft-ietf-behave-nat authors to comment on > the specific text they're considering; it's my understanding > they are adding text which hits on your points above. > > > >To your second, a reference to RFC3605 will be added to the > > >'application behavior' document, which will describe how > applications > > >should behave. The current BEHAVE document just describes how NATs > > >should behave. > > > > If BEHAVE is how they "should" behave, then my > objections are > > lessened - though we need to make sure that people don't use this > > document as an excuse not to specify the RTCP port. > > Application behavior will be in the application document (not > in draft-ietf-behave-nat); Francois and I are going to take a > first cut at the application document in the next month or > two. The application document is described as "Produce a BCP > that discusses protocol design techniques for using the > existing set of NAT traversal approaches" in the BEHAVE > charter . > > -d > > > From dwing@cisco.com Wed, 17 Nov 2004 09:43:52 -0800 (PST) From: "Dan Wing" Date: Wed, 17 Nov 2004 09:43:52 -0800 (PST) Subject: RE: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: <4192CBF3.3040406@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Thanks for making us aware of your draft. In section 3.2 you appear to be describing a true NAT, not a NAPT (Network Address and Port Translator). Is my understanding accurate? Does your entire document talk about true NATs, or NAPTs? In section 4.1, "Simple NAT enhancement to support singly-homed SCTP associations", you write: ... In such cases, the enhancement needed for a NAT to support SCTP is relatively simple: 1) recognize the protocol number for SCTP, and 2) locate and change the transport ports (if needed). The location of the transport port numbers are the same as both TCP and UDP so these should be minor changes for NAT software. But there isn't a mention that the signaling to set up SCTP needs to learn, or communicate to the peer, the change to the SCTP transport port. (I noticed section 4.2 has a fuller description of what a NAT needs to do when it NATs an SCTP packet; you might want to use more parallel language in 4.1 and 4.2). Do applications that run over SCTP have symmetry, like RTP? See draft-wing-mmusic-symmetric-rtprtcp-01.txt, which will be folded into BEHAVE's "application" document. We can extend this to describe UDP applications (specifically RTP and RTCP) and SCTP. TCP already has symmetry as defined by draft-wing-mmusic-symmetric-rtprtcp-01.txt. In addition, I caution against the "(if needed)" clause in your document because allowing an implementation to leave the transport port the same means only one SCTP-capable host can be behind a NAT which is quite restrictive. Section 4.2 says, "This approach is transparent to the endpoints and can support multi-homing", but I'm curious how the other SCTP endpoint knows the mapping in a back-to-back NAT case (such as your second figure in section 3.1). I have some other comments, but these are the significant issues I wanted mention immediately. Thanks again, -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Qiaobing > Xie > Sent: Wednesday, November 10, 2004 6:18 PM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] NAT behave for SCTP (Re: > I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) > > > Hi, all, > > I'd like to get your feedback on this I-D. Our intention is to > put together some guidelines > and information for people who 1) want to run SCTP across NATs, > and 2) want to make future > NATs more SCTP friendly. This has been presented at tsvwg session today. > > regards, > -Qiaobing > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > > > Title : SCTP NAT Transverse Considerations > > Author(s) : Q. Xie, et al. > > Filename : draft-xie-tsvwg-sctp-nat-00.txt > > Pages : 8 > > Date : 2004-7-14 > > > > This document provides guidelines and solutions for dealing with SCTP > > association transversing NAT and similar middleboxes. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request at ietf.org with the word unsubscribe in > the body of the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-xie-tsvwg-sctp-nat-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv at ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different > MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local > documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From mshore@cisco.com Wed, 17 Nov 2004 10:13:20 -0800 (PST) From: Melinda Shore Date: Wed, 17 Nov 2004 10:13:20 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: Message-ID: <48F2C2BE-38C4-11D9-95FC-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Wednesday, November 17, 2004, at 12:43 PM, Dan Wing wrote: But there isn't a mention that the signaling to set up SCTP needs to learn, or communicate to the peer, the change to the SCTP transport port. It doesn't, actually. That information is transmitted in-band, and SCTP is a transport-layer protocol like TCP, not a session- layer protocol like RTP. In other words, SCTP streams can't be assumed to be signaled by another protocol - it's switched off the IP protocol number. Melinda From dwing@cisco.com Wed, 17 Nov 2004 11:10:47 -0800 (PST) From: Dan Wing Date: Wed, 17 Nov 2004 11:10:47 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: <48F2C2BE-38C4-11D9-95FC-000A95E35274@cisco.com> Message-ID: <3FFA330F-38CC-11D9-BCAB-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Nov 17, 2004, at 10:12 AM, Melinda Shore wrote: On Wednesday, November 17, 2004, at 12:43 PM, Dan Wing wrote: But there isn't a mention that the signaling to set up SCTP needs to learn, or communicate to the peer, the change to the SCTP transport port. It doesn't, actually. That information is transmitted in-band, and SCTP is a transport-layer protocol like TCP, not a session- layer protocol like RTP. In other words, SCTP streams can't be assumed to be signaled by another protocol - it's switched off the IP protocol number. If the multiplexing is done by IP protocol number, I guess two SCTP devices can't be behind a NAPT? -d From mshore@cisco.com Wed, 17 Nov 2004 11:21:24 -0800 (PST) From: Melinda Shore Date: Wed, 17 Nov 2004 11:21:24 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: <3FFA330F-38CC-11D9-BCAB-0003938AF740@cisco.com> Message-ID: <4E5E514B-38CD-11D9-95FC-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Wednesday, November 17, 2004, at 02:09 PM, Dan Wing wrote: If the multiplexing is done by IP protocol number, I guess two SCTP devices can't be behind a NAPT? Sure, but the NAT would need to be able to recognize SCTP and demultiplex SCTP traffic on port number. Getting NAT vendors to add basic SCTP support to their devices is one problem, but it's more-or-less the same problem as supporting TCP and UDP. The real problems are around stream endpoint address mutability and multihoming, which are unique to SCTP. Melinda From dwing@cisco.com Wed, 17 Nov 2004 12:31:36 -0800 (PST) From: Dan Wing Date: Wed, 17 Nov 2004 12:31:36 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: <4E5E514B-38CD-11D9-95FC-000A95E35274@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Nov 17, 2004, at 11:17 AM, Melinda Shore wrote: On Wednesday, November 17, 2004, at 02:09 PM, Dan Wing wrote: If the multiplexing is done by IP protocol number, I guess two SCTP devices can't be behind a NAPT? Sure, but the NAT would need to be able to recognize SCTP and demultiplex SCTP traffic on port number. Is the desire of draft-xie-tsvwg-sctp-nat-00 to _not_ work in such a scenario? The document didn't declare that out of scope, but the introduction does define a NAT as a device that also does port translation. Getting NAT vendors to add basic SCTP support to their devices is one problem, but it's more-or-less the same problem as supporting TCP and UDP. The real problems are around stream endpoint address mutability and multihoming, which are unique to SCTP. This is discussed a bit in the draft (3.2), but I'd like to see more discussion in the I-D about what NAT vendors could do to support such multhoming -- I expect the requirements to support SCTP's multihoming are nearly identical to support multihoming a device that uses TCP or UDP, no? -d Melinda From mshore@cisco.com Wed, 17 Nov 2004 12:39:13 -0800 (PST) From: Melinda Shore Date: Wed, 17 Nov 2004 12:39:13 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Wednesday, November 17, 2004, at 03:31 PM, Dan Wing wrote: Is the desire of draft-xie-tsvwg-sctp-nat-00 to _not_ work in such a scenario? The document didn't declare that out of scope, but the introduction does define a NAT as a device that also does port translation. Yes, the scoping should probably be clearer. This is discussed a bit in the draft (3.2), but I'd like to see more discussion in the I-D about what NAT vendors could do to support such multhoming -- I expect the requirements to support SCTP's multihoming are nearly identical to support multihoming a device that uses TCP or UDP, no? No, this is quite different. In the SCTP case the endpoint address may change over the lifetime of a stream and it may be the case that individual frames are sent to different addresses. For example, you could stripe one stream across multiple interfaces. Melinda From dwing@cisco.com Wed, 17 Nov 2004 12:49:48 -0800 (PST) From: Dan Wing Date: Wed, 17 Nov 2004 12:49:48 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: Message-ID: <4544ECC3-38DA-11D9-BCAB-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Nov 17, 2004, at 12:38 PM, Melinda Shore wrote: No, this is quite different. In the SCTP case the endpoint address may change over the lifetime of a stream and it may be the case that individual frames are sent to different addresses. For example, you could stripe one stream across multiple interfaces. Thanks. -d From Qiaobing.Xie@motorola.com Wed, 17 Nov 2004 14:15:39 -0800 (PST) From: Qiaobing Xie Date: Wed, 17 Nov 2004 14:15:39 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: <4E5E514B-38CD-11D9-95FC-000A95E35274@cisco.com> Message-ID: <419BCCDB.6070903@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Melinda Shore wrote: On Wednesday, November 17, 2004, at 02:09 PM, Dan Wing wrote: If the multiplexing is done by IP protocol number, I guess two SCTP devices can't be behind a NAPT? Sure, but the NAT would need to be able to recognize SCTP and demultiplex SCTP traffic on port number. Getting NAT vendors to add basic SCTP support to their devices is one problem, but it's more-or-less the same problem as supporting TCP and UDP. Yes, indeed. The work to support singly-homed SCTP is very much the same as for TCP or UDP. The intention of the draft is to cover both NAT and NAPT cases. The real problems are around stream endpoint address mutability and multihoming, which are unique to SCTP. Yes. That's the more interesting part :-) regards, -Qiaobing Melinda _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Qiaobing.Xie@motorola.com Wed, 17 Nov 2004 14:21:43 -0800 (PST) From: Qiaobing Xie Date: Wed, 17 Nov 2004 14:21:43 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: <4E5E514B-38CD-11D9-95FC-000A95E35274@cisco.com> Message-ID: <419BCE4E.9060504@motorola.com> MIME-Version: 1.0 Content-Type: text/plain On Nov 17, 2004, at 11:17 AM, Melinda Shore wrote: On Wednesday, November 17, 2004, at 02:09 PM, Dan Wing wrote: If the multiplexing is done by IP protocol number, I guess two SCTP devices can't be behind a NAPT? Sure, but the NAT would need to be able to recognize SCTP and demultiplex SCTP traffic on port number. Is the desire of draft-xie-tsvwg-sctp-nat-00 to _not_ work in such a scenario? The document didn't declare that out of scope, but the introduction does define a NAT as a device that also does port translation. I don't see why this has to be out of scope. Please clarify. Getting NAT vendors to add basic SCTP support to their devices is one problem, but it's more-or-less the same problem as supporting TCP and UDP. The real problems are around stream endpoint address mutability and multihoming, which are unique to SCTP. This is discussed a bit in the draft (3.2), but I'd like to see more discussion in the I-D about what NAT vendors could do to support such multhoming -- I expect the requirements to support SCTP's multihoming are nearly identical to support multihoming a device that uses TCP or UDP, no? No, section 3.2 is about "multi-point traverse". Multi-homing support recommendation is discussed in section 4.1. regards, -Qiaobing -d Melinda From Qiaobing.Xie@motorola.com Wed, 17 Nov 2004 14:26:51 -0800 (PST) From: Qiaobing Xie Date: Wed, 17 Nov 2004 14:26:51 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: Message-ID: <419BD0B0.60200@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Dan, Thanks for the review and comments. Please see my comments in-line. Dan Wing wrote: Thanks for making us aware of your draft. In section 3.2 you appear to be describing a true NAT, not a NAPT (Network Address and Port Translator). Is my understanding accurate? Does your entire document talk about true NATs, or NAPTs? Actually both. The text applies to both NAT and NAPT. An SCTP association can have multiple addresses but only one port number at either end. In section 4.1, "Simple NAT enhancement to support singly-homed SCTP associations", you write: ... In such cases, the enhancement needed for a NAT to support SCTP is relatively simple: 1) recognize the protocol number for SCTP, and 2) locate and change the transport ports (if needed). The location of the transport port numbers are the same as both TCP and UDP so these should be minor changes for NAT software. But there isn't a mention that the signaling to set up SCTP needs to learn, or communicate to the peer, the change to the SCTP transport port. This case is very much the same as TCP/UDP. As pointed out by Melinda. (I noticed section 4.2 has a fuller description of what a NAT needs to do when it NATs an SCTP packet; you might want to use more parallel language in 4.1 and 4.2). ok. Do applications that run over SCTP have symmetry, like RTP? See draft-wing-mmusic-symmetric-rtprtcp-01.txt, which will be folded into BEHAVE's "application" document. We can extend this to describe UDP applications (specifically RTP and RTCP) and SCTP. TCP already has symmetry as defined by draft-wing-mmusic-symmetric-rtprtcp-01.txt. In addition, I caution against the "(if needed)" clause in your document because allowing an implementation to leave the transport port the same means only one SCTP-capable host can be behind a NAT which is quite restrictive. As Melinda has pointed out, SCTP is a transport protocol like TCP. It is unlike RTP. Section 4.2 says, "This approach is transparent to the endpoints and can support multi-homing", but I'm curious how the other SCTP endpoint knows the mapping in a back-to-back NAT case (such as your second figure in section 3.1). The other SCTP endpoint will not be aware of the NATs in the path. It will only see the translated address list from the last NAT (and possibly the translated port number if NAPT is involved). I have some other comments, but these are the significant issues I wanted mention immediately. Thanks, -Qiaobing Thanks again, -d -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Qiaobing Xie Sent: Wednesday, November 10, 2004 6:18 PM To: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) Hi, all, I'd like to get your feedback on this I-D. Our intention is to put together some guidelines and information for people who 1) want to run SCTP across NATs, and 2) want to make future NATs more SCTP friendly. This has been presented at tsvwg session today. regards, -Qiaobing > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SCTP NAT Transverse Considerations > Author(s) : Q. Xie, et al. > Filename : draft-xie-tsvwg-sctp-nat-00.txt > Pages : 8 > Date : 2004-7-14 > > This document provides guidelines and solutions for dealing with SCTP > association transversing NAT and similar middleboxes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-xie-tsvwg-sctp-nat-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Wed, 17 Nov 2004 15:25:17 -0800 (PST) From: Dan Wing Date: Wed, 17 Nov 2004 15:25:17 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: <4E5E514B-38CD-11D9-95FC-000A95E35274@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Nov 17, 2004, at 2:18 PM, Qiaobing Xie wrote: On Nov 17, 2004, at 11:17 AM, Melinda Shore wrote: On Wednesday, November 17, 2004, at 02:09 PM, Dan Wing wrote: If the multiplexing is done by IP protocol number, I guess two SCTP devices can't be behind a NAPT? Sure, but the NAT would need to be able to recognize SCTP and demultiplex SCTP traffic on port number. Is the desire of draft-xie-tsvwg-sctp-nat-00 to _not_ work in such a scenario? The document didn't declare that out of scope, but the introduction does define a NAT as a device that also does port translation. I don't see why this has to be out of scope. Please clarify. If the NAPT translates port numbers, the other SCTP peer needs to know the translated port number. For example, if you have two SCTP endpoints behind a single NAPT and both of them are listening on SCTP port 1234, and the NAPT receives a SCTP packet for port 1234, what's the NAPT supposed to do? Currently you only discuss the NAPT intercepting and modifying SCTP packets for the multi-homing scenario (section 4.2); I believe you want similar behavior for the case of two SCTP devices behind a single NAT. Getting NAT vendors to add basic SCTP support to their devices is one problem, but it's more-or-less the same problem as supporting TCP and UDP. The real problems are around stream endpoint address mutability and multihoming, which are unique to SCTP. This is discussed a bit in the draft (3.2), but I'd like to see more discussion in the I-D about what NAT vendors could do to support such multhoming -- I expect the requirements to support SCTP's multihoming are nearly identical to support multihoming a device that uses TCP or UDP, no? No, section 3.2 is about "multi-point traverse". Multi-homing support recommendation is discussed in section 4.1. Thanks. -d regards, -Qiaobing -d Melinda From dwing@cisco.com Wed, 17 Nov 2004 15:31:39 -0800 (PST) From: Dan Wing Date: Wed, 17 Nov 2004 15:31:39 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Nov 17, 2004, at 2:29 PM, Qiaobing Xie wrote: Hi, Dan, Thanks for the review and comments. Please see my comments in-line. Dan Wing wrote: Thanks for making us aware of your draft. In section 3.2 you appear to be describing a true NAT, not a NAPT (Network Address and Port Translator). Is my understanding accurate? Does your entire document talk about true NATs, or NAPTs? Actually both. The text applies to both NAT and NAPT. An SCTP association can have multiple addresses but only one port number at either end. In section 4.1, "Simple NAT enhancement to support singly-homed SCTP associations", you write: ... In such cases, the enhancement needed for a NAT to support SCTP is relatively simple: 1) recognize the protocol number for SCTP, and 2) locate and change the transport ports (if needed). The location of the transport port numbers are the same as both TCP and UDP so these should be minor changes for NAT software. But there isn't a mention that the signaling to set up SCTP needs to learn, or communicate to the peer, the change to the SCTP transport port. This case is very much the same as TCP/UDP. As pointed out by Melinda. TCP doesn't have a mechanism to learn the ephemeral NAT'd port (that is, the source port), but also doesn't need to -- TCP connections are symmetric in that a 5-tuple describes the connection in both directions. UDP, and especially RTP, don't behave that way. Maybe SCTP does; I'm not familiar with it (which is undoubtedly obvious by now!). (I noticed section 4.2 has a fuller description of what a NAT needs to do when it NATs an SCTP packet; you might want to use more parallel language in 4.1 and 4.2). ok. Do applications that run over SCTP have symmetry, like RTP? See draft-wing-mmusic-symmetric-rtprtcp-01.txt, which will be folded into BEHAVE's "application" document. We can extend this to describe UDP applications (specifically RTP and RTCP) and SCTP. TCP already has symmetry as defined by draft-wing-mmusic-symmetric-rtprtcp-01.txt. In addition, I caution against the "(if needed)" clause in your document because allowing an implementation to leave the transport port the same means only one SCTP-capable host can be behind a NAT which is quite restrictive. As Melinda has pointed out, SCTP is a transport protocol like TCP. It is unlike RTP. I realize SCTP is its own protocol. However, I don't know if it has symmetry in its use of ports. For example, if an SCTP application sends a packet with a source port of 1234, will responses from the remote SCTP stack come back to that same port? UDP, which is its own protocol, doesn't guarantee this; TCP, which is also its own protocol, does guarantee this. I'm curious about SCTP's behavior in this regard. Section 4.2 says, "This approach is transparent to the endpoints and can support multi-homing", but I'm curious how the other SCTP endpoint knows the mapping in a back-to-back NAT case (such as your second figure in section 3.1). The other SCTP endpoint will not be aware of the NATs in the path. It will only see the translated address list from the last NAT (and possibly the translated port number if NAPT is involved). -d I have some other comments, but these are the significant issues I wanted mention immediately. Thanks, -Qiaobing Thanks again, -d -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Qiaobing Xie Sent: Wednesday, November 10, 2004 6:18 PM To: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) Hi, all, I'd like to get your feedback on this I-D. Our intention is to put together some guidelines and information for people who 1) want to run SCTP across NATs, and 2) want to make future NATs more SCTP friendly. This has been presented at tsvwg session today. regards, -Qiaobing > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SCTP NAT Transverse Considerations > Author(s) : Q. Xie, et al. > Filename : draft-xie-tsvwg-sctp-nat-00.txt > Pages : 8 > Date : 2004-7-14 > > This document provides guidelines and solutions for dealing with SCTP > association transversing NAT and similar middleboxes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-xie-tsvwg-sctp-nat-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-xie-tsvwg-sctp-nat-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Qiaobing.Xie@motorola.com Wed, 17 Nov 2004 18:01:37 -0800 (PST) From: Qiaobing Xie Date: Wed, 17 Nov 2004 18:01:37 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: <4E5E514B-38CD-11D9-95FC-000A95E35274@cisco.com> Message-ID: <419C02FD.9050504@motorola.com> MIME-Version: 1.0 Content-Type: text/plain .... If the NAPT translates port numbers, the other SCTP peer needs to know the translated port number. For example, if you have two SCTP endpoints behind a single NAPT and both of them are listening on SCTP port 1234, and the NAPT receives a SCTP packet for port 1234, what's the NAPT supposed to do? Currently But the two SCTP endpoints behind the NAPT will always have a different local IP address(es). I still do not seem to see the problem. regards, -Qiaobing you only discuss the NAPT intercepting and modifying SCTP packets for the multi-homing scenario (section 4.2); I believe you want similar behavior for the case of two SCTP devices behind a single NAT. From Qiaobing.Xie@motorola.com Wed, 17 Nov 2004 18:06:44 -0800 (PST) From: Qiaobing Xie Date: Wed, 17 Nov 2004 18:06:44 -0800 (PST) Subject: Re: [Ietf-behave] NAT behave for SCTP (Re: I-DACTION:draft-xie-tsvwg-sctp-nat-00.txt) In-Reply-To: Message-ID: <419C0439.6090102@motorola.com> MIME-Version: 1.0 Content-Type: text/plain ... TCP doesn't have a mechanism to learn the ephemeral NAT'd port (that is, the source port), but also doesn't need to -- TCP connections are symmetric in that a 5-tuple describes the connection in both directions. UDP, and especially RTP, don't behave that way. Maybe SCTP does; I'm not familiar with it (which is undoubtedly obvious by now!). Yes, SCTP does, just like TCP. The only difference with SCTP is that the src and dest address in TCP now become possibly a list of src and dest addresses. ... I realize SCTP is its own protocol. However, I don't know if it has symmetry in its use of ports. For example, if an SCTP application sends a packet with a source port of 1234, will responses from the remote SCTP stack come back to that same port? UDP, which is its own protocol, doesn't guarantee this; TCP, which is also its own protocol, does guarantee this. I'm curious about SCTP's behavior in this regard. Yes, SCTP has the same symmetry as TCP in port use. regards, -Qiaobing From Yutaka_Takeda@PlayStation.sony.com Fri, 19 Nov 2004 13:59:02 -0800 (PST) From: Yutaka_Takeda@PlayStation.sony.com Date: Fri, 19 Nov 2004 13:59:02 -0800 (PST) Subject: [Ietf-behave] Maximum number of binding Message-ID: <419E6CA3.2040006@PlayStation.sony.com> MIME-Version: 1.0 Content-Type: text/plain I like how 'behave-nat-00' classifies different behaviors of NAT. The common term definitions also make my life easier, indeed. Nice job! One thing I thought... It would be nice to include a requirement on: - Minimum number of bindings per NAT. Especially, NB=AD and NB=APD consume more memory resource in NAT. The requirement may have to have: - Minimum number of connections (destinations) per binding. I can see that developers especially who are working on residential gateways, or routers are trying minimize its memory requirement to bring down hardware cost as low as possible to win the race. Does anyone have any idea or thoughts on above parameters in existing NATs? Thanks, Yutaka From audet@nortelnetworks.com Fri, 19 Nov 2004 15:58:41 -0800 (PST) From: "Francois Audet" Date: Fri, 19 Nov 2004 15:58:41 -0800 (PST) Subject: RE: [Ietf-behave] Maximum number of binding Message-ID: <1ECE0EB50388174790F9694F77522CCF010BAD96@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Maximum number of binding Thanks for the comments. I hadn't put too much tought into it, as I viewed this more of a product specification type of requirement. Let's see if anybody has any views on the list. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx > Sent: Friday, November 19, 2004 13:59 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] Maximum number of binding > > > I like how 'behave-nat-00' classifies different behaviors of > NAT. The > common term definitions also make my life easier, indeed. Nice job! > > One thing I thought... It would be nice to include a requirement on: > > - Minimum number of bindings per NAT. > > Especially, NB=AD and NB=APD consume more memory resource in > NAT. The > requirement may have to have: > > - Minimum number of connections (destinations) per binding. > > I can see that developers especially who are working on residential > gateways, or routers are trying minimize its > memory requirement to bring down hardware cost as low as > possible to win > the race. Does anyone have any idea or thoughts on above > parameters in > existing NATs? > > Thanks, > Yutaka > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From dwing@cisco.com Tue, 23 Nov 2004 16:10:17 -0800 (PST) From: Dan Wing Date: Tue, 23 Nov 2004 16:10:17 -0800 (PST) Subject: [Ietf-behave] slashdot: p2p firewalled file transfers Message-ID: <46B1443F-3DAD-11D9-8254-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain My quick read is that folks are doing UDP-based file transfers because peer-to-peer TCP doesn't work. And we can expect UDP-based implementations won't be TCP-friendly... This seems ripe for net meltdown considering the claimed percentage of TCP traffic that, today, is p2p file sharing. http://slashdot.org/articles/04/11/23/1755226.shtml?tid=95&tid=185 From jdrosen@cisco.com Tue, 23 Nov 2004 23:41:58 -0800 (PST) From: Jonathan Rosenberg Date: Tue, 23 Nov 2004 23:41:58 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <46B1443F-3DAD-11D9-8254-0003938AF740@cisco.com> Message-ID: <41A43B3D.8020506@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Exactly the reason to try and get p2p tcp to work through a behave nat... it won't prevent these things from happening now, but hopefully it can be avoided in the future. I hope these p2p guys consider congestion control. The reference in the slashdot article to udp file transfer explicitly calls out the need to make the udp transfer tcp-friendly, which was at least somewhat reassuring. -Jonathan R. Dan Wing wrote: My quick read is that folks are doing UDP-based file transfers because peer-to-peer TCP doesn't work. And we can expect UDP-based implementations won't be TCP-friendly... This seems ripe for net meltdown considering the claimed percentage of TCP traffic that, today, is p2p file sharing. http://slashdot.org/articles/04/11/23/1755226.shtml?tid=95&tid=185 _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From nagendra@cs.stanford.edu Wed, 24 Nov 2004 02:02:02 -0800 (PST) From: nagendra modadugu Date: Wed, 24 Nov 2004 02:02:02 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <46B1443F-3DAD-11D9-8254-0003938AF740@cisco.com> Message-ID: <20041124100143.GA26450@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain >From the mailing list discussion of the subject, it seems that the bandwidth allocated to a stream is fixed for now, but will be adjusted based on RTT measurements (how to get this all to work is a still a question). I wonder why no-one has suggested user-land TCP to be run over UDP--it should be easier to integrate than some new reliable transport. nagendra * Jonathan Rosenberg [2004-11-24 02:41:49 -0500]: > Exactly the reason to try and get p2p tcp to work through a behave > nat... it won't prevent these things from happening now, but hopefully > it can be avoided in the future. > > I hope these p2p guys consider congestion control. The reference in the > slashdot article to udp file transfer explicitly calls out the need to > make the udp transfer tcp-friendly, which was at least somewhat reassuring. > > -Jonathan R. > > Dan Wing wrote: > > >My quick read is that folks are doing UDP-based file transfers because > >peer-to-peer TCP doesn't work. And we can expect UDP-based > >implementations won't be TCP-friendly... This seems ripe for net > >meltdown considering the claimed percentage of TCP traffic that, today, > >is p2p file sharing. > > > >http://slashdot.org/articles/04/11/23/1755226.shtml?tid=95&tid=185 > > > >_______________________________________________ > >Ietf-behave mailing list > >Ietf-behave@xxxxxxxxxxxxxxxxxxx > >https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Wed, 24 Nov 2004 08:06:52 -0800 (PST) From: Dan Wing Date: Wed, 24 Nov 2004 08:06:52 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <46B1443F-3DAD-11D9-8254-0003938AF740@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain TCP-over-UDP would use more bandwidth than TCP or a new "as-good-as-TCP" UDP-based protocol that someone will invent. -d On Nov 24, 2004, at 2:01 AM, nagendra modadugu wrote: From the mailing list discussion of the subject, it seems that the bandwidth allocated to a stream is fixed for now, but will be adjusted based on RTT measurements (how to get this all to work is a still a question). I wonder why no-one has suggested user-land TCP to be run over UDP--it should be easier to integrate than some new reliable transport. nagendra * Jonathan Rosenberg [2004-11-24 02:41:49 -0500]: Exactly the reason to try and get p2p tcp to work through a behave nat... it won't prevent these things from happening now, but hopefully it can be avoided in the future. I hope these p2p guys consider congestion control. The reference in the slashdot article to udp file transfer explicitly calls out the need to make the udp transfer tcp-friendly, which was at least somewhat reassuring. -Jonathan R. Dan Wing wrote: My quick read is that folks are doing UDP-based file transfers because peer-to-peer TCP doesn't work. And we can expect UDP-based implementations won't be TCP-friendly... This seems ripe for net meltdown considering the claimed percentage of TCP traffic that, today, is p2p file sharing. http://slashdot.org/articles/04/11/23/1755226.shtml?tid=95&tid=185 _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From mshore@cisco.com Wed, 24 Nov 2004 09:03:32 -0800 (PST) From: Melinda Shore Date: Wed, 24 Nov 2004 09:03:32 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <20041124100143.GA26450@cs.stanford.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Wednesday, November 24, 2004, at 05:01 AM, nagendra modadugu wrote: I wonder why no-one has suggested user-land TCP to be run over UDP-- Along the lines of DCCP? Melinda From dwing@cisco.com Wed, 24 Nov 2004 09:26:29 -0800 (PST) From: Dan Wing Date: Wed, 24 Nov 2004 09:26:29 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: Message-ID: <07A1B65D-3E3E-11D9-AFC1-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Will DCCP survive over my Linksys WRT54G? -d On Nov 24, 2004, at 9:03 AM, Melinda Shore wrote: On Wednesday, November 24, 2004, at 05:01 AM, nagendra modadugu wrote: I wonder why no-one has suggested user-land TCP to be run over UDP-- Along the lines of DCCP? Melinda _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From mshore@cisco.com Wed, 24 Nov 2004 09:33:40 -0800 (PST) From: Melinda Shore Date: Wed, 24 Nov 2004 09:33:40 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <07A1B65D-3E3E-11D9-AFC1-0003938AF740@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Wednesday, November 24, 2004, at 12:26 PM, Dan Wing wrote: Will DCCP survive over my Linksys WRT54G? Sure. although if you use it to transport application data that includes payload-embedded addresses the usual caveats apply. Melinda From dwing@cisco.com Wed, 24 Nov 2004 10:34:42 -0800 (PST) From: Dan Wing Date: Wed, 24 Nov 2004 10:34:42 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: Message-ID: <8F9EEB97-3E47-11D9-AFC1-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Nov 24, 2004, at 9:33 AM, Melinda Shore wrote: On Wednesday, November 24, 2004, at 12:26 PM, Dan Wing wrote: Will DCCP survive over my Linksys WRT54G? Sure. You're saying my Linksys WRT54G will see DCCP's IP protocol number (I don't see one listed at IANA's website, I guess because it isn't yet assigned by IANA) and the WRT54G will know to maintain a NAT binding based on the DCCP port numbers to allow bi-directional traffic -- just like UDP, TCP, and IPsec initiated by a PC behind the WRT54G. I'm doubtful. although if you use it to transport application data that includes payload-embedded addresses the usual caveats apply. Sure, of course. Which brings us back to the problem that started this thread -- using TCP for p2p file transfers. -d From mshore@cisco.com Wed, 24 Nov 2004 10:42:56 -0800 (PST) From: Melinda Shore Date: Wed, 24 Nov 2004 10:42:56 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <8F9EEB97-3E47-11D9-AFC1-0003938AF740@cisco.com> Message-ID: <95311546-3E48-11D9-95FC-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Wednesday, November 24, 2004, at 01:35 PM, Dan Wing wrote: I'm doubtful. If a NAT supports dccp it supports dccp. There's nothing inherently NAT-unfriendly about the protocol. Melinda From yutaka_takeda@playstation.sony.com Wed, 24 Nov 2004 10:56:16 -0800 (PST) From: yutaka_takeda@playstation.sony.com Date: Wed, 24 Nov 2004 10:56:16 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: Message-ID: <006d01c4d257$41760da0$4503620a@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain I think most residential routers do not understand DCCP and discard it because DCCP is another transport layer protocol with another 'protocol number'. Besides getting p2p-TCP to work through NATs, we might want to look into RUDP that IETF once explored in the past, and that implements congestion&flow control like TCP. http://www.ietf.org/proceedings/99mar/I-D/draft-ietf-sigtran-reliable-udp-00.txt which was derived from RDP: - rfc 980 (version 1) - rfc 1151 (version 2), Yutaka ----- Original Message ----- From: "Melinda Shore" To: "Dan Wing" Cc: Sent: Wednesday, November 24, 2004 9:33 AM Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers > On Wednesday, November 24, 2004, at 12:26 PM, Dan Wing wrote: > > Will DCCP survive over my Linksys WRT54G? > > Sure. although if you use it to transport application data > that includes payload-embedded addresses the usual caveats > apply. > > Melinda > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > From dwing@cisco.com Wed, 24 Nov 2004 11:04:54 -0800 (PST) From: Dan Wing Date: Wed, 24 Nov 2004 11:04:54 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <95311546-3E48-11D9-95FC-000A95E35274@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Nov 24, 2004, at 10:42 AM, Melinda Shore wrote: On Wednesday, November 24, 2004, at 01:35 PM, Dan Wing wrote: I'm doubtful. If a NAT supports dccp it supports dccp. There's nothing inherently NAT-unfriendly about the protocol. I didn't mean to imply there was some NAT-unfriendliness in the protocol. But DCCP doesn't, by itself, only provides TCP-friendliness. It doesn't provide the other necessary features for p2p connectivity, namely (1) the ability to traverse existing NATs and (2) the ability for p2p connectivity when both hosts are behind NATs. (2) could be solved with a STUN-like protocol. I don't see an elegant solution to (1). -d From nagendra@cs.stanford.edu Wed, 24 Nov 2004 12:04:21 -0800 (PST) From: nagendra modadugu Date: Wed, 24 Nov 2004 12:04:21 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <46B1443F-3DAD-11D9-8254-0003938AF740@cisco.com> Message-ID: <20041124200402.GA27629@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain > TCP-over-UDP would use more bandwidth than TCP or a new > "as-good-as-TCP" UDP-based protocol that someone will invent. > > -d More bandwidth because of the extra UDP header? Or are there other reasons? nagendra From ml-behave@ringle.org Wed, 24 Nov 2004 12:12:58 -0800 (PST) From: Jon Ringle Date: Wed, 24 Nov 2004 12:12:58 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <95311546-3E48-11D9-95FC-000A95E35274@cisco.com> Message-ID: <200411241457.25228.ml-behave@ringle.org> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 24 November 2004 02:05 pm, Dan Wing wrote: > On Nov 24, 2004, at 10:42 AM, Melinda Shore wrote: > > On Wednesday, November 24, 2004, at 01:35 PM, Dan Wing wrote: > >> I'm doubtful. > > > > If a NAT supports dccp it supports dccp. There's nothing > > inherently NAT-unfriendly about the protocol. > > I didn't mean to imply there was some NAT-unfriendliness in the > protocol. > > But DCCP doesn't, by itself, only provides TCP-friendliness. It > doesn't provide the other necessary features for p2p connectivity, > namely (1) the ability to traverse existing NATs and (2) the ability > for p2p connectivity when both hosts are behind NATs. > > (2) could be solved with a STUN-like protocol. > > I don't see an elegant solution to (1). In regards to to p2p tcp behind NATs, are you familiar with the NUTSS research: http://www.cs.cornell.edu/People/francis/ieee-nutss.pdf http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf This uses an approach that uses a STUN extension and SIP. For a "BEHAVE-compliant" NAT, the port prediction described is not necessary, since the port prediction is meant to try to deal with symmetric NATs. Jon From dwing@cisco.com Wed, 24 Nov 2004 14:27:15 -0800 (PST) From: Dan Wing Date: Wed, 24 Nov 2004 14:27:15 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <46B1443F-3DAD-11D9-8254-0003938AF740@cisco.com> Message-ID: <0CD39732-3E68-11D9-AFC1-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Nov 24, 2004, at 12:04 PM, nagendra modadugu wrote: TCP-over-UDP would use more bandwidth than TCP or a new "as-good-as-TCP" UDP-based protocol that someone will invent. -d More bandwidth because of the extra UDP header? Right. -d Or are there other reasons? From huitema@windows.microsoft.com Wed, 24 Nov 2004 14:44:04 -0800 (PST) From: "Christian Huitema" Date: Wed, 24 Nov 2004 14:44:04 -0800 (PST) Subject: RE: [Ietf-behave] slashdot: p2p firewalled file transfers Message-ID: MIME-Version: 1.0 Content-Type: text/plain The solution I would recommend to the P2P folks is to enable work over IPv6 when available, and to enable Teredo on the platform they are using. The stack looks like P2P/TCP/IPv6/UDP/IPv4. The advantage for the application is simplicity -- it just sees a regular TCP connection, the Teredo code takes care of the NAT traversal issues. The solution also preserves future evolution. It becomes P2P/TCP/IPv6/IPv4 as soon as the NAT is upgraded to support something like 6TO4, and indeed P2P/TCP/IPv6 as soon as we get native IPv6 connectivity -- without having to change the application code. -- Christian Huitema From yutaka_takeda@playstation.sony.com Wed, 24 Nov 2004 15:04:31 -0800 (PST) From: yutaka_takeda@playstation.sony.com Date: Wed, 24 Nov 2004 15:04:31 -0800 (PST) Subject: Re: [Ietf-behave] Maximum number of binding In-Reply-To: <1ECE0EB50388174790F9694F77522CCF010BAD96@zrc2hxm0.corp.nortel.com> Message-ID: <001f01c4d279$f2a21200$4503620a@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Maximum number of binding Ifnumber of simultaneous connections per bindingexceeds what a NAT can have, the NAT might eitheroverwrite an existing binding fora new connection or do nothing withthe new connection, and there is no way for an application to know what is goingon... this is the problem. I think Teredo is a good example, which encapsulates multiple IPv6 TCP/UDP connection to manyremote hostson a single IPv4 UDP socket binding assuming that a NAT can have enough number of connections on a single binding (especially when NB=AD or APD). I feel at least in such a case the NAT could send a newICMP error like "Too many connections" back to a connecting node, IMHO. Yutaka
----- Original Message -----
From: Francois Audet To: Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx ; 'ietf-behave@xxxxxxxxxxxxxxxxxxx' Sent: Friday, November 19, 2004 3:57 PM Subject: RE: [Ietf-behave] Maximum number of binding Thanks for the comments. I hadn't put too much tought into it, as I viewed this more of a product specification type of requirement. Let's see if anybody has any views on the list. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx > Sent: Friday, November 19, 2004 13:59 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] Maximum number of binding > > > I like how 'behave-nat-00' classifies different behaviors of > NAT. The > common term definitions also make my life easier, indeed. Nice job! > > One thing I thought... It would be nice to include a requirement on: > > - Minimum number of bindings per NAT. > > Especially, NB=AD and NB=APD consume more memory resource in > NAT. The > requirement may have to have: > > - Minimum number of connections (destinations) per binding. > > I can see that developers especially who are working on residential > gateways, or routers are trying minimize its > memory requirement to bring down hardware cost as low as > possible to win > the race. Does anyone have any idea or thoughts on above > parameters in > existing NATs? > > Thanks, > Yutaka > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________Ietf-behave mailing listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Wed, 24 Nov 2004 15:19:21 -0800 (PST) From: Dan Wing Date: Wed, 24 Nov 2004 15:19:21 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <95311546-3E48-11D9-95FC-000A95E35274@cisco.com> Message-ID: <5404361A-3E6F-11D9-94B6-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Nov 24, 2004, at 11:57 AM, Jon Ringle wrote: In regards to to p2p tcp behind NATs, are you familiar with the NUTSS research: http://www.cs.cornell.edu/People/francis/ieee-nutss.pdf http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf Yes, but I had forgotten about it. Thanks for the pointer. This uses an approach that uses a STUN extension and SIP. For a "BEHAVE-compliant" NAT, the port prediction described is not necessary, since the port prediction is meant to try to deal with symmetric NATs. Remember that behave (draft-ietf-behave-nat) only defines UDP behavior, not TCP behavior. At the meeting in DC, it was agreed that the filename would be modified to clearly indicate that it covers only UDP. TCP behavior would be described in another document. However, to my knowledge, no one has stepped up to writing the TCP behavior document. It appears that for p2p TCP to work, we need such a document and we need testing, akin to Cullen's draft-jennings-midcom-stun-results, to determine what TCP behavior exists for today's NATs. -d From dwing@cisco.com Wed, 24 Nov 2004 16:02:46 -0800 (PST) From: Dan Wing Date: Wed, 24 Nov 2004 16:02:46 -0800 (PST) Subject: Re: [Ietf-behave] Maximum number of binding In-Reply-To: <1ECE0EB50388174790F9694F77522CCF010BAD96@zrc2hxm0.corp.nortel.com> Message-ID: <6448CA8A-3E75-11D9-94B6-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain ICMP type=3, code=2 is "protocol unreachable" which most closely indicates the problem the NAT is attempting to communicate. However, code=2 can only be sent by the destination host. So ICMP type=3, code=0 "net unreachable" is probably best. -d On Nov 24, 2004, at 3:04 PM, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: Ifnumber of simultaneous connections per bindingexceeds what a NAT can have, the NAT might eitheroverwrite an existing binding fora new connection or do nothing withthe new connection, and there is no way for an application to know what is goingon... this is the problem. I think Teredo is a good example, which encapsulates multiple IPv6 TCP/UDP connection to manyremote hostson a single IPv4 UDP socket binding assuming that a NAT can have enough number of connections on a single binding (especially when NB=AD or APD). I feel at least in such a case the NAT could send a newICMP error like "Too many connections" back to a connecting node, IMHO. Yutaka ----- Original Message ----- From: Francois Audet To: Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx ; 'ietf-behave@xxxxxxxxxxxxxxxxxxx' Sent: Friday, November 19, 2004 3:57 PM Subject: RE: [Ietf-behave] Maximum number of binding Thanks for the comments. I hadn't put too much tought into it, as I viewed this more of a product specification type of requirement. Let's see if anybody has any views on the list. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx > Sent: Friday, November 19, 2004 13:59 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] Maximum number of binding > > > I like how 'behave-nat-00' classifies different behaviors of > NAT. The > common term definitions also make my life easier, indeed. Nice job! > > One thing I thought... It would be nice to include a requirement on: > > - Minimum number of bindings per NAT. > > Especially, NB=AD and NB=APD consume more memory resource in > NAT. The > requirement may have to have: > > - Minimum number of connections (destinations) per binding. > > I can see that developers especially who are working on residential > gateways, or routers are trying minimize its > memory requirement to bring down hardware cost as low as > possible to win > the race. Does anyone have any idea or thoughts on above > parameters in > existing NATs? > > Thanks, > Yutaka > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortelnetworks.com Wed, 24 Nov 2004 16:30:53 -0800 (PST) From: "Francois Audet" Date: Wed, 24 Nov 2004 16:30:53 -0800 (PST) Subject: RE: [Ietf-behave] Maximum number of binding Message-ID: <1ECE0EB50388174790F9694F77522CCF01127D59@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Maximum number of binding Let me know if there is some precise wording that needs to be added, and where. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Wednesday, November 24, 2004 16:03 > To: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx; Audet, Francois [SC100:9T51:EXCH] > Subject: Re: [Ietf-behave] Maximum number of binding > > > ICMP type=3, code=2 is "protocol unreachable" which most closely > indicates the problem the NAT is attempting to communicate. However, > code=2 can only be sent by the destination host. So ICMP type=3, > code=0 "net unreachable" is probably best. > > -d > > On Nov 24, 2004, at 3:04 PM, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: > > > Ifnumber of simultaneous connections per bindingexceeds what a NAT > > can have, the NAT might eitheroverwrite an existing > binding fora new > > connection or do nothing withthe new connection, and there > is no way > > for an application to know what is goingon... this is the > problem. I > > think Teredo is a good example, which encapsulates multiple IPv6 > > TCP/UDP connection to manyremote hostson a single IPv4 UDP socket > > binding assuming that a NAT can have enough number of > connections on a > > single binding (especially when NB=AD or APD). I feel at > least in such > > a case the NAT could send a newICMP error like "Too many > connections" > > back to a connecting node, IMHO. > > > > Yutaka > > > > ----- Original Message ----- > > From: Francois Audet > > To: Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx ; > > 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > Sent: Friday, November 19, 2004 3:57 PM > > Subject: RE: [Ietf-behave] Maximum number of binding > > > > > > Thanks for the comments. I hadn't put too much tought into it, as I > > viewed this more of a product specification type of requirement. > > > > Let's see if anybody has any views on the list. > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx > > > Sent: Friday, November 19, 2004 13:59 > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: [Ietf-behave] Maximum number of binding > > > > > > > > > I like how 'behave-nat-00' classifies different behaviors of > > > NAT. The > > > common term definitions also make my life easier, indeed. > Nice job! > > > > > > One thing I thought... It would be nice to include a > requirement on: > > > > > > - Minimum number of bindings per NAT. > > > > > > Especially, NB=AD and NB=APD consume more memory resource in > > > NAT. The > > > requirement may have to have: > > > > > > - Minimum number of connections (destinations) per binding. > > > > > > I can see that developers especially who are working on > residential > > > gateways, or routers are trying minimize its > > > memory requirement to bring down hardware cost as low as > possible to > > > win > > > the race. Does anyone have any idea or thoughts on above > > > parameters in > > > existing NATs? > > > > > > Thanks, > > > Yutaka > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > From dwing@cisco.com Wed, 24 Nov 2004 16:47:25 -0800 (PST) From: Dan Wing Date: Wed, 24 Nov 2004 16:47:25 -0800 (PST) Subject: Re: [Ietf-behave] Maximum number of binding In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01127D59@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Section 3.2, "port assignment", needs to discuss running out of ports. I suggest adding another paragraph, probably right after the paragraph discussing the 1-1023 and 1024-65535 ranges: In high-load situations, a NAT may exhaust its source UDP port range. If such an event occurs, o the NAT MUST NOT prematurely re-use a UDP port, as this may cause a datagram from the old UDP binding to be injected into the new UDP binding, and; o the NAT MUST NOT use a source UDP port from the other UDP port range, and; o it is strongly RECOMMENDED that the NAT send an ICMP message type=3, code=0 ("net unreachable") in response to the UDP packet, and; o Alternatively, but less preferred, the NAT SHOULD simply drop the UDP packet and not transmit it on the public side of the NAT. (I noticed that 'public side' and 'private side' aren't defined in draft-ietf-behave-nat-00, so replace that term appropriately in my suggested paragraph above.) -d On Nov 24, 2004, at 4:29 PM, Francois Audet wrote: Let me know if there is some precise wording that needs to be added, and where. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Wednesday, November 24, 2004 16:03 > To: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx; Audet, Francois [SC100:9T51:EXCH] > Subject: Re: [Ietf-behave] Maximum number of binding > > > ICMP type=3, code=2 is "protocol unreachable" which most closely > indicates the problem the NAT is attempting to communicate. However, > code=2 can only be sent by the destination host. So ICMP type=3, > code=0 "net unreachable" is probably best. > > -d > > On Nov 24, 2004, at 3:04 PM, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: > > > Ifnumber of simultaneous connections per bindingexceeds what a NAT > > can have, the NAT might eitheroverwrite an existing > binding fora new > > connection or do nothing withthe new connection, and there > is no way > > for an application to know what is goingon... this is the > problem. I > > think Teredo is a good example, which encapsulates multiple IPv6 > > TCP/UDP connection to manyremote hostson a single IPv4 UDP socket > > binding assuming that a NAT can have enough number of > connections on a > > single binding (especially when NB=AD or APD). I feel at > least in such > > a case the NAT could send a newICMP error like "Too many > connections" > > back to a connecting node, IMHO. > > > > Yutaka > > > > ----- Original Message ----- > > From: Francois Audet > > To: Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx ; > > 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > Sent: Friday, November 19, 2004 3:57 PM > > Subject: RE: [Ietf-behave] Maximum number of binding > > > > > > Thanks for the comments. I hadn't put too much tought into it, as I > > viewed this more of a product specification type of requirement. > > > > Let's see if anybody has any views on the list. > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx > > > Sent: Friday, November 19, 2004 13:59 > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: [Ietf-behave] Maximum number of binding > > > > > > > > > I like how 'behave-nat-00' classifies different behaviors of > > > NAT. The > > > common term definitions also make my life easier, indeed. > Nice job! > > > > > > One thing I thought... It would be nice to include a > requirement on: > > > > > > - Minimum number of bindings per NAT. > > > > > > Especially, NB=AD and NB=APD consume more memory resource in > > > NAT. The > > > requirement may have to have: > > > > > > - Minimum number of connections (destinations) per binding. > > > > > > I can see that developers especially who are working on > residential > > > gateways, or routers are trying minimize its > > > memory requirement to bring down hardware cost as low as > possible to > > > win > > > the race. Does anyone have any idea or thoughts on above > > > parameters in > > > existing NATs? > > > > > > Thanks, > > > Yutaka > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > From nagendra@cs.stanford.edu Wed, 24 Nov 2004 16:54:15 -0800 (PST) From: nagendra modadugu Date: Wed, 24 Nov 2004 16:54:15 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <46B1443F-3DAD-11D9-8254-0003938AF740@cisco.com> Message-ID: <20041125005413.GB28006@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain > >>TCP-over-UDP would use more bandwidth than TCP or a new > >>"as-good-as-TCP" UDP-based protocol that someone will invent. > >> > >>-d > > > >More bandwidth because of the extra UDP header? > > Right. > > -d Not that I'm recommending userland TCP as a solution, but it's likely to be better behaved than the schemes being designed by the p2p folks (it took so many years for TCP implementations to stabilize and generate friendly quantifyable flows). I'd think that the client programming model will be a bigger issue (handling all the timers in userland, that are otherwise abstracted by the kernel, etc.), than the 8-byte UDP header overhead. nagendra From ml-behave@ringle.org Wed, 24 Nov 2004 17:19:49 -0800 (PST) From: Jon Ringle Date: Wed, 24 Nov 2004 17:19:49 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <95311546-3E48-11D9-95FC-000A95E35274@cisco.com> Message-ID: <200411242003.52967.ml-behave@ringle.org> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 24 November 2004 06:19 pm, Dan Wing wrote: > On Nov 24, 2004, at 11:57 AM, Jon Ringle wrote: > > In regards to to p2p tcp behind NATs, are you familiar with the NUTSS > > research: > > > > http://www.cs.cornell.edu/People/francis/ieee-nutss.pdf > > http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf > > Yes, but I had forgotten about it. Thanks for the pointer. > > > This uses an approach that uses a STUN extension and SIP. For a > > "BEHAVE-compliant" NAT, the port prediction described is not > > necessary, since > > the port prediction is meant to try to deal with symmetric NATs. > > Remember that behave (draft-ietf-behave-nat) only defines UDP behavior, > not TCP behavior. At the meeting in DC, it was agreed that the filename > would be modified to clearly indicate that it covers only UDP. > > TCP behavior would be described in another document. However, to my > knowledge, no one has stepped up to writing the TCP behavior document. > It appears that for p2p TCP to work, we need such a document and we > need testing, akin to Cullen's draft-jennings-midcom-stun-results, to > determine what TCP behavior exists for today's NATs. You mean something like Saikat's work: http://list.sipfoundry.org/archive/ietf-behave/msg00215.html Jon From ThomasGal@LumenVox.com Wed, 24 Nov 2004 17:55:55 -0800 (PST) From: "Thomas Gal" Date: Wed, 24 Nov 2004 17:55:55 -0800 (PST) Subject: RE: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB02758E5C@svr-exc.domain.com> Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630132.multipart/signed" --Boundary..27398.1163630132.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Speaking of documents, I volunteered to work on a BEHAVE testing document and code. Cullen did my email get nabbed by a spam filter? I think we had talked about that stun paper that disappeared, and we might as well merge it all. -Tom thomasgal@xxxxxxxxxxxx > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jon Ringle > Sent: Wednesday, November 24, 2004 5:04 PM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers > > On Wednesday 24 November 2004 06:19 pm, Dan Wing wrote: > > On Nov 24, 2004, at 11:57 AM, Jon Ringle wrote: > > > In regards to to p2p tcp behind NATs, are you familiar with the > > > NUTSS > > > research: > > > > > > http://www.cs.cornell.edu/People/francis/ieee-nutss.pdf > > > http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf > > > > Yes, but I had forgotten about it. Thanks for the pointer. > > > > > This uses an approach that uses a STUN extension and SIP. For a > > > "BEHAVE-compliant" NAT, the port prediction described is not > > > necessary, since the port prediction is meant to try to deal with > > > symmetric NATs. > > > > Remember that behave (draft-ietf-behave-nat) only defines UDP > > behavior, not TCP behavior. At the meeting in DC, it was > agreed that > > the filename would be modified to clearly indicate that it > covers only UDP. > > > > TCP behavior would be described in another document. > However, to my > > knowledge, no one has stepped up to writing the TCP > behavior document. > > It appears that for p2p TCP to work, we need such a document and we > > need testing, akin to Cullen's > draft-jennings-midcom-stun-results, to > > determine what TCP behavior exists for today's NATs. > > You mean something like Saikat's work: > http://list.sipfoundry.org/archive/ietf-behave/msg00215.html > > Jon > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > Attachment: smime.p7s --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="p7s00000.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7s00000.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMCTCCBMQw ggKsoAMCAQICAwDMSDANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNDExMTkxNjA0NDlaFw0w NTExMTkxNjA0NDlaMEExGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjElMCMGCSqGSIb3DQEJARYW dGhvbWFzZ2FsQGx1bWVudm94LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKmW HVujvQPzLRxeFDw0oQywCwWy8UfIw2zW16AvERBWu1Q9lpnuN/lD+G0FK8QGcyenXMKmBZ8I61Oe KnnuLzEoSkkGklIH5CMhf1ANUecnlfHVF6ofAzdwcUoFUnhe4ZcvgOVv1JjGT7Qxp/7xHEQqIPJQ qt2WaSqXcLUeF6n69HRDGtSgPHsPGkaZzg+ArKuI1Jou0vrjPHHZcYCL0X26ig5GW6itAYNi9uz2 yzdUUYWL/vy0ZEQkIrStHlGr5nZGoxYW+X99z4G4pYOlWHvfTTD8Pe8sbbGfHWXX8++KilDAInEx K3XMBx4Dmm8nbOo5058XZPSSMJVwxxqWvO0CAwEAAaOBjDCBiTAMBgNVHRMBAf8EAjAAMFYGCWCG SAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVy IHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAhBgNVHREEGjAYgRZ0aG9tYXNnYWxAbHVtZW52b3gu Y29tMA0GCSqGSIb3DQEBBAUAA4ICAQB9Ld6CCMyIKqePp8KXWoWOJcijRMxF5BJe/F/xApg12EQE hLEaOzqS8ltdrXjvkRxuifjM/79ApcKkb+BMxTJ43+hkzSO61rR5hwdQRZvrCgGPg66JcXTqpqYe j5mEOJSkpa9qS0nZRD6eMN2ci+vmCyHvdH+l6veUPJRPt42qZ26zZMYJSz591VNycx0Bie1xJ23A /n6JuBu7sAsLKtfncNTQaCX+KdcxEidTmy6YhzfUBtQPA92WRIOqcTz9tLzgAggRu/4ka/Qx2zVE fEJzGJ84DQE8Q3gcKhoLEyjNUemypRaij1Fgc+I2YXoolTgFMlcr/YPgzu/q7vQSbOm+3f2OoZG9 SK7zLg8S39f8XNNlsv9wwXG9TFeuveiMnDClAsFhLVFfB41nYkk9JISiCQC/+x55hspmKTk3B2Rr cjROCT5wCkBjZl9KEcMGu0wF1V7JQCTv2tY2rl04BuW+/pSNeV5xUkxUZYl6pIuwdP5e0H5ioNNc Exu6yVNguL7mP8IntnS1UUEuHXRPDUo256+4lZT56zs7iNbLIWjVo7K2ZpBT/T88RG/xjZ8JFSuh VzjRGXJvE3Rm+9Ja8GlH9JqCLXqRDwRwmtZg11Kw68t3lqzTcVo3G8GTZSs1Xxye3PGW1fwhvdUw aJXy+qUSdQRbUqQRI2qwXsq3iwhUIDCCBz0wggUloAMCAQICAQAwDQYJKoZIhvcNAQEEBQAweTEQ MA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQD ExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy dC5vcmcwHhcNMDMwMzMwMTIyOTQ5WhcNMzMwMzI5MTIyOTQ5WjB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAM4iwOJGfew2KAdQlvKgM0CMS/E7Zj8x5WsCNtvWfPbxiI9O dzYFQZX5CfASz0aGc2C3bn7owFhkrs2wrUUXDGP6Zwro1tK/PueYxPBM+uADuzVdbCHeniDZus1m Mjdy+vcI9cfNWMmO5w5e6j7+HKEUChVshoRbZGYqeqlLU3n1iKJ77i8KYSuNsn5NVqUT7Orakp6s REEeWGBlBWb4wES9y5T3Qn4L92VomFEF8PMFkQQdGxeC7MhXu8NreojxsHLMJVsgkewWAhKPMukX GEjQxwUuAjBCuCWcBWs/qjqn61NI9+jStgeY3BvGNH9/yRyCegVYKwhb8ziiqxddZsmY154Qi6LS 3XSa93EMcmDfzW+YM52WNHY+JHqSsA6VHm/moEU4R6rXQe1KtxL21xuDig8u2Am2WdeqBP/Sk31o Lt2LS6tYui+N6pWnoMNUiaX724tRIp2yw74RviyRhouWeK0g04ovGj/G0FFlhyGxGQFlf0Uch/V8 0EFMTymYIf0zH3UMBFH6GXfb1BQc7oHDHfWYt2kGkSLdAFDMgTGsEgd7ONpoW+Yr1H7JX63o63JM 8wHlSyC/mqZXypEAAYuhdSE3tWMNZz5GT3AgZ87F1lnbAuDw0svNumK3kEHo3SDkKbxkKULIItx4 mv9D7JgbCVFLWlrCcfHEy3Op5aELAgMBAAGjggHOMIIByjAdBgNVHQ4EFgQUFrUyG9TH8+DmjvO9 0rA67rI5GNEwgaMGA1UdIwSBmzCBmIAUFrUyG9TH8+DmjvO90rA67rI5GNGhfaR7MHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn ggEAMA8GA1UdEwEB/wQFMAMBAf8wMgYDVR0fBCswKTAnoCWgI4YhaHR0cHM6Ly93d3cuY2FjZXJ0 Lm9yZy9yZXZva2UuY3JsMDAGCWCGSAGG+EIBBAQjFiFodHRwczovL3d3dy5jYWNlcnQub3JnL3Jl dm9rZS5jcmwwNAYJYIZIAYb4QgEIBCcWJWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZy9pbmRleC5waHA/ aWQ9MTAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5jYWNlcnQub3JnMA0GCSqGSIb3DQEBBAUAA4ICAQAo x+6cggK6XIASyjUKHYFviWqZzPJoD3+n4Y1YlT698gbDkFqstWD2mUMBo4hwnJ1inaSHr2dYDTA2 O+atSNPLdAKGcT7iKwNo8TRiQEY7U+oo9Kz7ZpVTik1d/TvZYNfKeWk7sWWSpsaBglyczetNAYql 3xFVqhXKHzfAgphwYdtqfJajji5UPk8hqZDv3IK/3OhFrU2Qcwg8lGWwBJl2f+K8wmoVqpcENyTY HpRObQ5RvtbEj8qWbfdD3+gwZSc7e7tDQ2PEQ/ey7GjM4RmOIvuY4XtaPgE3O4sIsKLzlU4ay5vN mrHbsnDwLUrb2LDjb0VIMxL//jwyKlT3xPeK8Igjwkf+ZHpxwNEepmOwB36kL9MBj9yfK7bGCKkP k0gl/BL9n0Lc88Q+9lew191p0QZ3NApL0sqg/xzGjMkWvsTMMjdoc18I+1H3SVM2BQqVAkzyeRoQ 9tg6dZzzHfGiDXBnhhuzFvUv5aTreYb5PQvCcwulmaxv/Ge45S8LphgkjXvRSDUpGECsk2DhloZQ tHpZ2I8hC5/PgpHGO79r3AeRuZdWI6q2bJTGSAY85M5OquT2LwncU28u/HTrOmOZwqasibynskSg DYoQ42zyJMv6m59wRy7eFIvUsiAJlqJk8SQc3KE1nBWy1LxVLn0G9ZwOVfRa1pPadq0lc0zFQzGC A5wwggOYAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2Fj ZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJ ARYSc3VwcG9ydEBjYWNlcnQub3JnAgMAzEgwCQYFKw4DAhoFAKCCAfAwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTI1MDE1NTUwWjAjBgkqhkiG9w0BCQQxFgQU 457t9JzeerSlQwqRux0DmJpZ4+IwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhow CgYIKoZIhvcNAgUwgZEGCSsGAQQBgjcQBDGBgzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAMxIMIGTBgsqhkiG9w0B CRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2Vy dC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAMxIMA0GCSqGSIb3DQEBAQUABIIBADoeH2uYePthkyoX+R4R PjB+6DqPI51yooNX7bfukkXd4lkM9hduGzA06URw+9Cndf9yUDe4ZgAkumr+nruzEw9UL9F4Zuyc tNVQW2hIJ4kKafHdrXfzw0ACK/xmohhnXWVzjAQP4+tNVY27xgY4PqAz7AQghTI7vG3jHRPpFpT7 UhwX5SGKceRvJ8oloAFm7Lt69XwIN1kdbTNCkU0Xw4YEpwlUrDYtjOaThxb8+KMNEhXi3p9O4c3u aYXjvgLUEObLK8AqsLwwygO7qfVApla1nFfbZzynfKR6Dh8CObKDmrq1JVzaijhrLr5lcr1lqIbA yHH2EmTgVVGY14QRrckAAAAAAAA= --Boundary..27398.1163630132.multipart/signed-- From spencer@mcsr-labs.org Wed, 24 Nov 2004 19:27:58 -0800 (PST) From: "Spencer Dawkins" Date: Wed, 24 Nov 2004 19:27:58 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: Message-ID: <1d6e01c4d29e$e85b4da0$90878182@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain I think most residential routers do not understand DCCP and discard it because DCCP is another transport layer protocol with another 'protocol number'. I might have misunderstood the point of this thread, but this SEEMED to be the issue - since DCCP is another transport protocol (albeit one that hasn't made it to RFC yet), the cable modem with a builtin NAT you bought last week will look at the packet, decide it doesn't know what to do with Protocol 33 ("informally made available for experimental DCCP use", quoting the current draft), and drop the packets on the floor. So the hope would be that TCP-over-UDP would pass unscathed through the same cable modem with a builtin NAT, because it's just dorking with the outermost UDP headers, and not noticing that the "application protocol" seems to be TCP. If your cable modem with a builtin NAT doesn't think it's also an ALG, that could work. If you DO have a Very Helpful cable modem with a builtin NAT and ALG, the ALG will notice that the "application protocol" doesn't seem to be HTTP, SMTP, POP3, or some other widely-deployed TCP-based client-server protocol, and will ALSO drop the packets on the floor. If I caught the drift. Besides getting p2p-TCP to work through NATs, we might want to look into RUDP that IETF once explored in the past, and that implements congestion&flow control like TCP. http://www.ietf.org/proceedings/99mar/I-D/draft-ietf-sigtran-reliable-udp-00.txt which was derived from RDP: - rfc 980 (version 1) - rfc 1151 (version 2), I am always eager to learn, but do not understand at this time why RUDP would be simpler than TCP over UDP, if the point is to pole-vault over a NAT that has UDP policies that we like better than its TCP policies. At the very least, we should be clear on what we're trying to achieve. We threw DCCP into the discussion, but nobody explained why DCCP (with congestion avoidance but no transport-level retransmissions) would be a good protocol for file transfers (maybe we changed topics, but that WAS the subject of the thread I'm replying to!)... Spencer From dwing@cisco.com Wed, 24 Nov 2004 22:30:13 -0800 (PST) From: Dan Wing Date: Wed, 24 Nov 2004 22:30:13 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <46B1443F-3DAD-11D9-8254-0003938AF740@cisco.com> Message-ID: <82584DB9-3EAB-11D9-94B6-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I couldn't agree more. However, when was the last time you met someone in the computer industry who didn't think they could Do Better? -d On Nov 24, 2004, at 4:54 PM, nagendra modadugu wrote: TCP-over-UDP would use more bandwidth than TCP or a new "as-good-as-TCP" UDP-based protocol that someone will invent. -d More bandwidth because of the extra UDP header? Right. -d Not that I'm recommending userland TCP as a solution, but it's likely to be better behaved than the schemes being designed by the p2p folks (it took so many years for TCP implementations to stabilize and generate friendly quantifyable flows). I'd think that the client programming model will be a bigger issue (handling all the timers in userland, that are otherwise abstracted by the kernel, etc.), than the 8-byte UDP header overhead. nagendra From dwing@cisco.com Wed, 24 Nov 2004 22:36:48 -0800 (PST) From: Dan Wing Date: Wed, 24 Nov 2004 22:36:48 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <95311546-3E48-11D9-95FC-000A95E35274@cisco.com> Message-ID: <6F9BEE52-3EAC-11D9-94B6-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Nov 24, 2004, at 5:03 PM, Jon Ringle wrote: On Wednesday 24 November 2004 06:19 pm, Dan Wing wrote: On Nov 24, 2004, at 11:57 AM, Jon Ringle wrote: In regards to to p2p tcp behind NATs, are you familiar with the NUTSS research: http://www.cs.cornell.edu/People/francis/ieee-nutss.pdf http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf Yes, but I had forgotten about it. Thanks for the pointer. This uses an approach that uses a STUN extension and SIP. For a "BEHAVE-compliant" NAT, the port prediction described is not necessary, since the port prediction is meant to try to deal with symmetric NATs. Remember that behave (draft-ietf-behave-nat) only defines UDP behavior, not TCP behavior. At the meeting in DC, it was agreed that the filename would be modified to clearly indicate that it covers only UDP. TCP behavior would be described in another document. However, to my knowledge, no one has stepped up to writing the TCP behavior document. It appears that for p2p TCP to work, we need such a document and we need testing, akin to Cullen's draft-jennings-midcom-stun-results, to determine what TCP behavior exists for today's NATs. You mean something like Saikat's work: http://list.sipfoundry.org/archive/ietf-behave/msg00215.html Yes, thanks. The key, though, is to run that test against all of the NATs available at Circuit City, Fry's, Best Buy, and their EMEA and AsiaPac equivalents, and throw in a few NATs that are resold/leased by service providers in each of those markets, and publish the results. With that we can spend efforts to solving the problems that are solvable by today's NATs. For example, from Cullen's experiments we learned that symmetric NATs are a mostly-theoretical problem, and don't exist in quantity in the wild. -d From sg266@cornell.edu Thu, 25 Nov 2004 02:53:26 -0800 (PST) From: Saikat Guha Date: Thu, 25 Nov 2004 02:53:26 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <95311546-3E48-11D9-95FC-000A95E35274@cisco.com> Message-ID: <1101379999.10133.52.camel@broomhilde.guha.cc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630132.multipart/signed" --Boundary..27398.1163630132.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2004-11-24 at 15:19 -0800, Dan Wing wrote: > TCP behavior would be described in another document. However, to my > knowledge, no one has stepped up to writing the TCP behavior document. > It appears that for p2p TCP to work, we need such a document and we > need testing, akin to Cullen's draft-jennings-midcom-stun-results, to > determine what TCP behavior exists for today's NATs. I will volunteer for this. I have been testing NATs for TCP traversal and have some preliminary data based on the 13 or so NATs that I could find readily. I would like the opportunity to test it on both a wider spectrum of NATs and on a distribution of NATs that represent market penetration of the various models. Please contact me if you can donate some computer time; the test client can be downloaded from http://www.cs.cornell.edu/~saikat/NATs.html Ongoing test results are available at http://www.cs.cornell.edu/~saikat/NAT-results.htm -- Saikat Attachment: signature.asc --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="pgp00013.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00013.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi42IChHTlUv TGludXgpCgppRDhEQlFCQnBibWZuRmx0cWk2OTEvb1JBaThuQUo0MmgzVzFURTBJVmJjanA5QzND N2lFOVR0SVBRQ2ZTSkl1Cjd5WklpN29MeXNDb2NkeUJaTmpXRlZZPQo9NHV3WQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630132.multipart/signed-- From mshore@cisco.com Thu, 25 Nov 2004 06:27:26 -0800 (PST) From: Melinda Shore Date: Thu, 25 Nov 2004 06:27:26 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <1d6e01c4d29e$e85b4da0$90878182@DFNJGL21> Message-ID: <0EE454A0-3EEE-11D9-95FC-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Wednesday, November 24, 2004, at 10:29 PM, Spencer Dawkins wrote: At the very least, we should be clear on what we're trying to achieve. We threw DCCP into the discussion, but nobody explained why DCCP (with congestion avoidance but no transport-level retransmissions) would be a good protocol for file transfers (maybe we changed topics, but that WAS the subject of the thread I'm replying to!)... It's not, particularly, but if the problem to be solved is a NAT- friendly-ish transport protocol that doesn't misbehave on the network, DCCP would probably be the closest of what's currently available. That said, I'm not particularly a DCCP fan - I think the cost/benefit tradeoff is kind of marginal in many cases. Melinda From ssenthil@cisco.com Thu, 25 Nov 2004 11:40:48 -0800 (PST) From: Senthil Sivakumar Date: Thu, 25 Nov 2004 11:40:48 -0800 (PST) Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers In-Reply-To: <5404361A-3E6F-11D9-94B6-0003938AF740@cisco.com> Message-ID: <4.3.2.7.2.20041125113527.0327b728@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I have expressed my willingness to Cullen to spend some time to work on the TCP behavior document.. Senthil At 05:53 AM 11/25/2004 -0500, Saikat Guha wrote: On Wed, 2004-11-24 at 15:19 -0800, Dan Wing wrote: > TCP behavior would be described in another document. However, to my > knowledge, no one has stepped up to writing the TCP behavior document. > It appears that for p2p TCP to work, we need such a document and we > need testing, akin to Cullen's draft-jennings-midcom-stun-results, to > determine what TCP behavior exists for today's NATs. I will volunteer for this. I have been testing NATs for TCP traversal and have some preliminary data based on the 13 or so NATs that I could find readily. I would like the opportunity to test it on both a wider spectrum of NATs and on a distribution of NATs that represent market penetration of the various models. Please contact me if you can donate some computer time; the test client can be downloaded from http://www.cs.cornell.edu/~saikat/NATs.html Ongoing test results are available at http://www.cs.cornell.edu/~saikat/NAT-results.htm -- Saikat _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From ssenthil@cisco.com Thu, 25 Nov 2004 11:45:23 -0800 (PST) From: Senthil Sivakumar Date: Thu, 25 Nov 2004 11:45:23 -0800 (PST) Subject: Re: [Ietf-behave] Maximum number of binding In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01127D59@zrc2hxm0.corp.nortel.com> Message-ID: <4.3.2.7.2.20041125114202.0325e748@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain At 04:47 PM 11/24/2004 -0800, Dan Wing wrote: Section 3.2, "port assignment", needs to discuss running out of ports. I suggest adding another paragraph, probably right after the paragraph discussing the 1-1023 and 1024-65535 ranges: In high-load situations, a NAT may exhaust its source UDP port range. If such an event occurs, o the NAT MUST NOT prematurely re-use a UDP port, as this may cause a datagram from the old UDP binding to be injected into the new UDP binding, and; o the NAT MUST NOT use a source UDP port from the other UDP port range, and; What is the use of the above restriction/requirement? o it is strongly RECOMMENDED that the NAT send an ICMP message type=3, code=0 ("net unreachable") in response to the UDP packet, and; o Alternatively, but less preferred, the NAT SHOULD simply drop the UDP packet and not transmit it on the public side of the NAT. Shouldn't this be a MUST? Senthil (I noticed that 'public side' and 'private side' aren't defined in draft-ietf-behave-nat-00, so replace that term appropriately in my suggested paragraph above.) -d On Nov 24, 2004, at 4:29 PM, Francois Audet wrote: Let me know if there is some precise wording that needs to be added, and where. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Wednesday, November 24, 2004 16:03 > To: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx; Audet, Francois [SC100:9T51:EXCH] > Subject: Re: [Ietf-behave] Maximum number of binding > > > ICMP type=3, code=2 is "protocol unreachable" which most closely > indicates the problem the NAT is attempting to communicate. However, > code=2 can only be sent by the destination host. So ICMP type=3, > code=0 "net unreachable" is probably best. > > -d > > On Nov 24, 2004, at 3:04 PM, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: > > > If number of simultaneous connections per binding exceeds what a NAT > > can have, the NAT might either overwrite an existing > binding for a new > > connection or do nothing with the new connection, and there > is no way > > for an application to know what is going on... this is the > problem. I > > think Teredo is a good example, which encapsulates multiple IPv6 > > TCP/UDP connection to many remote hosts on a single IPv4 UDP socket > > binding assuming that a NAT can have enough number of > connections on a > > single binding (especially when NB=AD or APD). I feel at > least in such > > a case the NAT could send a new ICMP error like "Too many > connections" > > back to a connecting node, IMHO. > > > > Yutaka > > > > ----- Original Message ----- > > From: Francois Audet > > To: Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx ; > > 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > Sent: Friday, November 19, 2004 3:57 PM > > Subject: RE: [Ietf-behave] Maximum number of binding > > > > > > Thanks for the comments. I hadn't put too much tought into it, as I > > viewed this more of a product specification type of requirement. > > > > Let's see if anybody has any views on the list. > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx > > > Sent: Friday, November 19, 2004 13:59 > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: [Ietf-behave] Maximum number of binding > > > > > > > > > I like how 'behave-nat-00' classifies different behaviors of > > > NAT. The > > > common term definitions also make my life easier, indeed. > Nice job! > > > > > > One thing I thought... It would be nice to include a > requirement on: > > > > > > - Minimum number of bindings per NAT. > > > > > > Especially, NB=AD and NB=APD consume more memory resource in > > > NAT. The > > > requirement may have to have: > > > > > > - Minimum number of connections (destinations) per binding. > > > > > > I can see that developers especially who are working on > residential > > > gateways, or routers are trying minimize its > > > memory requirement to bring down hardware cost as low as > possible to > > > win > > > the race. Does anyone have any idea or thoughts on above > > > parameters in > > > existing NATs? > > > > > > Thanks, > > > Yutaka > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Thu, 25 Nov 2004 12:39:47 -0800 (PST) From: Dan Wing Date: Thu, 25 Nov 2004 12:39:47 -0800 (PST) Subject: Re: [Ietf-behave] Maximum number of binding In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01127D59@zrc2hxm0.corp.nortel.com> Message-ID: <34015CD6-3F22-11D9-BE4F-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Nov 25, 2004, at 11:46 AM, Senthil Sivakumar wrote: At 04:47 PM 11/24/2004 -0800, Dan Wing wrote: Section 3.2, "port assignment", needs to discuss running out of ports. I suggest adding another paragraph, probably right after the paragraph discussing the 1-1023 and 1024-65535 ranges: In high-load situations, a NAT may exhaust its source UDP port range. If such an event occurs, o the NAT MUST NOT prematurely re-use a UDP port, as this may cause a datagram from the old UDP binding to be injected into the new UDP binding, and; o the NAT MUST NOT use a source UDP port from the other UDP port range, and; What is the use of the above restriction/requirement? See the discussion in section 3.2 of draft-ietf-behave-nat-00.txt regarding the well-known, registered, and dynamic port ranges. o it is strongly RECOMMENDED that the NAT send an ICMP message type=3, code=0 ("net unreachable") in response to the UDP packet, and; o Alternatively, but less preferred, the NAT SHOULD simply drop the UDP packet and not transmit it on the public side of the NAT. Shouldn't this be a MUST? Sure, how about rewording that last bullet to: o If the NAT doesn't send the above-described ICMP message, the NAT MUST drop the UDP packet and not transmit it on the public side of the NAT. -d Senthil (I noticed that 'public side' and 'private side' aren't defined in draft-ietf-behave-nat-00, so replace that term appropriately in my suggested paragraph above.) -d On Nov 24, 2004, at 4:29 PM, Francois Audet wrote: Let me know if there is some precise wording that needs to be added, and where. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Wednesday, November 24, 2004 16:03 > To: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx; Audet, Francois [SC100:9T51:EXCH] > Subject: Re: [Ietf-behave] Maximum number of binding > > > ICMP type=3, code=2 is "protocol unreachable" which most closely > indicates the problem the NAT is attempting to communicate. However, > code=2 can only be sent by the destination host. So ICMP type=3, > code=0 "net unreachable" is probably best. > > -d > > On Nov 24, 2004, at 3:04 PM, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: > > > If number of simultaneous connections per binding exceeds what a NAT > > can have, the NAT might either overwrite an existing > binding for a new > > connection or do nothing with the new connection, and there > is no way > > for an application to know what is going on... this is the > problem. I > > think Teredo is a good example, which encapsulates multiple IPv6 > > TCP/UDP connection to many remote hosts on a single IPv4 UDP socket > > binding assuming that a NAT can have enough number of > connections on a > > single binding (especially when NB=AD or APD). I feel at > least in such > > a case the NAT could send a new ICMP error like "Too many > connections" > > back to a connecting node, IMHO. > > > > Yutaka > > > > ----- Original Message ----- > > From: Francois Audet > > To: Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx ; > > 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > Sent: Friday, November 19, 2004 3:57 PM > > Subject: RE: [Ietf-behave] Maximum number of binding > > > > > > Thanks for the comments. I hadn't put too much tought into it, as I > > viewed this more of a product specification type of requirement. > > > > Let's see if anybody has any views on the list. > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx > > > Sent: Friday, November 19, 2004 13:59 > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: [Ietf-behave] Maximum number of binding > > > > > > > > > I like how 'behave-nat-00' classifies different behaviors of > > > NAT. The > > > common term definitions also make my life easier, indeed. > Nice job! > > > > > > One thing I thought... It would be nice to include a > requirement on: > > > > > > - Minimum number of bindings per NAT. > > > > > > Especially, NB=AD and NB=APD consume more memory resource in > > > NAT. The > > > requirement may have to have: > > > > > > - Minimum number of connections (destinations) per binding. > > > > > > I can see that developers especially who are working on > residential > > > gateways, or routers are trying minimize its > > > memory requirement to bring down hardware cost as low as > possible to > > > win > > > the race. Does anyone have any idea or thoughts on above > > > parameters in > > > existing NATs? > > > > > > Thanks, > > > Yutaka > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From spencer@mcsr-labs.org Thu, 25 Nov 2004 20:50:50 -0800 (PST) From: "Spencer Dawkins" Date: Thu, 25 Nov 2004 20:50:50 -0800 (PST) Subject: Re: [Ietf-behave] Maximum number of binding In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01127D59@zrc2hxm0.corp.nortel.com> Message-ID: <1ec001c4d373$a566e420$90878182@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain I understand that we're trolling the depths of aberrent behavior here, but has anyone seen a NAT that cannot allocate a UDP source port (due to a large number of bindings leading to port exhaustion, as previously described) and still transmits the packet on the public side of the NAT? o it is strongly RECOMMENDED that the NAT send an ICMP message type=3, code=0 ("net unreachable") in response to the UDP packet, and; o Alternatively, but less preferred, the NAT SHOULD simply drop the UDP packet and not transmit it on the public side of the NAT. Shouldn't this be a MUST? Sure, how about rewording that last bullet to: o If the NAT doesn't send the above-described ICMP message, the NAT MUST drop the UDP packet and not transmit it on the public side of the NAT. I'm just trying to understand how precise we need to be in describing MUST NOT behavior. Thanks, Spencer From yutaka_takeda@playstation.sony.com Fri, 26 Nov 2004 13:14:51 -0800 (PST) From: yutaka_takeda@playstation.sony.com Date: Fri, 26 Nov 2004 13:14:51 -0800 (PST) Subject: Re: [Ietf-behave] Maximum number of binding In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01127D59@zrc2hxm0.corp.nortel.com> Message-ID: <001f01c4d3fc$f6342b90$4503620a@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain > In high-load situations, a NAT may exhaust its source UDP port range. > If such an event occurs, Let me make sure if we are on the same boat. Besides the source UDP port range (space) exhaustion, I am also concerned about binding resource exhaustion in NAT. Say, a NAT has NB=I and EF=ADP properties, and a host wants to send UDP packets to outside from a single source port bound to a socket. Although the NAT only needs one external port, the NAT has to remember each packets destination address and port number for filtering. Then, "how many transport addresses associated to the single binding the NAT can remember?" is my question. (I just realized that I said 'NB' where I meant 'EF' in my previous postings. Sorry.) > o the NAT MUST NOT prematurely re-use a UDP port, as > this may cause a datagram from the old UDP binding to be > injected into the new UDP binding, and; I agree. > o the NAT MUST NOT use a source UDP port from the > other UDP port range, and; I agree. > o it is strongly RECOMMENDED that the NAT send an ICMP > message type=3, code=0 ("net unreachable") in response to the > UDP packet, and; Is there a reason why this cannot be a MUST. > o Alternatively, but less preferred, the NAT SHOULD simply drop > the UDP packet and not transmit it on the public side of the NAT. I feel this needs to be a MUST. Yutaka ----- Original Message ----- From: "Dan Wing" To: "Francois Audet" Cc: ; Sent: Wednesday, November 24, 2004 4:47 PM Subject: Re: [Ietf-behave] Maximum number of binding Section 3.2, "port assignment", needs to discuss running out of ports. I suggest adding another paragraph, probably right after the paragraph discussing the 1-1023 and 1024-65535 ranges: In high-load situations, a NAT may exhaust its source UDP port range. If such an event occurs, o the NAT MUST NOT prematurely re-use a UDP port, as this may cause a datagram from the old UDP binding to be injected into the new UDP binding, and; o the NAT MUST NOT use a source UDP port from the other UDP port range, and; o it is strongly RECOMMENDED that the NAT send an ICMP message type=3, code=0 ("net unreachable") in response to the UDP packet, and; o Alternatively, but less preferred, the NAT SHOULD simply drop the UDP packet and not transmit it on the public side of the NAT. (I noticed that 'public side' and 'private side' aren't defined in draft-ietf-behave-nat-00, so replace that term appropriately in my suggested paragraph above.) -d On Nov 24, 2004, at 4:29 PM, Francois Audet wrote: > Let me know if there is some precise wording that needs to be added, > and where. > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Wednesday, November 24, 2004 16:03 > > To: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx; Audet, Francois > [SC100:9T51:EXCH] > > Subject: Re: [Ietf-behave] Maximum number of binding > > > > > > ICMP type=3, code=2 is "protocol unreachable" which most closely > > indicates the problem the NAT is attempting to communicate. However, > > code=2 can only be sent by the destination host. So ICMP type=3, > > code=0 "net unreachable" is probably best. > > > > -d > > > > On Nov 24, 2004, at 3:04 PM, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > wrote: > > > > > If number of simultaneous connections per binding exceeds what a > NAT > > > can have, the NAT might either overwrite an existing > > binding for a new > > > connection or do nothing with the new connection, and there > > is no way > > > for an application to know what is going on... this is the > > problem. I > > > think Teredo is a good example, which encapsulates multiple IPv6 > > > TCP/UDP connection to many remote hosts on a single IPv4 UDP socket > > > binding assuming that a NAT can have enough number of > > connections on a > > > single binding (especially when NB=AD or APD). I feel at > > least in such > > > a case the NAT could send a new ICMP error like "Too many > > connections" > > > back to a connecting node, IMHO. > > > > > > Yutaka > > > > > > ----- Original Message ----- > > > From: Francois Audet > > > To: Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx ; > > > 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > > Sent: Friday, November 19, 2004 3:57 PM > > > Subject: RE: [Ietf-behave] Maximum number of binding > > > > > > > > > Thanks for the comments. I hadn't put too much tought into it, as I > > > viewed this more of a product specification type of requirement. > > > > > > Let's see if anybody has any views on the list. > > > > > > > -----Original Message----- > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > > Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx > > > > Sent: Friday, November 19, 2004 13:59 > > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Subject: [Ietf-behave] Maximum number of binding > > > > > > > > > > > > I like how 'behave-nat-00' classifies different behaviors of > > > > NAT. The > > > > common term definitions also make my life easier, indeed. > > Nice job! > > > > > > > > One thing I thought... It would be nice to include a > > requirement on: > > > > > > > > - Minimum number of bindings per NAT. > > > > > > > > Especially, NB=AD and NB=APD consume more memory resource in > > > > NAT. The > > > > requirement may have to have: > > > > > > > > - Minimum number of connections (destinations) per binding. > > > > > > > > I can see that developers especially who are working on > > residential > > > > gateways, or routers are trying minimize its > > > > memory requirement to bring down hardware cost as low as > > possible to > > > > win > > > > the race. Does anyone have any idea or thoughts on above > > > > parameters in > > > > existing NATs? > > > > > > > > Thanks, > > > > Yutaka > > > > > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > From kbiswas@cisco.com Sat, 27 Nov 2004 13:09:44 -0800 (PST) From: Kaushik Biswas Date: Sat, 27 Nov 2004 13:09:44 -0800 (PST) Subject: Re: [Ietf-behave] Maximum number of binding In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01127D59@zrc2hxm0.corp.nortel.com> Message-ID: <4.3.2.7.2.20041127130242.0220d518@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain At 01:14 PM 11/26/2004 -0800, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: > In high-load situations, a NAT may exhaust its source UDP port range. > If such an event occurs, Shouldn't we reword this to include Address & Port exhaustion to be more specific so as to avoid any confusions ? UDP port-range for one NAT public-address can exhaust but NAT can still pick up the next public-address from its address-pool(s) and start using the port-range associated with that. -Kaushik Let me make sure if we are on the same boat. Besides the source UDP port range (space) exhaustion, I am also concerned about binding resource exhaustion in NAT. Say, a NAT has NB=I and EF=ADP properties, and a host wants to send UDP packets to outside from a single source port bound to a socket. Although the NAT only needs one external port, the NAT has to remember each packets destination address and port number for filtering. Then, "how many transport addresses associated to the single binding the NAT can remember?" is my question. (I just realized that I said 'NB' where I meant 'EF' in my previous postings. Sorry.) > o the NAT MUST NOT prematurely re-use a UDP port, as > this may cause a datagram from the old UDP binding to be > injected into the new UDP binding, and; I agree. > o the NAT MUST NOT use a source UDP port from the > other UDP port range, and; I agree. > o it is strongly RECOMMENDED that the NAT send an ICMP > message type=3, code=0 ("net unreachable") in response to the > UDP packet, and; Is there a reason why this cannot be a MUST. > o Alternatively, but less preferred, the NAT SHOULD simply drop > the UDP packet and not transmit it on the public side of the NAT. I feel this needs to be a MUST. Yutaka ----- Original Message ----- From: "Dan Wing" To: "Francois Audet" Cc: ; Sent: Wednesday, November 24, 2004 4:47 PM Subject: Re: [Ietf-behave] Maximum number of binding Section 3.2, "port assignment", needs to discuss running out of ports. I suggest adding another paragraph, probably right after the paragraph discussing the 1-1023 and 1024-65535 ranges: In high-load situations, a NAT may exhaust its source UDP port range. If such an event occurs, o the NAT MUST NOT prematurely re-use a UDP port, as this may cause a datagram from the old UDP binding to be injected into the new UDP binding, and; o the NAT MUST NOT use a source UDP port from the other UDP port range, and; o it is strongly RECOMMENDED that the NAT send an ICMP message type=3, code=0 ("net unreachable") in response to the UDP packet, and; o Alternatively, but less preferred, the NAT SHOULD simply drop the UDP packet and not transmit it on the public side of the NAT. (I noticed that 'public side' and 'private side' aren't defined in draft-ietf-behave-nat-00, so replace that term appropriately in my suggested paragraph above.) -d On Nov 24, 2004, at 4:29 PM, Francois Audet wrote: > Let me know if there is some precise wording that needs to be added, > and where. > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Wednesday, November 24, 2004 16:03 > > To: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx; Audet, Francois > [SC100:9T51:EXCH] > > Subject: Re: [Ietf-behave] Maximum number of binding > > > > > > ICMP type=3, code=2 is "protocol unreachable" which most closely > > indicates the problem the NAT is attempting to communicate. However, > > code=2 can only be sent by the destination host. So ICMP type=3, > > code=0 "net unreachable" is probably best. > > > > -d > > > > On Nov 24, 2004, at 3:04 PM, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > wrote: > > > > > If number of simultaneous connections per binding exceeds what a > NAT > > > can have, the NAT might either overwrite an existing > > binding for a new > > > connection or do nothing with the new connection, and there > > is no way > > > for an application to know what is going on... this is the > > problem. I > > > think Teredo is a good example, which encapsulates multiple IPv6 > > > TCP/UDP connection to many remote hosts on a single IPv4 UDP socket > > > binding assuming that a NAT can have enough number of > > connections on a > > > single binding (especially when NB=AD or APD). I feel at > > least in such > > > a case the NAT could send a new ICMP error like "Too many > > connections" > > > back to a connecting node, IMHO. > > > > > > Yutaka > > > > > > ----- Original Message ----- > > > From: Francois Audet > > > To: Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx ; > > > 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > > Sent: Friday, November 19, 2004 3:57 PM > > > Subject: RE: [Ietf-behave] Maximum number of binding > > > > > > > > > Thanks for the comments. I hadn't put too much tought into it, as I > > > viewed this more of a product specification type of requirement. > > > > > > Let's see if anybody has any views on the list. > > > > > > > -----Original Message----- > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > > Yutaka_Takeda@xxxxxxxxxxxxxxxxxxxx > > > > Sent: Friday, November 19, 2004 13:59 > > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Subject: [Ietf-behave] Maximum number of binding > > > > > > > > > > > > I like how 'behave-nat-00' classifies different behaviors of > > > > NAT. The > > > > common term definitions also make my life easier, indeed. > > Nice job! > > > > > > > > One thing I thought... It would be nice to include a > > requirement on: > > > > > > > > - Minimum number of bindings per NAT. > > > > > > > > Especially, NB=AD and NB=APD consume more memory resource in > > > > NAT. The > > > > requirement may have to have: > > > > > > > > - Minimum number of connections (destinations) per binding. > > > > > > > > I can see that developers especially who are working on > > residential > > > > gateways, or routers are trying minimize its > > > > memory requirement to bring down hardware cost as low as > > possible to > > > > win > > > > the race. Does anyone have any idea or thoughts on above > > > > parameters in > > > > existing NATs? > > > > > > > > Thanks, > > > > Yutaka > > > > > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Mon, 29 Nov 2004 10:01:46 -0800 (PST) From: Dan Wing Date: Mon, 29 Nov 2004 10:01:46 -0800 (PST) Subject: Re: [Ietf-behave] Maximum number of binding In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01127D59@zrc2hxm0.corp.nortel.com> Message-ID: <4B7DAE98-4226-11D9-8765-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Nov 25, 2004, at 8:51 PM, Spencer Dawkins wrote: I understand that we're trolling the depths of aberrent behavior here, but has anyone seen a NAT that cannot allocate a UDP source port (due to a large number of bindings leading to port exhaustion, as previously described) and still transmits the packet on the public side of the NAT? The behavior I want to explicitly prohibit is a NAT that decides to prematurely time out a previous binding, as that behavior leads to non-deterministic behavior from an application's view. o it is strongly RECOMMENDED that the NAT send an ICMP message type=3, code=0 ("net unreachable") in response to the UDP packet, and; o Alternatively, but less preferred, the NAT SHOULD simply drop the UDP packet and not transmit it on the public side of the NAT. Shouldn't this be a MUST? Sure, how about rewording that last bullet to: o If the NAT doesn't send the above-described ICMP message, the NAT MUST drop the UDP packet and not transmit it on the public side of the NAT. I'm just trying to understand how precise we need to be in describing MUST NOT behavior. You're suggesting we just need to prohibit a NAT from reusing a previous binding before the 2 minute timeout and leave it at that -- or that the existing wording for the two minute timeout is sufficient? -d From audet@nortelnetworks.com Mon, 29 Nov 2004 10:43:57 -0800 (PST) From: "Francois Audet" Date: Mon, 29 Nov 2004 10:43:57 -0800 (PST) Subject: RE: [Ietf-behave] Maximum number of binding Message-ID: <1ECE0EB50388174790F9694F77522CCF01128606@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Maximum number of binding I have similar concerns. We may be starting to overspecify. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Spencer Dawkins > Sent: Thursday, November 25, 2004 20:52 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Maximum number of binding > > > I understand that we're trolling the depths of aberrent > behavior here, > but has anyone seen a NAT that cannot allocate a UDP source port (due > to a large number of bindings leading to port exhaustion, as > previously described) and still transmits the packet on the public > side of the NAT? > > >>> o it is strongly RECOMMENDED that the NAT send an ICMP message > >>> type=3, > >>> code=0 ("net unreachable") in response to the UDP packet, > >>> and; > >>> > >>> o Alternatively, but less preferred, the NAT SHOULD simply > >>> drop the > >>> UDP packet and not transmit it on the public side of the > >>> NAT. > >> > >> Shouldn't this be a MUST? > > > > Sure, how about rewording that last bullet to: > > > > o If the NAT doesn't send the above-described ICMP message, the > > NAT > > MUST drop the UDP packet and not transmit it on the public side > > of > > the NAT. > > I'm just trying to understand how precise we need to be in describing > MUST NOT behavior. > > Thanks, > > Spencer > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From yutaka_takeda@playstation.sony.com Mon, 29 Nov 2004 11:37:14 -0800 (PST) From: yutaka_takeda@playstation.sony.com Date: Mon, 29 Nov 2004 11:37:14 -0800 (PST) Subject: Re: [Ietf-behave] Maximum number of binding In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01127D59@zrc2hxm0.corp.nortel.com> Message-ID: <004c01c4d64a$cf109170$4503620a@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain > ..., as that behavior leads to > non-deterministic behavior from an application's view. I agree with your idea. No matter how the existing NATs are implemented, if there is any case that can lead to non-deterministic behavior of NATs, we should take precautions against it. Thanks, Yutaka ----- Original Message ----- From: "Dan Wing" To: "Spencer Dawkins" Cc: Sent: Monday, November 29, 2004 8:47 AM Subject: Re: [Ietf-behave] Maximum number of binding > > On Nov 25, 2004, at 8:51 PM, Spencer Dawkins wrote: > > > I understand that we're trolling the depths of aberrent behavior here, > > but has anyone seen a NAT that cannot allocate a UDP source port (due > > to a large number of bindings leading to port exhaustion, as > > previously described) and still transmits the packet on the public > > side of the NAT? > > The behavior I want to explicitly prohibit is a NAT that decides to > prematurely time out a previous binding, as that behavior leads to > non-deterministic behavior from an application's view. > > >>>> o it is strongly RECOMMENDED that the NAT send an ICMP message > >>>> type=3, > >>>> code=0 ("net unreachable") in response to the UDP packet, and; > >>>> > >>>> o Alternatively, but less preferred, the NAT SHOULD simply drop > >>>> the > >>>> UDP packet and not transmit it on the public side of the NAT. > >>> > >>> Shouldn't this be a MUST? > >> > >> Sure, how about rewording that last bullet to: > >> > >> o If the NAT doesn't send the above-described ICMP message, the NAT > >> MUST drop the UDP packet and not transmit it on the public side of > >> the NAT. > > > > I'm just trying to understand how precise we need to be in describing > > MUST NOT behavior. > > You're suggesting we just need to prohibit a NAT from reusing a > previous binding before the 2 minute timeout and leave it at that -- or > that the existing wording for the two minute timeout is sufficient? > > -d > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > From fluffy@cisco.com Tue, 7 Dec 2004 16:42:08 -0800 (PST) From: Cullen Jennings Date: Tue, 7 Dec 2004 16:42:08 -0800 (PST) Subject: [Ietf-behave] testing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Thomas, Thanks - I think I just lost token on this. I just sent out a list of people that I know have been doing some work on various areas. There are a tone of things that need to be done around testing - sync up with the folks thinking about the parts you can help on. On 11/24/04 5:55 PM, "Thomas Gal" wrote: > Speaking of documents, I volunteered to work on a BEHAVE testing document > and code. Cullen did my email get nabbed by a spam filter? I think we had > talked about that stun paper that disappeared, and we might as well merge it > all. > > -Tom > > thomasgal@xxxxxxxxxxxx > >> -----Original Message----- >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of >> Jon Ringle >> Sent: Wednesday, November 24, 2004 5:04 PM >> To: ietf-behave@xxxxxxxxxxxxxxxxxxx >> Subject: Re: [Ietf-behave] slashdot: p2p firewalled file transfers >> >> On Wednesday 24 November 2004 06:19 pm, Dan Wing wrote: >>> On Nov 24, 2004, at 11:57 AM, Jon Ringle wrote: >>>> In regards to to p2p tcp behind NATs, are you familiar with the >>>> NUTSS >>>> research: >>>> >>>> http://www.cs.cornell.edu/People/francis/ieee-nutss.pdf >>>> http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf >>> >>> Yes, but I had forgotten about it. Thanks for the pointer. >>> >>>> This uses an approach that uses a STUN extension and SIP. For a >>>> "BEHAVE-compliant" NAT, the port prediction described is not >>>> necessary, since the port prediction is meant to try to deal with >>>> symmetric NATs. >>> >>> Remember that behave (draft-ietf-behave-nat) only defines UDP >>> behavior, not TCP behavior. At the meeting in DC, it was >> agreed that >>> the filename would be modified to clearly indicate that it >> covers only UDP. >>> >>> TCP behavior would be described in another document. >> However, to my >>> knowledge, no one has stepped up to writing the TCP >> behavior document. >>> It appears that for p2p TCP to work, we need such a document and we >>> need testing, akin to Cullen's >> draft-jennings-midcom-stun-results, to >>> determine what TCP behavior exists for today's NATs. >> >> You mean something like Saikat's work: >> http://list.sipfoundry.org/archive/ietf-behave/msg00215.html >> >> Jon >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Tue, 7 Dec 2004 16:42:20 -0800 (PST) From: Cullen Jennings Date: Tue, 7 Dec 2004 16:42:20 -0800 (PST) Subject: [Ietf-behave] Re: BEHAVE WG notes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Many thanks to Mary, Spencer, and Alan for the great notes. Cullen From fluffy@cisco.com Tue, 7 Dec 2004 16:42:23 -0800 (PST) From: Cullen Jennings Date: Tue, 7 Dec 2004 16:42:23 -0800 (PST) Subject: [Ietf-behave] Adopting draft-wing-behave-multicast as WG item Message-ID: MIME-Version: 1.0 Content-Type: text/plain The working group seems to be relatively happy with this multicast draft. I'm proposing that we accept it as a WG item. Do people have any objections to this? If so, get them in before December 15 and we can decide what to do with this draft. Thanks, Cullen From fluffy@cisco.com Tue, 7 Dec 2004 16:42:24 -0800 (PST) From: Cullen Jennings Date: Tue, 7 Dec 2004 16:42:24 -0800 (PST) Subject: [Ietf-behave] Status update Dec 7 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Below I have listed all the chunks of work and the people who have expressed interested in writing drafts. I'm sure I missed some folks so let me know can keep this stuff moving as quickly as possible. -------- Defining NAT Behavior -------------------- * UDP Unicast Behavior - Goal May 05 Good work moving forward Francois leading work Srisuresh helping merge parts from ford-midcom-p2p See draft-ietf-behave-nat-00 * UDP Multicast Behavior - Goal May 05 Good work moving forward - Dan leading See draft-wing-behave-multicast-00 * TCP Behavior - Goal Sep 05 Some thought starting in this area. Work from Nagendra Modadugu Bryan Ford Senthil Sivakumar * ICMP behavior - Goal Nov 05 Is this goal a mistake, should this just be in other documents? --------- Behavior Testing ---------------------- * Using STUN for testing UDP - Goal Mar 05 Not much happening on this. Rohan might do some work on this - no ETA Would be good to get some other volunteers on this one. * Revisions to STUN - Goal Jul 05 Jonathan has under control See draft-ietf-behave-rfc3489bis-00.txt * TCP Testing Saikat Guha Bryan Ford Lots of work done - need draft -------- Application Design ---------------------- * UDP Design Techniques - Goal Dec 05 Dan Wing Francois Bryan Ford * TCP Design Techniques - Goal Dec 05 Bryan Ford Dan Wing Francois -------- Test Results ----------------------------- * UDP NAT Test Results - Goal TBD Nice to get ICMP results Nice to see change from Jan 04 to Jan 05 Cullen has been doing some of this - I need help See draft-jennings-midcom-stun-results-02 * UDP Multicast Test Results * TCP NAT Test Results Saikat Guha Shiva * ICMP NAT Test Results --------- Other ------------- Srisuresh is working on draft on "P2P state of the NAT world" ------- random links of interest --------- http://www.ietf.org/html.charters/behave-charter.html http://list.sipfoundry.org/archive/ietf-behave http://www.cs.cornell.edu/People/francis/ieee-nutss.pdf http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_7-3/anatomy .html http://bgp.lcs.mit.edu/~dga/view.cgi http://www.cs.cornell.edu/~saikat/NATs.html http://www.cs.cornell.edu/~saikat/NAT-results.htm http://midcom-p2p.sourceforge.net/ http://sourceforge.net/projects/stun From fluffy@cisco.com Tue, 7 Dec 2004 16:42:23 -0800 (PST) From: Cullen Jennings Date: Tue, 7 Dec 2004 16:42:23 -0800 (PST) Subject: [Ietf-behave] What to do about ICMP Message-ID: MIME-Version: 1.0 Content-Type: text/plain When we were putting our goal together long ago, we said, ICMP, that's a protocol, we will have a document for it. Now it is looking more like there is not much to say about it other than in the context of other documents. What do we need to say about it outside the context of anything else such as UDP, Multicast, or TCP? Do we need a document on this? Should we just wrap it into another document? Does anyone care what NAT's do with ping? Thoughts ? Thanks, Cullen From fluffy@cisco.com Tue, 7 Dec 2004 17:11:55 -0800 (PST) From: Cullen Jennings Date: Tue, 7 Dec 2004 17:11:55 -0800 (PST) Subject: [Ietf-behave] TCP Testing Message-ID: MIME-Version: 1.0 Content-Type: text/plain ok we have some software for testing, we have a bunch of NATs, we have an idea of what we want to test, we have some previous drafts to work from. How can we get to having: A draft that describes how to test the TCP portion of a NAT Some software to do it Some labs set up where we can generate the results Someone to run the test A draft with the results I guess I would like to start with an email thread on who can do what and by when - I'll start a separate thread on what to test. From fluffy@cisco.com Tue, 7 Dec 2004 17:11:57 -0800 (PST) From: Cullen Jennings Date: Tue, 7 Dec 2004 17:11:57 -0800 (PST) Subject: [Ietf-behave] TCP - what to test Message-ID: MIME-Version: 1.0 Content-Type: text/plain A a rough straw man of things we might want to test in TCP I went and pulled these out of the ford-midcom-p2p draft and Saikat's work. If a SYN packets goes out, will a SYN packet be allowed in If nothing has gone out, will an inbound SYN get dropped or get a RST or ICMP If a connection from IP1:port1 is made to an outside destination, will a connection from the same source to a different destination get the same port on the outside of the NAT What is the timeout for a connection when only a SYN has been seen. Is it larger than 60 seconds? What is the timeout for an established connection. Is it larger than 7200 seconds? From sg266@cornell.edu Tue, 7 Dec 2004 19:59:04 -0800 (PST) From: Saikat Guha Date: Tue, 7 Dec 2004 19:59:04 -0800 (PST) Subject: [Ietf-behave] Re: TCP Testing In-Reply-To: Message-ID: <1102478333.25903.31.camel@broomhilde.guha.cc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630132.multipart/signed" --Boundary..27398.1163630132.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit I can do the following: On Tue, 2004-12-07 at 17:11 -0800, Cullen Jennings wrote: > A draft that describes how to test the TCP portion of a NAT I am not sure what this entails but I can assist in the writeup. > Some software to do it I have the client and server ready. The client can be downloaded from http://www.cs.cornell.edu/~saikat/NATs.html. By default it will use the server currently running at a public Cornell IP. For tests confined to a lab without direct external internet access I'll post the server and instructions at http://www.cs.cornell.edu/~saikat/NAT-test.html by tomorrow. > Some labs set up where we can generate the results > > Someone to run the test We are in the process of enlisting the beta-testers community for a P2P app to run the client. We expect results from them in two or three weeks. While this provides insight into the behavior of popular NATs, it likely does not represent the full spectrum of NAT behavior. I have a lab set up with a small selection of NATs that can contribute towards the latter. > A draft with the results I can start working on a draft once I have some preliminary results. -- Saikat Attachment: signature.asc --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="pgp00014.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00014.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi42IChHTlUv TGludXgpCgppRDhEQlFCQnRudjluRmx0cWk2OTEvb1JBdmVnQUo0aVdudktTekFYSkZTdVAwTGpR VDFYSVRCcldBQ2ZVNUdWCjl5VytjVzZjSzBId0ZzUEp1TWhhNm44PQo9dEx0OAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630132.multipart/signed-- From fluffy@cisco.com Tue, 7 Dec 2004 21:18:24 -0800 (PST) From: Cullen Jennings Date: Tue, 7 Dec 2004 21:18:24 -0800 (PST) Subject: [Ietf-behave] Re: TCP Testing In-Reply-To: <200412080231.AGV25201@ind-mira-01.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 12/7/04 6:40 PM, "Shiva" wrote: > I can do the following > > Some labs set up where we can generate the results > > Someone to run the test > > A draft with the results > > For all the devices that we have in the next 3-4 weeks timeframe the long > pole being the lab setup itself. But I would need the software to do the > testing. > > Regards > Shiva > Shiva and I are working on getting the NATs I have (a big box full :-) set up in a place he can test. From fluffy@cisco.com Tue, 7 Dec 2004 21:23:46 -0800 (PST) From: Cullen Jennings Date: Tue, 7 Dec 2004 21:23:46 -0800 (PST) Subject: Re: [Ietf-behave] Status update Dec 7 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain I missed someone earlier - I should have added that Kaushik Biswas had also expressed that he may be able to help on the TCP Behavior stuff. Sorry, Cullen From ssenthil@cisco.com Tue, 7 Dec 2004 22:15:06 -0800 (PST) From: Senthil Sivakumar Date: Tue, 7 Dec 2004 22:15:06 -0800 (PST) Subject: Re: [Ietf-behave] TCP - what to test In-Reply-To: Message-ID: <4.3.2.7.2.20041207213017.01cc79a0@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain To add to this list: Would a RST/Fin- FinACK clean the NAT entry, if not how long does the session last? Both endpoints behind the same NAT. Test all of these for both dynamic NAT and PAT configs. Senthil At 05:11 PM 12/7/2004 -0800, Cullen Jennings wrote: A a rough straw man of things we might want to test in TCP I went and pulled these out of the ford-midcom-p2p draft and Saikat's work. If a SYN packets goes out, will a SYN packet be allowed in If nothing has gone out, will an inbound SYN get dropped or get a RST or ICMP If a connection from IP1:port1 is made to an outside destination, will a connection from the same source to a different destination get the same port on the outside of the NAT What is the timeout for a connection when only a SYN has been seen. Is it larger than 60 seconds? What is the timeout for an established connection. Is it larger than 7200 seconds? _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortelnetworks.com Wed, 8 Dec 2004 08:38:27 -0800 (PST) From: "Francois Audet" Date: Wed, 8 Dec 2004 08:38:27 -0800 (PST) Subject: RE: [Ietf-behave] Adopting draft-wing-behave-multicast as WG item Message-ID: <1ECE0EB50388174790F9694F77522CCF0122FB36@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Adopting draft-wing-behave-multicast as WG item Looks good to me. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Cullen Jennings > Sent: Tuesday, December 07, 2004 15:55 > To: Behave > Subject: [Ietf-behave] Adopting draft-wing-behave-multicast as WG item > > > > The working group seems to be relatively happy with this > multicast draft. I'm proposing that we accept it as a WG > item. Do people have any objections to this? If so, get them > in before December 15 and we can decide what to do with this draft. > > Thanks, Cullen > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From baford@mit.edu Wed, 8 Dec 2004 14:06:42 -0800 (PST) From: Bryan Ford Date: Wed, 8 Dec 2004 14:06:42 -0800 (PST) Subject: [Ietf-behave] Twice NAT _must_ be in-scope Message-ID: <200412081706.35671.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Hi Francois, A comment on draft-ietf-behave-nat-00 (and apologies in advanced if this issue has been discussed before but I missed it...): > This specification only covers Traditional NATs [4]. Bi-directional, > Twice NAT, and Multihomed NAT [3] are outside the scope of this > document. I do not think it is acceptable for us to leave Twice NAT outside the scope of this document (or any other BEHAVE document), because Twice NAT is not a distinct "type" of NAT per se, but merely a kind of _network configuration_ that can and does arise naturally as a result of multiple _ordinary_ Traditional NATs being combined on the Internet in a hierarchical fashion. For example, consider the standard scenario: an ISP gets a few public IP addresses from its upstream provider, and uses Traditional NAT to create lots of private IP addresses for its customers. Many of the ISP's customers, then, **independently and of their own volition**, deploy their own Traditional NATs to create home networks. We now have a Twice NAT network scenario, even though all of the actual NAT boxes in use are just ordinary Traditional NATs. If one of the basic purposes of BEHAVE is to make the use of NATs more robust and deterministic, then this absolutely has to include making them work in all of the common, natural interconnection scenarios, including Twice NAT. I think it is right for us to leave the more "exotic" types of NATs out of scope for now, such as bidirectional and multihomed NATs, because those are specific types of NAT _boxes_ that operate substantially differently from "Traditional NAT" boxes and often serve somewhat different purposes. It is not legitimate for us to leave Twice NAT out of the picture, however, because Twice NAT arises from natural combinations of standard Traditional NAT boxes on real networks. Cheers, Bryan From audet@nortelnetworks.com Wed, 8 Dec 2004 14:17:48 -0800 (PST) From: "Francois Audet" Date: Wed, 8 Dec 2004 14:17:48 -0800 (PST) Subject: [Ietf-behave] RE: Twice NAT _must_ be in-scope Message-ID: <1ECE0EB50388174790F9694F77522CCF0122FEEB@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: Twice NAT _must_ be in-scope I see your point, and I agree. I will make the change. > -----Original Message----- > From: Bryan Ford [mailto:baford@xxxxxxx] > Sent: Wednesday, December 08, 2004 14:07 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Twice NAT _must_ be in-scope > > > Hi Francois, > > A comment on draft-ietf-behave-nat-00 (and apologies in > advanced if this issue > has been discussed before but I missed it...): > > > This specification only covers Traditional NATs [4]. > Bi-directional, > > Twice NAT, and Multihomed NAT [3] are outside the scope of this > > document. > > I do not think it is acceptable for us to leave Twice NAT > outside the scope of > this document (or any other BEHAVE document), because Twice > NAT is not a > distinct "type" of NAT per se, but merely a kind of _network > configuration_ > that can and does arise naturally as a result of multiple _ordinary_ > Traditional NATs being combined on the Internet in a > hierarchical fashion. > For example, consider the standard scenario: an ISP gets a > few public IP > addresses from its upstream provider, and uses Traditional > NAT to create lots > of private IP addresses for its customers. Many of the ISP's > customers, > then, **independently and of their own volition**, deploy their own > Traditional NATs to create home networks. We now have a > Twice NAT network > scenario, even though all of the actual NAT boxes in use are > just ordinary > Traditional NATs. > > If one of the basic purposes of BEHAVE is to make the use of > NATs more robust > and deterministic, then this absolutely has to include making > them work in > all of the common, natural interconnection scenarios, > including Twice NAT. I > think it is right for us to leave the more "exotic" types of > NATs out of > scope for now, such as bidirectional and multihomed NATs, > because those are > specific types of NAT _boxes_ that operate substantially > differently from > "Traditional NAT" boxes and often serve somewhat different > purposes. It is > not legitimate for us to leave Twice NAT out of the picture, > however, because > Twice NAT arises from natural combinations of standard > Traditional NAT boxes > on real networks. > > Cheers, > Bryan > > From srisuresh@yahoo.com Wed, 8 Dec 2004 16:55:13 -0800 (PST) From: Pyda Srisuresh Date: Wed, 8 Dec 2004 16:55:13 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <200412081706.35671.baford@mit.edu> Message-ID: <20041209005513.194.qmail@web40406.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Hi Bryan, That is a good point you bring up. Essentialy, what you area saying is that hairpin/loopback transaltion involves translating both endpoints. That is the characteristic of a twice-NAT. So, we shoudl include twice-NATs in soope. I like that. cheers, suresh --- Bryan Ford wrote: > Hi Francois, > > A comment on draft-ietf-behave-nat-00 (and apologies in advanced if this > issue > has been discussed before but I missed it...): > > > This specification only covers Traditional NATs [4]. Bi-directional, > > Twice NAT, and Multihomed NAT [3] are outside the scope of this > > document. > > I do not think it is acceptable for us to leave Twice NAT outside the scope > of > this document (or any other BEHAVE document), because Twice NAT is not a > distinct "type" of NAT per se, but merely a kind of _network configuration_ > that can and does arise naturally as a result of multiple _ordinary_ > Traditional NATs being combined on the Internet in a hierarchical fashion. > For example, consider the standard scenario: an ISP gets a few public IP > addresses from its upstream provider, and uses Traditional NAT to create lots > > of private IP addresses for its customers. Many of the ISP's customers, > then, **independently and of their own volition**, deploy their own > Traditional NATs to create home networks. We now have a Twice NAT network > scenario, even though all of the actual NAT boxes in use are just ordinary > Traditional NATs. > > If one of the basic purposes of BEHAVE is to make the use of NATs more robust > > and deterministic, then this absolutely has to include making them work in > all of the common, natural interconnection scenarios, including Twice NAT. I > > think it is right for us to leave the more "exotic" types of NATs out of > scope for now, such as bidirectional and multihomed NATs, because those are > specific types of NAT _boxes_ that operate substantially differently from > "Traditional NAT" boxes and often serve somewhat different purposes. It is > not legitimate for us to leave Twice NAT out of the picture, however, because > > Twice NAT arises from natural combinations of standard Traditional NAT boxes > on real networks. > > Cheers, > Bryan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > ===== From jdrosen@cisco.com Wed, 8 Dec 2004 20:54:28 -0800 (PST) From: Jonathan Rosenberg Date: Wed, 8 Dec 2004 20:54:28 -0800 (PST) Subject: Re: [Ietf-behave] Adopting draft-wing-behave-multicast as WG item In-Reply-To: Message-ID: <41B7DA7E.4010008@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Seems good to me. -Jonathan R. Cullen Jennings wrote: The working group seems to be relatively happy with this multicast draft. I'm proposing that we accept it as a WG item. Do people have any objections to this? If so, get them in before December 15 and we can decide what to do with this draft. Thanks, Cullen _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From fluffy@cisco.com Wed, 8 Dec 2004 22:00:09 -0800 (PST) From: Cullen Jennings Date: Wed, 8 Dec 2004 22:00:09 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <200412081706.35671.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 12/8/04 2:06 PM, "Bryan Ford" wrote: > Traditional NATs being combined on the Internet in a hierarchical fashion. > For example, consider the standard scenario: an ISP gets a few public IP > addresses from its upstream provider, and uses Traditional NAT to create lots > of private IP addresses for its customers. Many of the ISP's customers, > then, **independently and of their own volition**, deploy their own > Traditional NATs to create home networks. We now have a Twice NAT network > scenario, even though all of the actual NAT boxes in use are just ordinary > Traditional NATs. I agree this scenario is definitely in scope but I get confused by some of the terminology at times. Is this what RFC 2663 would call twice NAT? From jdrosen@cisco.com Wed, 8 Dec 2004 22:24:40 -0800 (PST) From: Jonathan Rosenberg Date: Wed, 8 Dec 2004 22:24:40 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: Message-ID: <41B7EFA1.7030106@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I agree that we need to cover the situation Bryan is talking about, but I have heard this called "cascaded NAT" or "multi-layer NAT" or some equivalent. To answer Cullen's question, I think twice NAT is quite different, as it specifically involves DNS tricks to deal with address collisions between two domains. See section 4.3 of rfc2663. I don't think we need to deal with twice NAT as defined in rfc2663; its really awful and not that common (AFAIK). Thanks, Jonathan R. Cullen Jennings wrote: On 12/8/04 2:06 PM, "Bryan Ford" wrote: Traditional NATs being combined on the Internet in a hierarchical fashion. For example, consider the standard scenario: an ISP gets a few public IP addresses from its upstream provider, and uses Traditional NAT to create lots of private IP addresses for its customers. Many of the ISP's customers, then, **independently and of their own volition**, deploy their own Traditional NATs to create home networks. We now have a Twice NAT network scenario, even though all of the actual NAT boxes in use are just ordinary Traditional NATs. I agree this scenario is definitely in scope but I get confused by some of the terminology at times. Is this what RFC 2663 would call twice NAT? _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From srisuresh@yahoo.com Thu, 9 Dec 2004 06:56:33 -0800 (PST) From: Pyda Srisuresh Date: Thu, 9 Dec 2004 06:56:33 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <41B7EFA1.7030106@cisco.com> Message-ID: <20041209145632.55739.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen & Jonathan, RFC 2663 refers to twice-NAT as one that translates both end points of a session. Consider the multi-stage NAT scenario (Refer section 3.3.3 of ford-midcom-p2p-03) that illustrates hairpin/loopback translation on the second stage NAT. Hairpin translation does involve translating both endpoints of a session. By this argument, Bryan's reference to twice-NAT below is in line with twice-NAT, as defined in RFC 2663. cheers, suresh --- Jonathan Rosenberg wrote: > I agree that we need to cover the situation Bryan is talking about, but > I have heard this called "cascaded NAT" or "multi-layer NAT" or some > equivalent. To answer Cullen's question, I think twice NAT is quite > different, as it specifically involves DNS tricks to deal with address > collisions between two domains. See section 4.3 of rfc2663. I don't > think we need to deal with twice NAT as defined in rfc2663; its really > awful and not that common (AFAIK). > > Thanks, > Jonathan R. > > Cullen Jennings wrote: > > > On 12/8/04 2:06 PM, "Bryan Ford" wrote: > > > > > >>Traditional NATs being combined on the Internet in a hierarchical fashion. > >>For example, consider the standard scenario: an ISP gets a few public IP > >>addresses from its upstream provider, and uses Traditional NAT to create > lots > >>of private IP addresses for its customers. Many of the ISP's customers, > >>then, **independently and of their own volition**, deploy their own > >>Traditional NATs to create home networks. We now have a Twice NAT network > >>scenario, even though all of the actual NAT boxes in use are just ordinary > >>Traditional NATs. > > > > > > I agree this scenario is definitely in scope but I get confused by some of > > the terminology at times. Is this what RFC 2663 would call twice NAT? > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > ===== From baford@mit.edu Thu, 9 Dec 2004 07:36:03 -0800 (PST) From: Bryan Ford Date: Thu, 9 Dec 2004 07:36:03 -0800 (PST) Subject: Re: [Ietf-behave] TCP - what to test In-Reply-To: Message-ID: <200412091036.01927.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 07 December 2004 20:11, Cullen Jennings wrote: > A a rough straw man of things we might want to test in TCP I went and > pulled these out of the ford-midcom-p2p draft and Saikat's work. > > If a SYN packets goes out, will a SYN packet be allowed in > > If nothing has gone out, will an inbound SYN get dropped or get a RST or > ICMP > > If a connection from IP1:port1 is made to an outside destination, will a > connection from the same source to a different destination get the same > port on the outside of the NAT > > What is the timeout for a connection when only a SYN has been seen. Is it > larger than 60 seconds? > > What is the timeout for an established connection. Is it larger than 7200 > seconds? I can think of two other related properties that are likely to be important: * After a TCP session has been closed via graceful shutdown (a FIN has been seen from each endpoint), does the NAT "close the hole" immediately and reject any subsequent incoming SYNs from the same external endpoint, or does it leave the hole open a while longer (e.g., at least 60 seconds, or perhaps for the duration of the TCP TIME-WAIT state)? * Similarly, after a TCP session has been closed non-gracefully due to an RST being received from one endpoint, does the NAT "close the hole" immediately or leave it open for some time longer? For obscure political reasons I have to get someone's permission before discussing in detail why these properties are important, but I'll explain shortly when I can. :) But the upshot is that I think a NAT's timeouts may be important in practice not only for half-open and open connections, but also for recently-closed and recently-reset connections. Thanks, Bryan From baford@mit.edu Thu, 9 Dec 2004 07:50:40 -0800 (PST) From: Bryan Ford Date: Thu, 9 Dec 2004 07:50:40 -0800 (PST) Subject: Re: [Ietf-behave] TCP - what to test In-Reply-To: <4.3.2.7.2.20041207213017.01cc79a0@mira-sjcd-2.cisco.com> Message-ID: <200412091050.39151.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 08 December 2004 01:16, Senthil Sivakumar wrote: > To add to this list: > > Would a RST/Fin- FinACK clean the NAT entry, if not how long does the > session last? Oops, I should have read through the rest of my E-mail before posting my last message... :) Another important one: * Does the NAT properly implement hairpin aka loopback translation? Thanks, Bryan From audet@nortelnetworks.com Thu, 9 Dec 2004 08:14:17 -0800 (PST) From: "Francois Audet" Date: Thu, 9 Dec 2004 08:14:17 -0800 (PST) Subject: RE: [Ietf-behave] Twice NAT _must_ be in-scope Message-ID: <1ECE0EB50388174790F9694F77522CCF01284D83@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Twice NAT _must_ be in-scope I think just removing the statement about Twice-NAT is the way to go. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxx] > Sent: Wednesday, December 08, 2004 22:25 > To: Cullen Jennings > Cc: Bryan Ford; Audet, Francois [SC100:9T51:EXCH]; Pyda > Srisuresh; Behave > Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope > > > I agree that we need to cover the situation Bryan is talking > about, but > I have heard this called "cascaded NAT" or "multi-layer NAT" or some > equivalent. To answer Cullen's question, I think twice NAT is quite > different, as it specifically involves DNS tricks to deal > with address > collisions between two domains. See section 4.3 of rfc2663. I don't > think we need to deal with twice NAT as defined in rfc2663; > its really > awful and not that common (AFAIK). > > Thanks, > Jonathan R. > > Cullen Jennings wrote: > > > On 12/8/04 2:06 PM, "Bryan Ford" wrote: > > > > > >>Traditional NATs being combined on the Internet in a hierarchical > >>fashion. For example, consider the standard scenario: an ISP gets a > >>few public IP addresses from its upstream provider, and uses > >>Traditional NAT to create lots of private IP addresses for its > >>customers. Many of the ISP's customers, then, > **independently and of > >>their own volition**, deploy their own Traditional NATs to > create home > >>networks. We now have a Twice NAT network scenario, even > though all > >>of the actual NAT boxes in use are just ordinary Traditional NATs. > > > > > > I agree this scenario is definitely in scope but I get confused by > > some of the terminology at times. Is this what RFC 2663 would call > > twice NAT? > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > From baford@mit.edu Thu, 9 Dec 2004 09:15:51 -0800 (PST) From: Bryan Ford Date: Thu, 9 Dec 2004 09:15:51 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <20041209005513.194.qmail@web40406.mail.yahoo.com> Message-ID: <200412091215.49296.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 08 December 2004 19:55, Pyda Srisuresh wrote: > Hi Bryan, > > That is a good point you bring up. Essentialy, what you area saying is that > hairpin/loopback transaltion involves translating both endpoints. That is > the characteristic of a twice-NAT. So, we shoudl include twice-NATs in > soope. I like that. Hmmm... It's nice that everyone agrees with me, but now I'm not sure I agree with myself anymore... :) After just now looking back again at RFC2663's discussion of "Twice NAT" again (section 4.3), I noticed that the details of the specific motivating scenario discussed by the RFC is quite different than the typical "Twice NAT" scenario of today that results from combinations of Traditional NAT boxes on a network. RFC2663's "Twice NAT" scenario basically seems to be about organizations that want to keep using old "public" IP addresses on their private networks that are no longer allocated to them globally. The result is similar in either scenario, in that the internal and external address spaces may overlap arbitrarily resulting in a need to translate both the source and destination addresses in packets - but the motivating scenarios are quite different. Also, in the way RFC2663 explains Twice NAT, it _does_ in that context sort of come across as "a fundamentally different kind of NAT box" rather than just an outcome of interconnecting multiple Traditional NATs in hierarchical fashion. As per my previous message, the latter form of "Twice NAT" (as I've been using the term) definitely needs to be in-scope for BEHAVE, but the former, strange and hopefully deprecated scenario discussed in RFC2663 obviously should not be. So I'm wondering if we have a potential terminology confusion issue here. What do the people on this list think of in association with the term "Twice NAT" - do you associate the term with "multiple levels of Traditional NAT" (which has so far been my natural association with the term), or do you associate it with "a particularly weird type of NAT box that is administratively set up to translate between two arbitrarily-overlapping IP address spaces"? Should we perhaps use the term "Multi-level Traditional NAT" or something like that to refer to the hierarchical interconnection of Traditional NATs, in order to avoid potential confusion with the RFC2663-style "Twice NAT" scenario? (In which case Francois's original paragraph about "Twice NAT" being out of scope would actually be correct, and we'd be inventing new terminology to cover the hierarchical interconnect scenario.) I don't have a strong feeling either way on this - I'm also happy to keep reusing the term "Twice NAT" the way we have been, as long as the hierarchical interconnect scenario is included and clearly explained somehow. Cheers, Bryan From baford@mit.edu Thu, 9 Dec 2004 09:23:20 -0800 (PST) From: Bryan Ford Date: Thu, 9 Dec 2004 09:23:20 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: Message-ID: <200412091223.19632.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 09 December 2004 01:00, Cullen Jennings wrote: > On 12/8/04 2:06 PM, "Bryan Ford" wrote: > > Traditional NATs being combined on the Internet in a hierarchical > > fashion. For example, consider the standard scenario: an ISP gets a few > > public IP addresses from its upstream provider, and uses Traditional NAT > > to create lots of private IP addresses for its customers. Many of the > > ISP's customers, then, **independently and of their own volition**, > > deploy their own Traditional NATs to create home networks. We now have a > > Twice NAT network scenario, even though all of the actual NAT boxes in > > use are just ordinary Traditional NATs. > > I agree this scenario is definitely in scope but I get confused by some of > the terminology at times. Is this what RFC 2663 would call twice NAT? Exactly the issue I just noticed, after reading Suresh's response to my earlier message. :) What do you think? What _should_ the hierarchical interconnect scenario be called? Bryan From audet@nortelnetworks.com Thu, 9 Dec 2004 09:25:07 -0800 (PST) From: "Francois Audet" Date: Thu, 9 Dec 2004 09:25:07 -0800 (PST) Subject: RE: [Ietf-behave] Twice NAT _must_ be in-scope Message-ID: <1ECE0EB50388174790F9694F77522CCF01284E42@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Twice NAT _must_ be in-scope I think we can safely not talk about Twice-NAT in the document. I don't think it should be the job of BEHAVE to clarify the twice-NAT terminology... In reality being BEHAVE-compliant in a NAT always used as a twice-AT is probably not terribly useful. However, if the NAT is intended to be used either in Twice-NAT mode or Traditional NAT mode, it might be worthile to be BEHAVE compliant for both. > -----Original Message----- > From: Bryan Ford [mailto:baford@xxxxxxx] > Sent: Thursday, December 09, 2004 09:16 > To: Pyda Srisuresh > Cc: Audet, Francois [SC100:9T51:EXCH]; 'Behave' > Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope > > > On Wednesday 08 December 2004 19:55, Pyda Srisuresh wrote: > > Hi Bryan, > > > > That is a good point you bring up. Essentialy, what you > area saying is > > that hairpin/loopback transaltion involves translating both > endpoints. > > That is the characteristic of a twice-NAT. So, we shoudl include > > twice-NATs in soope. I like that. > > Hmmm... It's nice that everyone agrees with me, but now I'm > not sure I agree > with myself anymore... :) > > After just now looking back again at RFC2663's discussion of > "Twice NAT" again > (section 4.3), I noticed that the details of the specific > motivating scenario > discussed by the RFC is quite different than the typical > "Twice NAT" scenario > of today that results from combinations of Traditional NAT boxes on a > network. RFC2663's "Twice NAT" scenario basically seems to be about > organizations that want to keep using old "public" IP > addresses on their > private networks that are no longer allocated to them > globally. The result > is similar in either scenario, in that the internal and > external address > spaces may overlap arbitrarily resulting in a need to > translate both the > source and destination addresses in packets - but the > motivating scenarios > are quite different. Also, in the way RFC2663 explains Twice > NAT, it _does_ > in that context sort of come across as "a fundamentally > different kind of NAT > box" rather than just an outcome of interconnecting multiple > Traditional NATs > in hierarchical fashion. As per my previous message, the > latter form of > "Twice NAT" (as I've been using the term) definitely needs to > be in-scope for > BEHAVE, but the former, strange and hopefully deprecated > scenario discussed > in RFC2663 obviously should not be. > > So I'm wondering if we have a potential terminology confusion > issue here. > What do the people on this list think of in association with > the term "Twice > NAT" - do you associate the term with "multiple levels of Traditional > NAT" (which has so far been my natural association with the > term), or do you > associate it with "a particularly weird type of NAT box that is > administratively set up to translate between two > arbitrarily-overlapping IP > address spaces"? Should we perhaps use the term "Multi-level > Traditional > NAT" or something like that to refer to the hierarchical > interconnection of > Traditional NATs, in order to avoid potential confusion with the > RFC2663-style "Twice NAT" scenario? (In which case > Francois's original > paragraph about "Twice NAT" being out of scope would actually > be correct, and > we'd be inventing new terminology to cover the hierarchical > interconnect > scenario.) I don't have a strong feeling either way on this > - I'm also happy > to keep reusing the term "Twice NAT" the way we have been, as > long as the > hierarchical interconnect scenario is included and clearly > explained somehow. > > Cheers, > Bryan > > From fluffy@cisco.com Thu, 9 Dec 2004 10:38:46 -0800 (PST) From: Cullen Jennings Date: Thu, 9 Dec 2004 10:38:46 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01284D83@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Re: [Ietf-behave] Twice NAT _must_ be in-scope I think that twice-nat as described in 2663 is out of scope of this document. It's like static NAT in that what do you say about it. On 12/9/04 8:13 AM, "Francois Audet" wrote: I think just removing the statement about Twice-NAT is the way to go. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxx] > Sent: Wednesday, December 08, 2004 22:25 > To: Cullen Jennings > Cc: Bryan Ford; Audet, Francois [SC100:9T51:EXCH]; Pyda > Srisuresh; Behave > Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope > > > I agree that we need to cover the situation Bryan is talking > about, but > I have heard this called "cascaded NAT" or "multi-layer NAT" or some > equivalent. To answer Cullen's question, I think twice NAT is quite > different, as it specifically involves DNS tricks to deal > with address > collisions between two domains. See section 4.3 of rfc2663. I don't > think we need to deal with twice NAT as defined in rfc2663; > its really > awful and not that common (AFAIK). > > Thanks, > Jonathan R. > > Cullen Jennings wrote: > > > On 12/8/04 2:06 PM, "Bryan Ford" wrote: > > > > > >>Traditional NATs being combined on the Internet in a hierarchical > >>fashion. For example, consider the standard scenario: an ISP gets a > >>few public IP addresses from its upstream provider, and uses > >>Traditional NAT to create lots of private IP addresses for its > >>customers. Many of the ISP's customers, then, > **independently and of > >>their own volition**, deploy their own Traditional NATs to > create home > >>networks. We now have a Twice NAT network scenario, even > though all > >>of the actual NAT boxes in use are just ordinary Traditional NATs. > > > > > > I agree this scenario is definitely in scope but I get confused by > > some of the terminology at times. Is this what RFC 2663 would call > > twice NAT? > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > From fluffy@cisco.com Thu, 9 Dec 2004 11:51:58 -0800 (PST) From: Cullen Jennings Date: Thu, 9 Dec 2004 11:51:58 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <200412091223.19632.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 12/9/04 9:23 AM, "Bryan Ford" wrote: > Exactly the issue I just noticed, after reading Suresh's response to my > earlier message. :) What do you think? What _should_ the hierarchical > interconnect scenario be called? multilayer nat deployments. Two layers is common in Asia (ISP and home). I have seen 3 layers in cases where the ISP had a NAT, the business had one, then a lab inside the business had a NAT. From ssenthil@cisco.com Thu, 9 Dec 2004 11:52:13 -0800 (PST) From: Senthil Sivakumar Date: Thu, 9 Dec 2004 11:52:13 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <20041209005513.194.qmail@web40406.mail.yahoo.com> Message-ID: <4.3.2.7.2.20041209114219.02fdc718@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain At 12:15 PM 12/9/2004 -0500, Bryan Ford wrote: On Wednesday 08 December 2004 19:55, Pyda Srisuresh wrote: > Hi Bryan, > > That is a good point you bring up. Essentialy, what you area saying is that > hairpin/loopback transaltion involves translating both endpoints. That is > the characteristic of a twice-NAT. So, we shoudl include twice-NATs in > soope. I like that. Hmmm... It's nice that everyone agrees with me, but now I'm not sure I agree with myself anymore... :) After just now looking back again at RFC2663's discussion of "Twice NAT" again (section 4.3), I noticed that the details of the specific motivating scenario discussed by the RFC is quite different than the typical "Twice NAT" scenario of today that results from combinations of Traditional NAT boxes on a network. RFC2663's "Twice NAT" scenario basically seems to be about organizations that want to keep using old "public" IP addresses on their private networks that are no longer allocated to them globally. The result is similar in either scenario, in that the internal and external address spaces may overlap arbitrarily resulting in a need to translate both the source and destination addresses in packets - but the motivating scenarios are quite different. Also, in the way RFC2663 explains Twice NAT, it _does_ in that context sort of come across as "a fundamentally different kind of NAT box" rather than just an outcome of interconnecting multiple Traditional NATs in hierarchical fashion. As per my previous message, the latter form of "Twice NAT" (as I've been using the term) definitely needs to be in-scope for BEHAVE, but the former, strange and hopefully deprecated scenario discussed in RFC2663 obviously should not be. So I'm wondering if we have a potential terminology confusion issue here. What do the people on this list think of in association with the term "Twice NAT" - do you associate the term with "multiple levels of Traditional NAT" (which has so far been my natural association with the term), or do you associate it with "a particularly weird type of NAT box that is administratively set up to translate between two arbitrarily-overlapping IP Any time both the source and the destination addresses are translated by the same NAT box, we refer to them as twice NAT. The reason some one has to translate both the source and the destination is that they have overlapping networks (mostly caused by mergers/acquisitions/bad design/whatever). But the multiple levels of traditional NATs don't cause the source and destination to be translated by the same NAT box but by different NAT boxes, as I see it. To me, that is not the same as twice NAT. Senthil address spaces"? Should we perhaps use the term "Multi-level Traditional NAT" or something like that to refer to the hierarchical interconnection of Traditional NATs, in order to avoid potential confusion with the RFC2663-style "Twice NAT" scenario? (In which case Francois's original paragraph about "Twice NAT" being out of scope would actually be correct, and we'd be inventing new terminology to cover the hierarchical interconnect scenario.) I don't have a strong feeling either way on this - I'm also happy to keep reusing the term "Twice NAT" the way we have been, as long as the hierarchical interconnect scenario is included and clearly explained somehow. Cheers, Bryan _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From kbiswas@cisco.com Thu, 9 Dec 2004 11:58:27 -0800 (PST) From: Kaushik Biswas Date: Thu, 9 Dec 2004 11:58:27 -0800 (PST) Subject: Re: [Ietf-behave] TCP - what to test In-Reply-To: Message-ID: <4.3.2.7.2.20041209113301.02d31868@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Couple more to the list: * When a TCP Segmented packet comes how does the NAT behave, does it spoof back an ACK (it should if it is handling segmentation-reassembly since otherwise the end-point will not generate subsequent TCP segments, and it shouldn't if the ALG processing is disabled in the NAT) . [Query: Do we want to cover this aspect in the first place] * If the outgoing TCP packet is sourced on a well-known-port does NAT change this port to something else (even if that port is available for NAT to use), if it is sharing the NAT Pool-address with one of its interface-address. * Also how does the NAT allocate the ports wrt port-ranges: well-known-range, priv-range & user-range. Thanks, Kaushik At 05:11 PM 12/7/2004 -0800, Cullen Jennings wrote: A a rough straw man of things we might want to test in TCP I went and pulled these out of the ford-midcom-p2p draft and Saikat's work. If a SYN packets goes out, will a SYN packet be allowed in If nothing has gone out, will an inbound SYN get dropped or get a RST or ICMP If a connection from IP1:port1 is made to an outside destination, will a connection from the same source to a different destination get the same port on the outside of the NAT What is the timeout for a connection when only a SYN has been seen. Is it larger than 60 seconds? What is the timeout for an established connection. Is it larger than 7200 seconds? _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Thu, 9 Dec 2004 12:03:59 -0800 (PST) From: Cullen Jennings Date: Thu, 9 Dec 2004 12:03:59 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <200412091215.49296.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 12/9/04 9:15 AM, "Bryan Ford" wrote: > So I'm wondering if we have a potential terminology confusion issue here. I think we have proven beyond any shadow of a doubt that this is true. If we are confused, imagine 99.999% of the world that needs to deploy this. From fluffy@cisco.com Thu, 9 Dec 2004 12:24:15 -0800 (PST) From: Cullen Jennings Date: Thu, 9 Dec 2004 12:24:15 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <20041209145632.55739.qmail@web40425.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hmm... If I take two normal linksys NAT and connect the two public sides together, I do not get twice NAT. I think this description is of twice-NAT is greatly over simplified. On 12/9/04 6:56 AM, "Pyda Srisuresh" wrote: > Cullen & Jonathan, > > RFC 2663 refers to twice-NAT as one that translates both end points of a > session. > > Consider the multi-stage NAT scenario (Refer section 3.3.3 of > ford-midcom-p2p-03) that illustrates hairpin/loopback translation on the > second > stage NAT. Hairpin translation does involve translating both endpoints of a > session. By this argument, Bryan's reference to twice-NAT below is in line > with > twice-NAT, as defined in RFC 2663. > > cheers, > suresh > > --- Jonathan Rosenberg wrote: > >> I agree that we need to cover the situation Bryan is talking about, but >> I have heard this called "cascaded NAT" or "multi-layer NAT" or some >> equivalent. To answer Cullen's question, I think twice NAT is quite >> different, as it specifically involves DNS tricks to deal with address >> collisions between two domains. See section 4.3 of rfc2663. I don't >> think we need to deal with twice NAT as defined in rfc2663; its really >> awful and not that common (AFAIK). >> >> Thanks, >> Jonathan R. >> >> Cullen Jennings wrote: >> >>> On 12/8/04 2:06 PM, "Bryan Ford" wrote: >>> >>> >>>> Traditional NATs being combined on the Internet in a hierarchical fashion. >>>> For example, consider the standard scenario: an ISP gets a few public IP >>>> addresses from its upstream provider, and uses Traditional NAT to create >> lots >>>> of private IP addresses for its customers. Many of the ISP's customers, >>>> then, **independently and of their own volition**, deploy their own >>>> Traditional NATs to create home networks. We now have a Twice NAT network >>>> scenario, even though all of the actual NAT boxes in use are just ordinary >>>> Traditional NATs. >>> >>> >>> I agree this scenario is definitely in scope but I get confused by some of >>> the terminology at times. Is this what RFC 2663 would call twice NAT? >>> >>> _______________________________________________ >>> Ietf-behave mailing list >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@xxxxxxxxx FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> > > > ===== From srisuresh@yahoo.com Thu, 9 Dec 2004 13:12:25 -0800 (PST) From: Pyda Srisuresh Date: Thu, 9 Dec 2004 13:12:25 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: Message-ID: <20041209211225.15657.qmail@web40401.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, Are you saying that Static NATs shoudl be out of scope? If so, I disagree. What is the reason for taking static NAT out of scope? Many NAT boxes do have an ability to configure static address/port mapping. I believe, static NATs shoudl be within scope. >From what I can tell, much of the recommendation to NAT vendors centers around requiring them to maintain address/port binds. I would like all NAT vendors to carry the theme, whether twice-NAT, NAT-PT or bi-directional NAT. I really dont see substantial benefit in restricting the discussion scope to traditional NATs. That is my 2c. regards, suresh --- Cullen Jennings wrote: > > I think that twice-nat as described in 2663 is out of scope of this > document. It's like static NAT in that what do you say about it. > > > On 12/9/04 8:13 AM, "Francois Audet" wrote: > > > I think just removing the statement about Twice-NAT is the way to go. > > > >> > -----Original Message----- > >> > From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxx] > >> > Sent: Wednesday, December 08, 2004 22:25 > >> > To: Cullen Jennings > >> > Cc: Bryan Ford; Audet, Francois [SC100:9T51:EXCH]; Pyda > >> > Srisuresh; Behave > >> > Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope > >> > > >> > > >> > I agree that we need to cover the situation Bryan is talking > >> > about, but > >> > I have heard this called "cascaded NAT" or "multi-layer NAT" or some > >> > equivalent. To answer Cullen's question, I think twice NAT is quite > >> > different, as it specifically involves DNS tricks to deal > >> > with address > >> > collisions between two domains. See section 4.3 of rfc2663. I don't > >> > think we need to deal with twice NAT as defined in rfc2663; > >> > its really > >> > awful and not that common (AFAIK). > >> > > >> > Thanks, > >> > Jonathan R. > >> > > >> > Cullen Jennings wrote: > >> > > >>> > > On 12/8/04 2:06 PM, "Bryan Ford" wrote: > >>> > > > >>> > > > >>>> > >>Traditional NATs being combined on the Internet in a hierarchical > >>>> > >>fashion. For example, consider the standard scenario: an ISP gets a > >>>> > >>few public IP addresses from its upstream provider, and uses > >>>> > >>Traditional NAT to create lots of private IP addresses for its > >>>> > >>customers. Many of the ISP's customers, then, > >> > **independently and of > >>>> > >>their own volition**, deploy their own Traditional NATs to > >> > create home > >>>> > >>networks. We now have a Twice NAT network scenario, even > >> > though all > >>>> > >>of the actual NAT boxes in use are just ordinary Traditional NATs. > >>> > > > >>> > > > >>> > > I agree this scenario is definitely in scope but I get confused by > >>> > > some of the terminology at times. Is this what RFC 2663 would call > >>> > > twice NAT? > >>> > > > >>> > > _______________________________________________ > >>> > > Ietf-behave mailing list > >>> > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>> > > > >> > > >> > -- > >> > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> > Director, Service Provider VoIP Architecture Parsippany, NJ > >> > 07054-2711 > >> > Cisco Systems > >> > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > >> > http://www.jdrosen.net PHONE: (973) 952-5000 > >> > http://www.cisco.com > >> > > >> > > > > > > ===== From srisuresh@yahoo.com Thu, 9 Dec 2004 13:14:37 -0800 (PST) From: Pyda Srisuresh Date: Thu, 9 Dec 2004 13:14:37 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: Message-ID: <20041209211437.40311.qmail@web40404.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Multi-stage NAT deployment being in scope sounds good to me. Actually, I didnt think it was out of scope to start with. Oh, well.. regards, suresh --- Cullen Jennings wrote: > On 12/9/04 9:23 AM, "Bryan Ford" wrote: > > > Exactly the issue I just noticed, after reading Suresh's response to my > > earlier message. :) What do you think? What _should_ the hierarchical > > interconnect scenario be called? > > multilayer nat deployments. Two layers is common in Asia (ISP and home). I > have seen 3 layers in cases where the ISP had a NAT, the business had one, > then a lab inside the business had a NAT. > > ===== From srisuresh@yahoo.com Thu, 9 Dec 2004 13:21:33 -0800 (PST) From: Pyda Srisuresh Date: Thu, 9 Dec 2004 13:21:33 -0800 (PST) Subject: RE: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01284E42@zrc2hxm0.corp.nortel.com> Message-ID: <20041209212132.49569.qmail@web40424.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Francois Audet wrote: > I think we can safely not talk about Twice-NAT in the document. > > I don't think it should be the job of BEHAVE to clarify the > twice-NAT terminology... > > In reality being BEHAVE-compliant in a NAT always used > as a twice-AT is probably not terribly useful. [suresh] I disagree. A twice-NAT could be using NAPT type of translation for one of the endpoints (i.e., one address multiplexing for several machines) . It would be useful to have Behave compliance there. > However, if the > NAT is intended to be used either in Twice-NAT mode or Traditional > NAT mode, it might be worthile to be BEHAVE compliant for both. [suresh] Yup. regards, suresh > > > > > -----Original Message----- > > From: Bryan Ford [mailto:baford@xxxxxxx] > > Sent: Thursday, December 09, 2004 09:16 > > To: Pyda Srisuresh > > Cc: Audet, Francois [SC100:9T51:EXCH]; 'Behave' > > Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope > > > > > > On Wednesday 08 December 2004 19:55, Pyda Srisuresh wrote: > > > Hi Bryan, > > > > > > That is a good point you bring up. Essentialy, what you > > area saying is > > > that hairpin/loopback transaltion involves translating both > > endpoints. > > > That is the characteristic of a twice-NAT. So, we shoudl include > > > twice-NATs in soope. I like that. > > > > Hmmm... It's nice that everyone agrees with me, but now I'm > > not sure I agree > > with myself anymore... :) > > > > After just now looking back again at RFC2663's discussion of > > "Twice NAT" again > > (section 4.3), I noticed that the details of the specific > > motivating scenario > > discussed by the RFC is quite different than the typical > > "Twice NAT" scenario > > of today that results from combinations of Traditional NAT boxes on a > > network. RFC2663's "Twice NAT" scenario basically seems to be about > > organizations that want to keep using old "public" IP > > addresses on their > > private networks that are no longer allocated to them > > globally. The result > > is similar in either scenario, in that the internal and > > external address > > spaces may overlap arbitrarily resulting in a need to > > translate both the > > source and destination addresses in packets - but the > > motivating scenarios > > are quite different. Also, in the way RFC2663 explains Twice > > NAT, it _does_ > > in that context sort of come across as "a fundamentally > > different kind of NAT > > box" rather than just an outcome of interconnecting multiple > > Traditional NATs > > in hierarchical fashion. As per my previous message, the > > latter form of > > "Twice NAT" (as I've been using the term) definitely needs to > > be in-scope for > > BEHAVE, but the former, strange and hopefully deprecated > > scenario discussed > > in RFC2663 obviously should not be. > > > > So I'm wondering if we have a potential terminology confusion > > issue here. > > What do the people on this list think of in association with > > the term "Twice > > NAT" - do you associate the term with "multiple levels of Traditional > > NAT" (which has so far been my natural association with the > > term), or do you > > associate it with "a particularly weird type of NAT box that is > > administratively set up to translate between two > > arbitrarily-overlapping IP > > address spaces"? Should we perhaps use the term "Multi-level > > Traditional > > NAT" or something like that to refer to the hierarchical > > interconnection of > > Traditional NATs, in order to avoid potential confusion with the > > RFC2663-style "Twice NAT" scenario? (In which case > > Francois's original > > paragraph about "Twice NAT" being out of scope would actually > > be correct, and > > we'd be inventing new terminology to cover the hierarchical > > interconnect > > scenario.) I don't have a strong feeling either way on this > > - I'm also happy > > to keep reusing the term "Twice NAT" the way we have been, as > > long as the > > hierarchical interconnect scenario is included and clearly > > explained somehow. > > > > Cheers, > > Bryan > > > > > ===== From srisuresh@yahoo.com Thu, 9 Dec 2004 13:26:25 -0800 (PST) From: Pyda Srisuresh Date: Thu, 9 Dec 2004 13:26:25 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <4.3.2.7.2.20041209114219.02fdc718@mira-sjcd-2.cisco.com> Message-ID: <20041209212625.47209.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Senthil, I agree with what you say. However, the multi-stage NAT scenario that Bryan talks about exhibits twice-NAT characteristic (when suporting hairpin translation), in that both endpoints are translated. This happens even as the NAT box itself may not have been configured with twice-NAT address maps. regards, suresh --- Senthil Sivakumar wrote: > At 12:15 PM 12/9/2004 -0500, Bryan Ford wrote: > >On Wednesday 08 December 2004 19:55, Pyda Srisuresh wrote: > > > Hi Bryan, > > > > > > That is a good point you bring up. Essentialy, what you area saying is > that > > > hairpin/loopback transaltion involves translating both endpoints. That is > > > the characteristic of a twice-NAT. So, we shoudl include twice-NATs in > > > soope. I like that. > > > >Hmmm... It's nice that everyone agrees with me, but now I'm not sure I > agree > >with myself anymore... :) > > > >After just now looking back again at RFC2663's discussion of "Twice NAT" > >again > >(section 4.3), I noticed that the details of the specific motivating > scenario > >discussed by the RFC is quite different than the typical "Twice NAT" > scenario > >of today that results from combinations of Traditional NAT boxes on a > >network. RFC2663's "Twice NAT" scenario basically seems to be about > >organizations that want to keep using old "public" IP addresses on their > >private networks that are no longer allocated to them globally. The result > >is similar in either scenario, in that the internal and external address > >spaces may overlap arbitrarily resulting in a need to translate both the > >source and destination addresses in packets - but the motivating scenarios > >are quite different. Also, in the way RFC2663 explains Twice NAT, it _does_ > >in that context sort of come across as "a fundamentally different kind of > NAT > >box" rather than just an outcome of interconnecting multiple Traditional > NATs > >in hierarchical fashion. As per my previous message, the latter form of > >"Twice NAT" (as I've been using the term) definitely needs to be in-scope > for > >BEHAVE, but the former, strange and hopefully deprecated scenario discussed > >in RFC2663 obviously should not be. > > > >So I'm wondering if we have a potential terminology confusion issue here. > >What do the people on this list think of in association with the term "Twice > >NAT" - do you associate the term with "multiple levels of Traditional > >NAT" (which has so far been my natural association with the term), or do you > >associate it with "a particularly weird type of NAT box that is > >administratively set up to translate between two arbitrarily-overlapping IP > > Any time both the source and the destination addresses are translated by > the same NAT box, we refer to them as twice NAT. The reason some one > has to translate both the source and the destination is that they have > overlapping > networks (mostly caused by mergers/acquisitions/bad design/whatever). > > But the multiple levels of traditional NATs don't cause the source and > destination > to be translated by the same NAT box but by different NAT boxes, as I see it. > To me, that is not the same as twice NAT. > > Senthil > > > >address spaces"? Should we perhaps use the term "Multi-level Traditional > >NAT" or something like that to refer to the hierarchical interconnection of > >Traditional NATs, in order to avoid potential confusion with the > >RFC2663-style "Twice NAT" scenario? (In which case Francois's original > >paragraph about "Twice NAT" being out of scope would actually be correct, > and > >we'd be inventing new terminology to cover the hierarchical interconnect > >scenario.) I don't have a strong feeling either way on this - I'm also > happy > >to keep reusing the term "Twice NAT" the way we have been, as long as the > >hierarchical interconnect scenario is included and clearly explained > somehow. > > > >Cheers, > >Bryan > >_______________________________________________ > >Ietf-behave mailing list > >Ietf-behave@xxxxxxxxxxxxxxxxxxx > >https://list.sipfoundry.org/mailman/listinfo/ietf-behave > ===== From fluffy@cisco.com Thu, 9 Dec 2004 13:29:27 -0800 (PST) From: Cullen Jennings Date: Thu, 9 Dec 2004 13:29:27 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <20041209211437.40311.qmail@web40404.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I don't know what multi stage is but multilayer as described in Bryan's email has always been one of things this document wanted to work with. On 12/9/04 1:14 PM, "Pyda Srisuresh" wrote: > > Multi-stage NAT deployment being in scope sounds good to me. Actually, I didnt > think it was out of scope to start with. Oh, well.. > > regards, > suresh > > --- Cullen Jennings wrote: > >> On 12/9/04 9:23 AM, "Bryan Ford" wrote: >> >>> Exactly the issue I just noticed, after reading Suresh's response to my >>> earlier message. :) What do you think? What _should_ the hierarchical >>> interconnect scenario be called? >> >> multilayer nat deployments. Two layers is common in Asia (ISP and home). I >> have seen 3 layers in cases where the ISP had a NAT, the business had one, >> then a lab inside the business had a NAT. >> >> > > > ===== From fluffy@cisco.com Thu, 9 Dec 2004 13:37:41 -0800 (PST) From: Cullen Jennings Date: Thu, 9 Dec 2004 13:37:41 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <20041209211225.15657.qmail@web40401.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I don't really know what the definition of static nat is but if static nat is that a packet that arrives at a particular address/port on the outside of the NAT gets forwarded to some configured address/port on the inside then I don't know what to say about this. Yes that exists. Many people implement it. It's described in other documents. What are NATs doing today with static port forwarding that we thinks need further clarification? What behavior would we like to clarify or change? There may very well be clear answers to this but so far no one seems to have brought them up so that's why Francois and I had tried to get this document to focus on the non deterministic properties that were causing application problems. On 12/9/04 1:12 PM, "Pyda Srisuresh" wrote: > Cullen, > > Are you saying that Static NATs shoudl be out of scope? If so, I disagree. > What > is the reason for taking static NAT out of scope? Many NAT boxes do have an > ability to configure static address/port mapping. I believe, static NATs > shoudl be within scope. > > From what I can tell, much of the recommendation to NAT vendors centers around > requiring them to maintain address/port binds. I would like all NAT vendors to > carry the theme, whether twice-NAT, NAT-PT or bi-directional NAT. I really > dont > see substantial benefit in restricting the discussion scope to traditional > NATs. That is my 2c. > > regards, > suresh > > --- Cullen Jennings wrote: > >> >> I think that twice-nat as described in 2663 is out of scope of this >> document. It's like static NAT in that what do you say about it. >> >> >> On 12/9/04 8:13 AM, "Francois Audet" wrote: >> >>> I think just removing the statement about Twice-NAT is the way to go. >>> >>>>> -----Original Message----- >>>>> From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxx] >>>>> Sent: Wednesday, December 08, 2004 22:25 >>>>> To: Cullen Jennings >>>>> Cc: Bryan Ford; Audet, Francois [SC100:9T51:EXCH]; Pyda >>>>> Srisuresh; Behave >>>>> Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope >>>>> >>>>> >>>>> I agree that we need to cover the situation Bryan is talking >>>>> about, but >>>>> I have heard this called "cascaded NAT" or "multi-layer NAT" or some >>>>> equivalent. To answer Cullen's question, I think twice NAT is quite >>>>> different, as it specifically involves DNS tricks to deal >>>>> with address >>>>> collisions between two domains. See section 4.3 of rfc2663. I don't >>>>> think we need to deal with twice NAT as defined in rfc2663; >>>>> its really >>>>> awful and not that common (AFAIK). >>>>> >>>>> Thanks, >>>>> Jonathan R. >>>>> >>>>> Cullen Jennings wrote: >>>>> >>>>>>> On 12/8/04 2:06 PM, "Bryan Ford" wrote: >>>>>>> >>>>>>> >>>>>>>>> Traditional NATs being combined on the Internet in a hierarchical >>>>>>>>> fashion. For example, consider the standard scenario: an ISP gets a >>>>>>>>> few public IP addresses from its upstream provider, and uses >>>>>>>>> Traditional NAT to create lots of private IP addresses for its >>>>>>>>> customers. Many of the ISP's customers, then, >>>>> **independently and of >>>>>>>>> their own volition**, deploy their own Traditional NATs to >>>>> create home >>>>>>>>> networks. We now have a Twice NAT network scenario, even >>>>> though all >>>>>>>>> of the actual NAT boxes in use are just ordinary Traditional NATs. >>>>>>> >>>>>>> >>>>>>> I agree this scenario is definitely in scope but I get confused by >>>>>>> some of the terminology at times. Is this what RFC 2663 would call >>>>>>> twice NAT? >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ietf-behave mailing list >>>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >>>>>>> >>>>> >>>>> -- >>>>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>>> Director, Service Provider VoIP Architecture Parsippany, NJ >>>>> 07054-2711 >>>>> Cisco Systems >>>>> jdrosen@xxxxxxxxx FAX: (973) 952-5050 >>>>> http://www.jdrosen.net PHONE: (973) 952-5000 >>>>> http://www.cisco.com >>>>> >>>>> >>> >> >> >> > > > ===== From fluffy@cisco.com Thu, 9 Dec 2004 13:38:14 -0800 (PST) From: Cullen Jennings Date: Thu, 9 Dec 2004 13:38:14 -0800 (PST) Subject: [Ietf-behave] FW: BEHAVE minutes IETF 61 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain ------ Forwarded Message From: Cullen Jennings Date: Thu, 09 Dec 2004 12:53:11 -0800 To: Cc: Jiri Kuthan , Cullen Jennings Subject: BEHAVE minutes IETF 61 Behavior Engineering for Hindrance Avoidance WG (behave) TUESDAY, November 9, 2004, 1415-1515 ===================================== CHAIRS: Jiri Kuthan Cullen Jennings 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 From baford@mit.edu Thu, 9 Dec 2004 14:35:45 -0800 (PST) From: Bryan Ford Date: Thu, 9 Dec 2004 14:35:45 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <20041209005513.194.qmail@web40406.mail.yahoo.com> Message-ID: <200412091735.39101.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 09 December 2004 14:52, Senthil Sivakumar wrote: > Any time both the source and the destination addresses are translated by > the same NAT box, we refer to them as twice NAT. The reason some one > has to translate both the source and the destination is that they have > overlapping > networks (mostly caused by mergers/acquisitions/bad design/whatever). > > But the multiple levels of traditional NATs don't cause the source and > destination > to be translated by the same NAT box but by different NAT boxes, as I see > it. To me, that is not the same as twice NAT. Multiple levels of traditional NATs _must_, in some network interconnect scenarios, translate both the source and destination addresses in order to enable reliable P2P connectivity between any two nodes. This is precisely the hairpin translation issue that Suresh alluded to and was discussed in our original draft and elsewhere. In this respect, multiple levels of NAT _do_ qualify as "Twice NAT" in this loose sense of the term as you use it (and as I've inadvertently been using it). But Cullen and others have a legitimate point that RFC 2663's use of the term appears more restricted to a particular type of special-purpose box that _always_ translates both source and destination addresses regardless of the network configuration it is deployed in. So I'm quite happy to go with a different term such as "Multi-level NAT" to refer to the "hierarchical interconnection of Traditional NATs" scenario in which translation of both source and destination ports is _sometimes_ required (in the hairpin case) depending on who is talking to whom. As Cullen pointed out: >On 12/9/04 9:15 AM, "Bryan Ford" wrote: >> So I'm wondering if we have a potential terminology confusion issue here. > >I think we have proven beyond any shadow of a doubt that this is true. If we >are confused, imagine 99.999% of the world that needs to deploy this. Hear hear. Bryan From audet@nortelnetworks.com Thu, 9 Dec 2004 15:28:09 -0800 (PST) From: "Francois Audet" Date: Thu, 9 Dec 2004 15:28:09 -0800 (PST) Subject: RE: [Ietf-behave] Twice NAT _must_ be in-scope Message-ID: <1ECE0EB50388174790F9694F77522CCF01285174@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Twice NAT _must_ be in-scope Again, I'll remove the statement about Twice-NAT and static NAT. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Bryan Ford > Sent: Thursday, December 09, 2004 14:36 > To: Senthil Sivakumar > Cc: 'Behave' > Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope > > > On Thursday 09 December 2004 14:52, Senthil Sivakumar wrote: > > Any time both the source and the destination addresses are > translated > > by the same NAT box, we refer to them as twice NAT. The reason some > > one has to translate both the source and the destination is > that they > > have overlapping networks (mostly caused by > mergers/acquisitions/bad > > design/whatever). > > > > But the multiple levels of traditional NATs don't cause the > source and > > destination to be translated by the same NAT box but by > different NAT > > boxes, as I see it. To me, that is not the same as twice NAT. > > Multiple levels of traditional NATs _must_, in some network > interconnect > scenarios, translate both the source and destination > addresses in order to > enable reliable P2P connectivity between any two nodes. This > is precisely > the hairpin translation issue that Suresh alluded to and was > discussed in our > original draft and elsewhere. In this respect, multiple > levels of NAT _do_ > qualify as "Twice NAT" in this loose sense of the term as you > use it (and as > I've inadvertently been using it). > > But Cullen and others have a legitimate point that RFC 2663's > use of the term > appears more restricted to a particular type of > special-purpose box that > _always_ translates both source and destination addresses > regardless of the > network configuration it is deployed in. So I'm quite happy > to go with a > different term such as "Multi-level NAT" to refer to the > "hierarchical > interconnection of Traditional NATs" scenario in which > translation of both > source and destination ports is _sometimes_ required (in the > hairpin case) > depending on who is talking to whom. > > As Cullen pointed out: > >On 12/9/04 9:15 AM, "Bryan Ford" wrote: > >> So I'm wondering if we have a potential terminology > confusion issue > >> here. > > > >I think we have proven beyond any shadow of a doubt that > this is true. > >If we are confused, imagine 99.999% of the world that needs > to deploy > >this. > > Hear hear. > > Bryan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From srisuresh@yahoo.com Thu, 9 Dec 2004 18:11:56 -0800 (PST) From: Pyda Srisuresh Date: Thu, 9 Dec 2004 18:11:56 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: Message-ID: <20041210021155.97281.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Sorry, that is what I meant. regards, suresh --- Cullen Jennings wrote: > > I don't know what multi stage is but multilayer as described in Bryan's > email has always been one of things this document wanted to work with. > > > On 12/9/04 1:14 PM, "Pyda Srisuresh" wrote: > > > > > Multi-stage NAT deployment being in scope sounds good to me. Actually, I > didnt > > think it was out of scope to start with. Oh, well.. > > > > regards, > > suresh > > > > --- Cullen Jennings wrote: > > > >> On 12/9/04 9:23 AM, "Bryan Ford" wrote: > >> > >>> Exactly the issue I just noticed, after reading Suresh's response to my > >>> earlier message. :) What do you think? What _should_ the hierarchical > >>> interconnect scenario be called? > >> > >> multilayer nat deployments. Two layers is common in Asia (ISP and home). I > >> have seen 3 layers in cases where the ISP had a NAT, the business had one, > >> then a lab inside the business had a NAT. > >> > >> > > > > > > ===== > > ===== From srisuresh@yahoo.com Thu, 9 Dec 2004 18:25:14 -0800 (PST) From: Pyda Srisuresh Date: Thu, 9 Dec 2004 18:25:14 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: Message-ID: <20041210022514.88286.qmail@web40424.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, You make a good point. However, BEHAVE recommendations is not all about static/dynamic port bindings. For example, the UDP behave draft recommends support for hairpin behavior. The draft also recommends support for IP fragmentation. Why should static NATs be excluded for these and other such requirements? regards, suresh --- Cullen Jennings wrote: > > I don't really know what the definition of static nat is but if static nat > is that a packet that arrives at a particular address/port on the outside of > the NAT gets forwarded to some configured address/port on the inside then I > don't know what to say about this. Yes that exists. Many people implement > it. It's described in other documents. What are NATs doing today with static > port forwarding that we thinks need further clarification? What behavior > would we like to clarify or change? There may very well be clear answers to > this but so far no one seems to have brought them up so that's why Francois > and I had tried to get this document to focus on the non deterministic > properties that were causing application problems. > > > On 12/9/04 1:12 PM, "Pyda Srisuresh" wrote: > > > Cullen, > > > > Are you saying that Static NATs shoudl be out of scope? If so, I disagree. > > What > > is the reason for taking static NAT out of scope? Many NAT boxes do have an > > ability to configure static address/port mapping. I believe, static NATs > > shoudl be within scope. > > > > From what I can tell, much of the recommendation to NAT vendors centers > around > > requiring them to maintain address/port binds. I would like all NAT vendors > to > > carry the theme, whether twice-NAT, NAT-PT or bi-directional NAT. I really > > dont > > see substantial benefit in restricting the discussion scope to traditional > > NATs. That is my 2c. > > > > regards, > > suresh > > > > --- Cullen Jennings wrote: > > > >> > >> I think that twice-nat as described in 2663 is out of scope of this > >> document. It's like static NAT in that what do you say about it. > >> > >> > >> On 12/9/04 8:13 AM, "Francois Audet" wrote: > >> > >>> I think just removing the statement about Twice-NAT is the way to go. > >>> > >>>>> -----Original Message----- > >>>>> From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxx] > >>>>> Sent: Wednesday, December 08, 2004 22:25 > >>>>> To: Cullen Jennings > >>>>> Cc: Bryan Ford; Audet, Francois [SC100:9T51:EXCH]; Pyda > >>>>> Srisuresh; Behave > >>>>> Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope > >>>>> > >>>>> > >>>>> I agree that we need to cover the situation Bryan is talking > >>>>> about, but > >>>>> I have heard this called "cascaded NAT" or "multi-layer NAT" or some > >>>>> equivalent. To answer Cullen's question, I think twice NAT is quite > >>>>> different, as it specifically involves DNS tricks to deal > >>>>> with address > >>>>> collisions between two domains. See section 4.3 of rfc2663. I don't > >>>>> think we need to deal with twice NAT as defined in rfc2663; > >>>>> its really > >>>>> awful and not that common (AFAIK). > >>>>> > >>>>> Thanks, > >>>>> Jonathan R. > >>>>> > >>>>> Cullen Jennings wrote: > >>>>> > >>>>>>> On 12/8/04 2:06 PM, "Bryan Ford" wrote: > >>>>>>> > >>>>>>> > >>>>>>>>> Traditional NATs being combined on the Internet in a hierarchical > >>>>>>>>> fashion. For example, consider the standard scenario: an ISP gets a > >>>>>>>>> few public IP addresses from its upstream provider, and uses > >>>>>>>>> Traditional NAT to create lots of private IP addresses for its > >>>>>>>>> customers. Many of the ISP's customers, then, > >>>>> **independently and of > >>>>>>>>> their own volition**, deploy their own Traditional NATs to > >>>>> create home > >>>>>>>>> networks. We now have a Twice NAT network scenario, even > >>>>> though all > >>>>>>>>> of the actual NAT boxes in use are just ordinary Traditional NATs. > >>>>>>> > >>>>>>> > >>>>>>> I agree this scenario is definitely in scope but I get confused by > >>>>>>> some of the terminology at times. Is this what RFC 2663 would call > >>>>>>> twice NAT? > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ietf-behave mailing list > >>>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>>>>> > >>>>> > >>>>> -- > >>>>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>>>> Director, Service Provider VoIP Architecture Parsippany, NJ > >>>>> 07054-2711 > >>>>> Cisco Systems > >>>>> jdrosen@xxxxxxxxx FAX: (973) 952-5050 > >>>>> http://www.jdrosen.net PHONE: (973) 952-5000 > >>>>> http://www.cisco.com > >>>>> > >>>>> > >>> > >> > >> > >> > > > > > > ===== > > ===== From srisuresh@yahoo.com Thu, 9 Dec 2004 18:40:46 -0800 (PST) From: Pyda Srisuresh Date: Thu, 9 Dec 2004 18:40:46 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: Message-ID: <20041210024046.54177.qmail@web40401.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain OK, No problem. Use of hairpin translation & multi level NAT deployments would work for me. cheers, suresh --- Cullen Jennings wrote: > Hmm... > > If I take two normal linksys NAT and connect the two public sides together, > I do not get twice NAT. I think this description is of twice-NAT is greatly > over simplified. > > > On 12/9/04 6:56 AM, "Pyda Srisuresh" wrote: > > > Cullen & Jonathan, > > > > RFC 2663 refers to twice-NAT as one that translates both end points of a > > session. > > > > Consider the multi-stage NAT scenario (Refer section 3.3.3 of > > ford-midcom-p2p-03) that illustrates hairpin/loopback translation on the > > second > > stage NAT. Hairpin translation does involve translating both endpoints of a > > session. By this argument, Bryan's reference to twice-NAT below is in line > > with > > twice-NAT, as defined in RFC 2663. > > > > cheers, > > suresh > > > > --- Jonathan Rosenberg wrote: > > > >> I agree that we need to cover the situation Bryan is talking about, but > >> I have heard this called "cascaded NAT" or "multi-layer NAT" or some > >> equivalent. To answer Cullen's question, I think twice NAT is quite > >> different, as it specifically involves DNS tricks to deal with address > >> collisions between two domains. See section 4.3 of rfc2663. I don't > >> think we need to deal with twice NAT as defined in rfc2663; its really > >> awful and not that common (AFAIK). > >> > >> Thanks, > >> Jonathan R. > >> > >> Cullen Jennings wrote: > >> > >>> On 12/8/04 2:06 PM, "Bryan Ford" wrote: > >>> > >>> > >>>> Traditional NATs being combined on the Internet in a hierarchical > fashion. > >>>> For example, consider the standard scenario: an ISP gets a few public IP > >>>> addresses from its upstream provider, and uses Traditional NAT to create > >> lots > >>>> of private IP addresses for its customers. Many of the ISP's customers, > >>>> then, **independently and of their own volition**, deploy their own > >>>> Traditional NATs to create home networks. We now have a Twice NAT > network > >>>> scenario, even though all of the actual NAT boxes in use are just > ordinary > >>>> Traditional NATs. > >>> > >>> > >>> I agree this scenario is definitely in scope but I get confused by some > of > >>> the terminology at times. Is this what RFC 2663 would call twice NAT? > >>> > >>> _______________________________________________ > >>> Ietf-behave mailing list > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>> > >> > >> -- > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > >> Cisco Systems > >> jdrosen@xxxxxxxxx FAX: (973) 952-5050 > >> http://www.jdrosen.net PHONE: (973) 952-5000 > >> http://www.cisco.com > >> > > > > > > ===== > > ===== From laforge@netfilter.org Fri, 10 Dec 2004 00:03:24 -0800 (PST) From: Harald Welte Date: Fri, 10 Dec 2004 00:03:24 -0800 (PST) Subject: Re: [Ietf-behave] What to do about ICMP In-Reply-To: Message-ID: <20041210080317.GW22577@sunbeam.de.gnumonks.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630132.multipart/signed" --Boundary..27398.1163630132.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, Dec 07, 2004 at 04:23:10PM -0800, Cullen Jennings wrote: > When we were putting our goal together long ago, we said, ICMP, that's a > protocol, we will have a document for it. Now it is looking more like there > is not much to say about it other than in the context of other documents. > > What do we need to say about it outside the context of anything else such as > UDP, Multicast, or TCP? Do we need a document on this? Should we just wrap > it into another document? Does anyone care what NAT's do with ping? Well, there are basically two types of icmp messages 1) error messages related to TCP/UDP/... connections 2) query-response messsages such as ECHO REQUESST / REPLY '1' is mostly generic (like the NAT needs to also translate the inner ip and transport header encapsulated inside of the error message). It is related to TCP/UDP, but can be described in a generic way, I think. I think it would be sane to REQUIRE a NAT to correctly translate PORT/HOST/NET UNREACHABLE and especially FRAGMENTATION NEEDED. '2' is totally independent from other protocols. So I see no reason why it should be merged into TCP/UDP documents. It shold be an entirely seperate document only describing ICMP translation requirements. > Thanks, Cullen -- - Harald Welte http://www.gnumonks.org/ ============================================================================ Programming is like sex: One mistake and you have to support it your lifetime Attachment: signature.asc --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="pgp00015.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00015.pgp" Content-Description: "Description: Digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi41IChHTlUv TGludXgpCgppRDhEQlFGQnVWaEZYYVhHVlREMGkvOFJBdFFBQUtDZ0l4bHhrdkJtNEVUUTVLb3Z0 TXMxYXY0YW1BQ2ZVTFplCklPZldvZXo5MW5DZVhKbmIrVUF5UjcwPQo9MWR1SAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630132.multipart/signed-- From sg266@cornell.edu Fri, 10 Dec 2004 02:55:50 -0800 (PST) From: Saikat Guha Date: Fri, 10 Dec 2004 02:55:50 -0800 (PST) Subject: [Ietf-behave] TCP Simultaneous Open, NATs and Bryan's paper Message-ID: <1102676142.18905.84.camel@broomhilde.guha.cc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630132.multipart/signed" --Boundary..27398.1163630132.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit I am trying to interpret my results from testing, among others, the TCP hole-punching technique proposed in Bryan's paper (http://list.sipfoundry.org/archive/ietf-behave/msg00243.html). I came up with something odd. Maybe someone familiar with nat-check can point out my mistake. Bryan? First, regarding TCP simultaneous-open, it is known that Windows XP (pre SP2) has a buggy implementation. Windows XP SP2 fixes this problem. Other than XP does anyone know of other stacks that don't support it? Regardless, my observation pertains to Windows XP pre SP2. I am wondering if nat-check checks if two windows boxes each behind a NAT can establish a TCP or if one side has to be linux. In my tests, if both ends are windows then it doesn't seem to work as I'll explain later. I went through the nat-check client code and I think the discrepancy can be explained if one of the ends is linux. Has anyone successfully used the technique in the paper above to establish TCP between NAT'ed windows boxes? In the following diagrams, A and B are windows XP pre-SP2 and N and M are NATs. S is a linux box. Here is what I observed. A N M B --------SYN----------->x <-----------------SYN---------- --------SYNACK----------------> <-----------------ACK---------- <----------------DATA---------- --------SYNACK-----------------> (retransmission) <-----------------ACK---------- <----------------DATA---------- --------SYNACK-----------------> (retransmission) ... <-----------------ACK---------- <----------------DATA---------- --------RST--------------------> This is with a server-socket and client-socket both open and bound to the same port on A and similarly for B (as proposed by the paper). One side (in this case B) gets a half-open pipe while the other end appears to be horribly confused. This always happens if you can somehow arrange for an incoming SYN while in SYN-Sent state. Now here is what I am speculating could be happening with NAT-check. Correct me if I am wrong. Case 1: NAT is Cone ... so the S's SYN packet makes its way through to A. S = server #3. A N S <-----------------SYN---------- --------SYNACK----------------> <-----------------ACK---------- the SYN packet is picked up by A's server socket, TCP is established accept() on A succeeds and the subsequent connect() fails (since there is already an established TCP between the respective addresses). Life is good. Case 2: NAT is not cone. Server's SYN is dropped. A N S x<------------SYN------ -----------SYN----------------> <--------------SYNACK---------- --------------ACK-------------> Since the server is linux, it correctly responds with SYNACK to A's SYN and A sees a 3-way handshake. On A, connect() succeeds, accept() doesn't (no incoming SYN). Again it works. Essentially, the Windows XP bug is not triggered in either of the cases since no incoming SYN is seen while in SYN-Sent state. There is a remote case 3 where the bug could be triggered with nat-check. Case 3: A N S +---------SYN------ --------SYN-|-----------------> <-----------+ This is a race condition that is not triggered, I believe, because the client initiates a connect() long after the server has sent the SYN. In the rare occasion that the race were to play out as above then I believe nat-check too would trigger the bug ... though for that the server's timing needs to be adjusted. That said, I do agree that the technique mitigates the problem. This is explained as follows: Case 1: Pure simultaneous open. No NATs. Both A and S have client sockets. No server sockets anywhere. A S <------------------SYN--------- -----------RST----------------> <------------------SYN--------- -----------RST----------------> +---------SYN------ --------SYN-|-----------------> <-----------+ bug triggered. That S keeps retrying increases the probability that a SYN in encountered in the SYN-Sent state. Case 2: Bryan's technique. A S <-----------------SYN---------- --------SYNACK----------------> <-----------------ACK---------- The server socket on A soaks up the SYN and serves two purposes. 1) Stops S from sending any more SYNs and establishes the connection. 2) Stops A from sending out SYNs by failing the connect() thereby avoiding SYN-Sent altogether. Now all this breaks down in we throw in NATs and make both A and B windows boxes, which is what I observed. A N B x<------------SYN------ -----------SYN----------------> the bug is triggered (this time at B). Thoughts? -- Saikat Attachment: signature.asc --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="pgp00016.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00016.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi42IChHTlUv TGludXgpCgppRDhEQlFCQnVZQ3VuRmx0cWk2OTEvb1JBbU5VQUo0bDExaEpKVDlWTHhjWEM3RXdw Ym5xckZvUkdBQ2RHeVh3CmcyYXUydjNMRkR6eGRpL25ZQXl1RTZjPQo9TGJIUwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630132.multipart/signed-- From fluffy@cisco.com Fri, 10 Dec 2004 13:05:19 -0800 (PST) From: Cullen Jennings Date: Fri, 10 Dec 2004 13:05:19 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <20041210022514.88286.qmail@web40424.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 12/9/04 6:25 PM, "Pyda Srisuresh" wrote: > Cullen, > > You make a good point. However, BEHAVE recommendations is not all about > static/dynamic port bindings. For example, the UDP behave draft recommends > support for hairpin behavior. The draft also recommends support for IP > fragmentation. Why should static NATs be excluded for these and other such > requirements? > > regards, > suresh Yes I agree with you that various things types of NATs may want to do many of the same things. I just don't want to take on, in this document, describing all the things one might want to do on a twice-nat to give applications the best odds of working. You make a good point that fragmentation and loopback are examples of things that all NATs might want to deal with in a similar way. Just trying to take this in small bite size pieces. From audet@nortelnetworks.com Fri, 10 Dec 2004 13:08:44 -0800 (PST) From: "Francois Audet" Date: Fri, 10 Dec 2004 13:08:44 -0800 (PST) Subject: RE: [Ietf-behave] Twice NAT _must_ be in-scope Message-ID: <1ECE0EB50388174790F9694F77522CCF0128567D@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Twice NAT _must_ be in-scope Basically, the point is that the requirements in this document is applicable to NATs that support Twice-NAT and Static NAT. I agree with that. What we don't want to do in this document is talk about Twice-NAT or Static NAT specific aspects. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Friday, December 10, 2004 10:50 > To: Pyda Srisuresh; Audet, Francois [SC100:9T51:EXCH]; > Jonathan Rosenberg > Cc: 'Bryan Ford'; Behave > Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope > > > On 12/9/04 6:25 PM, "Pyda Srisuresh" wrote: > > > Cullen, > > > > You make a good point. However, BEHAVE recommendations is not all > > about static/dynamic port bindings. For example, the UDP > behave draft > > recommends support for hairpin behavior. The draft also recommends > > support for IP fragmentation. Why should static NATs be > excluded for > > these and other such requirements? > > > > regards, > > suresh > > Yes I agree with you that various things types of NATs may > want to do many of the same things. I just don't want to take > on, in this document, describing all the things one might > want to do on a twice-nat to give applications the best odds > of working. You make a good point that fragmentation and > loopback are examples of things that all NATs might want to > deal with in a similar way. Just trying to take this in small > bite size pieces. > > > From srisuresh@yahoo.com Fri, 10 Dec 2004 17:53:47 -0800 (PST) From: Pyda Srisuresh Date: Fri, 10 Dec 2004 17:53:47 -0800 (PST) Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: Message-ID: <20041211015347.55008.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, May be, you guys went over this before already. If so, my apologies. But, why not include all NAT types in scope - including Twice-NAT, bi-directional NAT and NAT-PT. From what I had seens of the documents so far, I believe, all of the recommendations we set out for tarditional NATs are applicable to other types of NATs equally well. By includign all NAT types, NAT vendors woudl not have to be concerned that there are no recommendations for certain types of NATs on what would constitute a good behavior. I believe, with little extra effort, we can identify recommendations that would be applicabel across all NAT types. There will always be boxes that take different NAT incarnations, depending upon how the box is configured. Thats my 2c. Thanks. regards, suresh --- Cullen Jennings wrote: > On 12/9/04 6:25 PM, "Pyda Srisuresh" wrote: > > > Cullen, > > > > You make a good point. However, BEHAVE recommendations is not all about > > static/dynamic port bindings. For example, the UDP behave draft recommends > > support for hairpin behavior. The draft also recommends support for IP > > fragmentation. Why should static NATs be excluded for these and other such > > requirements? > > > > regards, > > suresh > > Yes I agree with you that various things types of NATs may want to do many > of the same things. I just don't want to take on, in this document, > describing all the things one might want to do on a twice-nat to give > applications the best odds of working. You make a good point that > fragmentation and loopback are examples of things that all NATs might want > to deal with in a similar way. Just trying to take this in small bite size > pieces. > > ===== From srisuresh@yahoo.com Fri, 10 Dec 2004 17:57:41 -0800 (PST) From: Pyda Srisuresh Date: Fri, 10 Dec 2004 17:57:41 -0800 (PST) Subject: RE: [Ietf-behave] Twice NAT _must_ be in-scope In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0128567D@zrc2hxm0.corp.nortel.com> Message-ID: <20041211015740.13353.qmail@web40407.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Agreed. It is not the objective of the draft to describe NAT types. But, it is the objective of the draft to provide behavioral recommendaations for the known NAT types. regards, suresh --- Francois Audet wrote: > Basically, the point is that the requirements in this document is > applicable to NATs that support Twice-NAT and Static NAT. > > I agree with that. > > What we don't want to do in this document is talk about > Twice-NAT or Static NAT specific aspects. > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > > Sent: Friday, December 10, 2004 10:50 > > To: Pyda Srisuresh; Audet, Francois [SC100:9T51:EXCH]; > > Jonathan Rosenberg > > Cc: 'Bryan Ford'; Behave > > Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope > > > > > > On 12/9/04 6:25 PM, "Pyda Srisuresh" wrote: > > > > > Cullen, > > > > > > You make a good point. However, BEHAVE recommendations is not all > > > about static/dynamic port bindings. For example, the UDP > > behave draft > > > recommends support for hairpin behavior. The draft also recommends > > > support for IP fragmentation. Why should static NATs be > > excluded for > > > these and other such requirements? > > > > > > regards, > > > suresh > > > > Yes I agree with you that various things types of NATs may > > want to do many of the same things. I just don't want to take > > on, in this document, describing all the things one might > > want to do on a twice-nat to give applications the best odds > > of working. You make a good point that fragmentation and > > loopback are examples of things that all NATs might want to > > deal with in a similar way. Just trying to take this in small > > bite size pieces. > > > > > > > ===== From srisuresh@yahoo.com Sun, 12 Dec 2004 22:37:19 -0800 (PST) From: Pyda Srisuresh Date: Sun, 12 Dec 2004 22:37:19 -0800 (PST) Subject: Re: [Ietf-behave] TCP Simultaneous Open, NATs and Bryan's paper In-Reply-To: <1102676142.18905.84.camel@broomhilde.guha.cc> Message-ID: <20041213063719.49772.qmail@web40428.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Saikat, I believe, the traces you outline are taken between M & N, right? It woudl be easy to debug if you have the actual traces (with full frames, along with seqno/ackno) at A, and at B, in addition to between M & N. For example, is it possible that the Ackno. on the ACK frame coming from B does not acknowledge the seqno. on the SYN (or) SYNACK from node A, for whatever reason - introduced by the NAT devices enroute or the buggy end nodes. BTW, what is the bug you are referign to w.r.t Windows XP/SP1? cheers, suresh --- Saikat Guha wrote: > I am trying to interpret my results from testing, among others, the TCP > hole-punching technique proposed in Bryan's paper > (http://list.sipfoundry.org/archive/ietf-behave/msg00243.html). > I came up with something odd. Maybe someone familiar with nat-check can > point out my mistake. Bryan? > > First, regarding TCP simultaneous-open, it is known that Windows XP (pre > SP2) has a buggy implementation. Windows XP SP2 fixes this problem. > Other than XP does anyone know of other stacks that don't support it? > Regardless, my observation pertains to Windows XP pre SP2. > > I am wondering if nat-check checks if two windows boxes each behind a > NAT can establish a TCP or if one side has to be linux. In my tests, if > both ends are windows then it doesn't seem to work as I'll explain > later. I went through the nat-check client code and I think the > discrepancy can be explained if one of the ends is linux. Has anyone > successfully used the technique in the paper above to establish TCP > between NAT'ed windows boxes? > > In the following diagrams, A and B are windows XP pre-SP2 and N and M > are NATs. S is a linux box. Here is what I observed. > > A N M B > --------SYN----------->x > <-----------------SYN---------- > --------SYNACK----------------> > <-----------------ACK---------- > <----------------DATA---------- > --------SYNACK-----------------> (retransmission) > <-----------------ACK---------- > <----------------DATA---------- > --------SYNACK-----------------> (retransmission) > ... > <-----------------ACK---------- > <----------------DATA---------- > --------RST--------------------> > > This is with a server-socket and client-socket both open and bound to > the same port on A and similarly for B (as proposed by the paper). One > side (in this case B) gets a half-open pipe while the other end appears > to be horribly confused. This always happens if you can somehow arrange > for an incoming SYN while in SYN-Sent state. > > Now here is what I am speculating could be happening with NAT-check. > Correct me if I am wrong. > > Case 1: > NAT is Cone ... so the S's SYN packet makes its way through to A. S = > server #3. > > A N S > <-----------------SYN---------- > --------SYNACK----------------> > <-----------------ACK---------- > > the SYN packet is picked up by A's server socket, TCP is established > accept() on A succeeds and the subsequent connect() fails (since there > is already an established TCP between the respective addresses). Life is > good. > > > Case 2: > NAT is not cone. Server's SYN is dropped. > > A N S > x<------------SYN------ > -----------SYN----------------> > <--------------SYNACK---------- > --------------ACK-------------> > > Since the server is linux, it correctly responds with SYNACK to A's SYN > and A sees a 3-way handshake. On A, connect() succeeds, accept() doesn't > (no incoming SYN). Again it works. > > > Essentially, the Windows XP bug is not triggered in either of the cases > since no incoming SYN is seen while in SYN-Sent state. There is a remote > case 3 where the bug could be triggered with nat-check. > > > Case 3: > > A N S > +---------SYN------ > --------SYN-|-----------------> > <-----------+ > > This is a race condition that is not triggered, I believe, because the > client initiates a connect() long after the server has sent the SYN. In > the rare occasion that the race were to play out as above then I believe > nat-check too would trigger the bug ... though for that the server's > timing needs to be adjusted. > > That said, I do agree that the technique mitigates the problem. This is > explained as follows: > > Case 1: > Pure simultaneous open. No NATs. Both A and S have client sockets. No > server sockets anywhere. > > A S > <------------------SYN--------- > -----------RST----------------> > <------------------SYN--------- > -----------RST----------------> > +---------SYN------ > --------SYN-|-----------------> > <-----------+ > > bug triggered. That S keeps retrying increases the probability that a > SYN in encountered in the SYN-Sent state. > > > Case 2: > Bryan's technique. > > A S > <-----------------SYN---------- > --------SYNACK----------------> > <-----------------ACK---------- > > The server socket on A soaks up the SYN and serves two purposes. 1) > Stops S from sending any more SYNs and establishes the connection. 2) > Stops A from sending out SYNs by failing the connect() thereby avoiding > SYN-Sent altogether. > > > Now all this breaks down in we throw in NATs and make both A and B > windows boxes, which is what I observed. > > A N B > x<------------SYN------ > -----------SYN----------------> > > the bug is triggered (this time at B). > > Thoughts? > > -- > Saikat > > ATTACHMENT part 1.2 application/pgp-signature name=signature.asc > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > ===== From srisuresh@yahoo.com Sun, 12 Dec 2004 22:47:25 -0800 (PST) From: Pyda Srisuresh Date: Sun, 12 Dec 2004 22:47:25 -0800 (PST) Subject: Re: [Ietf-behave] What to do about ICMP In-Reply-To: <20041210080317.GW22577@sunbeam.de.gnumonks.org> Message-ID: <20041213064725.1055.qmail@web40406.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Harald, Both uses of ICMP you list below are covered in RFC 3022 (sections 4.1 & 4.3). I believe, the Behave drafts ought to simply cover those cases where these is room for subjectivity and misinterpretation, right. If so, I would argue, item-1 below is the most likely to have misinterpretations (if any) and could be covered under the auspices of TCP & UDP behave drafts, right? cheers, suresh --- Harald Welte wrote: > On Tue, Dec 07, 2004 at 04:23:10PM -0800, Cullen Jennings wrote: > > > When we were putting our goal together long ago, we said, ICMP, that's a > > protocol, we will have a document for it. Now it is looking more like there > > is not much to say about it other than in the context of other documents. > > > > What do we need to say about it outside the context of anything else such > as > > UDP, Multicast, or TCP? Do we need a document on this? Should we just wrap > > it into another document? Does anyone care what NAT's do with ping? > > Well, there are basically two types of icmp messages > > 1) error messages related to TCP/UDP/... connections > > 2) query-response messsages such as ECHO REQUESST / REPLY > > '1' is mostly generic (like the NAT needs to also translate the > inner ip and transport header encapsulated inside of the error > message). It is related to TCP/UDP, but can be described in a generic > way, I think. > > I think it would be sane to REQUIRE a NAT to correctly translate > PORT/HOST/NET UNREACHABLE and especially FRAGMENTATION NEEDED. > > '2' is totally independent from other protocols. > > So I see no reason why it should be merged into TCP/UDP documents. It > shold be an entirely seperate document only describing ICMP translation > requirements. > > > Thanks, Cullen > > -- > - Harald Welte http://www.gnumonks.org/ > ============================================================================ > Programming is like sex: One mistake and you have to support it your lifetime > > ATTACHMENT part 1.2 application/pgp-signature name=signature.asc > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > ===== From sg266@cornell.edu Sun, 12 Dec 2004 23:45:23 -0800 (PST) From: Saikat Guha Date: Sun, 12 Dec 2004 23:45:23 -0800 (PST) Subject: Re: [Ietf-behave] TCP Simultaneous Open, NATs and Bryan's paper In-Reply-To: <20041213063719.49772.qmail@web40428.mail.yahoo.com> Message-ID: <1102923911.24538.13.camel@broomhilde.guha.cc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630132.multipart/signed" --Boundary..27398.1163630132.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2004-12-12 at 22:37 -0800, Pyda Srisuresh wrote: > BTW, what is the bug you are referign to w.r.t Windows XP/SP1? If TCP simultaneous open was attempted on a Windows 2K or XP/SP1 box then the stack would get quite confused. Instead of taking the SYN_SENT -> SYN_RCVD -> ESTABLISHED transition, it would essentially take SYN_SENT -> SYN_RCVD -> SYN_RCVD -> ... where it would keep on sending out SYNACK packets before timing out even after seeing SYNACK and ACK packets. This has been fixed in XP2 and 2k3 we have been told. On a side note, in the draft I cited earlier, Section 4.3 bullet 1 describes the usual TCP simultaneous open as it works under linux, XP SP2 etc. Which implementations correspond to bullet 2? >Subject: RE: Simultaneous 2-way opening >Date: Tue, 16 Nov 2004 14:36:37 -0800 >X-MS-Has-Attach: >X-MS-TNEF-Correlator: >Thread-Topic: Simultaneous 2-way opening >Thread-Index: AcTMI22Fq3Cx25pBSjeR9CgPiv3K8wABkGpw >From: "Richard Draves" >To: "Paul Francis" >Cc: >X-OriginalArrivalTime: 16 Nov 2004 22:36:35.0921 (UTC) >FILETIME=[BAE1E410:01C4CC2C] > >As I noted below, they were already aware of the bug so we can't take >credit for bringing it to their attention. I would be surprised to see a >regression on this in the future, since it's in their test suite now. > > > -----Original Message----- > > From: Paul Francis [mailto:francis@xxxxxxxxxxxxxx] > > Sent: Tuesday, November 16, 2004 1:30 PM > > To: Richard Draves > > Cc: minshall@xxxxxxx > > Subject: RE: Simultaneous 2-way opening > > > > > > My student tells me that service pack 2 of XP now has > > symmetric open for TCP! > > > > Is this thanks to you???? If not, do you know the story? > > I'm especially interested in whether this is a long-term > > change (i.e. future versions of windows OS will allow > > symmetric establishment). > > > > PF > > > > > > At 07:07 PM 9/8/2004, Richard Draves wrote: > > >I checked with the Windows TCP folks. > > > > > >First, they do now test the state transitions > > >SYN_SENT->SYN_RCVD->ESTD->FIN_WAIT1->TIME_WAIT. > > > > > >Second, they had a regression in Win2k/XP. It should be > > fixed in Win2k3 > > >and XPSP2. > > > > > >So I suggest that you test this again with XPSP2 and see if it works. > > > > > >Rich > > > > > > > -----Original Message----- > > > > From: minshall@xxxxxxx [mailto:minshall@xxxxxxx] > > > > Sent: Wednesday, September 08, 2004 4:27 PM > > > > To: Paul Francis > > > > Cc: Richard Draves > > > > Subject: Re: Simultaneous 2-way opening > > > > > > > > i didn't know p2p cared, but if it can be fixed, so much > > the better! -- Saikat Attachment: signature.asc --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="pgp00017.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00017.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi42IChHTlUv TGludXgpCgppRDhEQlFCQnZVaUhuRmx0cWk2OTEvb1JBdFgzQUo5WE1ZVytxaGExNXBwRldlclBZ WitndW9Uc09nQ2JCTEFPCnpNcjBLbS9ieDUyalgrTmVaSkJlNHZVPQo9bDZQTQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630132.multipart/signed-- From dwing@cisco.com Mon, 13 Dec 2004 10:48:22 -0800 (PST) From: Dan Wing Date: Mon, 13 Dec 2004 10:48:22 -0800 (PST) Subject: Re: [Ietf-behave] What to do about ICMP In-Reply-To: <20041213064725.1055.qmail@web40406.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Dec 12, 2004, at 10:47 PM, Pyda Srisuresh wrote: Harald, Both uses of ICMP you list below are covered in RFC 3022 (sections 4.1 & 4.3). I believe, the Behave drafts ought to simply cover those cases where these is room for subjectivity and misinterpretation, right. If so, I would argue, item-1 below is the most likely to have misinterpretations (if any) and could be covered under the auspices of TCP & UDP behave drafts, right? Yes, and section 8 of draft-ietf-behave-nat-00.txt already discusses how a NAT should handle ICMPs that come back after the NAT has sent a UDP packet. draft-ietf-behave-nat is the UDP BEHAVE document (at the IETF meeting it was agreed it will be renamed to make it clearer that it's UDP-only). I think that leaves us with a perhaps very small document to discuss how unsolicited ICMP messages, such as echo request, are supposed to be handled and the existing router requirements in this area (RFC1812, section 4) and the host requirements (RFC1123, section 3.2.2). -d cheers, suresh --- Harald Welte wrote: On Tue, Dec 07, 2004 at 04:23:10PM -0800, Cullen Jennings wrote: When we were putting our goal together long ago, we said, ICMP, that's a protocol, we will have a document for it. Now it is looking more like there is not much to say about it other than in the context of other documents. What do we need to say about it outside the context of anything else such as UDP, Multicast, or TCP? Do we need a document on this? Should we just wrap it into another document? Does anyone care what NAT's do with ping? Well, there are basically two types of icmp messages 1) error messages related to TCP/UDP/... connections 2) query-response messsages such as ECHO REQUESST / REPLY '1' is mostly generic (like the NAT needs to also translate the inner ip and transport header encapsulated inside of the error message). It is related to TCP/UDP, but can be described in a generic way, I think. I think it would be sane to REQUIRE a NAT to correctly translate PORT/HOST/NET UNREACHABLE and especially FRAGMENTATION NEEDED. '2' is totally independent from other protocols. So I see no reason why it should be merged into TCP/UDP documents. It shold be an entirely seperate document only describing ICMP translation requirements. Thanks, Cullen -- - Harald Welte http://www.gnumonks.org/ ====================================================================== ====== Programming is like sex: One mistake and you have to support it your lifetime ATTACHMENT part 1.2 application/pgp-signature name=signature.asc _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave ===== _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From baford@mit.edu Mon, 13 Dec 2004 16:32:20 -0800 (PST) From: Bryan Ford Date: Mon, 13 Dec 2004 16:32:20 -0800 (PST) Subject: [Ietf-behave] Re: TCP Simultaneous Open, NATs and Bryan's paper In-Reply-To: <1102676142.18905.84.camel@broomhilde.guha.cc> Message-ID: <200412131932.13674.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Friday 10 December 2004 05:55, Saikat Guha wrote: > I am trying to interpret my results from testing, among others, the TCP > hole-punching technique proposed in Bryan's paper > (http://list.sipfoundry.org/archive/ietf-behave/msg00243.html). > I came up with something odd. Maybe someone familiar with nat-check can > point out my mistake. Bryan? > > First, regarding TCP simultaneous-open, it is known that Windows XP (pre > SP2) has a buggy implementation. Windows XP SP2 fixes this problem. > Other than XP does anyone know of other stacks that don't support it? > Regardless, my observation pertains to Windows XP pre SP2. I've heard of this long-standing Windows bug, but never knew the details of it, and I'm glad to hear it's finally been fixed. > I am wondering if nat-check checks if two windows boxes each behind a > NAT can establish a TCP or if one side has to be linux. In my tests, if > both ends are windows then it doesn't seem to work as I'll explain > later. I went through the nat-check client code and I think the > discrepancy can be explained if one of the ends is linux. Has anyone > successfully used the technique in the paper above to establish TCP > between NAT'ed windows boxes? NAT Check as written normally performs its tests between the client machine you run it on and a fixed machine here in my lab that happens to run FreeBSD. So you're right - NAT Check doesn't provide a direct test for hole punching between two Windows machines. Since my purpose in writing NAT Check was to test the properties of the NAT(s) on the path rather than to test the properties of the end hosts, this seemed reasonable, and it eliminated the need for the user to have TWO different clients between different firewalls to run NAT Check on simultaneously. But obviously there are some hole punching issues that are caused by certain combinations of broken end host OSes, in addition to those issues caused by the NATs themselves. :) > In the following diagrams, A and B are windows XP pre-SP2 and N and M > are NATs. S is a linux box. Here is what I observed. > > A N M B > --------SYN----------->x > <-----------------SYN---------- > --------SYNACK----------------> > <-----------------ACK---------- > <----------------DATA---------- > --------SYNACK-----------------> (retransmission) > <-----------------ACK---------- > <----------------DATA---------- > --------SYNACK-----------------> (retransmission) > ... > <-----------------ACK---------- > <----------------DATA---------- > --------RST--------------------> > > This is with a server-socket and client-socket both open and bound to > the same port on A and similarly for B (as proposed by the paper). One > side (in this case B) gets a half-open pipe while the other end appears > to be horribly confused. This always happens if you can somehow arrange > for an incoming SYN while in SYN-Sent state. Building on what Suresh already suggested, here is what I suspect might be happening in the above figure: 1. A connects to B while listening on the same source port, sending a SYN to B, which B's NAT drops. A's (buggy) TCP stack creates a TCP state data structure for this outgoing connection attempt and stores (among other things) the initial sequence number it chose for this first outgoing SYN in that data structure. 2. B connects to A while listening on the same source port, sending a SYN to A, which gets through A's now-open hole. Since it's just a raw SYN rather than a SYNACK, A does not associate B's SYN with A's outgoing connection attempt, but instead accepts it via A's outstanding listen socket. Now, rather than re-using the TCP state structure A already created for its outgoing connect() attempt to B, A just creates a new TCP state structure representing an accept()ed server-side socket, and A's TCP stack probably chooses a new and potentially different initial sequence number for its SYNACK response. The fact that A's first SYN might have a different initial sequence number from its subsequent SYNACK might theoretically cause problems, but it presumably isn't the direct cause of THIS specific problem since A's first SYN was never actually seen by B. 3. Now, A has TWO TCP state structures for the same source and destination endpoints - how does it deal with them? Linux immediately cancels the first one (the one created for the outgoing connect()), leaving only the one for the accept() socket, which makes things work right. BSD apparently never creates the two TCP state structures in the first place, which is even better IMHO. But I could very easily envision the buggy Windows TCP stack doing something stupid like keeping the original connect()-initiated state structure around in some fashion, so that when B starts sending real data to A, A tries to associate this data with A's original connect() socket rather than with the accept() socket from which A's SYNACK was produced. Since the TCP stack may well have chosen different initial sequence numbers for the two TCP state structures, A's TCP stack will in this case think that B is sending ACKs and data with totally inappropriate sequence numbers, and just keep retrying its SYNACK as shown above. This is only a vague guess, of course - I've never seen the Windows TCP stack, so I really have no clue exactly how it's managing to screw this up. I'm just happy to hear that they finally fixed it. > Now here is what I am speculating could be happening with NAT-check. > Correct me if I am wrong. I think your analysis of the reason the bug does not manifest itself when the client is a Windows machine but the server is FreeBSD or Linux is most likely exactly correct. Cheers, Bryan > > Case 1: > NAT is Cone ... so the S's SYN packet makes its way through to A. S = > server #3. > > A N S > <-----------------SYN---------- > --------SYNACK----------------> > <-----------------ACK---------- > > the SYN packet is picked up by A's server socket, TCP is established > accept() on A succeeds and the subsequent connect() fails (since there > is already an established TCP between the respective addresses). Life is > good. > > > Case 2: > NAT is not cone. Server's SYN is dropped. > > A N S > x<------------SYN------ > -----------SYN----------------> > <--------------SYNACK---------- > --------------ACK-------------> > > Since the server is linux, it correctly responds with SYNACK to A's SYN > and A sees a 3-way handshake. On A, connect() succeeds, accept() doesn't > (no incoming SYN). Again it works. > > > Essentially, the Windows XP bug is not triggered in either of the cases > since no incoming SYN is seen while in SYN-Sent state. There is a remote > case 3 where the bug could be triggered with nat-check. > > > Case 3: > > A N S > +---------SYN------ > --------SYN-|-----------------> > <-----------+ > > This is a race condition that is not triggered, I believe, because the > client initiates a connect() long after the server has sent the SYN. In > the rare occasion that the race were to play out as above then I believe > nat-check too would trigger the bug ... though for that the server's > timing needs to be adjusted. > > That said, I do agree that the technique mitigates the problem. This is > explained as follows: > > Case 1: > Pure simultaneous open. No NATs. Both A and S have client sockets. No > server sockets anywhere. > > A S > <------------------SYN--------- > -----------RST----------------> > <------------------SYN--------- > -----------RST----------------> > +---------SYN------ > --------SYN-|-----------------> > <-----------+ > > bug triggered. That S keeps retrying increases the probability that a > SYN in encountered in the SYN-Sent state. > > > Case 2: > Bryan's technique. > > A S > <-----------------SYN---------- > --------SYNACK----------------> > <-----------------ACK---------- > > The server socket on A soaks up the SYN and serves two purposes. 1) > Stops S from sending any more SYNs and establishes the connection. 2) > Stops A from sending out SYNs by failing the connect() thereby avoiding > SYN-Sent altogether. > > > Now all this breaks down in we throw in NATs and make both A and B > windows boxes, which is what I observed. > > A N B > x<------------SYN------ > -----------SYN----------------> > > the bug is triggered (this time at B). > > Thoughts? From sg266@cornell.edu Mon, 13 Dec 2004 20:37:35 -0800 (PST) From: Saikat Guha Date: Mon, 13 Dec 2004 20:37:35 -0800 (PST) Subject: [Ietf-behave] Re: TCP Simultaneous Open, NATs and Bryan's paper In-Reply-To: <1102676142.18905.84.camel@broomhilde.guha.cc> Message-ID: <1102999047.27653.38.camel@broomhilde.guha.cc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630132.multipart/signed" --Boundary..27398.1163630132.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Here is an annotated version of the trace. (Pcap files attached). A N M B (192.168.1.137) (128.84.154.97) (128.84.154.99) (192.168.1.1) ----SYN SEQ:425311996----------->x <---SYN SEQ:2632191422---------------------------- ----SYNACK SEQ:425311996,ACK:2632191423-------------> <---ACK SEQ:2632191423,ACK:425311997-------------- <---ACK SEQ:2632191423,ACK:425311997, DATA-------- ----SYNACK SEQ:425311996,ACK:2632191423-------------> (retransmit) <---ACK SEQ:2632191423,ACK:425311997-------------- (retransmit) <---ACK SEQ:2632191423,ACK:425311997, DATA-------- (retransmit) ----SYNACK SEQ:425311996,ACK:2632191423-------------> (retransmit) <---ACK SEQ:2632191423,ACK:425311997-------------- (retransmit) <---ACK SEQ:2632191423,ACK:425311997, DATA-------- (retransmit) <---ACK SEQ:2632191423,ACK:425311997, DATA-------- (retransmit) ----RST SEQ:425311997----------------------------> (Bryan's original mail didn't show up on the list, at-least for me, so I am including relevant portions of his email) > Building on what Suresh already suggested, here is what I suspect might be > happening in the above figure: > > 1. A connects to B while listening on the same source port, sending a SYN to > B, which B's NAT drops. A's (buggy) TCP stack creates a TCP state data > structure for this outgoing connection attempt and stores (among other > things) the initial sequence number it chose for this first outgoing SYN in > that data structure. > > 2. B connects to A while listening on the same source port, sending a SYN to > A, which gets through A's now-open hole. Since it's just a raw SYN rather > than a SYNACK, A does not associate B's SYN with A's outgoing connection > attempt, but instead accepts it via A's outstanding listen socket. Now, > rather than re-using the TCP state structure A already created for its > outgoing connect() attempt to B, A just creates a new TCP state structure > representing an accept()ed server-side socket, and A's TCP stack probably > chooses a new and potentially different initial sequence number for its > SYNACK response. The fact that A's first SYN might have a different initial > sequence number from its subsequent SYNACK might theoretically cause > problems, but it presumably isn't the direct cause of THIS specific problem > since A's first SYN was never actually seen by B. > > 3. Now, A has TWO TCP state structures for the same source and destination > endpoints - how does it deal with them? Linux immediately cancels the first > one (the one created for the outgoing connect()), leaving only the one for > the accept() socket, which makes things work right. BSD apparently never > creates the two TCP state structures in the first place, which is even better > IMHO. But I could very easily envision the buggy Windows TCP stack doing > something stupid like keeping the original connect()-initiated state > structure around in some fashion, so that when B starts sending real data to > A, A tries to associate this data with A's original connect() socket rather > than with the accept() socket from which A's SYNACK was produced. Since the > TCP stack may well have chosen different initial sequence numbers for the two > TCP state structures, A's TCP stack will in this case think that B is sending > ACKs and data with totally inappropriate sequence numbers, and just keep > retrying its SYNACK as shown above. > > This is only a vague guess, of course - I've never seen the Windows TCP > stack, > so I really have no clue exactly how it's managing to screw this up. I'm > just happy to hear that they finally fixed it. I haven't seen the Windows stack either, but I observed the same behavior with just two facing client sockets (without the server sockets). So I am inclined to write it off as a bug as opposed to a premeditated implementation trait. The reason I bring this up is because, to the best of my knowledge, this is the reason why simultaneous-open has not succeeded under windows so far. Windows (SP2) and Linux (and likely the BSDs too) can all now establish a TCP connection with just two facing client sockets. Buggy implementations and NATs blocking incoming SYNs aside, I want to know if there are other stacks that don't support simultaneous-open. The answers to the questions above help me in evaluating the merits of the various TCP traversal techniques that have been proposed -- 1) pure simultaneous open with two client sockets, 2) Bryan's technique with two client and two server sockets, and 3,4) the two mentioned in the NUTSS paper (http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf). -- Saikat Attachment: A-N.pcap Description: Binary data Attachment: B-M.pcap Description: Binary data Attachment: N-M.pcap --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="pgp00018.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00018.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi42IChHTlUv TGludXgpCgppRDhEQlFCQnZtNEhuRmx0cWk2OTEvb1JBb0FTQUo0M1NGblBPS3BwOGFHN1lwSG9D SFpnRW1rSXV3Q2RFNFJOCmlnWVBoa0cwaDdXRWR0c0ROTitVQXlzPQo9QXNYcwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="bin00002.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bin00002.bin" Content-Description: "signature.asc" 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAND2+QbMeCQA+AAAAPgAAAADgmLwRfwANVKlpgQgARQAA MCAhQAB/BqY5gFSaYYBUmmMOcgQoGVm+/AAAAABwAvrwZ9EAAAIEBbQBAQQCND2+QZ/gCgA+AAAA PgAAAAANVKlpgQDgmLwRfwgARQAAMBEpQACABrQxgFSaY4BUmmEEKA5ynOQNvgAAAABwAvrwlYQA AAIEBbQBAQQCND2+QeXrCgA+AAAAPgAAAADgmLwRfwANVKlpgQgARQAAMCAjQAB/BqY3gFSaYYBU mmMOcgQoGVm+/JzkDb9wEvrwvR0AAAIEBbQBAQQCND2+QcfuCgA8AAAAPAAAAAANVKlpgQDgmLwR fwgARQAAKBEqQACABrQ4gFSaY4BUmmEEKA5ynOQNvxlZvv1QEPrw6eEAAAAAAAAAADQ9vkGn8woA tgAAALYAAAAADVSpaYEA4Ji8EX8IAEUAAKgRK0AAgAazt4BUmmOAVJphBCgOcpzkDb8ZWb79UBj6 8FcqAABIZWxsbyBmcm9tIGhvc3QgMS4wAMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzDc9vkHROgoAPgAAAD4AAAAA4Ji8EX8ADVSpaYEIAEUAADAgKEAA fwamMoBUmmGAVJpjDnIEKBlZvvyc5A2/cBL68L0dAAACBAW0AQEEAjc9vkHSPQoAPAAAADwAAAAA DVSpaYEA4Ji8EX8IAEUAACgRL0AAgAa0M4BUmmOAVJphBCgOcpzkDj8ZWb79UBD68OlhAAAAAAAA AAA3Pb5BEuUKALYAAAC2AAAAAA1UqWmBAOCYvBF/CABFAACoETBAAIAGs7KAVJpjgFSaYQQoDnKc 5A2/GVm+/VAY+vBXKgAASGVsbG8gZnJvbSBob3N0IDEuMADMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMw9Pb5BYV4KAD4AAAA+AAAAAOCYvBF/AA1UqWmB CABFAAAwIClAAH8GpjGAVJphgFSaYw5yBCgZWb78nOQNv3AS+vC9HQAAAgQFtAEBBAI9Pb5Bx2AK ADwAAAA8AAAAAA1UqWmBAOCYvBF/CABFAAAoETFAAIAGtDGAVJpjgFSaYQQoDnKc5A4/GVm+/VAQ +vDpYQAAAAAAAAAAPT2+QacHCwC2AAAAtgAAAAANVKlpgQDgmLwRfwgARQAAqBEyQACABrOwgFSa Y4BUmmEEKA5ynOQNvxlZvv1QGPrwVyoAAEhlbGxvIGZyb20gaG9zdCAxLjAAzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMST2+QU9OCwC2AAAAtgAAAAAN VKlpgQDgmLwRfwgARQAAqBEzQACABrOvgFSaY4BUmmEEKA5ynOQNvxlZvv1QGPrwVyoAAEhlbGxv IGZyb20gaG9zdCAxLjAAzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMST2+QV9eCwA8AAAAPAAAAADgmLwRfwANVKlpgQgARQAAKCAtAAB/BuY1gFSaYYBU mmMOcgQoGVm+/RlZvv1QBAAAtysAAAAAAAAAAA== --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="bin00001.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bin00001.bin" Content-Description: "Attachment:" 1MOyoQIABAAAAAAAAAAAAEQAAAABAAAAND2+QRwCCgA+AAAAPgAAAADgmLwRgAAIApJSeAgARQAA MBEpQACABgAAwKgBAYBUmmEEKA5ynOQNvgAAAABwAvrw7pIAAAIEBbQBAQQCND2+QcoPCgA+AAAA PgAAAAAIApJSeADgmLwRgAgARQAAMCAjQAB/Bv9FgFSaYcCoAQEOcgQoGVm+/JzkDb9wEvrwFiwA AAIEBbQBAQQCND2+QQ4RCgA2AAAANgAAAADgmLwRgAAIApJSeAgARQAAKBEqQACABgAAwKgBAYBU mmEEKA5ynOQNvxlZvv1QEPrw3HkAADQ9vkHuFQoARAAAALYAAAAA4Ji8EYAACAKSUngIAEUAAKgR K0AAgAYAAMCoAQGAVJphBCgOcpzkDb8ZWb79UBj68Nz5AABIZWxsbyBmcm9tIGhvczc9vkFWXgkA PgAAAD4AAAAACAKSUngA4Ji8EYAIAEUAADAgKEAAfwb/QIBUmmHAqAEBDnIEKBlZvvyc5A2/cBL6 8BYsAAACBAW0AQEEAjc9vkEVXwkANgAAADYAAAAA4Ji8EYAACAKSUngIAEUAACgRL0AAgAYAAMCo AQGAVJphBCgOcpzkDj8ZWb79UBD68Nx5AAA3Pb5BXgYKAEQAAAC2AAAAAOCYvBGAAAgCklJ4CABF AACoETBAAIAGAADAqAEBgFSaYQQoDnKc5A2/GVm+/VAY+vDc+QAASGVsbG8gZnJvbSBob3M9Pb5B Z4AJAD4AAAA+AAAAAAgCklJ4AOCYvBGACABFAAAwIClAAH8G/z+AVJphwKgBAQ5yBCgZWb78nOQN v3AS+vAWLAAAAgQFtAEBBAI9Pb5BJYEJADYAAAA2AAAAAOCYvBGAAAgCklJ4CABFAAAoETFAAIAG AADAqAEBgFSaYQQoDnKc5A4/GVm+/VAQ+vDceQAAPT2+Qe0nCgBEAAAAtgAAAADgmLwRgAAIApJS eAgARQAAqBEyQACABgAAwKgBAYBUmmEEKA5ynOQNvxlZvv1QGPrw3PkAAEhlbGxvIGZyb20gaG9z ST2+QedrCgBEAAAAtgAAAADgmLwRgAAIApJSeAgARQAAqBEzQACABgAAwKgBAYBUmmEEKA5ynOQN vxlZvv1QGPrw3PkAAEhlbGxvIGZyb20gaG9zST2+QQB+CgA8AAAAPAAAAAAIApJSeADgmLwRgAgA RQAAKCAtAAB/Bj9EgFSaYcCoAQEOcgQoGVm+/RlZvv1QBAAAEDoAAAAAAAAAAA== --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="bin00000.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bin00000.bin" Content-Description: "Description: Binary data" 1MOyoQIABAAAAAAAAAAAAEQAAAABAAAA1jy+QT25CgA+AAAAPgAAAAANVKlpgAAIApKgSAgARQAA MCAhQACABgAAwKgBiYBUmmMOcgQoGVm+/AAAAABwAvrwwFUAAAIEBbQBAQQC1jy+QXyGDAA+AAAA PgAAAAAIApKgSAANVKlpgAgARQAAMBEpQAB/Bg22gFSaY8CoAYkEKA5ynOQNvgAAAABwAvrw7ggA AAIEBbQBAQQC1jy+QVyHDAA+AAAAPgAAAAANVKlpgAAIApKgSAgARQAAMCAjQACABgAAwKgBiYBU mmMOcgQoGVm+/JzkDb9wEvrwFaIAAAIEBbQBAQQC1jy+QceWDAA8AAAAPAAAAAAIApKgSAANVKlp gAgARQAAKBEqQAB/Bg29gFSaY8CoAYkEKA5ynOQNvxlZvv1QEPrwQmYAAAAAAAAAANY8vkEUmwwA RAAAALYAAAAACAKSoEgADVSpaYAIAEUAAKgRK0AAfwYNPIBUmmPAqAGJBCgOcpzkDb8ZWb79UBj6 8K+uAABIZWxsbyBmcm9tIGhvc9k8vkFS1QsAPgAAAD4AAAAADVSpaYAACAKSoEgIAEUAADAgKEAA gAYAAMCoAYmAVJpjDnIEKBlZvvyc5A2/cBL68BWiAAACBAW0AQEEAtk8vkH64gsAPAAAADwAAAAA CAKSoEgADVSpaYAIAEUAACgRL0AAfwYNuIBUmmPAqAGJBCgOcpzkDj8ZWb79UBD68EHmAAAAAAAA AADZPL5B5okMAEQAAAC2AAAAAAgCkqBIAA1UqWmACABFAACoETBAAH8GDTeAVJpjwKgBiQQoDnKc 5A2/GVm+/VAY+vCvrgAASGVsbG8gZnJvbSBob3PfPL5ByPYLAD4AAAA+AAAAAA1UqWmAAAgCkqBI CABFAAAwIClAAIAGAADAqAGJgFSaYw5yBCgZWb78nOQNv3AS+vAVogAAAgQFtAEBBALfPL5B+gcM ADwAAAA8AAAAAAgCkqBIAA1UqWmACABFAAAoETFAAH8GDbaAVJpjwKgBiQQoDnKc5A4/GVm+/VAQ +vBB5gAAAAAAAAAA3zy+QRWrDABEAAAAtgAAAAAIApKgSAANVKlpgAgARQAAqBEyQAB/Bg01gFSa Y8CoAYkEKA5ynOQNvxlZvv1QGPrwr64AAEhlbGxvIGZyb20gaG9z6zy+QZryDABEAAAAtgAAAAAI ApKgSAANVKlpgAgARQAAqBEzQAB/Bg00gFSaY8CoAYkEKA5ynOQNvxlZvv1QGPrwr64AAEhlbGxv IGZyb20gaG9z6zy+QVf0DAA2AAAANgAAAAANVKlpgAAIApKgSAgARQAAKCAtAACABj26wKgBiYBU mmMOcgQoGVm+/RlZvv1QBAAAD7AAAA== --Boundary..27398.1163630132.multipart/signed-- From baford@mit.edu Tue, 14 Dec 2004 07:50:44 -0800 (PST) From: Bryan Ford Date: Tue, 14 Dec 2004 07:50:44 -0800 (PST) Subject: Re: [Ietf-behave] Re: TCP Simultaneous Open, NATs and Bryan's paper In-Reply-To: <1102676142.18905.84.camel@broomhilde.guha.cc> Message-ID: <200412141050.43584.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Monday 13 December 2004 23:37, Saikat Guha wrote: > Here is an annotated version of the trace. (Pcap files attached). > > A N M B > (192.168.1.137) (128.84.154.97) (128.84.154.99) (192.168.1.1) > > ----SYN SEQ:425311996----------->x > <---SYN SEQ:2632191422---------------------------- > ----SYNACK SEQ:425311996,ACK:2632191423-------------> > <---ACK SEQ:2632191423,ACK:425311997-------------- > <---ACK SEQ:2632191423,ACK:425311997, DATA-------- > ----SYNACK SEQ:425311996,ACK:2632191423-------------> (retransmit) > <---ACK SEQ:2632191423,ACK:425311997-------------- (retransmit) > <---ACK SEQ:2632191423,ACK:425311997, DATA-------- (retransmit) > ----SYNACK SEQ:425311996,ACK:2632191423-------------> (retransmit) > <---ACK SEQ:2632191423,ACK:425311997-------------- (retransmit) > <---ACK SEQ:2632191423,ACK:425311997, DATA-------- (retransmit) > <---ACK SEQ:2632191423,ACK:425311997, DATA-------- (retransmit) > ----RST SEQ:425311997----------------------------> Very interesting - the sequence numbers all look fine, so it presumably is indeed just utter internal confusion on the part of one of the Windows end hosts. Thanks for taking the time to do this analysis! > I haven't seen the Windows stack either, but I observed the same > behavior with just two facing client sockets (without the server > sockets). So I am inclined to write it off as a bug as opposed to a > premeditated implementation trait. The reason I bring this up is > because, to the best of my knowledge, this is the reason why > simultaneous-open has not succeeded under windows so far. Windows (SP2) > and Linux (and likely the BSDs too) can all now establish a TCP > connection with just two facing client sockets. Buggy implementations > and NATs blocking incoming SYNs aside, I want to know if there are other > stacks that don't support simultaneous-open. A good question - I haven't heard specific reports of any, but that of course doesn't really mean much. :) Cheers, Bryan From srisuresh@yahoo.com Thu, 6 Jan 2005 05:51:08 -0800 (PST) From: Pyda Srisuresh Date: Thu, 6 Jan 2005 05:51:08 -0800 (PST) Subject: [Ietf-behave] Please review draft-srisuresh-behave-p2p-state-00.txt Message-ID: <20050106135108.16613.qmail@web40423.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain folks, A new draft draft-srisuresh-behave-p2p-state-00.txt is available for your review. Below is an abstract of the draft. Essentially, the draft attempts to capture the state of P2P apps in conjunction with the NATs. Please provide your feedback on the draft. Also, the WG chairs would like to know whether you would want to pursue this as a WG item. Thanks. This memo documents the methods known to be in use by the TCP/UDP based peer-to-peer (P2P) applications for communication in the presence of network address translators (NATs) at the current time. This memo is not an endorsement of the methods in use, but merely an attempt to undertsand the techniques used. regards, suresh ===== From audet@nortelnetworks.com Thu, 6 Jan 2005 08:52:23 -0800 (PST) From: "Francois Audet" Date: Thu, 6 Jan 2005 08:52:23 -0800 (PST) Subject: RE: [Ietf-behave] Please review draft-srisuresh-behave-p2p-state- 00.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF014425E9@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Please review draft-srisuresh-behave-p2p-state-00.txt Suresh, Can you indicate if there were any major changes from the previous draft draft-ford-midcom-p2p? Thanks. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pyda Srisuresh > Sent: Thursday, January 06, 2005 05:51 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] Please review > draft-srisuresh-behave-p2p-state-00.txt > > > folks, > > A new draft draft-srisuresh-behave-p2p-state-00.txt is > available for your review. Below is an abstract of the draft. > Essentially, the draft attempts to capture the state of P2P > apps in conjunction with the NATs. Please provide your > feedback on the draft. Also, the WG chairs would like to know > whether you would want to pursue this as a WG item. Thanks. > > This memo documents the methods known to be in use by the > TCP/UDP based peer-to-peer (P2P) applications for communication > in the presence of network address translators (NATs) at the > current time. This memo is not an endorsement of the methods > in use, but merely an attempt to undertsand the techniques used. > > regards, > suresh > > ===== > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From srisuresh@yahoo.com Thu, 6 Jan 2005 12:46:15 -0800 (PST) From: Pyda Srisuresh Date: Thu, 6 Jan 2005 12:46:15 -0800 (PST) Subject: RE: [Ietf-behave] Please review draft-srisuresh-behave-p2p-state- 00.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF014425E9@zrc2hxm0.corp.nortel.com> Message-ID: <20050106204614.13699.qmail@web40423.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Francois, The draft is based on draft-ford-midcom-p2p draft. No major changes from the original in terms of content. However, this is only a portion of the original ford-midcom-p2p draft that captures the state of the P2P world. Ex: Guidelines for a p2p-friendly NAT and NAT-friendly-P2P-applications that were part of the ford-midcom draft, but are omitted in this draft. regards, suresh --- Francois Audet wrote: > Suresh, > > Can you indicate if there were any major changes from the previous > draft draft-ford-midcom-p2p? > > Thanks. > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Pyda Srisuresh > > Sent: Thursday, January 06, 2005 05:51 > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: [Ietf-behave] Please review > > draft-srisuresh-behave-p2p-state-00.txt > > > > > > folks, > > > > A new draft draft-srisuresh-behave-p2p-state-00.txt is > > available for your review. Below is an abstract of the draft. > > Essentially, the draft attempts to capture the state of P2P > > apps in conjunction with the NATs. Please provide your > > feedback on the draft. Also, the WG chairs would like to know > > whether you would want to pursue this as a WG item. Thanks. > > > > This memo documents the methods known to be in use by the > > TCP/UDP based peer-to-peer (P2P) applications for communication > > in the presence of network address translators (NATs) at the > > current time. This memo is not an endorsement of the methods > > in use, but merely an attempt to undertsand the techniques used. > > > > regards, > > suresh > > > > ===== > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > ===== From audet@nortelnetworks.com Thu, 6 Jan 2005 14:23:15 -0800 (PST) From: "Francois Audet" Date: Thu, 6 Jan 2005 14:23:15 -0800 (PST) Subject: RE: [Ietf-behave] Please review draft-srisuresh-behave-p2p-state- 00.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF01442896@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Please review draft-srisuresh-behave-p2p-state- 00.txt OK. Thanks. I guess it looks like draft-srisuresh-behave-p2p-state and draft-ietf-behave-behave-nat-udp do not overlap anymore. This is good. > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > Sent: Thursday, January 06, 2005 12:46 > To: Audet, Francois [SC100:9T51:EXCH]; > 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: RE: [Ietf-behave] Please review > draft-srisuresh-behave-p2p-state- 00.txt > > > Francois, > > The draft is based on draft-ford-midcom-p2p draft. No major > changes from the original in terms of content. However, this > is only a portion of the original ford-midcom-p2p draft that > captures the state of the P2P world. Ex: Guidelines for a > p2p-friendly NAT and NAT-friendly-P2P-applications that were > part of the ford-midcom draft, but are omitted in this draft. > > regards, > suresh > > --- Francois Audet wrote: > > > Suresh, > > > > Can you indicate if there were any major changes from the previous > > draft draft-ford-midcom-p2p? > > > > Thanks. > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > Pyda Srisuresh > > > Sent: Thursday, January 06, 2005 05:51 > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: [Ietf-behave] Please review > > > draft-srisuresh-behave-p2p-state-00.txt > > > > > > > > > folks, > > > > > > A new draft draft-srisuresh-behave-p2p-state-00.txt is > > > available for your review. Below is an abstract of the draft. > > > Essentially, the draft attempts to capture the state of P2P > > > apps in conjunction with the NATs. Please provide your > > > feedback on the draft. Also, the WG chairs would like to know > > > whether you would want to pursue this as a WG item. Thanks. > > > > > > This memo documents the methods known to be in use by the > > > TCP/UDP based peer-to-peer (P2P) applications for > communication > > > in the presence of network address translators (NATs) at the > > > current time. This memo is not an endorsement of the methods > > > in use, but merely an attempt to undertsand the > techniques used. > > > > > > regards, > > > suresh > > > > > > ===== > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > ===== > > > From carol_chang8009@yahoo.com.cn Sun, 9 Jan 2005 22:51:22 -0800 (PST) From: Carol Chang Date: Sun, 9 Jan 2005 22:51:22 -0800 (PST) Subject: [Ietf-behave] Looking forward to cooperate with you----Our company sell IPphone, ATA Message-ID: <20050110065115.93288.qmail@web15309.mail.cnb.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Dear All,       We take the liberty of writing to you with a view to building bussiness relations with your firm.       We are a manufacturer of IP PHONE,ATA at china, Our ip phone，ATA --YWH100,YWH10 and YGW10 series are well known for its first-quality,good voice ,high stability ,low cost. Now we have CE and FCC ,at the same time we own export liscense! If you want to know more informations in details, please contact with us or visit our website: http://www.yntx.com We look forward to your specific enquiries and hope to have the opportunity to work together with you in the future.   Wishing you the best of business.Carol==============================Contact person:Carol MSN:Carol_chang8009@xxxxxxxxxxx Email:ync@xxxxxxxxxxx YahooID:Carol_chang8009 ICQ:200931135 Tel:8603717657239 http://www.yntx.comZhengzhou Yuneng Communication Equipment Co.Ltd.=================================== Do You Yahoo!? 注册世界一流品质的雅虎免费电邮 From fluffy@cisco.com Mon, 17 Jan 2005 11:06:46 -0800 (PST) From: Cullen Jennings Date: Mon, 17 Jan 2005 11:06:46 -0800 (PST) Subject: [Ietf-behave] FW: Approval to Post Version -00 Internet-Drafts for the 62nd IETF Meeting in Minneapolis, MN In-Reply-To: <200501141456.JAA18582@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain If you plan to submit a 00 WG draft (i.e. one with a name ietf-behave-*), please let the chairs know a week before the draft submission deadline. Thanks, Cullen ------ Forwarded Message From: Internet-Drafts Administrator Date: Fri, 14 Jan 2005 09:56:39 -0500 To: Working Group Chairs Subject: Approval to Post Version -00 Internet-Drafts for the 62nd IETF Meeting in Minneapolis, MN Dear IETF Working Group Chairs: In order to expedite the processing of the many version -00 I-Ds that the Secretariat receives before an IETF meeting, we ask that you please notify the Secretariat prior to the initial submission cutoff date of all version -00 I-Ds that you expect to approve for posting as WG documents. Please send the filenames of your approved -00 I-Ds to internet-drafts@xxxxxxxx by no later than five (5) business days prior to the cutoff date for -00 submissions, or by Monday, February 7th at 9:00 AM ET for the 62nd IETF Meeting. Please include the word "Approved I-Ds" in the "Subject" field. This procedure will help to ensure that version -00 I-Ds are posted in a timely manner, allowing more time for review by the public. Thank you for your cooperation in this matter. The Internet-Drafts Administrator ------ End of Forwarded Message From audet@nortelnetworks.com Mon, 17 Jan 2005 18:53:19 -0800 (PST) From: "Francois Audet" Date: Mon, 17 Jan 2005 18:53:19 -0800 (PST) Subject: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-00.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF01559D21@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..27398.1163630132.multipart/mixed" --Boundary..27398.1163630132.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit Title: FW: I-D ACTION:draft-ietf-behave-nat-udp-00.txt FYI. This is the update to draft-ietf-behave-nat-00.txt. Notice that the name of the file was changed to include "udp", and thus retained the -00 version number. > -----Original Message----- > From: i-d-announce-bounces@xxxxxxxx > [mailto:i-d-announce-bounces@xxxxxxxx] On Behalf Of > Internet-Drafts@xxxxxxxx > Sent: Thursday, January 13, 2005 12:49 > To: i-d-announce@xxxxxxxx > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: I-D ACTION:draft-ietf-behave-nat-udp-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > Behavior Engineering for Hindrance Avoidance Working Group of > the IETF. > > Title : NAT Behavioral Requirements for Unicast UDP > Author(s) : F. Audet, C. Jennings > Filename : draft-ietf-behave-nat-udp-00.txt > Pages : 28 > Date : 2005-1-13 > > This document defines basic terminology for describing different > types of NAT behavior when handling Unicast UDP, and > defines a set of > requirements that would allow many applications, such as multimedia > communications or on-line gaming, to work consistently. Developing > NATs that meet this set of requirements will greatly increase the > likelihood that these applications will function properly. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@xxxxxxxx with the word unsubscribe in > the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-behave-nat-udp-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@xxxxxxxxx > In the body type: > "FILE /internet-drafts/draft-ietf-behave-nat-udp-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > Attachment: ATT600513.TXT Description: Binary data Transfer-mode: ftp.ietf.org _______________________________________________ I-D-Announce mailing list I-D-Announce@xxxxxxxx --Boundary..27398.1163630132.multipart/mixed Content-Type: application/octet-stream; name="bin00003.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bin00003.bin" Content-Description: "https://www1.ietf.org/mailman/listinfo/i-d-announce" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7CglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIgoKQ29udGVudC1UeXBlOiB0ZXh0L3Bs YWluCkNvbnRlbnQtSUQ6IDwyMDA1LTEtMTMxNTM0MDEuSS1EQGlldGYub3JnPgoKRU5DT0RJTkcg bWltZQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1iZWhhdmUtbmF0LXVkcC0wMC50 eHQK --Boundary..27398.1163630132.multipart/mixed-- From baford@mit.edu Sun, 23 Jan 2005 03:08:18 -0800 (PST) From: Bryan Ford Date: Sun, 23 Jan 2005 03:08:18 -0800 (PST) Subject: [Ietf-behave] Topological complications from NAT Message-ID: <200501231208.13009.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Hi folks, I want to get your "first reactions" on an early draft of a new document that my co-author Pyda Srisuresh and I have started, which discusses certain NAT topics that the BEHAVE roadmap currently doesn't address, but probably needs to. As written so far, the document focuses particularly on discussing some of the "weird topologies" that NAT deployment increasingly (and often unintentionally) leads to, such as multi-level NAT with potentially overlapping private IP address spaces, and IP address space conflicts created by remote access VPN software. I've been thinking, however, that this document might appropriately be generalized a bit further into a document describing "recommendations pertaining to NAT deployment" or something like that. Currently on the BEHAVE roadmap we have several documents targetted at NAT implementors, and a document targetted at application developers, but nothing targetted at network administrators who actually _deploy_ NATs - this might be a crucial gap. (Obviously we want to avoid making the title sound like the document is recommending the deployment of NAT, which it's definitely not - but that's a wording issue.) Let us know what you think. Thanks, Bryan --- Topological Complications from Network Address Translation (NAT-TOP) Abstract This document identifies and provides recommendations for dealing with several new issues that have arisen recently out the ubiquitous deployment of network address translators (NAT), and the unconventional network topologies that are often constructed with them. First, the simplicity of configuring and administering networks through the combination of NAT and DHCP is increasingly leading to the deployment of multi-level hierarchies of interconnected private networks involving many overlapping private IP address spaces. The creation of these multi-level hierarchies is often unintentional, since each level of NAT is typically deployed by a separate administrative entity: e.g., an ISP, a corporation, or a home user. Second, the popularity of corporate virtual private networks (VPN) in conjunction with NAT leads to problems in which the private IP address space of the Internet access network through which a remote client is attached may unintentionally conflict with the private IP address space of the corporate network into which the remote client is tunneled. This document specifies best current practice recommendations for addressing each of these issues. Internet Draft B. Ford Document: draft-ford-behave-top-00.txt M.I.T. Expires: July 2005 P. Srisuresh Caymas Systems January 2005 Topological Complications from Network Address Translation (NAT-TOP) Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document identifies and provides recommendations for dealing with several new issues that have arisen recently out the ubiquitous deployment of network address translators (NAT), and the unconventional network topologies that are often constructed with them. First, the simplicity of configuring and administering networks through the combination of NAT and DHCP is increasingly leading to the deployment of multi-level hierarchies of interconnected private networks involving many overlapping private IP address spaces. The creation of these multi-level hierarchies is often unintentional, since each level of NAT is typically deployed by Ford [Page 1] draft-ford-behave-top-00.txt January 2005 a separate administrative entity: e.g., an ISP, a corporation, or a home user. Second, the popularity of corporate virtual private networks (VPN) in conjunction with NAT leads to problems in which the private IP address space of the Internet access network through which a remote client is attached may unintentionally conflict with the private IP address space of the corporate network into which the remote client is tunneled. This document specifies best current practice recommendations for addressing each of these issues. Table of Contents 1. Introduction ................................................. 2. Multi-Level Private Address Space Topologies ................. 2.1. Operational Details of the Network ...................... 2.1.1. Client/Server Communication ........................... 2.1.2. Peer-to-Peer Communication ............................ 2.2. Caveats with the Network ................................ 2.3. Recommendations ......................................... 3. Remote Access VPN Topologies with Private Address Space ...... 3.1. Operational Details of the Network ...................... 3.2. Caveats with the Network ................................ 3.3. Recommendations .......................................... 4. Security Considerations ...................................... 1. Introduction The Internet was originally designed to use a single, global 32-bit IP address space to identify hosts on the network, allowing applications on one host to address and initiate communications with applications on any other host regardless of the respective hosts' topological locations or administrative domains. For a variety of pragmatic reasons, however, the Internet has gradually drifted away from strict conformance to this ideal of a single flat global address space, and towards a hierarchy of smaller "private" address spaces [RFC1918] clustered around a large central "public" address space. The most important pragmatic causes of this unintended evolution of the Internet's architecture appear to be: 1. Depletion of the 32-bit IPv4 address space due to the exploding total number of hosts on the Internet. Although IPv6 promises to solve this problem, the uptake of IPv6 has in practice been slower than expected. 2. Perceived Security and Privacy: Traditional NAT devices provide a filtering function that permits session flows to cross the NAT in just one direction, from private hosts to public network hosts. This filtering function is widely perceived as a security benefit. Ford [Page 2] draft-ford-behave-top-00.txt January 2005 In addition, the NAT's translation of a host's original IP addresses and port number in private network into an unrelated, external IP address and port number is perceived by some as a privacy benefit. 3. Ease-of-use: NAT vendors often combine the NAT function with a DHCP server function in the same device, which creates a compelling, effectively "plug-and-play" method of setting up small Internet-attached personal networks that is often much easier in practice for unsophisticated consumers than configuring up a true IP subnet. The many popular and inexpensive consumer NAT devices on the market are usually configured "out of the box" to obtain a single "public" IP address from an ISP or "upstream" network via DHCP, and the NAT device in turn acts as both a DHCP server and default router for any "downstream" hosts (and even other NATs) that the user plugs into it. Consumer NATs in this way effectively create and manage private home networks automatically without requiring any knowledge of network protocols or management on the part of the user. This ease-of-use benefit of NAT stems ultimately from the fact that DHCP is only capable of providing a single auto-configured IP address to each client. A DHCP client currently has no way to request a *block* of IP addresses from the server, from it might in turn form its own auto-configured "downstream" IP subnet for which it provides its own DHCP service. The fact that DHCP is only capable of auto-configuring client hosts, and is not capable of auto-configuring entire "client subnets", makes NAT a compelling solution in this common scenario. 2 Multi-Level Private Address Space Topologies Due to the above pragmatic considerations and perhaps others, NATs are increasingly, and often unintentionally, used to create hierarchically interconnected clusters of private networks as illustrated in the following diagram: Ford [Page 3] draft-ford-behave-top-00.txt January 2005 Main Internet (public IP addresses) ----+---------------+---------------+---------------+---- | | | | | | | | 66.39.3.7 18.181.0.31 138.76.29.7 155.99.25.1 +-------+ Host A Host B +-------------+ | NAT 1 | (Alice) (Jim) | NAT 2 | | (Bob) | | (CheapoISP) | +-------+ +-------------+ 10.1.1.1 10.1.1.1 | | | | Private Network 1 Private Network 2 (private IP addresses) (private IP addresses) ----+--------+---- ----+-----------------------+---- | | | | | | | | | | 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 10.1.1.12 Host C Host D +-------+ Host E +-------+ | NAT 3 | (Mary) | NAT 4 | | (Ann) | | (Lex) | +-------+ +-------+ 10.1.1.1 10.1.1.1 | | | | Private Network 3 | Private Network 4 (private IP addresses)| (private IP addresses) ----+-----------+---+ ----+-----------+---- | | | | | | | | 10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 Host F Host G Host H Host I In the above scenario, Bob, Alice, Jim, and CheapoISP have each obtained a "genuine", globally routable IP address from an upstream service provider. Alice and Jim have chosen to attach only a single machine at each of these public IP addresses, preserving the originally intended architecture of the Internet and making their hosts, A and B, globally addressable throughout the Internet. Bob, in contrast, has purchased and attached a typical consumer NAT box. Bob's NAT obtains its external IP address (66.39.3.7) from Bob's ISP via DHCP, and automatically creates a private 10.1.1.x network for Bob's hosts C and D, acting as the DHCP server and default router for this private network. Bob probably does not even know anything about IP addresses; he merely knows that plugging the NAT into the Internet as instructed by the ISP, and then plugging his hosts into the NAT as the NAT's manual indicates, seems to work and gives all of his hosts Ford [Page 4] draft-ford-behave-top-00.txt January 2005 access to Internet. CheapoISP, an inexpensive service provider, has allocated only one or a few globally routable IP addresses, and uses NAT to share these public IP addresses among its many customers. Such an arrangement is becoming extremely common, especially in rapidly-developing countries where the exploding number of Internet-attached hosts greatly outstrips the ability of ISPs to obtain globally unique IP addresses for them. CheapoISP has chosen the popular 10.1.1.x address for its private network, since this is one of the three well-known private IP address blocks allocated in RFC specifically for this purpose. Out of the three incentives listed above for NAT deployment, the last two still apply even to customers of ISPs that use NAT, resulting in multi-level NAT toplogies as illustrated in the right side of the above diagram. (Even three-level NAT topologies are known to exist.) CheapoISP's customers Ann, Mary, and Lex have each obtained a single IP address on CheapoISP's network (Private Network 2), via DHCP as usual. Mary attaches only a single host at this point, but Ann and Lex each independently purchase and deploy consumer NATs in the same way that Bob did above. As it turns out, these consumer NATs also happen to use 10.1.1.x addresses for the private networks they create, since these are the configuration defaults hard-coded into the NATs by their vendors. Ann and Lex probably know nothing about IP addresses, and in particular they are probably unaware that the IP address spaces of their own private networks overlap not only with each other but also with the private IP address space used by their immediately upstream network. Nevertheless, despite this direct overlap, all of the "multi-level NATted hosts" - F, G, H, and I in this case - all nominally function and are able to initiate connections to any public server on the main Internet that has a globally routable IP address. Connections made from these hosts to the main Internet are merely translated twice: once by the consumer NAT (3 or 4) into the IP address space of CheapoISP's Private Network 2, and then again by CheapoISP's NAT 2 into the main Internet's global IP address space. 2.1 Operational Details of the Network In the "de facto" Internet address architecture that has resulted from the above pragmatic and economic incentives, only the nodes on the main Internet have globally unique IP addresses assigned by the official IP address registries. IP addresses on different private networks are typically managed independently: either manually by the administrator of the private network itself, or automatically by the NAT through which the private network is connected to its "upstream" service provider. Ford [Page 5] draft-ford-behave-top-00.txt January 2005 By convention, nodes on private networks are usually assigned IP addresses in one of the private address space ranges specifically allocated to this purpose in RFC 1918, ensuring that private IP addresses are easily distinguishable and do not conflict with the public IP addresses officially assigned to globally routable Internet hosts. A given private IP address can be and often is reused across many different private networks, however. In the figure above, for example, private networks 1, 2, 3, and 4 all have a node with IP address 10.1.1.10. Because the public and private IP address ranges are numerically disjoint, nodes on private networks can make use of both public and private IP addresses when initiating network communication sessions. Nodes on private networks can use private IP addresses to refer to other nodes on the same private network, and nodes can use public IP addresses to refer to nodes on the main Internet. Nodes on private networks have no direct method of addressing nodes on other private networks, however, and nodes on the main Internet have no direct way to address nodes on any private network. For example, host F in the figure above can directly address hosts A, B, and G using their assigned IP addresses, but F has no way to address any of the other hosts in the diagram. Host F in particular has no way even to address host E, even though E is located on the immediately "upstream" private network through which F is connected to the Internet! (Host E has the same IP address as host G, which is "legitimate" in the NAT world because the two hosts are on different private networks.) 2.1.1. Client/Server Communication When a host on a private network initiates a client/server-style communication session with a server on the main Internet, via the server's public IP address, the NAT intercepts the packets comprising that session (usually as a consequence of being the default router for the private network), and modifies the packets' IP and TCP/UDP headers so as to make the session appear externally as if it was initiated by the NAT itself. For example, if host C above initiates a connection to host A at IP address 18.181.0.31, NAT 1 modifies the packets comprising the session so as to appear on the main Internet as if the session originated from NAT 1. Similarly, if host F on private network 3 initiates a connection to host A, NAT 3 modifies the session so as to appear on private network 2 as if it had originated from NAT 3 at IP address 10.1.1.10. The modified session then traverses private network 2 and arrives at NAT 2, which further modifies the session so as to appear on the main Internet as if it had originated from NAT 2 at public IP address 155.99.25.1. The NATs in effect serve as Ford [Page 6] draft-ford-behave-top-00.txt January 2005 proxies that give their private "downstream" client nodes a temporary presence on "upstream" networks to support individual communication sessions. 2.1.2. Peer-to-Peer Communication While this network organization functions in practice for client/server-style communication, when the client is behind one or more levels of NAT and the server is on the main Internet, the lack of globally routable addresses for hosts on private networks makes direct peer-to-peer communication between those hosts difficult. For example, two private hosts F and H on the network shown above might "meet" and learn of each other through a well-known server on the main Internet, such as Host A, and desire to establish direct communication between G and H without requiring A to forward each packet. If G and H merely learn each other's (private) IP addresses from a registry kept by A, their attempts to connect to each other will fail because G and H reside on different private networks. Worse, if their connection attempts are not properly authenticated in some fashion, they may appear to succeed but end up talking to the wrong host: for example, G may end up talking to Host F, the host on Private Network 3 that happens to have the same private IP address as Host H. Host H might similarly end up unintentionally connecting to Host I. 2.2. Caveats with the Network (XXX This section is very rough and still needs a lot of work.) Even though conventional wisdom would suggest that the network described above is seriously broken, in practice it still works in many ways. Let us look at some anomalies here. For example, NAT-3 & NAT-4 are multi-homed on the same subnet(say, 10.1.1/24). Yet, the subnet is disjoint on different LANs; and so the NATs are really not multi-homed. This is an anomaly. NAT-3 is incapable of communicating reliably as a transport endpoint with other nodes on its adjacent networks 2 and 3 (e.g., for management purposes), unless its TCP/IP stack is capable of differentiating packets and communication sessions by the "side" or "port" they arrived from and not merely by IP address. If NAT-3 attempts to resolve the IP address of a neighboring host in the conventional manner by broadcasting an ARP request on all of its physical interfaces, for example, then it may get a different response on each of its physical interfaces. This is another anomaly. Ford [Page 7] draft-ford-behave-top-00.txt January 2005 2) Broken as it already is, it could have been worse and non- functional if the network layout wasnt carefully orchestrated to work. For example, all external interfaces are supposed to be heirarchically arranged, so the outgoign path reaches the Internet facing NAT. The NAT device is assumed to be providing DHCP-service on the private interfaces and NAT service on the external interface. If the nodes are connected differently, chaos could ensue - imagine one of the NAT devices (say, NAT-3) having its private interface on network-2 and NAt interface on network 3. Chaos could also ensue if there were multiple NAT devices on the same LAN. Multiple NAT devices providing DHCP service on the same LAN, from the same address pool is a recipe for chaos. Multiple nodes woudl end up having the same IP address. That would make the network broken. The network can also be broken if two NAT nodes attempt to provide NAT service without coordination between the two. The network will also be broken, if the address a NAT node (ex: NAT-3 or NAT-4) assumed on the DHCP-service providing interface is same as the address it is assigned on the external interface. This can easily happen when the vendors are different. Say, both interfaces being assigned 10.1.1.1 However below are some known caveats. 3. The NAT boxes (NAT 3, Nat 4, NAt 1, NAt 2) themselves do not provide any service other than respond to ping. NATs are not managed. 4. Hosts on the private realm are all assumed to be on a single LAN subnet. What if ISP unwisely uses private RFC1918 IP addresses for its mail servers, etc., which need to be accessible to its customers? Answer: bad things happen. 2.3. Recommendations (XXX needs a lot of work.) Consumer-oriented "Plug and Play" NAT devices MUST, and all NATs SHOULD, be able to handle topologies such as the one described above, in which a private IP address space on one side of the NAT potentially conflicts with the private IP address space on the other side. This means that the NAT must be able to keep the two IP address spaces separate in its internal data structures, and base all packet processing decisions on the "side" or "port" from which the packet arrived and not just on the basis of the IP addresses it contains. Ford [Page 8] draft-ford-behave-top-00.txt January 2005 NATs should individually conform to [BEHAVE-UDP] and [BEHAVE-TCP] guidelines, especially including hairpin translation support. Peer-to-peer apps should conform to [BEHAVE-APP] guidelines for middlebox traversal. Ideally, ISPs should not NAT their customers. If they do, any servers on the ISP's private network that need to be accessible to the ISP's customers (e.g., mail servers) should have global IP addresses, to ensure accessibility to customers who deploy NAT themselves. NAT boxes shoudl privide an ability to use one of two DHCP address pools and automagically use an address pool that does not conflict with the external interface IP address. 3. Remote Access VPN Topologies with Private Address Space Typically, when an enterprise user has a secure remote-access VPN client installed on his/her PC, the VPN client installs a Virtual adapter (VA) on the PC. When the secure VPN is established with corporate office, the VA is assigned an IP address from the corporate VPN-address pool. Subsequent to that, the routes on the PC are redone such that routes to all networks in the corporate network are redirected to the secure VPN, while leaving all other routes unchanged. Now, this becomes tricky when the corporate intranet network is built using RFC1918 address space. The employee may be accessing the corporate VPN either from his/her home office (or) a hotel (or) a customer site (or) a partner site. In other words, the employee's PC may already be located in a RFC1918 address space. So, when the VA is assigned an RC1918 address from the VPN server pool, there may be conflict with being able to route the packets correctly to the employee's corporate network. Ford [Page 9] draft-ford-behave-top-00.txt January 2005 (Corporate Private network 10.0.0.0/8) --------+---------------+------------+---------- | | 10.1.1.1 +---------------+ | | | Secure | | Remote Access | | VPN Server | +------+--------+ | {----+---------------+---------------} { } { Main Internet } { (public IP addresses) } { } {----+---------------+---------------} | 155.99.25.1 +----------------+ | NAT | | (in a Hotel | +--------+ | or home office | | | | or a partner's | | DHCP | | corp. office | | Server | | | | | +----------------+ +--------+ 10.1.1.1 10.1.1.2 | | Remote Private Network | | ----+-----------+-----------+-------------+----------+------ | | | | | | | | 10.1.1.10 10.1.1.11 10.1.1.12 10.1.1.13 Host A Host B +--------+ Host C | RA-VPN | | Client | | PC | +--------+ 3.1. Operational Details of the Network Ford [Page 10] draft-ford-behave-top-00.txt January 2005 3.2. Caveats with the Network 3.3. Recommendations Clearly, the remote access VPN client works best when the external client IP address (on the ethernet NIC) does not overlap with the corporate address space and the coporate VPN address pool. However, this cannot be assumed always. Employees often need to work from within arbitrary private IP address spaces such as hotel rooms, which neither the employee nor the corporate network administrator has any control over. In these situations, we advise the following to ensure proper operation of the Remote access VPN client. 1. The RA-VPN client's external IP address and subnet (at the remote site) should not fall within the address pool assigned by the VPN server. 2. The corporate VPN resources that match the following entities in remote address space will not be permitted access from the remote access VPN client. These are: a) client's external IP address, b) client's next-hop IP address, necessary to access the remote access VPN server from external interface, c) DHCP server on the remote network thatprovides address leases. In general, in orer to ensure continued availability of DHCP-server, any corporate network resource that overlaps the client's xternal IP address network is disallowed. For example, if the PC's external NIC is configured with 10.1.1.1/24, corporate network that overlaps this is not accessible from the remote access VPN client. XXX The above recommendations prevent "network meltdown", but still do not guarantee that the remote employee will be able to access the nodes on the corporate network he needs to if there is address overlap. Possible solutions: 1. Even if most of the private corporate network uses RFC1918 address space, allocate global IP addresses at least for the pool of IP addresses assigned to remote VPN clients, and for the critical servers on the corporate network that the remote VPN clients typically need to access. This will ensure at least that the remote VPN clients can always access those critical servers regardless of the private address space used at the remote attachment point. 2. We can suggest that there be two IP address pools on the VPN server, so the address pool which is used for a VPN client doesnt ever conflict with the physical NIC's IP address. For example, the VPN server might detect a conflict and inform the user that he Ford [Page 11] draft-ford-behave-top-00.txt January 2005 should try to connect to the "other" VPN server or IP address pool; ideally the VPN client and server could cooperate to perform this negotiation automatically. 3. the subnet mask used on the hotels be as small as possible (say, /29) and the hotels have a centralized DHCP-server that covers multiple small subnets. 4. Perhaps, if the VPN server identifed the overlap of the remote IP network and notified the VPN-client of the loss of connectivity to that portion of the corporate world, the VPN-client could do soemthing about it - such as talk to the local admin about assigning himself an IP address from a different subnet (say, plugging to a different plug point) if the hotel has such a facility. 5. Finally, the VPN-client could come in as bump in the stack and redirect all relevant packets in the subnet (with the exception of this that match with the router and DHCP server) over the VPN. This at least reduces the size of the "black hole" on the corporate network from a whole subnet to merely two IP addresses. 4. Security Considerations References (XXX needs serious updating) [BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working Committee, "Bidirectional Peer-to-Peer Communication with Interposing Firewalls and NATs", August 2001. http://www.peer-to-peerwg.org/tech/nat/ [ICE] J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for the Session Initiation Protocol (SIP)", draft-rosenberg-sipping-ice-00 (Work In Progress), February 2003. [IPSEC-NAT] B. Aboba and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004. [KEGEL] Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999. http://www.alumni.caltech.edu/~dank/peer-nat.html [MIDCOM] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. Ford [Page 12] draft-ford-behave-top-00.txt January 2005 [NAT-APPL] D. Senie, "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002. [NAT-PROT] M. Holdrege and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. [NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RSIP] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001. [SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [STUN] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [SYM-STUN] Y. Takeda, "Symmetric NAT Traversal using STUN", draft-takeda-symmetric-nat-traversal-00.txt (Work In Progress), June 2003. [TCP] "Transmission Control Protocol", RFC 793, September 1981. [TEREDO] C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs", draft-ietf-ngtrans-shipworm-08.txt (Work In Progress), September 2002. [TURN] J. Rosenberg, J. Weinberger, R. Mahy, and C. Huitema, "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-01 (Work In Progress), March 2003. [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001. http://www.upnp.org/standardizeddcps/igd.asp Ford [Page 13] draft-ford-behave-top-00.txt January 2005 Author's Address Bryan Ford Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology 77 Massachusetts Ave. Cambridge, MA 02139 U.S.A. Phone: (617) 253-5261 E-mail: baford@xxxxxxx Web: http://www.brynosaurus.com/ Pyda Srisuresh Caymas Systems, Inc. 1179-A North McDowell Blvd. Petaluma, CA 94954 U.S.A. Phone: (707) 283-5063 E-mail: srisuresh@xxxxxxxxx Dan Kegel Kegel.com 901 S. Sycamore Ave. Los Angeles, CA 90036 Phone: (323) 931-6717 E-mail: dank@xxxxxxxxx Web: http://www.kegel.com/ Full Copyright Statement Copyright (C) The Internet Society (2005). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Ford [Page 14] draft-ford-behave-top-00.txt January 2005 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Ford [Page 15] From sg266@cornell.edu Mon, 24 Jan 2005 20:14:34 -0800 (PST) From: Saikat Guha Date: Mon, 24 Jan 2005 20:14:34 -0800 (PST) Subject: [Ietf-behave] NAT TCP Test Client Message-ID: <1106626446.2692.19.camel@broomhilde.guha.cc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630132.multipart/signed" --Boundary..27398.1163630132.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello all, I am classifying NATs to study P2P TCP NAT traversal. I have a new version of the NAT TCP test (similar to Bryan's natcheck). This version tests NAT TCP binding behavior, TCP timers, packet filtering, hairpinning, port overloading etc. Unlike the previous version, this version doesn't require installing a device driver and is available for both Linux and Windows clients. I'd appreciate it a lot if people could test the NATs they have access to and upload the results. Installation: http://nutss.gforge.cis.cornell.edu/stunt-client-installation.php Test results: http://nutss.gforge.cis.cornell.edu/stunt-results.php STUNT Homepage: http://nutss.gforge.cis.cornell.edu/stunt.php Description of tests: http://nutss.gforge.cis.cornell.edu/stunt-client.php Thanks -- Saikat Attachment: signature.asc --Boundary..27398.1163630132.multipart/signed Content-Type: application/octet-stream; name="pgp00019.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00019.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQjljZU5uRmx0cWk2OTEvb1JBbGFVQUo5SkN4RzNEcVEzMUs4V1NOUUFK VnVmRGdxV3RnQ2ZhQjVkCmQ2emhWVVlMclA5SEYyc1BKU3I5T01rPQo9UHVmcgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630132.multipart/signed-- From dwing@cisco.com Wed, 26 Jan 2005 13:48:20 -0800 (PST) From: Dan Wing Date: Wed, 26 Jan 2005 13:48:20 -0800 (PST) Subject: [Ietf-behave] NATting SCTP In-Reply-To: <41E5CD14.4010206@reed.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain (CC'ing ietf-behave, and setting reply-to to ietf-behave) On Jan 26, 2005, at 12:20 PM, Randall Stewart wrote: I admit to only reading that I-D once, but NATting SCTP is certainly more complex than NATting TCP or UDP, especially with multihoming. I'm unclear how two SCTP devices, behind their own NATs, can communicate with each other. The communication problem seems akin to two UDP or TCP devices, behind their own NATs, communicating with each other ---- the NAT will have to preserve the port numbers which means only one SCTP device is permitted behind a NAT, or else the NAT will have to multiplex using something other than the SCTP port number, or else you need an SCTP port discovery protocol (akin to STUN for UDP). No why do you say that? If you follow the recomendation of the drafts you get --From IP-A'(port:2222)-INIT(**)-To:IP-Z:port-80----> ** No addresses listed aka we are singly homed. Nat gets it and makes it ----->From IP-A(port:9999)-INIT(**)---To:IPZ:port-80--------> Nat at IPZ gets it and does whatever static mapping.. i.e. you have the same problem you have with a apache server behind a NAT .. you must have the NAT direct the port 80 connection somewhere.. this is the same for TCP.. ----From IP-A(port:9999)---INIT(**)----To:IPZ':port-8080----> And the reverse mappings take place the opposite ways... I don't see how this does not work.. I agree it works, but only if: 1. you know the SCTP servers behind the NAT, and 2. reconfigure your NAT to do port forwarding, and 3. inform the remote SCTP client of your public SCTP port (which, if there is only one SCTP device behind the NAT, might well be the same as your application's default SCTP port). However, the barista at the local coffeeshop won't reconfigure their NAT to support your SCTP server while you're using wireless at the coffeeshop. And my proverbial father wouldn't know how to reconfigure his NAT, either, and my SCTP application won't know the public SCTP port he chose to use when I visit his house with my wireless device. As to your statement that this is how TCP works, there are active efforts to make TCP servers behind NATs 'just work', without requiring the NAT to be configured for port forwarding. See for example http://nutss.gforge.cis.cornell.edu/stunt.php, which would require only (3) from my list above -- which is necessary anyway if the same application exists on multiple hosts behind a common NAT. -d R and yes Cisco has had at least one customer ask for it... Have they had lots .. no. The reason being where Cisco currently makes money from SCTP is inside the network. Most folks don't run their SS7 over IP network where they want to have a NAT to Global address cross over. [...] I expect SCTP will find more applications than just SS7-over-SCTP, and that will help drive the need for NATs that understand SCTP. -d -- Randall Stewart 803-345-0369 815-342-5222(cell) From dwing@cisco.com Sun, 30 Jan 2005 23:20:15 -0800 (PST) From: Dan Wing Date: Sun, 30 Jan 2005 23:20:15 -0800 (PST) Subject: [Ietf-behave] Re: [e2e] Re: NATting SCTP In-Reply-To: <41E5CD14.4010206@reed.com> Message-ID: <8C4DFBCB-7358-11D9-98B0-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Jan 27, 2005, at 4:00 PM, Randall Stewart wrote: Dan Wing wrote: (CC'ing ietf-behave, and setting reply-to to ietf-behave) On Jan 26, 2005, at 12:20 PM, Randall Stewart wrote: I admit to only reading that I-D once, but NATting SCTP is certainly more complex than NATting TCP or UDP, especially with multihoming. I'm unclear how two SCTP devices, behind their own NATs, can communicate with each other. The communication problem seems akin to two UDP or TCP devices, behind their own NATs, communicating with each other ---- the NAT will have to preserve the port numbers which means only one SCTP device is permitted behind a NAT, or else the NAT will have to multiplex using something other than the SCTP port number, or else you need an SCTP port discovery protocol (akin to STUN for UDP). No why do you say that? If you follow the recomendation of the drafts you get --From IP-A'(port:2222)-INIT(**)-To:IP-Z:port-80----> ** No addresses listed aka we are singly homed. Nat gets it and makes it ----->From IP-A(port:9999)-INIT(**)---To:IPZ:port-80--------> Nat at IPZ gets it and does whatever static mapping.. i.e. you have the same problem you have with a apache server behind a NAT .. you must have the NAT direct the port 80 connection somewhere.. this is the same for TCP.. ----From IP-A(port:9999)---INIT(**)----To:IPZ':port-8080----> And the reverse mappings take place the opposite ways... I don't see how this does not work.. I agree it works, but only if: 1. you know the SCTP servers behind the NAT, and And does this differ with the way we do TCP servers behind a NAT? 2. reconfigure your NAT to do port forwarding, and And again, does this differ with the way we do TCP servers behind a NAT? 3. inform the remote SCTP client of your public SCTP port (which, if there is only one SCTP device behind the NAT, might well be the same as your application's default SCTP port). Again.. All of these cavets you list are the SAME exact ones that you do when you put a TCP server behind a NAT.. you: 1) Place the TCP server behind the NAT and 2) configure your nat to port forward <80> (for example) to 8080 at 10.1.1.1 and 3) Tell the client about the public port. Nothing here is any differnet then the way current nats work with TCP... As I said, I agree it works. I agree that's what happens to use TCP servers today. If you're comfortable that SCTP servers will always need manual configuration of NATs, that's great. TCP hasn't worked out that way, though -- for example, Windows fileshares and "p2p" filesharing both want to connect to TCP servers behind NATs. However, the barista at the local coffeeshop won't reconfigure their NAT to support your SCTP server while you're using wireless at the coffeeshop. And my proverbial father wouldn't know how to reconfigure his NAT, either, and my SCTP application won't know the public SCTP port he chose to use when I visit his house with my wireless device. And let me guess you think someone at these same places is going to know how to configure a TCP server behind a NAT too? I think not.. Today's difficulties in getting TCP servers working behind NATs has caused several workarounds for applications, as you're undoubtedly aware, because TCP servers that are behind unconfigured NATs are inaccessible. As to your statement that this is how TCP works, there are active efforts to make TCP servers behind NATs 'just work', without requiring the NAT to be configured for port forwarding. See for example http://nutss.gforge.cis.cornell.edu/stunt.php, which would require only (3) from my list above -- which is necessary anyway if the same application exists on multiple hosts behind a common NAT. Ok.. there are efforts underway ..I will look at your link.. but whatever you come up with for TCP you can do the same exact thing for SCTP.. Its the same work.. and note that it is "an effort under way" which means the folks at the coffee shop are still doing 1 and 2 to get their TCP server to work behind their NAT :-0 -d R -d R and yes Cisco has had at least one customer ask for it... Have they had lots .. no. The reason being where Cisco currently makes money from SCTP is inside the network. Most folks don't run their SS7 over IP network where they want to have a NAT to Global address cross over. [...] I expect SCTP will find more applications than just SS7-over-SCTP, and that will help drive the need for NATs that understand SCTP. -d -- Randall Stewart 803-345-0369 815-342-5222(cell) -- Randall Stewart 803-345-0369 815-342-5222(cell) From dwing@cisco.com Mon, 31 Jan 2005 08:18:46 -0800 (PST) From: Dan Wing Date: Mon, 31 Jan 2005 08:18:46 -0800 (PST) Subject: [Ietf-behave] Re: [e2e] Re: NATting SCTP In-Reply-To: <41E5CD14.4010206@reed.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Jan 31, 2005, at 5:07 AM, Randall Stewart wrote: Dan: So what magic do you expect SCTP to be able to do that TCP can not? Let me give an example: Today it is possible, with the majority of the NATs on the market, to set up a bi-directional UDP 'connection' with two hosts that are behind their own NATs, _without_ changing the configuration of the NAT. This can be done with STUN (RFC3489), which is done by the application. However, with TCP, it currently isn't possible to do the same -- rather, at least one of the NATs has to be configured. Do we design protocols to go through NAT's now? I'm not suggesting changes to SCTP, the protocol. Rather, I'm suggesting that the recommendations for NATting SCTP be written to allow two SCTP applications behind their own NATs to communicate directly with each other, without requiring configuration changes to their NATs. I expect that SCTP can do this. To answer your question, though, it's my understanding that IPsec-over-UDP was created primarily to traverse NATs. And I know STUN (RFC3489) was created expressly to assist UDP applications traverse NATs. I realize that this is a long standing problem... I suppose one could change the fundamental API of SCTP and move it to use PPID's in the data chunks INSTEAD of ports to access apps... but even at that you still have a problem.. how do you find a port someone is listening on behind a NAT... that is the bottome line problem and I don't think I know a solution... do you? The device behind the NAT has to send a packet (towards the Internet) in order to establish the NAT binding. -d R Dan Wing wrote: On Jan 27, 2005, at 4:00 PM, Randall Stewart wrote: Dan Wing wrote: (CC'ing ietf-behave, and setting reply-to to ietf-behave) On Jan 26, 2005, at 12:20 PM, Randall Stewart wrote: I admit to only reading that I-D once, but NATting SCTP is certainly more complex than NATting TCP or UDP, especially with multihoming. I'm unclear how two SCTP devices, behind their own NATs, can communicate with each other. The communication problem seems akin to two UDP or TCP devices, behind their own NATs, communicating with each other ---- the NAT will have to preserve the port numbers which means only one SCTP device is permitted behind a NAT, or else the NAT will have to multiplex using something other than the SCTP port number, or else you need an SCTP port discovery protocol (akin to STUN for UDP). No why do you say that? If you follow the recomendation of the drafts you get --From IP-A'(port:2222)-INIT(**)-To:IP-Z:port-80----> ** No addresses listed aka we are singly homed. Nat gets it and makes it ----->From IP-A(port:9999)-INIT(**)---To:IPZ:port-80--------> Nat at IPZ gets it and does whatever static mapping.. i.e. you have the same problem you have with a apache server behind a NAT .. you must have the NAT direct the port 80 connection somewhere.. this is the same for TCP.. ----From IP-A(port:9999)---INIT(**)----To:IPZ':port-8080----> And the reverse mappings take place the opposite ways... I don't see how this does not work.. I agree it works, but only if: 1. you know the SCTP servers behind the NAT, and And does this differ with the way we do TCP servers behind a NAT? 2. reconfigure your NAT to do port forwarding, and And again, does this differ with the way we do TCP servers behind a NAT? 3. inform the remote SCTP client of your public SCTP port (which, if there is only one SCTP device behind the NAT, might well be the same as your application's default SCTP port). Again.. All of these cavets you list are the SAME exact ones that you do when you put a TCP server behind a NAT.. you: 1) Place the TCP server behind the NAT and 2) configure your nat to port forward <80> (for example) to 8080 at 10.1.1.1 and 3) Tell the client about the public port. Nothing here is any differnet then the way current nats work with TCP... As I said, I agree it works. I agree that's what happens to use TCP servers today. If you're comfortable that SCTP servers will always need manual configuration of NATs, that's great. TCP hasn't worked out that way, though -- for example, Windows fileshares and "p2p" filesharing both want to connect to TCP servers behind NATs. However, the barista at the local coffeeshop won't reconfigure their NAT to support your SCTP server while you're using wireless at the coffeeshop. And my proverbial father wouldn't know how to reconfigure his NAT, either, and my SCTP application won't know the public SCTP port he chose to use when I visit his house with my wireless device. And let me guess you think someone at these same places is going to know how to configure a TCP server behind a NAT too? I think not.. Today's difficulties in getting TCP servers working behind NATs has caused several workarounds for applications, as you're undoubtedly aware, because TCP servers that are behind unconfigured NATs are inaccessible. As to your statement that this is how TCP works, there are active efforts to make TCP servers behind NATs 'just work', without requiring the NAT to be configured for port forwarding. See for example http://nutss.gforge.cis.cornell.edu/stunt.php, which would require only (3) from my list above -- which is necessary anyway if the same application exists on multiple hosts behind a common NAT. Ok.. there are efforts underway ..I will look at your link.. but whatever you come up with for TCP you can do the same exact thing for SCTP.. Its the same work.. and note that it is "an effort under way" which means the folks at the coffee shop are still doing 1 and 2 to get their TCP server to work behind their NAT :-0 -d R -d R and yes Cisco has had at least one customer ask for it... Have they had lots .. no. The reason being where Cisco currently makes money from SCTP is inside the network. Most folks don't run their SS7 over IP network where they want to have a NAT to Global address cross over. [...] I expect SCTP will find more applications than just SS7-over-SCTP, and that will help drive the need for NATs that understand SCTP. -d -- Randall Stewart 803-345-0369 815-342-5222(cell) -- Randall Stewart 803-345-0369 815-342-5222(cell) -- Randall Stewart 803-345-0369 815-342-5222(cell) From ssenthil@cisco.com Mon, 31 Jan 2005 16:07:58 -0800 (PST) From: Senthil Sivakumar Date: Mon, 31 Jan 2005 16:07:58 -0800 (PST) Subject: [Ietf-behave] Draft on TCP Behavior Message-ID: <4.3.2.7.2.20050131160434.0329d6a0@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain TCP Behavior draft is available at: http://www.ietf.org/internet-drafts/draft-sivakumar-behave-nat-tcp-req-00.txt Please review this and let us know your comments. Senthil From laurenzi@coritel.it Tue, 1 Feb 2005 07:02:13 -0800 (PST) From: "Luca Laurenzi" Date: Tue, 1 Feb 2005 07:02:13 -0800 (PST) Subject: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: <008001c5086f$a197f650$1702a8c0@tesla> MIME-Version: 1.0 Content-Type: text/plain Ifi wantto mapmultiple IP addresses to a single IP adress,using a NAPT mechanism: HOST A+-----------------------N A--E+-------------cloud------------------+--HOST Z HOST B+----------------------P T if HOST A sends a packet: ----->From IP-A(port:2222)---------To:IPZ:port-80----------> Napt gets it and makes: ----->From IP-E(port:9999)---------To:IPZ:port-80-----------> if HOST B sends a packet: ----->From IP-B(port:1111)---------To:IPZ:port-80-----------> Napt gets it and makes: ----->From IP-E(port:8888)---------To:IPZ:port-80-----------> A NAPT table willmapinternal IP addresses toa singleexternal IP address E. NAPT table also create an uniquecorrespondence: HOST IP / source port number, (i.e. 2222 <----> IP A), chosing a portnumber, whitin a set of actually availables port numbers, (..on the fly..). This works, to multiplex/demultiplex packetsfrom/to NAPT device, if i have hosts that are sharing a single externalIP address. (thetraditional NAPT mechanism...) But.. If i have a multihomed host, working whit SCTP, i can't do this!! RFC3257 says "..If Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a perassociation basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association..." What does it means?..if i can't change source port number whitin a gived association, NAPT "will have to multiplex using something other than the SCTP port number"?.. From Qiaobing.Xie@motorola.com Tue, 1 Feb 2005 12:45:13 -0800 (PST) From: Qiaobing Xie Date: Tue, 1 Feb 2005 12:45:13 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <008001c5086f$a197f650$1702a8c0@tesla> Message-ID: <41FFEAFD.6000708@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Luca, Luca Laurenzi wrote: If i want to map multiple IP addresses to a single IP adress, using a NAPT mechanism: HOST A+-----------------------N A--E+-------------cloud------------------+--HOST Z HOST B+---------------------- P T In SCTP, the multiple IP addresses should belong to a single HOST and share a single port. Please revise your example and see if you still have problems. regards, -Qiaobing if HOST A sends a packet: ----->From IP-A(port:2222)---------To:IPZ:port-80----------> Napt gets it and makes: ----->From IP-E(port:9999)---------To:IPZ:port-80-----------> if HOST B sends a packet: ----->From IP-B(port:1111)---------To:IPZ:port-80-----------> Napt gets it and makes: ----->From IP-E(port:8888)---------To:IPZ:port-80-----------> A NAPT table will map internal IP addresses to a single external IP address E. NAPT table also create an unique correspondence: HOST IP / source port number, (i.e. 2222 <----> IP A), chosing a port number, whitin a set of actually availables port numbers, (..on the fly..). This works, to multiplex/demultiplex packets from/to NAPT device, if i have hosts that are sharing a single external IP address. (the traditional NAPT mechanism...) But.. If i have a multihomed host, working whit SCTP, i can't do this!! RFC3257 says "..If Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a perassociation basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association..." What does it means?..if i can't change source port number whitin a gived association, NAPT "will have to multiplex using something other than the SCTP port number"?.. ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From laurenzi@coritel.it Wed, 2 Feb 2005 03:41:39 -0800 (PST) From: "Luca Laurenzi" Date: Wed, 2 Feb 2005 03:41:39 -0800 (PST) Subject: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: <003701c5091c$d00267c0$1702a8c0@tesla> MIME-Version: 1.0 Content-Type: text/plain ok... i make myself clear... it was just an exemple of a general NAPT situation...2 different hosts Aand B, ... my problemwas referred to this situation: SCTP (A+)-------------N SCTP HOST X ( ) A--E+-------------cloud------------+--HOST Z (B+)------------ P T Multihomed Host X. Iconsidera singleassociation. SCTP HOST X use IP A as a main address, and IP B as a secondary address. When IP A sends his packets to Host Z, IP B sends an heartbeat packet: NAPT must traslate both addresses. if A sends a packet: >From IP-A(port:9999)---------To:IPZ:port-80-----------> and NAPTgets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> if B sends a packet: >From IP-B(port:9999)---------To:IPZ:port-80-----------> NAPTgets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> NAPT traslate both IP A and IP B to IP E, and also traslate PORT 9999 toPORT 2222 : because: "..if Network Address Port Translation is used with a multihomed SCTPendpoint, then any port translation must be applied on a perassociation basis such that an SCTPendpoint continues to receive the same port number for all messages within a given association..." Problem:When HOST Z responds: >From IP-Z(port: 80)---------To:IP-E:port-2222-----------> NAPTcannot whodeliver tothis packet: toIP-A or to IP-B ? my question was this: if i can't change source port number whitin a gived association,NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. Luca From Qiaobing.Xie@motorola.com Wed, 2 Feb 2005 15:51:52 -0800 (PST) From: Qiaobing Xie Date: Wed, 2 Feb 2005 15:51:52 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <003701c5091c$d00267c0$1702a8c0@tesla> Message-ID: <4201670E.9070105@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Luca, (cc'ing Randy, I think he may not see mails on this list). My feeling is that the NAPT can translate the response from HOST Z to either IP-A/9999 or IP-B/9999. There may be some interesting side effects though (e.g., heartbeat from IP-B/9999 --> IP-Z/80 gets a heartbeat ack from IP-Z/80 --> IP-A/9999). Or _maybe_ the NAPT should intercept and answer SCTP heartbeats (and handle ICMP messages). regards, -Qiaobing Luca Laurenzi wrote: ok... i make myself clear... it was just an exemple of a general NAPT situation...2 different hosts A and B, ... my problem was referred to this situation: SCTP (A+)-------------N SCTP HOST X ( ) A--E+-------------cloud------------+--HOST Z (B+)------------ P T Multihomed Host X. I consider a single association. SCTP HOST X use IP A as a main address, and IP B as a secondary address. When IP A sends his packets to Host Z, IP B sends an heartbeat packet: NAPT must traslate both addresses. if A sends a packet: >From IP-A(port:9999)---------To:IPZ:port-80-----------> and NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> if B sends a packet: >From IP-B(port:9999)---------To:IPZ:port-80-----------> NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> NAPT traslate both IP A and IP B to IP E, and also traslate PORT 9999 to PORT 2222 : because: "..if Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a per association basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association..." > Problem: When HOST Z responds: >From IP-Z(port: 80)---------To:IP-E:port-2222-----------> NAPT cannot who deliver to this packet: to IP-A or to IP-B ? my question was this: if i can't change source port number whitin a gived association, NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. > Luca ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Wed, 2 Feb 2005 16:40:02 -0800 (PST) From: Dan Wing Date: Wed, 2 Feb 2005 16:40:02 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <003701c5091c$d00267c0$1702a8c0@tesla> Message-ID: <29B3AA23-757C-11D9-98B0-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Feb 2, 2005, at 3:49 PM, Qiaobing Xie wrote: Luca, (cc'ing Randy, I think he may not see mails on this list). My feeling is that the NAPT can translate the response from HOST Z to either IP-A/9999 or IP-B/9999. There may be some interesting side effects though (e.g., heartbeat from IP-B/9999 --> IP-Z/80 gets a heartbeat ack from IP-Z/80 --> IP-A/9999). That doesn't sound desirable - the application won't be able to handle that well, if at all. Or _maybe_ the NAPT should intercept and answer SCTP heartbeats (and handle ICMP messages). By doing so you lose the value of the SCTP heartbeat -- check connectivity to, and the state of, the remote host. I don't think you want to have NATs do that sort of thing. -d regards, -Qiaobing Luca Laurenzi wrote: ok... i make myself clear... it was just an exemple of a general NAPT situation...2 different hosts A and B, ... my problem was referred to this situation: SCTP (A+)-------------N SCTP HOST X ( ) A--E+-------------cloud------------+--HOST Z (B+)------------ P T Multihomed Host X. I consider a single association. SCTP HOST X use IP A as a main address, and IP B as a secondary address. When IP A sends his packets to Host Z, IP B sends an heartbeat packet: NAPT must traslate both addresses. if A sends a packet: >From IP-A(port:9999)---------To:IPZ:port-80-----------> and NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> if B sends a packet: >From IP-B(port:9999)---------To:IPZ:port-80-----------> NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> NAPT traslate both IP A and IP B to IP E, and also traslate PORT 9999 to PORT 2222 : because: "..if Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a per association basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association..." > Problem: When HOST Z responds: >From IP-Z(port: 80)---------To:IP-E:port-2222-----------> NAPT cannot who deliver to this packet: to IP-A or to IP-B ? my question was this: if i can't change source port number whitin a gived association, NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. > Luca ---------------------------------------------------------------------- -- _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From laurenzi@coritel.it Thu, 3 Feb 2005 02:26:38 -0800 (PST) From: "Luca Laurenzi" Date: Thu, 3 Feb 2005 02:26:38 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: <001301c509db$82192160$1702a8c0@tesla> MIME-Version: 1.0 Content-Type: text/plain THUS... if i can't change source port number whitin a gived association, NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. From wolfgang.schruefer@siemens.com Thu, 3 Feb 2005 06:56:42 -0800 (PST) From: Schruefer Wolfgang Date: Thu, 3 Feb 2005 06:56:42 -0800 (PST) Subject: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain OR... ifyou want to use SCTP andyou want to use NAPT (in the classical way) ... ...in theory ... you could extend SCTP to accept fromaremote endpoint multiple IP addresses with multiple ports instead of multiple IP addresses with only onefixed port ... Wolfgang Von: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] Im Auftrag von Luca LaurenziGesendet: Donnerstag, 3. Februar 2005 11:31An: Ietf-behave@xxxxxxxxxxxxxxxxxxxBetreff: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP THUS... if i can't change source port number whitin a gived association, NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. From Qiaobing.Xie@motorola.com Thu, 3 Feb 2005 09:04:15 -0800 (PST) From: Qiaobing Xie Date: Thu, 3 Feb 2005 09:04:15 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <003701c5091c$d00267c0$1702a8c0@tesla> Message-ID: <42025A32.5080707@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Randy, Randall Stewart wrote: ... Now.. I would have a few questions on this arrangment.. 1) To Host Z, I would imagine Host-A must look singly homed... is this what you are thinking? Yes. HOST Z sees HOST A only with one IP addr: IP-E/2222. 2) How would NATP at E know that Host-A has both IP-A and IP-B... even if the NAT knows that Host-A has both of these how would it know that the IP-A and IP-B was bound by the same app to port 9999. Yes, it does, because it has a 2-1 mapping entry kept in its table. This NAPT is SCTP-aware and at the association setup time, it intercepted the INIT (or INIT-ACK) from HOST A and decided (for some outside reasons) to map the two IP addresses (IP A and B) to a single external IP-E. Of cause, NAPT will need to remember that this belongs to the same SCTP association. I guess what you are trying to do here is make NATP at E use both IP-A and IP-B for M-Homing.. but that cannot work unless either: a) The INIT going out from Host-A has the listed address and NATP removes the address list as part of its processing (yuck). Or replace the listed addr with IP E. Either way it will also recompose the INIT and re-do the checksum, etc. This is stated in the draft. It will be a bit work :-) But this is what is needed to make the NAPT SCTP-aware. regards, -Qiaobing b) You pre-configure NATP with this knowledge (double yuck) c) You develop a method to add this knowledge to the NAT.. which I am not sure how .. stun like? or maybe a modified ADD-IP... Anyway.. without this I don't see how the NAT could every use IP-B. .. just thoughts... R Qiaobing Xie wrote: Luca, (cc'ing Randy, I think he may not see mails on this list). My feeling is that the NAPT can translate the response from HOST Z to either IP-A/9999 or IP-B/9999. There may be some interesting side effects though (e.g., heartbeat from IP-B/9999 --> IP-Z/80 gets a heartbeat ack from IP-Z/80 --> IP-A/9999). Or _maybe_ the NAPT should intercept and answer SCTP heartbeats (and handle ICMP messages). regards, -Qiaobing Luca Laurenzi wrote: ok... i make myself clear... it was just an exemple of a general NAPT situation...2 different hosts A and B, ... my problem was referred to this situation: SCTP (A+)-------------N SCTP HOST X ( ) A--E+-------------cloud------------+--HOST Z (B+)------------ P T Multihomed Host X. I consider a single association. SCTP HOST X use IP A as a main address, and IP B as a secondary address. When IP A sends his packets to Host Z, IP B sends an heartbeat packet: NAPT must traslate both addresses. if A sends a packet: >From IP-A(port:9999)---------To:IPZ:port-80-----------> and NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> if B sends a packet: >From IP-B(port:9999)---------To:IPZ:port-80-----------> NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> NAPT traslate both IP A and IP B to IP E, and also traslate PORT 9999 to PORT 2222 : because: "..if Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a per association basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association..." > Problem: When HOST Z responds: >From IP-Z(port: 80)---------To:IP-E:port-2222-----------> NAPT cannot who deliver to this packet: to IP-A or to IP-B ? my question was this: if i can't change source port number whitin a gived association, NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. > Luca ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Qiaobing.Xie@motorola.com Thu, 3 Feb 2005 09:11:08 -0800 (PST) From: Qiaobing Xie Date: Thu, 3 Feb 2005 09:11:08 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <003701c5091c$d00267c0$1702a8c0@tesla> Message-ID: <42025BCE.8090603@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Dan Wing wrote: On Feb 2, 2005, at 3:49 PM, Qiaobing Xie wrote: Luca, (cc'ing Randy, I think he may not see mails on this list). My feeling is that the NAPT can translate the response from HOST Z to either IP-A/9999 or IP-B/9999. There may be some interesting side effects though (e.g., heartbeat from IP-B/9999 --> IP-Z/80 gets a heartbeat ack from IP-Z/80 --> IP-A/9999). That doesn't sound desirable - the application won't be able to handle that well, if at all. Multi-homing (as well as heartbeating) in SCTP is mostly transparent to the app at both ends. I.e., it is handled internally by the SCTP stack itself. Or _maybe_ the NAPT should intercept and answer SCTP heartbeats (and handle ICMP messages). By doing so you lose the value of the SCTP heartbeat -- check connectivity to, and the state of, the remote host. I don't think you want to have NATs do that sort of thing. Agreed. There are pros and cons for doing this. regards, -Qiaobing -d regards, -Qiaobing Luca Laurenzi wrote: ok... i make myself clear... it was just an exemple of a general NAPT situation...2 different hosts A and B, ... my problem was referred to this situation: SCTP (A+)-------------N SCTP HOST X ( ) A--E+-------------cloud------------+--HOST Z (B+)------------ P T Multihomed Host X. I consider a single association. SCTP HOST X use IP A as a main address, and IP B as a secondary address. When IP A sends his packets to Host Z, IP B sends an heartbeat packet: NAPT must traslate both addresses. if A sends a packet: >From IP-A(port:9999)---------To:IPZ:port-80-----------> and NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> if B sends a packet: >From IP-B(port:9999)---------To:IPZ:port-80-----------> NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> NAPT traslate both IP A and IP B to IP E, and also traslate PORT 9999 to PORT 2222 : because: "..if Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a per association basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association..." > Problem: When HOST Z responds: >From IP-Z(port: 80)---------To:IP-E:port-2222-----------> NAPT cannot who deliver to this packet: to IP-A or to IP-B ? my question was this: if i can't change source port number whitin a gived association, NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. > Luca ---------------------------------------------------------------------- -- _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Qiaobing.Xie@motorola.com Thu, 3 Feb 2005 09:12:13 -0800 (PST) From: Qiaobing Xie Date: Thu, 3 Feb 2005 09:12:13 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <001301c509db$82192160$1702a8c0@tesla> Message-ID: <42025C12.1010401@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Luca, Yes, you are correct. -Qiaobing Luca Laurenzi wrote: THUS... if i can't change source port number whitin a gived association, NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Qiaobing.Xie@motorola.com Thu, 3 Feb 2005 09:14:36 -0800 (PST) From: Qiaobing Xie Date: Thu, 3 Feb 2005 09:14:36 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <42025C9E.3060102@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Wolfgang, It is not possible to extend SCTP to use multiple ports in a single endpoint. One fixed port is rather a fundamental part of the SCTP design. regards, -Qiaobing Schruefer Wolfgang wrote: OR ... if you want to use SCTP and you want to use NAPT (in the classical way) ... ... in theory ... you could extend SCTP to accept from a remote endpoint multiple IP addresses with multiple ports instead of multiple IP addresses with only one fixed port ... Wolfgang ------------------------------------------------------------------------ Von: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] Im Auftrag von Luca Laurenzi Gesendet: Donnerstag, 3. Februar 2005 11:31 An: Ietf-behave@xxxxxxxxxxxxxxxxxxx Betreff: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP THUS... if i can't change source port number whitin a gived association, NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Thu, 3 Feb 2005 09:24:03 -0800 (PST) From: Dan Wing Date: Thu, 3 Feb 2005 09:24:03 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <003701c5091c$d00267c0$1702a8c0@tesla> Message-ID: <6F58A468-7608-11D9-98B0-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Feb 3, 2005, at 9:13 AM, Qiaobing Xie wrote: Dan Wing wrote: On Feb 2, 2005, at 3:49 PM, Qiaobing Xie wrote: Luca, (cc'ing Randy, I think he may not see mails on this list). My feeling is that the NAPT can translate the response from HOST Z to either IP-A/9999 or IP-B/9999. There may be some interesting side effects though (e.g., heartbeat from IP-B/9999 --> IP-Z/80 gets a heartbeat ack from IP-Z/80 --> IP-A/9999). That doesn't sound desirable - the application won't be able to handle that well, if at all. Multi-homing (as well as heartbeating) in SCTP is mostly transparent to the app at both ends. I.e., it is handled internally by the SCTP stack itself. So its akin to TCP keepalives which are also handled by the TCP stack but, when a timeout occurs, inform the application? Or _maybe_ the NAPT should intercept and answer SCTP heartbeats (and handle ICMP messages). By doing so you lose the value of the SCTP heartbeat -- check connectivity to, and the state of, the remote host. I don't think you want to have NATs do that sort of thing. Agreed. There are pros and cons for doing this. If SCTP keepalives are akin to TCP keepalives, I couldn't imagine too many people being happy with a NAT responding to TCP keepalives on behalf of a host that's actually dead. -d regards, -Qiaobing -d regards, -Qiaobing Luca Laurenzi wrote: ok... i make myself clear... it was just an exemple of a general NAPT situation...2 different hosts A and B, ... my problem was referred to this situation: SCTP (A+)-------------N SCTP HOST X ( ) A--E+-------------cloud------------+--HOST Z (B+)------------ P T Multihomed Host X. I consider a single association. SCTP HOST X use IP A as a main address, and IP B as a secondary address. When IP A sends his packets to Host Z, IP B sends an heartbeat packet: NAPT must traslate both addresses. if A sends a packet: >From IP-A(port:9999)---------To:IPZ:port-80-----------> and NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> if B sends a packet: >From IP-B(port:9999)---------To:IPZ:port-80-----------> NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> NAPT traslate both IP A and IP B to IP E, and also traslate PORT 9999 to PORT 2222 : because: "..if Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a per association basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association..." > Problem: When HOST Z responds: >From IP-Z(port: 80)---------To:IP-E:port-2222-----------> NAPT cannot who deliver to this packet: to IP-A or to IP-B ? my question was this: if i can't change source port number whitin a gived association, NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. > Luca -------------------------------------------------------------------- -- -- _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Qiaobing.Xie@motorola.com Thu, 3 Feb 2005 11:12:34 -0800 (PST) From: Qiaobing Xie Date: Thu, 3 Feb 2005 11:12:34 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <003701c5091c$d00267c0$1702a8c0@tesla> Message-ID: <42027847.904@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Dan Wing wrote: ... Multi-homing (as well as heartbeating) in SCTP is mostly transparent to the app at both ends. I.e., it is handled internally by the SCTP stack itself. So its akin to TCP keepalives which are also handled by the TCP stack but, when a timeout occurs, inform the application? Exactly. Or _maybe_ the NAPT should intercept and answer SCTP heartbeats (and handle ICMP messages). By doing so you lose the value of the SCTP heartbeat -- check connectivity to, and the state of, the remote host. I don't think you want to have NATs do that sort of thing. Agreed. There are pros and cons for doing this. If SCTP keepalives are akin to TCP keepalives, I couldn't imagine too many people being happy with a NAT responding to TCP keepalives on behalf of a host that's actually dead. There is another side to SCTP HB, that it is also meant to probe the path reachability in a multi-homed setting. Since the insertion of a NAPT may change the multi-path setting (like the example given in this thread), there _may_ be some pros for the NAPT to answer the path probings. regards, -Qiaobing -d regards, -Qiaobing -d regards, -Qiaobing Luca Laurenzi wrote: ok... i make myself clear... it was just an exemple of a general NAPT situation...2 different hosts A and B, ... my problem was referred to this situation: SCTP (A+)-------------N SCTP HOST X ( ) A--E+-------------cloud------------+--HOST Z (B+)------------ P T Multihomed Host X. I consider a single association. SCTP HOST X use IP A as a main address, and IP B as a secondary address. When IP A sends his packets to Host Z, IP B sends an heartbeat packet: NAPT must traslate both addresses. if A sends a packet: >From IP-A(port:9999)---------To:IPZ:port-80-----------> and NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> if B sends a packet: >From IP-B(port:9999)---------To:IPZ:port-80-----------> NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> NAPT traslate both IP A and IP B to IP E, and also traslate PORT 9999 to PORT 2222 : because: "..if Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a per association basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association..." > Problem: When HOST Z responds: >From IP-Z(port: 80)---------To:IP-E:port-2222-----------> NAPT cannot who deliver to this packet: to IP-A or to IP-B ? my question was this: if i can't change source port number whitin a gived association, NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. > Luca -------------------------------------------------------------------- -- -- _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Thu, 3 Feb 2005 11:19:42 -0800 (PST) From: Dan Wing Date: Thu, 3 Feb 2005 11:19:42 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <003701c5091c$d00267c0$1702a8c0@tesla> Message-ID: <96D0D548-7618-11D9-98B0-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Feb 3, 2005, at 11:15 AM, Qiaobing Xie wrote: Dan Wing wrote: ... Multi-homing (as well as heartbeating) in SCTP is mostly transparent to the app at both ends. I.e., it is handled internally by the SCTP stack itself. So its akin to TCP keepalives which are also handled by the TCP stack but, when a timeout occurs, inform the application? Exactly. Ok, thanks. Or _maybe_ the NAPT should intercept and answer SCTP heartbeats (and handle ICMP messages). By doing so you lose the value of the SCTP heartbeat -- check connectivity to, and the state of, the remote host. I don't think you want to have NATs do that sort of thing. Agreed. There are pros and cons for doing this. If SCTP keepalives are akin to TCP keepalives, I couldn't imagine too many people being happy with a NAT responding to TCP keepalives on behalf of a host that's actually dead. There is another side to SCTP HB, that it is also meant to probe the path reachability in a multi-homed setting. Since the insertion of a NAPT may change the multi-path setting (like the example given in this thread), there _may_ be some pros for the NAPT to answer the path probings. If the SCTP device is a wireless device and goes out of range, wouldn't you want heartbeat to notice it's no longer available? If the NAPT is responding to the heatbeats on the SCTP host's behalf (that is, the NAPT is "proxying" the heartbeats), the remote SCTP stack and remote SCTP application won't know the wireless SCTP device has gone out of range. -d regards, -Qiaobing -d regards, -Qiaobing -d regards, -Qiaobing Luca Laurenzi wrote: ok... i make myself clear... it was just an exemple of a general NAPT situation...2 different hosts A and B, ... my problem was referred to this situation: SCTP (A+)-------------N SCTP HOST X ( ) A--E+-------------cloud------------+--HOST Z (B+)------------ P T Multihomed Host X. I consider a single association. SCTP HOST X use IP A as a main address, and IP B as a secondary address. When IP A sends his packets to Host Z, IP B sends an heartbeat packet: NAPT must traslate both addresses. if A sends a packet: >From IP-A(port:9999)---------To:IPZ:port-80-----------> and NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> if B sends a packet: >From IP-B(port:9999)---------To:IPZ:port-80-----------> NAPT gets it and makes: >From IP-E(port:2222)---------To:IPZ:port-80-----------> NAPT traslate both IP A and IP B to IP E, and also traslate PORT 9999 to PORT 2222 : because: "..if Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a per association basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association..." > Problem: When HOST Z responds: >From IP-Z(port: 80)---------To:IP-E:port-2222-----------> NAPT cannot who deliver to this packet: to IP-A or to IP-B ? my question was this: if i can't change source port number whitin a gived association, NAPT will have to multiplex/demultiplex using something other than the SCTP port number?.. > Luca ------------------------------------------------------------------ -- -- -- _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Qiaobing.Xie@motorola.com Thu, 3 Feb 2005 12:22:54 -0800 (PST) From: Qiaobing Xie Date: Thu, 3 Feb 2005 12:22:54 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <003701c5091c$d00267c0$1702a8c0@tesla> Message-ID: <4202866B.7070503@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Dan Wing wrote: ... There is another side to SCTP HB, that it is also meant to probe the path reachability in a multi-homed setting. Since the insertion of a NAPT may change the multi-path setting (like the example given in this thread), there _may_ be some pros for the NAPT to answer the path probings. If the SCTP device is a wireless device and goes out of range, wouldn't you want heartbeat to notice it's no longer available? If the NAPT is responding to the heatbeats on the SCTP host's behalf (that is, the NAPT is "proxying" the heartbeats), the remote SCTP stack and remote SCTP application won't know the wireless SCTP device has gone out of range. Yes, it is rather interesting issue. I didn't mean to say it is always a good thing to do... in some cases it may not be advisable but in others it may have its merits. Need more thoughts on this. regards, -Qiaobing -d From laurenzi@coritel.it Mon, 7 Feb 2005 02:46:16 -0800 (PST) From: "Luca Laurenzi" Date: Mon, 7 Feb 2005 02:46:16 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: <001f01c50d02$e988a7b0$1702a8c0@tesla> MIME-Version: 1.0 Content-Type: text/plain Quiaobing, You say that its not possible to extend SCTP to use multiple ports in a single endpoint... but what is the problem? way SCTP cant workthis way?.. regards, Luca From Qiaobing.Xie@motorola.com Mon, 7 Feb 2005 19:16:53 -0800 (PST) From: Qiaobing Xie Date: Mon, 7 Feb 2005 19:16:53 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <001f01c50d02$e988a7b0$1702a8c0@tesla> Message-ID: <42082FCD.6090000@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Luca, Using a single port is a design decision made at a very early stage in SCTP development. Of cause it can be changed, but that would make it into a different protocol. -Q Luca Laurenzi wrote: Quiaobing, You say that its not possible to extend SCTP to use multiple ports in a single endpoint... but what is the problem? way SCTP cant work this way?.. regards, Luca ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From wolfgang.schruefer@siemens.com Mon, 14 Feb 2005 05:36:34 -0800 (PST) From: Schruefer Wolfgang Date: Mon, 14 Feb 2005 05:36:34 -0800 (PST) Subject: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain Qiaobing, why do you think an extension for multiple destination ports would make SCTP a different protocol? Please consider that the SCTP protocol would remain untouched for all existing scenarios. Only if NAPT is involved such an SCTP extension may be used. Please consider that only the DESTINATION transport addresses should be allowed to contain multiple port numbers. For the LOCAL address handling the design with a unique port remains untouched. Multiple destination ports would affect only the addressing of outgoing packets to an multihomed peer behind a NAPT. Before the packets arrive at the peer NAPT would retranslate the addresses back to an unique port number. This is the reason why SCTP would not need to handle multiple local port numbers. Best regards, Wolfgang Qiaobing Xie wrote: > Luca, > > Using a single port is a design decision made at a very early > stage in SCTP development. Of > cause it can be changed, but that would make it into a > different protocol. > > -Q > > Luca Laurenzi wrote: > > > Quiaobing, > > You say that its not possible to extend SCTP to use > multiple ports in a > > single endpoint... > > but what is the problem? > > way SCTP cant work this way?.. > > regards, > > Luca > > > > From mshore@cisco.com Mon, 14 Feb 2005 06:05:00 -0800 (PST) From: Melinda Shore Date: Mon, 14 Feb 2005 06:05:00 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <5D41883E-7E91-11D9-8494-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Monday, February 14, 2005, at 08:36 AM, Schruefer Wolfgang wrote: Please consider that the SCTP protocol would remain untouched for all existing scenarios. Only if NAPT is involved such an SCTP extension may be used. I think that might be the more typical case. Regardless, there are two problems here: 1) port reuse, and 2) "knowledge" of external addresses. Even if the port problem were solved there's the other problem, in which the fellow sending out the INIT or INIT-ACK needs to be able to place the correct addresses in the address list or the NATs need to be able to do the appropriate fixup. I think the latter is out of the question because it makes topological demands that are impossible to satisfy reliably. If the problem is pushed back out to the endpoints (which arguably is the "correct" way to do things in IP networking, anyway), each host participating in the SCTP endpoint would be able to acquire knowledge of its external address using mechanisms already under development, but there is no existing mechanism for that information to be communicated to the host that sends the address list. Possibly that information could be communicated using the same magic by which the host sending the INIT knows that there are other hosts participating in the endpoint, but wow - I wonder if there are any limits to how far we're willing to go to get stuff to work across NATs. Melinda From spencer@mcsr-labs.org Mon, 14 Feb 2005 21:14:53 -0800 (PST) From: "Spencer Dawkins" Date: Mon, 14 Feb 2005 21:14:53 -0800 (PST) Subject: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <015701c5131d$549be790$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain why do you think an extension for multiple destination ports would make SCTP a different protocol? Please consider that the SCTP protocol would remain untouched for all existing scenarios. Only if NAPT is involved such an SCTP extension may be used. OK, I'll bite... I was assuming (bad assumption?) that two different IP addresses might very well be on two different physical interfaces, on two separate subnets, so a single NAPT won't be on both paths in the general case. So a single NATP can't diddle with with the port numbers for both IP addresses, right? So if you're going to use two separate interfaces through multiple NAPTs, you're going to have to tell your peer about two different ports, and that will require mods to the peer - a much tougher deployment scenario than just me talking to my local NATP. My copy of RFC 2960 shows these options for the INIT chunk: Variable Parameters Status Type Value ------------------------------------------------------------- IPv4 Address (Note 1) Optional 5 IPv6 Address (Note 1) Optional 6 Cookie Preservative Optional 9 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 Supported Address Types (Note 4) Optional 12 So there's no way to tell a peer about two different ports without an extension, yes? What am I not understanding? Spencer From wolfgang.schruefer@siemens.com Tue, 15 Feb 2005 03:38:21 -0800 (PST) From: Schruefer Wolfgang Date: Tue, 15 Feb 2005 03:38:21 -0800 (PST) Subject: AW: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain Melinda, I think it is useful that you state that we have at least two different problems. But I think it is not useful to close a discussion about one problem by refering to the unsolved other problem. I am afraid then we spin round ... Please remember the history of this thread: > Qiaobing, > why do you think an extension for multiple destination ports > would make SCTP a different protocol? > Please consider that the SCTP protocol would remain untouched > for all existing scenarios. > Only if NAPT is involved such an SCTP extension may be used. > ... > Wolfgang > > Qiaobing Xie wrote: > > Luca, > > Using a single port is a design decision made at a very early > > stage in SCTP development. Of > > cause it can be changed, but that would make it into a > > different protocol. > > -Q > > > > Luca Laurenzi wrote: > > > Quiaobing, > > > You say that its not possible to extend SCTP to use > > > multiple ports in a single endpoint... > > > but what is the problem? > > > way SCTP cant work this way?.. > > > regards, > > > Luca Actually the discussion was about an extendend port number usage. Personally I think this is an improtant requirement for a future use of NAPT and it may be solved ... e.g. by an SCTP extension ... The second problem is the detection of external addresses: Here I agree that the existing method by an address list within the INIT/INIT_ACK seems to cause problems, but there might be alternatives ... Best regards, Wolfgang > -----Ursprngliche Nachricht----- > Von: Melinda Shore [mailto:mshore@xxxxxxxxx] > Gesendet: Montag, 14. Februar 2005 15:05 > An: Schruefer Wolfgang > Cc: Ietf-behave@xxxxxxxxxxxxxxxxxxx > Betreff: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP > > On Monday, February 14, 2005, at 08:36 AM, Schruefer Wolfgang wrote: > > Please consider that the SCTP protocol would remain > untouched for all > > existing scenarios. > > Only if NAPT is involved such an SCTP extension may be used. > > I think that might be the more typical case. Regardless, there > are two problems here: 1) port reuse, and 2) "knowledge" of external > addresses. Even if the port problem were solved there's the other > problem, in which the fellow sending out the INIT or INIT-ACK needs > to be able to place the correct addresses in the address list or > the NATs need to be able to do the appropriate fixup. I think the > latter is out of the question because it makes topological demands > that are impossible to satisfy reliably. If the problem is pushed > back out to the endpoints (which arguably is the "correct" way to > do things in IP networking, anyway), each host participating in > the SCTP endpoint would be able to acquire knowledge of its external > address using mechanisms already under development, but there is > no existing mechanism for that information to be communicated to > the host that sends the address list. Possibly that information could > be communicated using the same magic by which the host sending the > INIT knows that there are other hosts participating in the endpoint, > but wow - I wonder if there are any limits to how far we're willing > to go to get stuff to work across NATs. > > Melinda > From wolfgang.schruefer@siemens.com Tue, 15 Feb 2005 04:11:11 -0800 (PST) From: Schruefer Wolfgang Date: Tue, 15 Feb 2005 04:11:11 -0800 (PST) Subject: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain > So there's no way to tell a peer about two different ports without an > extension, yes? yes, without an SCTP extension it is not possible to use different ports and to overcome this problem. Best regards, Wolfgang > -----Ursprngliche Nachricht----- > Von: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] Im Auftrag > von Spencer Dawkins > Gesendet: Dienstag, 15. Februar 2005 06:15 > An: Ietf-behave@xxxxxxxxxxxxxxxxxxx > Betreff: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP > > > why do you think an extension for multiple destination ports would > > make SCTP a different protocol? > > > > Please consider that the SCTP protocol would remain untouched for > > all existing scenarios. > > Only if NAPT is involved such an SCTP extension may be used. > > OK, I'll bite... > > I was assuming (bad assumption?) that two different IP > addresses might > very well be on two different physical interfaces, on two separate > subnets, so a single NAPT won't be on both paths in the general case. > So a single NATP can't diddle with with the port numbers for both IP > addresses, right? So if you're going to use two separate interfaces > through multiple NAPTs, you're going to have to tell your peer about > two different ports, and that will require mods to the peer - a much > tougher deployment scenario than just me talking to my local NATP. > > My copy of RFC 2960 shows these options for the INIT chunk: > > Variable Parameters Status Type Value > ------------------------------------------------------------- > IPv4 Address (Note 1) Optional 5 > IPv6 Address (Note 1) Optional 6 > Cookie Preservative Optional 9 > Reserved for ECN Capable (Note 2) Optional 32768 > (0x8000) > Host Name Address (Note 3) Optional 11 > Supported Address Types (Note 4) Optional 12 > > So there's no way to tell a peer about two different ports without an > extension, yes? > > What am I not understanding? > > Spencer > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From mshore@cisco.com Tue, 15 Feb 2005 05:29:11 -0800 (PST) From: Melinda Shore Date: Tue, 15 Feb 2005 05:29:11 -0800 (PST) Subject: Re: AW: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <7EFEE383-7F55-11D9-8494-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Tuesday, February 15, 2005, at 06:38 AM, Schruefer Wolfgang wrote: But I think it is not useful to close a discussion about one problem by refering to the unsolved other problem. To the contrary - I think that in the past the IETF has made some big balls of wax by failing to consider the larger context when attacking problems as if they're unrelated. In this case SCTP is the most difficult protocol I've encountered to get across NATs, and I'm wondering just how far we're willing to go to get it to work. Only changing the handling of port numbers is not sufficient. Melinda From wolfgang.schruefer@siemens.com Tue, 15 Feb 2005 06:49:53 -0800 (PST) From: Schruefer Wolfgang Date: Tue, 15 Feb 2005 06:49:53 -0800 (PST) Subject: Re: AW: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain > To the contrary - I think that in the past the IETF has made > some big balls of wax by failing to consider the larger context > when attacking problems as if they're unrelated. Yes, let's do it better ;-) > ... Only changing the handling of port numbers is > not sufficient. It might be not sufficent, but for NAT it is ABSOLUTELY FUNDAMENTAL to know whether the port number can be changed or not. In my opinion this question is definitly part of any larger context, do you agree? Best regards, Wolfgang > -----Ursprngliche Nachricht----- > Von: Melinda Shore [mailto:mshore@xxxxxxxxx] > Gesendet: Dienstag, 15. Februar 2005 14:29 > An: Schruefer Wolfgang > Cc: Ietf-behave@xxxxxxxxxxxxxxxxxxx > Betreff: Re: AW: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP > > On Tuesday, February 15, 2005, at 06:38 AM, Schruefer Wolfgang wrote: > > But I think it is not useful to close a discussion about > one problem > > by refering to the unsolved other problem. > > To the contrary - I think that in the past the IETF has made > some big balls of wax by failing to consider the larger context > when attacking problems as if they're unrelated. In this case > SCTP is the most difficult protocol I've encountered to get across > NATs, and I'm wondering just how far we're willing to go to get > it to work. Only changing the handling of port numbers is > not sufficient. > > Melinda > From fluffy@cisco.com Tue, 15 Feb 2005 11:43:09 -0800 (PST) From: Cullen Jennings Date: Tue, 15 Feb 2005 11:43:09 -0800 (PST) Subject: [Ietf-behave] Agenda time IETF 61 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Jiri and are starting to think about putting together the agenda for the for the next IETF meeting. Please email both of us know if think you might want some agenda time. As always, we prefer to spend meeting time solving problems we can't bring to resolution on this list. Thanks, Cullen PS. I would prefer to see draft slides 24 hours before you present. I think this could help the chairs sort out the material to be covered and to make best use of meeting time. From fluffy@cisco.com Tue, 15 Feb 2005 11:44:32 -0800 (PST) From: Cullen Jennings Date: Tue, 15 Feb 2005 11:44:32 -0800 (PST) Subject: [Ietf-behave] Agenda time IETF 62 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain I am a bit late for IETF 61 so let's try for IETF 62 :-) On 2/15/05 11:42 AM, "Cullen Jennings" wrote: > > Jiri and are starting to think about putting together the agenda for the for > the next IETF meeting. Please email both of us know if think you might want > some agenda time. As always, we prefer to spend meeting time solving problems > we can't bring to resolution on this list. > > Thanks, Cullen > > PS. I would prefer to see draft slides 24 hours before you present. I think > this could help the chairs sort out the material to be covered and to make > best use of meeting time. From Qiaobing.Xie@motorola.com Tue, 15 Feb 2005 12:03:19 -0800 (PST) From: Qiaobing Xie Date: Tue, 15 Feb 2005 12:03:19 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <4212562E.3050304@motorola.com> MIME-Version: 1.0 Content-Type: text/plain (added Randy to the cc list since he's not seeing email on behave list) Hi, Wolfgang, Please see my comments in-line. Schruefer Wolfgang wrote: Qiaobing, why do you think an extension for multiple destination ports would make SCTP a different protocol? Please consider that the SCTP protocol would remain untouched for all existing scenarios. Only if NAPT is involved such an SCTP extension may be used. Please consider that only the DESTINATION transport addresses should be allowed to contain multiple port numbers. For the LOCAL address handling the design with a unique port remains untouched. Multiple destination ports would affect only the addressing of outgoing packets to an multihomed peer behind a NAPT. Before the packets arrive at the peer NAPT would retranslate the addresses back to an unique port number. This is the reason why SCTP would not need to handle multiple local port numbers. I guess I still do not fully understand what you are proposing. Let's see the following example - an INIT/INIT-ACK exchange through a NAPT. Which one would be the DESTINATION transport address that you would like to see with multiple port numbers? End A NAPT End B {IP-A, IP-B/p1} ## {IP-X, IP-Y/p3} INIT(src:IP-A,IP-B/p1)------>## INIT(src:IP-M,IP-N/p2)------->(p3) (dst: IP-X/p3) (dst:IP-X/p3) (p1)<---INIT_ACK(src:IP-X,IP-Y/p3) ##<------INIT_ACK(src:IP-X,IP-Y/p3) (dst: IP-A/p1) (dst:IP-M/p2) regards, -Qiaobing From rrs@cisco.com Tue, 15 Feb 2005 12:27:01 -0800 (PST) From: Randall Stewart Date: Tue, 15 Feb 2005 12:27:01 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <42125A56.3060500@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Q: Ok, I give up... I will subscribe to behave kicking and screaming to try to avoid one more mailing list :-D Comments below.. Qiaobing Xie wrote: (added Randy to the cc list since he's not seeing email on behave list) Hi, Wolfgang, Please see my comments in-line. Schruefer Wolfgang wrote: Qiaobing, why do you think an extension for multiple destination ports would make SCTP a different protocol? Please consider that the SCTP protocol would remain untouched for all existing scenarios. Only if NAPT is involved such an SCTP extension may be used. Please consider that only the DESTINATION transport addresses should be allowed to contain multiple port numbers. For the LOCAL address handling the design with a unique port remains untouched. Multiple destination ports would affect only the addressing of outgoing packets to an multihomed peer behind a NAPT. Before the packets arrive at the peer NAPT would retranslate the addresses back to an unique port number. This is the reason why SCTP would not need to handle multiple local port numbers. I too, like Q, am a bit confused.. and I have probably missed some of the discussion.. yes.. I know I should go back and read the archive.. but alas .. I have not the cycles.. What Wolfgang could be advocating is something more like: host-a NATP host-z ----IP-a --INIT---> ----IP-b (src-port:1) IP-A:src-P2 IP-B:src-P3 -------> But unless you had yet another NATP at the other side then host-z's SCTP stack would need to be aware of the multiple ports... which would be confusing and more complex.. I guess I still do not fully understand what you are proposing. Let's see the following example - an INIT/INIT-ACK exchange through a NAPT. Which one would be the DESTINATION transport address that you would like to see with multiple port numbers? End A NAPT End B {IP-A, IP-B/p1} ## {IP-X, IP-Y/p3} INIT(src:IP-A,IP-B/p1)------>## INIT(src:IP-M,IP-N/p2)------->(p3) (dst: IP-X/p3) (dst:IP-X/p3) (p1)<---INIT_ACK(src:IP-X,IP-Y/p3) ##<------INIT_ACK(src:IP-X,IP-Y/p3) (dst: IP-A/p1) (dst:IP-M/p2) The above looks to me like what a regular NAPT does.. i.e. End-A gets p1 and yet End B sees p2... this is no problem without changing the protocol... only if multiple addresses are involved is there an issue I think... and this may be what Wolfgang is trying to solve.. Wolfgangs.. clearfications for Q and I would be most welcome . R regards, -Qiaobing -- Randall Stewart ITD 803-345-0369 815-342-5222 From wolfgang.schruefer@siemens.com Wed, 16 Feb 2005 00:43:19 -0800 (PST) From: Schruefer Wolfgang Date: Wed, 16 Feb 2005 00:43:19 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hello, yesterday Melinda gave us the advice to consider the larger context... Therefore I will try first to explain my motivation by an example instead of technical details: ********************************************* Example (I will use Luca's scenario): - A client application on host X needs Interface redundancy, but unfortunately SCTP can not establish a multihomed Association due to NAPT... > > > SCTP (A+)-------------N SCTP > HOST X ( ) A--E+-------------cloud------------+--HOST Z > (B+)------------ P > T - But the application is smart: it creates 2 singled homed associations: a primary association containing Addr A as Source Address and a secondary containing Addr B as Source Address. - If Association A fails, the application continues data transfer using association B. And you see: The application has a multihoming functionality, it uses SCTP and it is behind a NAPT! ********************************************** What I expect: If the application can realize multihoming, SCTP should be able to do it also. Probably better. Do I really expect too much??? Best regards, Wolfgang > -----Ursprngliche Nachricht----- > Von: Randall Stewart [mailto:rrs@xxxxxxxxx] > Gesendet: Dienstag, 15. Februar 2005 21:24 > An: Qiaobing Xie > Cc: Schruefer Wolfgang; Luca Laurenzi; Ietf-behave@xxxxxxxxxxxxxxxxxxx > Betreff: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP > > Q: > > Ok, I give up... I will subscribe to behave kicking and screaming > to try to avoid one more mailing list :-D > > Comments below.. > > Qiaobing Xie wrote: > > (added Randy to the cc list since he's not seeing email on > behave list) > > > > Hi, Wolfgang, > > > > Please see my comments in-line. > > > > Schruefer Wolfgang wrote: > > > >> Qiaobing, > >> > >> why do you think an extension for multiple destination ports would > >> make SCTP a different protocol? > >> > >> Please consider that the SCTP protocol would remain > untouched for all > >> existing scenarios. Only if NAPT is involved such an SCTP > extension > >> may be used. > >> > >> Please consider that only the DESTINATION transport > addresses should > >> be allowed to contain multiple port numbers. For the LOCAL address > >> handling the design with a unique port remains untouched. > >> > >> Multiple destination ports would affect only the addressing of > >> outgoing packets to an multihomed peer behind a NAPT. Before the > >> packets arrive at the peer NAPT would retranslate the > addresses back > >> to an unique port number. This is the reason why SCTP > would not need > >> to handle multiple local port numbers. > > > > I too, like Q, am a bit confused.. and I have probably missed > some of the discussion.. yes.. I know I should go back and > read the archive.. but alas .. I have not the cycles.. > > What Wolfgang could be advocating is something more like: > > host-a NATP host-z > > ----IP-a --INIT---> > ----IP-b > (src-port:1) > > IP-A:src-P2 > IP-B:src-P3 -------> > > But unless you had yet another NATP at the other side then host-z's > SCTP stack would need to be aware of the multiple ports... which > would be confusing and more complex.. > > > > > > > > I guess I still do not fully understand what you are > proposing. Let's > > see the following example - an INIT/INIT-ACK exchange > through a NAPT. > > Which one would be the DESTINATION transport address that > you would like > > to see with multiple port numbers? > > > > End A NAPT End B > > {IP-A, IP-B/p1} ## > {IP-X, IP-Y/p3} > > > > INIT(src:IP-A,IP-B/p1)------>## INIT(src:IP-M,IP-N/p2)------->(p3) > > (dst: IP-X/p3) (dst:IP-X/p3) > > > > (p1)<---INIT_ACK(src:IP-X,IP-Y/p3) > ##<------INIT_ACK(src:IP-X,IP-Y/p3) > > (dst: IP-A/p1) (dst:IP-M/p2) > > > > The above looks to me like what a regular NAPT does.. i.e. End-A gets > p1 and yet End B sees p2... this is no problem without changing > the protocol... only if multiple addresses are involved is > there an issue I think... and this may be what Wolfgang is trying > to solve.. > > Wolfgangs.. clearfications for Q and I would be most welcome . > > R > > > > > > regards, > > -Qiaobing > > > > > > > -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 > From rrs@cisco.com Wed, 16 Feb 2005 04:08:00 -0800 (PST) From: Randall Stewart Date: Wed, 16 Feb 2005 04:08:00 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <421336E2.6010807@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Wolfgang: Comments below... Schruefer Wolfgang wrote: Hello, yesterday Melinda gave us the advice to consider the larger context... Therefore I will try first to explain my motivation by an example instead of technical details: ********************************************* Example (I will use Luca's scenario): - A client application on host X needs Interface redundancy, but unfortunately SCTP can not establish a multihomed Association due to NAPT... SCTP (A+)-------------N SCTP HOST X ( ) A--E+-------------cloud------------+--HOST Z (B+)------------ P T - But the application is smart: it creates 2 singled homed associations: a primary association containing Addr A as Source Address and a secondary containing Addr B as Source Address. - If Association A fails, the application continues data transfer using association B. And you see: The application has a multihoming functionality, it uses SCTP and it is behind a NAPT! Well.. I see your point.. but you would have to have a NAPT that understood SCTP and that would open more than one interface as the "private address" side. FreeBSD at least is not capable of doing this.. Yes, I can setup two NAPT's .. I have done that.. but each had to have an independant network to route out... aka two DSL's, which I used to have :-D Now, the problem here is that of ports... which is why you are asking for SCTP to have multiple ports. And I would argue that if your NAPT's is written to handle two interfaces, it could also assign the same outgoing translation port to both interfaces (if it knew that the SCTP endpoint was multi-homed by looking inside the INIT/INIT-ACK). Of course it would then have to do some method to use both networks. I.e. how would it decide to fail over.. it can't know what the end's are doing.. and of course the multi-homed nature would be hidden from the peer Host-Z which would mean it would not know to HB a seperate address. This gets ugly fast... If the base protocol had seperate ports allowed.. you might be able to do it... but that is a major change to the protocol.. R ********************************************** What I expect: If the application can realize multihoming, SCTP should be able to do it also. Probably better. Do I really expect too much??? Best regards, Wolfgang -----Ursprngliche Nachricht----- Von: Randall Stewart [mailto:rrs@xxxxxxxxx] Gesendet: Dienstag, 15. Februar 2005 21:24 An: Qiaobing Xie Cc: Schruefer Wolfgang; Luca Laurenzi; Ietf-behave@xxxxxxxxxxxxxxxxxxx Betreff: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Q: Ok, I give up... I will subscribe to behave kicking and screaming to try to avoid one more mailing list :-D Comments below.. Qiaobing Xie wrote: (added Randy to the cc list since he's not seeing email on behave list) Hi, Wolfgang, Please see my comments in-line. Schruefer Wolfgang wrote: Qiaobing, why do you think an extension for multiple destination ports would make SCTP a different protocol? Please consider that the SCTP protocol would remain untouched for all existing scenarios. Only if NAPT is involved such an SCTP extension may be used. Please consider that only the DESTINATION transport addresses should be allowed to contain multiple port numbers. For the LOCAL address handling the design with a unique port remains untouched. Multiple destination ports would affect only the addressing of outgoing packets to an multihomed peer behind a NAPT. Before the packets arrive at the peer NAPT would retranslate the addresses back to an unique port number. This is the reason why SCTP would not need to handle multiple local port numbers. I too, like Q, am a bit confused.. and I have probably missed some of the discussion.. yes.. I know I should go back and read the archive.. but alas .. I have not the cycles.. What Wolfgang could be advocating is something more like: host-a NATP host-z ----IP-a --INIT---> ----IP-b (src-port:1) IP-A:src-P2 IP-B:src-P3 -------> But unless you had yet another NATP at the other side then host-z's SCTP stack would need to be aware of the multiple ports... which would be confusing and more complex.. I guess I still do not fully understand what you are proposing. Let's see the following example - an INIT/INIT-ACK exchange through a NAPT. Which one would be the DESTINATION transport address that you would like to see with multiple port numbers? End A NAPT End B {IP-A, IP-B/p1} ## {IP-X, IP-Y/p3} INIT(src:IP-A,IP-B/p1)------>## INIT(src:IP-M,IP-N/p2)------->(p3) (dst: IP-X/p3) (dst:IP-X/p3) (p1)<---INIT_ACK(src:IP-X,IP-Y/p3) ##<------INIT_ACK(src:IP-X,IP-Y/p3) (dst: IP-A/p1) (dst:IP-M/p2) The above looks to me like what a regular NAPT does.. i.e. End-A gets p1 and yet End B sees p2... this is no problem without changing the protocol... only if multiple addresses are involved is there an issue I think... and this may be what Wolfgang is trying to solve.. Wolfgangs.. clearfications for Q and I would be most welcome . R regards, -Qiaobing -- Randall Stewart ITD 803-345-0369 815-342-5222 -- Randall Stewart ITD 803-345-0369 815-342-5222 From spencer@mcsr-labs.org Wed, 16 Feb 2005 05:54:54 -0800 (PST) From: "Spencer Dawkins" Date: Wed, 16 Feb 2005 05:54:54 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <03eb01c5142f$2a9bd000$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain Randall, Thanks for popping in here. My concern is about "multihoming solutions" that would require two different IP interfaces (chosen for diversity) to point traffic to the same NATP box (so it can assign the same outgoing translation port to both interfaces). It seems to me that inserting a single point of failure, regardless of its reliability, into a multihoming solution isn't quite solving the right problem. If I chose two interfaces that home through two different ISPs, traffic to two ISPs would have to traverse the same NATP in order to pull this off (or we could insert a NATP-to-NATP protocol that would keep translation ports synchronized, but...). Thank you for pointing out the "don't heartbeat to both IP addresses" problem. I hadn't thought of that. I agree that things are getting ugly fast. I'm not sure everyone has the same definition of "ugly" in this thread. Spencer Now, the problem here is that of ports... which is why you are asking for SCTP to have multiple ports. And I would argue that if your NAPT's is written to handle two interfaces, it could also assign the same outgoing translation port to both interfaces (if it knew that the SCTP endpoint was multi-homed by looking inside the INIT/INIT-ACK). Of course it would then have to do some method to use both networks. I.e. how would it decide to fail over.. it can't know what the end's are doing.. and of course the multi-homed nature would be hidden from the peer Host-Z which would mean it would not know to HB a seperate address. This gets ugly fast... If the base protocol had seperate ports allowed.. you might be able to do it... but that is a major change to the protocol.. R From mshore@cisco.com Wed, 16 Feb 2005 05:59:43 -0800 (PST) From: Melinda Shore Date: Wed, 16 Feb 2005 05:59:43 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <03eb01c5142f$2a9bd000$0400a8c0@DFNJGL21> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Wednesday, February 16, 2005, at 08:55 AM, Spencer Dawkins wrote: It seems to me that inserting a single point of failure, regardless of its reliability, into a multihoming solution isn't quite solving the right problem. This should probably be engraved somewhere for posterity. Melinda From wolfgang.schruefer@siemens.com Wed, 16 Feb 2005 08:51:36 -0800 (PST) From: Schruefer Wolfgang Date: Wed, 16 Feb 2005 08:51:36 -0800 (PST) Subject: AW: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain Randy, > ... your NAPT's could also assign the same outgoing > translation port to both interfaces > ... this gets ugly fast... I agree! And all discussion about this approach failed because it led to huge problems ... > If the base protocol had seperate ports allowed.. you might > be able to do it... but that is a major change to the > protocol.. But this seems to me is the only way to proceed! We need a discussion about it. What is a blocking point for this approach? I expect: when it is possible to establish two sigle-homed association between two host through NAPT, it should also be possible to establisch two paths between them. Wolfgang > -----Ursprngliche Nachricht----- > Von: Randall Stewart [mailto:rrs@xxxxxxxxx] > Gesendet: Mittwoch, 16. Februar 2005 13:05 > An: Schruefer Wolfgang > Cc: Qiaobing Xie; Luca Laurenzi; Ietf-behave@xxxxxxxxxxxxxxxxxxx > Betreff: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP > > Wolfgang: > > Comments below... > > Schruefer Wolfgang wrote: > > Hello, > > > > yesterday Melinda gave us the advice to consider the larger > context... > > Therefore I will try first to explain my motivation by an > example instead of technical details: > > > > ********************************************* > > Example (I will use Luca's scenario): > > > > - A client application on host X needs Interface > redundancy, but unfortunately SCTP can not establish a > multihomed Association due to NAPT... > > > > > >> > >> SCTP (A+)-------------N > SCTP > >> HOST X ( ) > A--E+-------------cloud------------+--HOST Z > >> (B+)------------ P > >> T > > > > > > - But the application is smart: it creates 2 singled homed > associations: a primary association containing Addr A as > Source Address and a secondary containing Addr B as Source Address. > > - If Association A fails, the application continues data > transfer using association B. > > > > And you see: The application has a multihoming > functionality, it uses SCTP and it is behind a NAPT! > > Well.. I see your point.. but you would have > to have a NAPT that understood SCTP and that > would open more than one interface as the > "private address" side. FreeBSD at least > is not capable of doing this.. > > Yes, I can setup two NAPT's .. I have done > that.. but each had to have an independant > network to route out... aka two DSL's, which > I used to have :-D > > > Now, the problem here is that of ports... which is > why you are asking for SCTP to have multiple ports. > > And I would argue that if your NAPT's is written to > handle two interfaces, it could also assign the same outgoing > translation port to both interfaces (if it knew that > the SCTP endpoint was multi-homed by looking > inside the INIT/INIT-ACK). Of course it would > then have to do some method to use both networks. I.e. > how would it decide to fail over.. it can't know > what the end's are doing.. and of course the > multi-homed nature would be hidden from the > peer Host-Z which would mean it would not > know to HB a seperate address. > > This gets ugly fast... > > If the base protocol had seperate ports allowed.. you might > be able to do it... but that is a major change to the > protocol.. > > R > > > > > > ********************************************** > > > > What I expect: > > > > If the application can realize multihoming, SCTP should be > able to do it also. Probably better. > > Do I really expect too much??? > > > > > > Best regards, > > Wolfgang > > > > > > > > > > > >>-----Ursprngliche Nachricht----- > >>Von: Randall Stewart [mailto:rrs@xxxxxxxxx] > >>Gesendet: Dienstag, 15. Februar 2005 21:24 > >>An: Qiaobing Xie > >>Cc: Schruefer Wolfgang; Luca Laurenzi; > Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>Betreff: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP > >> > >>Q: > >> > >>Ok, I give up... I will subscribe to behave kicking and screaming > >>to try to avoid one more mailing list :-D > >> > >>Comments below.. > >> > >>Qiaobing Xie wrote: > >> > >>>(added Randy to the cc list since he's not seeing email on > >> > >>behave list) > >> > >>>Hi, Wolfgang, > >>> > >>>Please see my comments in-line. > >>> > >>>Schruefer Wolfgang wrote: > >>> > >>> > >>>>Qiaobing, > >>>> > >>>>why do you think an extension for multiple destination > ports would > >>>>make SCTP a different protocol? > >>>> > >>>>Please consider that the SCTP protocol would remain > >> > >>untouched for all > >> > >>>>existing scenarios. Only if NAPT is involved such an SCTP > >> > >>extension > >> > >>>>may be used. > >>>> > >>>>Please consider that only the DESTINATION transport > >> > >>addresses should > >> > >>>>be allowed to contain multiple port numbers. For the > LOCAL address > >>>>handling the design with a unique port remains untouched. > >>>> > >>>>Multiple destination ports would affect only the addressing of > >>>>outgoing packets to an multihomed peer behind a NAPT. Before the > >>>>packets arrive at the peer NAPT would retranslate the > >> > >>addresses back > >> > >>>>to an unique port number. This is the reason why SCTP > >> > >>would not need > >> > >>>>to handle multiple local port numbers. > >>> > >>I too, like Q, am a bit confused.. and I have probably missed > >>some of the discussion.. yes.. I know I should go back and > >>read the archive.. but alas .. I have not the cycles.. > >> > >>What Wolfgang could be advocating is something more like: > >> > >>host-a NATP host-z > >> > >>----IP-a --INIT---> > >>----IP-b > >> (src-port:1) > >> > >> IP-A:src-P2 > >> IP-B:src-P3 -------> > >> > >>But unless you had yet another NATP at the other side then host-z's > >>SCTP stack would need to be aware of the multiple ports... which > >>would be confusing and more complex.. > >> > >> > >> > >> > >> > >>>I guess I still do not fully understand what you are > >> > >>proposing. Let's > >> > >>>see the following example - an INIT/INIT-ACK exchange > >> > >>through a NAPT. > >> > >>>Which one would be the DESTINATION transport address that > >> > >>you would like > >> > >>>to see with multiple port numbers? > >>> > >>> End A NAPT End B > >>>{IP-A, IP-B/p1} ## > >> > >>{IP-X, IP-Y/p3} > >> > >>>INIT(src:IP-A,IP-B/p1)------>## INIT(src:IP-M,IP-N/p2)------->(p3) > >>> (dst: IP-X/p3) (dst:IP-X/p3) > >>> > >>>(p1)<---INIT_ACK(src:IP-X,IP-Y/p3) > >> > >>##<------INIT_ACK(src:IP-X,IP-Y/p3) > >> > >>> (dst: IP-A/p1) (dst:IP-M/p2) > >>> > >> > >>The above looks to me like what a regular NAPT does.. i.e. > End-A gets > >>p1 and yet End B sees p2... this is no problem without changing > >>the protocol... only if multiple addresses are involved is > >>there an issue I think... and this may be what Wolfgang is trying > >>to solve.. > >> > >>Wolfgangs.. clearfications for Q and I would be most welcome . > >> > >>R > >> > >> > >> > >>>regards, > >>>-Qiaobing > >>> > >>> > >> > >> > >>-- > >>Randall Stewart > >>ITD > >>803-345-0369 815-342-5222 > > > > > > > > > -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 > From mshore@cisco.com Wed, 16 Feb 2005 09:07:05 -0800 (PST) From: Melinda Shore Date: Wed, 16 Feb 2005 09:07:05 -0800 (PST) Subject: Re: AW: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <20A2E2FE-803D-11D9-8494-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Wednesday, February 16, 2005, at 11:51 AM, Schruefer Wolfgang wrote: I expect: when it is possible to establish two sigle-homed association between two host through NAPT, it should also be possible to establisch two paths between them The conditions are profoundly different. In the multi-homed SCTP case there's a need for one single endpoint to explicitly signal a list of addresses, which means it must either know those addresses or those addresses must be fixed-up in transit by the NATs. That problem will not be fixed simply by adding support for multiple ports to SCTP. I think it's important to take Spencer's earlier comment to heart - if the intent behind multi-homing SCTP connections is to provide robustness and failure resistance, introducing inherently brittle mechanisms into the network in order to get SCTP to work across NATs is almost certainly working against your own interests. Melinda From Qiaobing.Xie@motorola.com Wed, 16 Feb 2005 12:50:20 -0800 (PST) From: Qiaobing Xie Date: Wed, 16 Feb 2005 12:50:20 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <4213B1CE.10104@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Wolfgang, Schruefer Wolfgang wrote: Hello, yesterday Melinda gave us the advice to consider the larger context... Therefore I will try first to explain my motivation by an example instead of technical details: ********************************************* Example (I will use Luca's scenario): - A client application on host X needs Interface redundancy, but unfortunately SCTP can not establish a multihomed Association due to NAPT... SCTP (A+)-------------N SCTP HOST X ( ) A--E+-------------cloud------------+--HOST Z (B+)------------ P T - But the application is smart: it creates 2 singled homed associations: a primary association containing Addr A as Source Address and a secondary containing Addr B as Source Address. - If Association A fails, the application continues data transfer using association B. I assume you meant that they were 2 singled homed associations with HOST Z, i.e., A<->Z and B<->Z. And you see: The application has a multihoming functionality, it uses SCTP and it is behind a NAPT! ********************************************** What I expect: If the application can realize multihoming, SCTP should be able to do it also. Probably better. Do I really expect too much??? But why this is a question unique to SCTP? Your smart application should be able to do the same with two TCP connections, right? If so, maybe your challenge should be: should any transport be able to do it also. regards, -Qiaobing Best regards, Wolfgang -----Ursprngliche Nachricht----- Von: Randall Stewart [mailto:rrs@xxxxxxxxx] Gesendet: Dienstag, 15. Februar 2005 21:24 An: Qiaobing Xie Cc: Schruefer Wolfgang; Luca Laurenzi; Ietf-behave@xxxxxxxxxxxxxxxxxxx Betreff: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Q: Ok, I give up... I will subscribe to behave kicking and screaming to try to avoid one more mailing list :-D Comments below.. Qiaobing Xie wrote: (added Randy to the cc list since he's not seeing email on behave list) Hi, Wolfgang, Please see my comments in-line. Schruefer Wolfgang wrote: Qiaobing, why do you think an extension for multiple destination ports would make SCTP a different protocol? Please consider that the SCTP protocol would remain untouched for all existing scenarios. Only if NAPT is involved such an SCTP extension may be used. Please consider that only the DESTINATION transport addresses should be allowed to contain multiple port numbers. For the LOCAL address handling the design with a unique port remains untouched. Multiple destination ports would affect only the addressing of outgoing packets to an multihomed peer behind a NAPT. Before the packets arrive at the peer NAPT would retranslate the addresses back to an unique port number. This is the reason why SCTP would not need to handle multiple local port numbers. I too, like Q, am a bit confused.. and I have probably missed some of the discussion.. yes.. I know I should go back and read the archive.. but alas .. I have not the cycles.. What Wolfgang could be advocating is something more like: host-a NATP host-z ----IP-a --INIT---> ----IP-b (src-port:1) IP-A:src-P2 IP-B:src-P3 -------> But unless you had yet another NATP at the other side then host-z's SCTP stack would need to be aware of the multiple ports... which would be confusing and more complex.. I guess I still do not fully understand what you are proposing. Let's see the following example - an INIT/INIT-ACK exchange through a NAPT. Which one would be the DESTINATION transport address that you would like to see with multiple port numbers? End A NAPT End B {IP-A, IP-B/p1} ## {IP-X, IP-Y/p3} INIT(src:IP-A,IP-B/p1)------>## INIT(src:IP-M,IP-N/p2)------->(p3) (dst: IP-X/p3) (dst:IP-X/p3) (p1)<---INIT_ACK(src:IP-X,IP-Y/p3) ##<------INIT_ACK(src:IP-X,IP-Y/p3) (dst: IP-A/p1) (dst:IP-M/p2) The above looks to me like what a regular NAPT does.. i.e. End-A gets p1 and yet End B sees p2... this is no problem without changing the protocol... only if multiple addresses are involved is there an issue I think... and this may be what Wolfgang is trying to solve.. Wolfgangs.. clearfications for Q and I would be most welcome . R regards, -Qiaobing -- Randall Stewart ITD 803-345-0369 815-342-5222 From Qiaobing.Xie@motorola.com Wed, 16 Feb 2005 13:00:10 -0800 (PST) From: Qiaobing Xie Date: Wed, 16 Feb 2005 13:00:10 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <4213B508.8090305@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Spencer, Spencer Dawkins wrote: Randall, Thanks for popping in here. My concern is about "multihoming solutions" that would require two different IP interfaces (chosen for diversity) to point traffic to the same NATP box (so it can assign the same outgoing translation port to both interfaces). It seems to me that inserting a single point of failure, regardless of its reliability, into a multihoming solution isn't quite solving the right problem. You are absolutely right and this is noted in the draft. However, having 90% of the path diversity (due to the presence of one or two single point of failures, i.e., NAPTs) is still far better than an end-to-end single path (i.e., no path diversity), in terms of overall reliability. Of cause, it would be great that NAPT can some day evolve to a point that it will be able retain e2e diversity of a multi-homed SCTP association. regards, -Qiaobing If I chose two interfaces that home through two different ISPs, traffic to two ISPs would have to traverse the same NATP in order to pull this off (or we could insert a NATP-to-NATP protocol that would keep translation ports synchronized, but...). Thank you for pointing out the "don't heartbeat to both IP addresses" problem. I hadn't thought of that. I agree that things are getting ugly fast. I'm not sure everyone has the same definition of "ugly" in this thread. Spencer Now, the problem here is that of ports... which is why you are asking for SCTP to have multiple ports. And I would argue that if your NAPT's is written to handle two interfaces, it could also assign the same outgoing translation port to both interfaces (if it knew that the SCTP endpoint was multi-homed by looking inside the INIT/INIT-ACK). Of course it would then have to do some method to use both networks. I.e. how would it decide to fail over.. it can't know what the end's are doing.. and of course the multi-homed nature would be hidden from the peer Host-Z which would mean it would not know to HB a seperate address. This gets ugly fast... If the base protocol had seperate ports allowed.. you might be able to do it... but that is a major change to the protocol.. R _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Qiaobing.Xie@motorola.com Wed, 16 Feb 2005 13:18:24 -0800 (PST) From: Qiaobing Xie Date: Wed, 16 Feb 2005 13:18:24 -0800 (PST) Subject: Re: AW: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <20A2E2FE-803D-11D9-8494-000A95E35274@cisco.com> Message-ID: <4213B821.4020904@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Melinda .... I think it's important to take Spencer's earlier comment to heart - if the intent behind multi-homing SCTP connections is to provide robustness and failure resistance, introducing inherently brittle mechanisms into the network in order to get SCTP to work across NATs is almost certainly working against your own interests. Yes, having the NAPT be able to retain the e2e path diversity is certainly ideal and would be the complete and perfect solution. But I disagree with your above view, since I believe a partial solution is till way better than no solution. regards, -Qiaobing Melinda _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From rrs@cisco.com Thu, 17 Feb 2005 06:59:20 -0800 (PST) From: Randall Stewart Date: Thu, 17 Feb 2005 06:59:20 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <4214B082.9000702@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Spencer: That is why I wondered about Wolfgang's proposal. You need seperate NAPT's on seperate boxes... to get diversity and no single point of failure.. You won't get that with Wolfgang's picture... And then the only way I can think of is to either a) have a nat-2-nat protocol... talk about way ugly or b) have a way to have SCTP use different ports.. which is not allowed by the spec (and rightly so in my mind). Changing it, especially since 99.9 % of all napt's know nothing about SCTP yet, is like having the tail wag the dog... IMO. You don't design a transport protocol FOR NAT's... So.. not sure of a multi-homing solution for SCTP and NAT. Singly homed will work just fine (as long as napt's will implement it). R Spencer Dawkins wrote: Randall, Thanks for popping in here. My concern is about "multihoming solutions" that would require two different IP interfaces (chosen for diversity) to point traffic to the same NATP box (so it can assign the same outgoing translation port to both interfaces). It seems to me that inserting a single point of failure, regardless of its reliability, into a multihoming solution isn't quite solving the right problem. If I chose two interfaces that home through two different ISPs, traffic to two ISPs would have to traverse the same NATP in order to pull this off (or we could insert a NATP-to-NATP protocol that would keep translation ports synchronized, but...). Thank you for pointing out the "don't heartbeat to both IP addresses" problem. I hadn't thought of that. I agree that things are getting ugly fast. I'm not sure everyone has the same definition of "ugly" in this thread. Spencer Now, the problem here is that of ports... which is why you are asking for SCTP to have multiple ports. And I would argue that if your NAPT's is written to handle two interfaces, it could also assign the same outgoing translation port to both interfaces (if it knew that the SCTP endpoint was multi-homed by looking inside the INIT/INIT-ACK). Of course it would then have to do some method to use both networks. I.e. how would it decide to fail over.. it can't know what the end's are doing.. and of course the multi-homed nature would be hidden from the peer Host-Z which would mean it would not know to HB a seperate address. This gets ugly fast... If the base protocol had seperate ports allowed.. you might be able to do it... but that is a major change to the protocol.. R _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Randall Stewart ITD 803-345-0369 815-342-5222 From rrs@cisco.com Thu, 17 Feb 2005 07:00:05 -0800 (PST) From: Randall Stewart Date: Thu, 17 Feb 2005 07:00:05 -0800 (PST) Subject: Re: AW: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <20A2E2FE-803D-11D9-8494-000A95E35274@cisco.com> Message-ID: <4214B0AF.9040504@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Melinda Shore wrote: On Wednesday, February 16, 2005, at 11:51 AM, Schruefer Wolfgang wrote: I expect: when it is possible to establish two sigle-homed association between two host through NAPT, it should also be possible to establisch two paths between them The conditions are profoundly different. In the multi-homed SCTP case there's a need for one single endpoint to explicitly signal a list of addresses, which means it must either know those addresses or those addresses must be fixed-up in transit by the NATs. That problem will not be fixed simply by adding support for multiple ports to SCTP. I think it's important to take Spencer's earlier comment to heart - if the intent behind multi-homing SCTP connections is to provide robustness and failure resistance, introducing inherently brittle mechanisms into the network in order to get SCTP to work across NATs is almost certainly working against your own interests. agreed. R Melinda _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Randall Stewart ITD 803-345-0369 815-342-5222 From baford@mit.edu Thu, 17 Feb 2005 08:27:56 -0800 (PST) From: Bryan Ford Date: Thu, 17 Feb 2005 08:27:56 -0800 (PST) Subject: [Ietf-behave] New drafts Message-ID: <200502171727.54140.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Hi folks, If you don't mind me interrupting the SCTP debate, there are three new BEHAVE-related drafts available at the ietf's Internet-Drafts archive. Unfortunately the IETF Secratariat may not forward the "official" availability announcement to this list because I forgot to ask them to in my submission. :( The first one is as follows; I'll announce the others in separate messages... "Design Principles and General Behavioral Requirements for Network Address Translators (BEH-GEN)" http://www.ietf.org/internet-drafts/draft-ford-behave-gen-00.txt Abstract: This document discusses design principles and behavioral properties required to make Network Address Translators (NAT) more predictable and compatible with diverse application protocols. First, this document presents a concrete architectural model for NAT devices and defines important terms used in conjunction with NAT design. This architectural model sets the stage for a set of concrete recommendations for NAT implementors and vendors, as being contemplated by the BEHAVE working group. The recommendations made by this document are independent of transport protocol; a set of companion documents provide behavioral recommendations specific to particular transport protocols. The intent of this draft is to fill the current "gap" between the current UDP behavior draft (draft-ietf-behave-nat-udp-00.txt) and the preliminary TCP draft (draft-sivakumar-behave-nat-tcp-req-00.txt), by defining general principles, terminology, and specific NAT behavioral requirements that are transport-independent or at least common to both TCP and UDP. At the moment the initial TCP draft is having to make awkward cross-references to parts of the UDP draft to talk about such common behavioral requirements, making it unclear precisely what parts of the UDP document are also supposed to apply to TCP and what parts are not. And there's currently no place at all for requirements like, "NATs MUST support both TCP and UDP". To fix these problems, I've taken the transport-independent portions of the UDP document, and transplanted them (with considerable editing) into this new "general principles" draft, along with some new content that hasn't appeared yet in either draft. The intent is that the transplanted sections from the original UDP draft can then be removed or trimmed drastically, and both the UDP and TCP documents can simply refer to the common transport-independent document, without the TCP document having to make frequent awkward cross-references to the UDP document. The specific sections of the original UDP draft that I'm proposing to move into the "general" document in this way are: 4.1 Address and Port Mapping 5.1 Filtering of Unsolicited Packets 7. Hairpinning Behavior 10. ICMP Behavior (#10, ICMP Behavior, doesn't yet appear in the General draft because I ran out of time.) If the BEHAVE group accepts the proposed document organization, then at least the General and UDP documents would probably need to be published together first, but the other related documents could still be published later in their own time as outlined in the original working group schedule. Now that we have working drafts for UDP, and TCP, however, it might be worth at least considering the option of trying to push them through together, in order to ensure consistency and coherent organization. But I'm also sympathetic to the reality that "IETF NAT documents are historically hard to publish", and that we shouldn't hold all the documents back unnecessarily if one or two prove particularly controversial. (It's pretty clear that TCP and UDP shouldn't wait for a consensus to develop on SCTP, for example. :)) I'm mainly just proposing that, however and whenever we publish these various documents, we should at least work on them together with a goal of making them mutually consistent and well-organized, and that's what the proposed "Design Principles and General Requirements" draft is about. Comments and reactions appreciated. Thanks, Bryan From baford@mit.edu Thu, 17 Feb 2005 08:36:54 -0800 (PST) From: Bryan Ford Date: Thu, 17 Feb 2005 08:36:54 -0800 (PST) Subject: [Ietf-behave] New draft: Application Design Guidelines Message-ID: <200502171736.52013.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain The second new draft is intended to provide a starting point for the "recommendations for application designers" document that has already been brought up several times on this list, and which I believe represents the Dec 05 milestone in the original BEHAVE WG timeline. As such, I'd like to ask the group to review it and consider adopting it as an official WG document for thus purpose. This document is not too closely tied to the NAT behavior documents, so it could move toward eventual publication on its own schedule. "Application Design Guidelines for Traversal of Network Address Translators" http://www.ietf.org/internet-drafts/draft-ford-behave-app-00.txt Abstract: This document defines best current practices by which application designers can create applications that communicate reliably and efficiently in the presence of network address translators (NAT), particularly when the application has a need for "peer-to-peer"-style (P2P) communication patterns in addition to traditional client/server-style communication. There is no single NAT traversal algorithm that will make a P2P application reliably work over all deployed NATs. Following the guidelines described in this document, however, allows a P2P application to work reliably over a majority of existing NATs, as well as all future NATs that conform to the requirements specified in companion documents. The NAT traversal techniques described here do not require the use of special proxy or relay protocols, do not require specific knowledge about the network topology or the number and type of NATs in the path, and do not require any low-level modifications to IP or transport-layer protocols that might require special privileges on the end hosts. Thanks, Bryan From baford@mit.edu Thu, 17 Feb 2005 08:47:36 -0800 (PST) From: Bryan Ford Date: Thu, 17 Feb 2005 08:47:36 -0800 (PST) Subject: [Ietf-behave] New draft: Topology Complications Message-ID: <200502171747.34593.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Finally, the following slightly revised and expanded version of the earlier "Topology complications" document I announced on the list, is now in the official Internet-Drafts repository. "Topology complications from Network Address Translator deployments" http://www.ietf.org/internet-drafts/draft-ford-behave-top-00.txt This document identifies and provides recommendations for dealing with issues that have arisen recently from the ubiquitous deployment of network address translators (NAT), and the unconventional network topologies that are often constructed with them. First, the simplicity of administering networks through the combination of NAT and DHCP is increasingly leading to the deployment of multi-level hierarchies of inter-connected private networks involving overlapping private IP address spaces. The creation of these multi-level hierarchies is often unintentional, since each level of NAT is typically deployed by a separate administrative entity such as an ISP, a corporation, or a home user. Second, the popularity of corporate virtual private networks (VPN) in conjunction with NAT leads to problems in which the private IP address space of the network through which a remote client is attached may unintentionally conflict with the private IP address space of the corporate network into which the remote client is tunneled. This document specifies best current practice recommendations for addressing the issues identified. Since I've already received a number of positive comments on the original draft privately by E-mail, I'd like to hear public reactions to the idea of adopting this draft as a WG document, to be published sometime down the road relatively independently of the other documents. The main complication is that there is currently no corresponding WG milestone or work item for this document, so one would have to be added. Thanks! Bryan From audet@nortel.com Thu, 17 Feb 2005 11:37:15 -0800 (PST) From: "Francois Audet" Date: Thu, 17 Feb 2005 11:37:15 -0800 (PST) Subject: RE: [Ietf-behave] New draft: Application Design Guidelines Message-ID: <1ECE0EB50388174790F9694F77522CCF018BC2F9@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New draft: Application Design Guidelines Good job. This is great. Some minor comments: - Section 1.2: More importantly than "so far none of these protocols have become widely accepted", it should be stated that it may not be feasible or desireable in many architectures to have the application controlling the NAT. - It's a little unclear to me what REQ-6 is trying to say. - Need a value for XX in REQ-7. Something smaller than half of 2 minutes (to match nat-behave). My guess is 30s. We could also talk about detecting the timeout. I think that there were text about that in either STUN or ICE, I forget. In any case, should be marked as "opened issue" for now. Also, we probably need to add some material on RTP/RTCP usage. For example, we need to discuss the fact that if RTP/RTCP address/port pairs do not respect the parity and contiguity rule, the application MUST list them separately (and not derive them algorithmically). Also, that if they are advertized seperately, media must be sent to those addresses, and rules on substracting one (as per RFC 3550 do not apply). Maybe list RFC 3605 as as the mechanism used by SDP to list them separately. I agree with Dan on the symmetric RTP draft being folded in. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Bryan Ford > Sent: Thursday, February 17, 2005 08:37 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] New draft: Application Design Guidelines > > > The second new draft is intended to provide a starting point for the > "recommendations for application designers" document that has > already been > brought up several times on this list, and which I believe > represents the Dec > 05 milestone in the original BEHAVE WG timeline. As such, > I'd like to ask > the group to review it and consider adopting it as an > official WG document > for thus purpose. This document is not too closely tied to > the NAT behavior > documents, so it could move toward eventual publication on > its own schedule. > > > "Application Design Guidelines for Traversal of Network > Address Translators" > http://www.ietf.org/internet-drafts/draft-ford-behave-app-00.txt > > Abstract: > This document defines best current practices by which application > designers can create applications that communicate reliably > and efficiently > in the presence of network address translators (NAT), > particularly when the > application has a need for "peer-to-peer"-style (P2P) > communication patterns > in addition to traditional client/server-style communication. > There is no > single NAT traversal algorithm that will make a P2P > application reliably work > over all deployed NATs. Following the guidelines described in > this document, > however, allows a P2P application to work reliably over a majority of > existing NATs, as well as all future NATs that conform to the > requirements > specified in companion documents. The NAT traversal > techniques described here > do not require the use of special proxy or relay protocols, > do not require > specific knowledge about the network topology or the number > and type of NATs > in the path, and do not require any low-level modifications to IP or > transport-layer protocols that might require special > privileges on the end > hosts. > > Thanks, > Bryan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From wolfgang.schruefer@siemens.com Thu, 17 Feb 2005 13:25:12 -0800 (PST) From: Schruefer Wolfgang Date: Thu, 17 Feb 2005 13:25:12 -0800 (PST) Subject: RE: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain Qiaobing, Qiaobing Xie wrote: > > Schruefer Wolfgang wrote: > > > Hello, > > > > yesterday Melinda gave us the advice to consider the larger context... > > Therefore I will try first to explain my motivation by an example instead > > of technical details: > > > > ********************************************* > > Example (I will use Luca's scenario): > > > > - A client application on host X needs Interface > > redundancy, but unfortunately SCTP can not establish a multihomed > > Association due to NAPT... > > > > > >> > >> SCTP (A+)-------------N SCTP > >> HOST X ( ) A--E+-------------cloud------------+--HOST Z > >> (B+)------------ P > >> T > > > > > > - But the application is smart: it creates 2 singled homed associations: a > > primary association containing Addr A as > > Source Address and a secondary containing Addr B as Source Address. > > - If Association A fails, the application continues data > > transfer using association B. > > I assume you meant that they were 2 singled homed > associations with HOST Z, i.e., A<->Z and > B<->Z. Yes, exactly. I wanted just to make it simple. Please see the NAPT as a cloud with random Address and Port translations, not as a single box. > > > > And you see: The application has a multihoming > functionality, it uses SCTP and it is behind a NAPT! > > > > ********************************************** > > > > What I expect: > > > > If the application can realize multihoming, SCTP should be > able to do it also. Probably better. > > Do I really expect too much??? > > But why this is a question unique to SCTP? Your smart > application should be able to do the > same with two TCP connections, right? If so, maybe your > challenge should be: should any > transport be able to do it also. This question is unique to SCTP, because it is the unique protocol that claims the multihoming feature. Let me cite the introduction of the SCTP RFC: "SCTP ... offers the following services to its users: --... -- network-level fault tolerance through supporting of multi- homing at either or both ends of an association." Sure, as you agree that an application might implement its own multihoming if SCTP fails, it would not need SCTP. Then a smart application might use TCP or even UDP... But the transport protocols should provide best service to applications to make things easier and with as less restrictions as possible. That is why I think the multihoming and port numbering restrictions should be a topic for future SCTP improvement. Best regards, Wolfgang > > regards, > -Qiaobing > From rrs@cisco.com Thu, 17 Feb 2005 13:44:29 -0800 (PST) From: Randall Stewart Date: Thu, 17 Feb 2005 13:44:29 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <42150FAA.8010801@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Comments inline.. Schruefer Wolfgang wrote: Qiaobing, Qiaobing Xie wrote: Schruefer Wolfgang wrote: Hello, yesterday Melinda gave us the advice to consider the larger context... Therefore I will try first to explain my motivation by an example instead of technical details: ********************************************* Example (I will use Luca's scenario): - A client application on host X needs Interface redundancy, but unfortunately SCTP can not establish a multihomed Association due to NAPT... SCTP (A+)-------------N SCTP HOST X ( ) A--E+-------------cloud------------+--HOST Z (B+)------------ P T - But the application is smart: it creates 2 singled homed associations: a primary association containing Addr A as Source Address and a secondary containing Addr B as Source Address. - If Association A fails, the application continues data transfer using association B. I assume you meant that they were 2 singled homed associations with HOST Z, i.e., A<->Z and B<->Z. Yes, exactly. I wanted just to make it simple. Please see the NAPT as a cloud with random Address and Port translations, not as a single box. And you see: The application has a multihoming functionality, it uses SCTP and it is behind a NAPT! ********************************************** What I expect: If the application can realize multihoming, SCTP should be able to do it also. Probably better. Do I really expect too much??? But why this is a question unique to SCTP? Your smart application should be able to do the same with two TCP connections, right? If so, maybe your challenge should be: should any transport be able to do it also. This question is unique to SCTP, because it is the unique protocol that claims the multihoming feature. Let me cite the introduction of the SCTP RFC: "SCTP ... offers the following services to its users: --... -- network-level fault tolerance through supporting of multi- homing at either or both ends of an association." Sure, as you agree that an application might implement its own multihoming if SCTP fails, it would not need SCTP. Then a smart application might use TCP or even UDP... But the transport protocols should provide best service to applications to make things easier and with as less restrictions as possible. That is why I think the multihoming and port numbering restrictions should be a topic for future SCTP improvement. So you want to change a fundamental design concept to accomadate a hack called NAT. And on top of that, I know of NO NAT's that yet implement SCTP.. yes I have worked on a BSD version of one but its not released or even fully tested yet.... So we have roughly 25-30 different implementations of SCTP many being used in production environments.. and you want all of them to go through major changes so you can make implementing SCTP over NAT's more easy.. And yes it is major changes since you are talking about the fundamental method that associations are found via.. And it does not help solve the single point of failure issue... either.. nor does it help with HB'ing and all the other things. In fact it solves very little of the true M-Homing NAT problem.. which IMO is a need for a Nat-2-Nat communication protocol to allow two NATs to assign the same port numbers and communicate state to each other. Especially since very few nats are configured per your drawing... IMO R Best regards, Wolfgang regards, -Qiaobing -- Randall Stewart ITD 803-345-0369 815-342-5222 From wolfgang.schruefer@siemens.com Thu, 17 Feb 2005 13:48:03 -0800 (PST) From: Schruefer Wolfgang Date: Thu, 17 Feb 2005 13:48:03 -0800 (PST) Subject: RE: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain Randy, Randall Stewart wrote: > > Spencer: > > That is why I wondered about Wolfgang's proposal. > > You need seperate NAPT's on seperate boxes... to > get diversity and no single point of failure.. > > You won't get that with Wolfgang's picture... Sorry, the picture was misleading, I just wanted to make it as easy a possible ... Please see the NAPT as a cloud with random Address and Port translations, not as a single box. > > And then the only way I can think of is to either > a) have a nat-2-nat protocol... talk about way ugly > > or > > b) have a way to have SCTP use different ports.. which > is not allowed by the spec (and rightly so in my mind). Changing > it, especially since 99.9 % of all napt's know nothing about > SCTP yet, is like having the tail wag the dog... IMO. You don't > design a transport protocol FOR NAT's... By this argumentation You'll have a dog biting its tail ... NATs would not implement SCTP because SCTP does not support NAT ... SCTP would not support NAT because NATs do not support SCTP ... > > So.. not sure of a multi-homing solution for SCTP and NAT. Singly > homed will work just fine (as long as napt's will implement it). > Please let me summarize your words: We have 3 Options: a) nat-2-nat protocol: (... ugly ...) b) bring SCTP to use different ports (... not needed...) c) forget NAT usage for SCTP ... If everybody shares your opinion I think we can close the discussion. I personally do not agree, I would continue with option b) ... Best regards, Wolfgang > R > > Spencer Dawkins wrote: > > Randall, > > > > Thanks for popping in here. > > > > My concern is about "multihoming solutions" that would require two > > different IP interfaces (chosen for diversity) to point > traffic to the > > same NATP box (so it can assign the same outgoing > translation port to > > both interfaces). > > > > It seems to me that inserting a single point of failure, > regardless of > > its reliability, into a multihoming solution isn't quite > solving the > > right problem. > > > > If I chose two interfaces that home through two different > ISPs, traffic > > to two ISPs would have to traverse the same NATP in order > to pull this > > off (or we could insert a NATP-to-NATP protocol that would keep > > translation ports synchronized, but...). > > > > Thank you for pointing out the "don't heartbeat to both IP > addresses" > > problem. I hadn't thought of that. > > > > I agree that things are getting ugly fast. I'm not sure > everyone has the > > same definition of "ugly" in this thread. > > > > Spencer > > > >> > >> Now, the problem here is that of ports... which is > >> why you are asking for SCTP to have multiple ports. > >> > >> And I would argue that if your NAPT's is written to > >> handle two interfaces, it could also assign the same outgoing > >> translation port to both interfaces (if it knew that > >> the SCTP endpoint was multi-homed by looking > >> inside the INIT/INIT-ACK). Of course it would > >> then have to do some method to use both networks. I.e. > >> how would it decide to fail over.. it can't know > >> what the end's are doing.. and of course the > >> multi-homed nature would be hidden from the > >> peer Host-Z which would mean it would not > >> know to HB a seperate address. > >> > >> This gets ugly fast... > >> > >> If the base protocol had seperate ports allowed.. you might > >> be able to do it... but that is a major change to the > >> protocol.. > >> > >> R > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From mshore@cisco.com Thu, 17 Feb 2005 14:03:00 -0800 (PST) From: Melinda Shore Date: Thu, 17 Feb 2005 14:03:00 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <42150FAA.8010801@cisco.com> Message-ID: <99096946-812F-11D9-8494-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Thursday, February 17, 2005, at 04:42 PM, Randall Stewart wrote: In fact it solves very little of the true M-Homing NAT problem.. which IMO is a need for a Nat-2-Nat communication protocol to allow two NATs to assign the same port numbers and communicate state to each other. I think this would be extremely difficult to do with any reliability or robustness and I also think that we need to step back a bit. It's not that we've wandered into the weeds, it's that we're starting out in the weeds. What you're proposing here is that a host not only needs to know the address of a NAT that its packets are going to traverse, the NAT is going to need to know the address of another NAT and choose the correct one based on addressing information. Basically it's going to need to know how to do network-layer routing. Not only that, because packets will not have started flowing from the other host(s) comprising the endpoint, the nat-nat protocol you're proposing would also have to be a request protocol - it's going to have to ask the other NAT(s) to install a mapping and return the results (we already have that - it's called midcom). Now think security, and what would have to be done to authenticate both the request and response (and in the case of NAT, an authenticated response is as important, if not moreso, than an authenticated request). Frankly, I think that the topology problem in doing this nat-nat thing is basically intractable in IP networks as they work today. My preference, because it's architecturally more harmonious (oommmmm), would be to have the endpoint sending the INIT or ACK do the requesting/discovery. A more compelling reason, perhaps, than the question of architectural goodness would be that if you're using AH you're not going to be able to allow the NATs to scribble in the headers. So in addition to breaking basic IP networking principles you'd also be causing a more tangible problem by breaking security. Hence my preference for the endpoint-initiated request, although I still think it's a mistake. Melinda From mshore@cisco.com Thu, 17 Feb 2005 14:04:29 -0800 (PST) From: Melinda Shore Date: Thu, 17 Feb 2005 14:04:29 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Thursday, February 17, 2005, at 04:47 PM, Schruefer Wolfgang wrote: We have 3 Options: a) nat-2-nat protocol: (... ugly ...) b) bring SCTP to use different ports (... not needed...) c) forget NAT usage for SCTP ... a and b solve two completely different problems. If SCTP is to traverse NATs, both of those problems would need to be solved. I have a strong preference for c, at least in the multihomed case. Melinda From Qiaobing.Xie@motorola.com Thu, 17 Feb 2005 14:18:39 -0800 (PST) From: Qiaobing Xie Date: Thu, 17 Feb 2005 14:18:39 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <421515AA.8060605@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Wolfgang, ... This question is unique to SCTP, because it is the unique protocol that claims the multihoming feature. Let me cite the introduction of the SCTP RFC: "SCTP ... offers the following services to its users: --... -- network-level fault tolerance through supporting of multi- homing at either or both ends of an association." Sure, as you agree that an application might implement its own multihoming if SCTP fails, it would not need SCTP. Then a smart application might use TCP or even UDP... But the transport protocols should provide best service to applications to make things easier and with as less restrictions as possible. That is why I think the multihoming and port numbering restrictions should be a topic for future SCTP improvement. So, it is a unique challenge to SCTP simply because SCTP is the one that has made such a statement/claim of supporting multi-homed endpoints while TCP does not? To be specific, which part(s) of the above quoted text from SCTP is invalidated or be made questionable by some one throwing a NAPT or two into the path? regards, -Qiaobing Best regards, Wolfgang regards, -Qiaobing From rrs@cisco.com Thu, 17 Feb 2005 14:21:20 -0800 (PST) From: Randall Stewart Date: Thu, 17 Feb 2005 14:21:20 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <42151846.2010201@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Schruefer Wolfgang wrote: Randy, Randall Stewart wrote: Spencer: That is why I wondered about Wolfgang's proposal. You need seperate NAPT's on seperate boxes... to get diversity and no single point of failure.. You won't get that with Wolfgang's picture... Sorry, the picture was misleading, I just wanted to make it as easy a possible ... Please see the NAPT as a cloud with random Address and Port translations, not as a single box. If you have two random NAPT's scattered amongst the cloud somewhere.. .then how would you ever coordinate the heartbeating? If you have two seperate IP addresses on the NAT's then you have a problem with only one side will get the INIT (or INIT-ACK) to populate the state.. and, since SCTP only knows about its internal private addresses thats all it can list in its INIT... And right now we specifically tests at inter-ops that SCTP endpoints DON'T do this so they can get through NAT's singly homed. So... you would then need NAT'a KNOWING that NAT'b was at a different address... and knowing its address and then somehow talking to it to get state set in.. once you have the two NATs talking I think it should be no problem to coordinate what ports are handed out.. and then.. tada SCTP works as is through a NAT.. we just need to get the above fixed in SCTP implementations.. i.e. go ahead and list your private addresses... And then the only way I can think of is to either a) have a nat-2-nat protocol... talk about way ugly or b) have a way to have SCTP use different ports.. which is not allowed by the spec (and rightly so in my mind). Changing it, especially since 99.9 % of all napt's know nothing about SCTP yet, is like having the tail wag the dog... IMO. You don't design a transport protocol FOR NAT's... By this argumentation You'll have a dog biting its tail ... NATs would not implement SCTP because SCTP does not support NAT ... SCTP would not support NAT because NATs do not support SCTP ... A Nat can support SCTP the same way it supports TCP.. aka singly homed. There is no problem with this at all. So.. not sure of a multi-homing solution for SCTP and NAT. Singly homed will work just fine (as long as napt's will implement it). Please let me summarize your words: We have 3 Options: a) nat-2-nat protocol: (... ugly ...) b) bring SCTP to use different ports (... not needed...) c) forget NAT usage for SCTP ... No.. Lets first GET NAT's working with singly homed SCTP. Thats the FIRST step.. there are problems to address in that (I know from experience) world... Then, the next step is to try to get M-Homed working in some way.. and that MAY take an ugly NAT-2-NAT protocol. We don't go re-design the base spec to fit NAT's.. What we do is get NAT's working for the general case (singly homed) then we can discuss the more complex area .. which by the way .. will have less demand. R If everybody shares your opinion I think we can close the discussion. I personally do not agree, I would continue with option b) ... Best regards, Wolfgang R Spencer Dawkins wrote: Randall, Thanks for popping in here. My concern is about "multihoming solutions" that would require two different IP interfaces (chosen for diversity) to point traffic to the same NATP box (so it can assign the same outgoing translation port to both interfaces). It seems to me that inserting a single point of failure, regardless of its reliability, into a multihoming solution isn't quite solving the right problem. If I chose two interfaces that home through two different ISPs, traffic to two ISPs would have to traverse the same NATP in order to pull this off (or we could insert a NATP-to-NATP protocol that would keep translation ports synchronized, but...). Thank you for pointing out the "don't heartbeat to both IP addresses" problem. I hadn't thought of that. I agree that things are getting ugly fast. I'm not sure everyone has the same definition of "ugly" in this thread. Spencer Now, the problem here is that of ports... which is why you are asking for SCTP to have multiple ports. And I would argue that if your NAPT's is written to handle two interfaces, it could also assign the same outgoing translation port to both interfaces (if it knew that the SCTP endpoint was multi-homed by looking inside the INIT/INIT-ACK). Of course it would then have to do some method to use both networks. I.e. how would it decide to fail over.. it can't know what the end's are doing.. and of course the multi-homed nature would be hidden from the peer Host-Z which would mean it would not know to HB a seperate address. This gets ugly fast... If the base protocol had seperate ports allowed.. you might be able to do it... but that is a major change to the protocol.. R _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Randall Stewart ITD 803-345-0369 815-342-5222 _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Randall Stewart ITD 803-345-0369 815-342-5222 From Qiaobing.Xie@motorola.com Thu, 17 Feb 2005 14:23:57 -0800 (PST) From: Qiaobing Xie Date: Thu, 17 Feb 2005 14:23:57 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <421518FC.2090209@motorola.com> MIME-Version: 1.0 Content-Type: text/plain ... c) forget NAT usage for SCTP ... a and b solve two completely different problems. If SCTP is to traverse NATs, both of those problems would need to be solved. I have a strong preference for c, at least in the multihomed case. What do you mean by "forget NAT usage for SCTP"? I personally have known commercially deployed networks running multi-homed SCTP nodes across NATs. regards, -Qiaobing Melinda _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From wolfgang.schruefer@siemens.com Thu, 17 Feb 2005 14:24:58 -0800 (PST) From: Schruefer Wolfgang Date: Thu, 17 Feb 2005 14:24:58 -0800 (PST) Subject: RE: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain Comments below ... Randall Stewart wrote: > Comments inline.. > > Schruefer Wolfgang wrote: > > Qiaobing, > > > > Qiaobing Xie wrote: > > > >> Schruefer Wolfgang wrote: > >> > >> > >>> Hello, > >>> > >>> yesterday Melinda gave us the advice to consider the larger > >>> context... Therefore I will try first to explain my motivation by > >>> an example instead of technical details: > >>> > >>> ********************************************* Example (I will use > >>> Luca's scenario): > >>> > >>> - A client application on host X needs Interface redundancy, but > >>> unfortunately SCTP can not establish a multihomed Association due > >>> to NAPT... > >>> > >>> > >>> > >>>> SCTP (A+)-------------N > >>>> SCTP HOST X ( ) > >>>> A--E+-------------cloud------------+--HOST Z (B+)------------ P > >>>> T > >>> > >>> > >>> - But the application is smart: it creates 2 singled homed > >>> associations: a primary association containing Addr A as Source > >>> Address and a secondary containing Addr B as Source Address. - If > >>> Association A fails, the application continues data transfer > >>> using association B. > >> > >> I assume you meant that they were 2 singled homed associations with > >> HOST Z, i.e., A<->Z and B<->Z. > > > > > > Yes, exactly. I wanted just to make it simple. Please see > the NAPT as > > a cloud with random Address and Port translations, not as a single > > box. > > > > > > > > > >>> And you see: The application has a multihoming > >> > >> functionality, it uses SCTP and it is behind a NAPT! > >> > >>> ********************************************** > >>> > >>> What I expect: > >>> > >>> If the application can realize multihoming, SCTP should be > >> > >> able to do it also. Probably better. > >> > >>> Do I really expect too much??? > >> > >> But why this is a question unique to SCTP? Your smart application > >> should be able to do the same with two TCP connections, right? If > >> so, maybe your challenge should be: should any transport be able to > >> do it also. > > > > > > > > This question is unique to SCTP, because it is the unique protocol > > that claims the multihoming feature. Let me cite the introduction of > > the SCTP RFC: "SCTP ... offers the following services to its users: > > --... -- network-level fault tolerance through supporting of multi- > > homing at either or both ends of an association." > > > > > > Sure, as you agree that an application might implement its own > > multihoming if SCTP fails, it would not need SCTP. Then a smart > > application might use TCP or even UDP... > > > > But the transport protocols should provide best service to > > applications to make things easier and with as less restrictions as > > possible. That is why I think the multihoming and port numbering > > restrictions should be a topic for future SCTP improvement. > > > > So you want to change a fundamental design concept to accomadate > a hack called NAT. ... not fundamental ... just an extension > > And on top of that, I know of NO NAT's that yet implement SCTP.. ... actually NATs only need to learn how to calculate SCTP checksum ... this is not so complicated ... IMO > yes > I have worked on a BSD version of one but its not released or even > fully tested yet.... So we have roughly 25-30 different > implementations > of SCTP many being used in production environments.. and you want all > of them to go through major changes so you can make implementing SCTP > over NAT's more easy.. ... same procedure as implementing ADDIP, some may do, some not ... > And yes it is major changes since you are > talking about the fundamental method that associations are > found via.. > > And it does not help solve the single point of failure > issue... either.. > nor does it help with HB'ing and all the other things. > > In fact it solves very little of the true M-Homing NAT problem.. which > IMO is a need for a Nat-2-Nat communication protocol to allow two NATs > to assign the same port numbers and communicate state to each other. > > Especially since very few nats are configured per your drawing... IMO Here I will bring again my example about application multihoming. Now with a better drawing, hopefully. None of your problems appeare ... ********************************************* Example: - A client application on host X needs Interface redundancy, but unfortunately SCTP can not establish a multihomed Association due to NAPT... - I assume this NAPT box is able to handle SCTP like TCP ... SCTP (A1, Port P)----- NAPT(A2,P1)----cloud SCTP (here single HOST cloud------------+--HOST homed for X (B1, Port P)----- NAPT(B2,P2)----cloud Z easier drawing....) - The application is smart: it creates 2 singled homed associations: a primary association containing Addr A as Source Address and a secondary containing Addr B as Source Address. - If Association A fails, the application continues data transfer using association B. And you see: The application has a multihoming functionality, it uses SCTP and it is behind a NAPT! ********************************************** My vision: If the application can realize multihoming, SCTP should be able to do it also. Probably better. My question: Why is impossible and a fundamental change to implement this application logic within SCTP??? Best regards, Wolfgang > > R > > > > > Best regards, Wolfgang > > > > > > > >> regards, -Qiaobing > >> > > > > > > > -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 > From rrs@cisco.com Thu, 17 Feb 2005 14:27:15 -0800 (PST) From: Randall Stewart Date: Thu, 17 Feb 2005 14:27:15 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <99096946-812F-11D9-8494-000A95E35274@cisco.com> Message-ID: <421519B1.4030207@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Melinda: The last thing I would want to do is advocate such a protocol. Its the only way, off hand, I can see of doing multi-homing with NATs.. there may be other ways .. BUT I would NOT support changing SCTP to make it work. Now what we SHOULD be doing in NAT land is figuring out how to make sure SCTP works through NAT's and getting THAT working first... Lets concentrate on a singly homed SCTP endpoint working through a NAT the same way TCP does today. Get that done first and we have accomplished something.. AFTER that is done.. we can head off into the weeds and look and see if we can find a Bass willing to byte our hook.. as long as it don't byte our heads off :-D R Melinda Shore wrote: On Thursday, February 17, 2005, at 04:42 PM, Randall Stewart wrote: In fact it solves very little of the true M-Homing NAT problem.. which IMO is a need for a Nat-2-Nat communication protocol to allow two NATs to assign the same port numbers and communicate state to each other. I think this would be extremely difficult to do with any reliability or robustness and I also think that we need to step back a bit. It's not that we've wandered into the weeds, it's that we're starting out in the weeds. What you're proposing here is that a host not only needs to know the address of a NAT that its packets are going to traverse, the NAT is going to need to know the address of another NAT and choose the correct one based on addressing information. Basically it's going to need to know how to do network-layer routing. Not only that, because packets will not have started flowing from the other host(s) comprising the endpoint, the nat-nat protocol you're proposing would also have to be a request protocol - it's going to have to ask the other NAT(s) to install a mapping and return the results (we already have that - it's called midcom). Now think security, and what would have to be done to authenticate both the request and response (and in the case of NAT, an authenticated response is as important, if not moreso, than an authenticated request). Frankly, I think that the topology problem in doing this nat-nat thing is basically intractable in IP networks as they work today. My preference, because it's architecturally more harmonious (oommmmm), would be to have the endpoint sending the INIT or ACK do the requesting/discovery. A more compelling reason, perhaps, than the question of architectural goodness would be that if you're using AH you're not going to be able to allow the NATs to scribble in the headers. So in addition to breaking basic IP networking principles you'd also be causing a more tangible problem by breaking security. Hence my preference for the endpoint-initiated request, although I still think it's a mistake. Melinda -- Randall Stewart ITD 803-345-0369 815-342-5222 From rrs@cisco.com Thu, 17 Feb 2005 14:28:13 -0800 (PST) From: Randall Stewart Date: Thu, 17 Feb 2005 14:28:13 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <421519EC.2050601@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Melinda Shore wrote: On Thursday, February 17, 2005, at 04:47 PM, Schruefer Wolfgang wrote: We have 3 Options: a) nat-2-nat protocol: (... ugly ...) b) bring SCTP to use different ports (... not needed...) c) forget NAT usage for SCTP ... a and b solve two completely different problems. If SCTP is to traverse NATs, both of those problems would need to be solved. I have a strong preference for c, at least in the multihomed case. I think we agree then.. lets get singly homed SCTP NAT's working And then head out south into the hinter land :-D R Melinda _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Randall Stewart ITD 803-345-0369 815-342-5222 From rrs@cisco.com Thu, 17 Feb 2005 14:29:17 -0800 (PST) From: Randall Stewart Date: Thu, 17 Feb 2005 14:29:17 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <42151A2D.6050009@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Qiaobing Xie wrote: ... c) forget NAT usage for SCTP ... a and b solve two completely different problems. If SCTP is to traverse NATs, both of those problems would need to be solved. I have a strong preference for c, at least in the multihomed case. What do you mean by "forget NAT usage for SCTP"? I personally have known commercially deployed networks running multi-homed SCTP nodes across NATs. Whoses NAT are they using? Tell me in private if you can't tell me in public.. I am curious and this could help me to know that.. R regards, -Qiaobing Melinda _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Randall Stewart ITD 803-345-0369 815-342-5222 From rrs@cisco.com Thu, 17 Feb 2005 14:39:04 -0800 (PST) From: Randall Stewart Date: Thu, 17 Feb 2005 14:39:04 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <42151C78.4030409@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Schruefer Wolfgang wrote: So you want to change a fundamental design concept to accomadate a hack called NAT. ... not fundamental ... just an extension The way implementations find associations with ports and addresses is a fundamental design issue that every SCTP implementation that i have seen must deal with... Changes in ports and addresses mean fundamental changes to this.. And on top of that, I know of NO NAT's that yet implement SCTP.. ... actually NATs only need to learn how to calculate SCTP checksum ... this is not so complicated ... IMO And ports and state .. there are issues here.. you just have to dig a bit deeper into the problem.. like try to make it work correctly :0- yes I have worked on a BSD version of one but its not released or even fully tested yet.... So we have roughly 25-30 different implementations of SCTP many being used in production environments.. and you want all of them to go through major changes so you can make implementing SCTP over NAT's more easy.. ... same procedure as implementing ADDIP, some may do, some not ... No you can't have optionial extra ports.. one side must always be aware of it.. which means all sides must be aware of it since neither will know when a NAT does something. And yes it is major changes since you are talking about the fundamental method that associations are found via.. And it does not help solve the single point of failure issue... either.. nor does it help with HB'ing and all the other things. In fact it solves very little of the true M-Homing NAT problem.. which IMO is a need for a Nat-2-Nat communication protocol to allow two NATs to assign the same port numbers and communicate state to each other. Especially since very few nats are configured per your drawing... IMO Here I will bring again my example about application multihoming. Now with a better drawing, hopefully. None of your problems appeare ... ********************************************* Example: - A client application on host X needs Interface redundancy, but unfortunately SCTP can not establish a multihomed Association due to NAPT... - I assume this NAPT box is able to handle SCTP like TCP ... SCTP (A1, Port P)----- NAPT(A2,P1)----cloud SCTP (here single HOST cloud------------+--HOST homed for X (B1, Port P)----- NAPT(B2,P2)----cloud Z easier drawing....) - The application is smart: it creates 2 singled homed associations: a primary association containing Addr A as Source Address and a secondary containing Addr B as Source Address. - If Association A fails, the application continues data transfer using association B. And you see: The application has a multihoming functionality, it uses SCTP and it is behind a NAPT! ********************************************** My vision: If the application can realize multihoming, SCTP should be able to do it also. Probably better. My question: Why is impossible and a fundamental change to implement this application logic within SCTP??? Because, in your drawing, you get to send two different INIT's one to B-side and one to A-side. this allows propagation of independant state in two seperate NAT's. This also allows the SCTP stack at Z to deal with them as just that two assocaiations.. indexed by port etc. If you somehow magically were allowed two different ports on the same association then the ONLY way it would work is if Host-Z was capable of handling this strange behaviour. It would have to have all of the tracking information AND Host-A also needs to do soemthing as well to propagate state into the NAT it did NOT use to setup the association... and thus communicate with Z the new port number. All of which is a fundamental change to SCTP's design. Lets first go fix the real problem.. getting NAT's and SCTP singly homed to work.. Once that gets fixed we can play in the "weeds" as Melinda puts it :-D I do like to fish for Stripe Bass.. lets save that for another day though ;-D R Best regards, Wolfgang R Best regards, Wolfgang regards, -Qiaobing -- Randall Stewart ITD 803-345-0369 815-342-5222 -- Randall Stewart ITD 803-345-0369 815-342-5222 From Qiaobing.Xie@motorola.com Thu, 17 Feb 2005 14:46:13 -0800 (PST) From: Qiaobing Xie Date: Thu, 17 Feb 2005 14:46:13 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <42151E7C.3030202@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Wolfgang, ... Example: - A client application on host X needs Interface redundancy, but unfortunately SCTP can not establish a multihomed Association due to NAPT... - I assume this NAPT box is able to handle SCTP like TCP ... SCTP (A1, Port P)----- NAPT(A2,P1)----cloud SCTP (here single HOST cloud------------+--HOST homed for X (B1, Port P)----- NAPT(B2,P2)----cloud Z easier drawing....) - The application is smart: it creates 2 singled homed associations: a primary association containing Addr A as Source Address and a secondary containing Addr B as Source Address. - If Association A fails, the application continues data transfer using association B. You are talking about failover from one SCTP association to another. This is covered in RSERPOOL, not SCTP. regards, -Qiaobing And you see: The application has a multihoming functionality, it uses SCTP and it is behind a NAPT! ********************************************** My vision: If the application can realize multihoming, SCTP should be able to do it also. Probably better. My question: Why is impossible and a fundamental change to implement this application logic within SCTP??? Best regards, Wolfgang From mshore@cisco.com Thu, 17 Feb 2005 14:48:00 -0800 (PST) From: Melinda Shore Date: Thu, 17 Feb 2005 14:48:00 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <421518FC.2090209@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Thursday, February 17, 2005, at 05:21 PM, Qiaobing Xie wrote: What do you mean by "forget NAT usage for SCTP"? I personally have known commercially deployed networks running multi-homed SCTP nodes across NATs. Do you know how they're doing it? You'll note that I qualified my "forget NAT ... " comment with "at least in the multihomed case." I do think that if there are concerns beyond basic protocol support they should be documented, as is being done here with TCP, etc. What I think should be forgotten, or at least deferred for the time being, is modifying SCTP to support multiple port numbers. What I think should be deferred forever is a nat-nat protocol, since there are security reasons and topological reasons to push the solution for that particular problem out to the endpoints rather than embedding it in the NATs. Melinda From wolfgang.schruefer@siemens.com Thu, 17 Feb 2005 15:07:26 -0800 (PST) From: Schruefer Wolfgang Date: Thu, 17 Feb 2005 15:07:26 -0800 (PST) Subject: RE: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain Qiaobing, please see inline ... > -----Original Message----- > From: Qiaobing Xie [mailto:Qiaobing.Xie@xxxxxxxxxxxx] > Sent: Thursday, February 17, 2005 11:45 PM > To: Schruefer Wolfgang > Cc: 'Randall Stewart'; Luca Laurenzi; Ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP > > Wolfgang, > > ... > > Example: > > > > - A client application on host X needs Interface redundancy, > > but unfortunately SCTP can not establish a multihomed > Association due to NAPT... > > - I assume this NAPT box is able to handle SCTP like TCP ... > > > > > > SCTP (A1, Port P)----- NAPT(A2,P1)----cloud SCTP (here > > single > > HOST cloud------------+--HOST homed > > for > > X (B1, Port P)----- NAPT(B2,P2)----cloud Z > > easier drawing....) > > > > > > - The application is smart: it creates 2 singled homed associations: > > a primary association containing Addr A as Source Address > and a secondary containing Addr B as Source Address. > > - If Association A fails, the application continues data > transfer using association B. > > You are talking about failover from one SCTP association to > another. This is covered in > RSERPOOL, not SCTP. Please see it as an example how easy multihoming might work over NAPT ... I thought RSERPOOL covers a failover of different Hosts, not a failover of redundant associations between the same hosts ... Wolfgang > > regards, > -Qiaobing > > > > > And you see: The application has a multihoming > functionality, it uses SCTP and it is behind a NAPT! > > > > ********************************************** > > > > My vision: > > If the application can realize multihoming, SCTP should be > able to do it also. Probably better. > > > > My question: > > Why is impossible and a fundamental change to implement > this application logic within SCTP??? > > > > > > Best regards, > > Wolfgang > > From wolfgang.schruefer@siemens.com Thu, 17 Feb 2005 15:14:13 -0800 (PST) From: Schruefer Wolfgang Date: Thu, 17 Feb 2005 15:14:13 -0800 (PST) Subject: RE: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain Please see inline ... Randall Stewart wrote: > Schruefer Wolfgang wrote: > > Randy, > > > > Randall Stewart wrote: > > > >> Spencer: > >> > >> That is why I wondered about Wolfgang's proposal. > >> > >> You need seperate NAPT's on seperate boxes... to get diversity and > >> no single point of failure.. > >> > >> You won't get that with Wolfgang's picture... > > > > > > Sorry, the picture was misleading, I just wanted to make it > as easy a > > possible ... Please see the NAPT as a cloud with random Address and > > Port translations, not as a single box. > > > > If you have two random NAPT's scattered amongst the cloud > somewhere.. .then how would you ever coordinate the heartbeating? > > If you have two seperate IP addresses on the NAT's then > you have a problem with only one side will get the INIT > (or INIT-ACK) to populate the state.. and, since SCTP only > knows about its internal private addresses thats all it > can list in its INIT... And right now we specifically tests > at inter-ops that SCTP endpoints DON'T do this so they can > get through NAT's singly homed. Forget the address list within an INIT. I agree that this would not work The SCTP extension would need a new procedure to establish the secondary path ... e.g if you send a second INIT via the alternate path Then you avoid most problems addressed below ... Wolfgang > > So... you would then need NAT'a KNOWING that NAT'b was > at a different address... and knowing its address and then > somehow talking to it to get state set in.. once you have > the two NATs talking I think it should be no problem to > coordinate what ports are handed out.. and then.. tada > SCTP works as is through a NAT.. we just need to get the above > fixed in SCTP implementations.. i.e. go ahead and list > your private addresses... > > > > > >> And then the only way I can think of is to either a) have a > >> nat-2-nat protocol... talk about way ugly > >> > >> or > >> > >> b) have a way to have SCTP use different ports.. which is not > >> allowed by the spec (and rightly so in my mind). Changing it, > >> especially since 99.9 % of all napt's know nothing about SCTP yet, > >> is like having the tail wag the dog... IMO. You don't design a > >> transport protocol FOR NAT's... > > > > > > By this argumentation You'll have a dog biting its tail ... NATs > > would not implement SCTP because SCTP does not support NAT ... SCTP > > would not support NAT because NATs do not support SCTP ... > > > > > > A Nat can support SCTP the same way it supports TCP.. aka > singly homed. There is no problem with this at all. > > > > > >> So.. not sure of a multi-homing solution for SCTP and NAT. Singly > >> homed will work just fine (as long as napt's will implement it). > >> > > > > > > Please let me summarize your words: > > > > We have 3 Options: > > > > a) nat-2-nat protocol: (... ugly ...) b) bring SCTP to use different > > ports (... not needed...) c) forget NAT usage for SCTP ... > > > No.. > > Lets first GET NAT's working with singly homed SCTP. Thats the > FIRST step.. there are problems to address in that (I know > from experience) world... > > Then, the next step is to try to get M-Homed working in some way.. and > that MAY take an ugly NAT-2-NAT protocol. > > We don't go re-design the base spec to fit NAT's.. What we > do is get NAT's working for the general case (singly homed) then > we can discuss the more complex area .. which by the way .. will > have less demand. > > R > > > If everybody shares your opinion I think we can close the > discussion. > > I personally do not agree, I would continue with option b) ... > > > > Best regards, Wolfgang > > > > > > > > > >> R > >> > >> Spencer Dawkins wrote: > >> > >>> Randall, > >>> > >>> Thanks for popping in here. > >>> > >>> My concern is about "multihoming solutions" that would require > >>> two different IP interfaces (chosen for diversity) to point > >> > >> traffic to the > >> > >>> same NATP box (so it can assign the same outgoing > >> > >> translation port to > >> > >>> both interfaces). > >>> > >>> It seems to me that inserting a single point of failure, > >> > >> regardless of > >> > >>> its reliability, into a multihoming solution isn't quite > >> > >> solving the > >> > >>> right problem. > >>> > >>> If I chose two interfaces that home through two different > >> > >> ISPs, traffic > >> > >>> to two ISPs would have to traverse the same NATP in order > >> > >> to pull this > >> > >>> off (or we could insert a NATP-to-NATP protocol that would keep > >>> translation ports synchronized, but...). > >>> > >>> Thank you for pointing out the "don't heartbeat to both IP > >> > >> addresses" > >> > >>> problem. I hadn't thought of that. > >>> > >>> I agree that things are getting ugly fast. I'm not sure > >> > >> everyone has the > >> > >>> same definition of "ugly" in this thread. > >>> > >>> Spencer > >>> > >>> > >>>> Now, the problem here is that of ports... which is why you are > >>>> asking for SCTP to have multiple ports. > >>>> > >>>> And I would argue that if your NAPT's is written to handle two > >>>> interfaces, it could also assign the same outgoing translation > >>>> port to both interfaces (if it knew that the SCTP endpoint was > >>>> multi-homed by looking inside the INIT/INIT-ACK). Of course it > >>>> would then have to do some method to use both networks. I.e. > >>>> how would it decide to fail over.. it can't know what the end's > >>>> are doing.. and of course the multi-homed nature would be > >>>> hidden from the peer Host-Z which would mean it would not know > >>>> to HB a seperate address. > >>>> > >>>> This gets ugly fast... > >>>> > >>>> If the base protocol had seperate ports allowed.. you might be > >>>> able to do it... but that is a major change to the protocol.. > >>>> > >>>> R > >>> > >>> > >>> > >>> _______________________________________________ Ietf-behave > >>> mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>> > >> > >> > >> -- Randall Stewart ITD 803-345-0369 815-342-5222 > >> _______________________________________________ Ietf-behave mailing > >> list Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > > > > > > > -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 > From Qiaobing.Xie@motorola.com Thu, 17 Feb 2005 15:42:59 -0800 (PST) From: Qiaobing Xie Date: Thu, 17 Feb 2005 15:42:59 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <42152CAE.9070205@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Malinda, .... What do you mean by "forget NAT usage for SCTP"? I personally have known commercially deployed networks running multi-homed SCTP nodes across NATs. Do you know how they're doing it? I won't be able to give details. But at a very high level, they did not try to attempt a multi-point traverse of a multi-homed sctp association (as we are trying to figured out here and we all agree that there is no cheap solution). In their case, the association in the network gives you true path redundancy from HOST A to NAT, and true path redundancy from NAT to HOST Z, and they accept the fact that the NAT is a single point of failure in the path. regards, -Qiaobing You'll note that I qualified my "forget NAT ... " comment with "at least in the multihomed case." I do think that if there are concerns beyond basic protocol support they should be documented, as is being done here with TCP, etc. What I think should be forgotten, or at least deferred for the time being, is modifying SCTP to support multiple port numbers. What I think should be deferred forever is a nat-nat protocol, since there are security reasons and topological reasons to push the solution for that particular problem out to the endpoints rather than embedding it in the NATs. Melinda From wolfgang.schruefer@siemens.com Thu, 17 Feb 2005 15:44:24 -0800 (PST) From: Schruefer Wolfgang Date: Thu, 17 Feb 2005 15:44:24 -0800 (PST) Subject: RE: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP Message-ID: MIME-Version: 1.0 Content-Type: text/plain Please see inline... Randall Stewart wrote: > Schruefer Wolfgang wrote: > > >> > >>So you want to change a fundamental design concept to accomadate > >>a hack called NAT. > > > > > > ... not fundamental ... just an extension > The way implementations find associations with ports and addresses > is a fundamental design issue that every SCTP implementation > that i have seen must deal with... Changes in ports and addresses > mean fundamental changes to this.. > > > > > >>And on top of that, I know of NO NAT's that yet implement SCTP.. > > > > > > ... actually NATs only need to learn how to calculate SCTP checksum > > ... this is not so complicated ... IMO > > And ports and state .. there are issues here.. you just > have to dig a bit deeper into the problem.. like try > to make it work correctly :0- > > > > > >>yes > >>I have worked on a BSD version of one but its not released or even > >>fully tested yet.... So we have roughly 25-30 different > >>implementations > >>of SCTP many being used in production environments.. and > you want all > >>of them to go through major changes so you can make > implementing SCTP > >>over NAT's more easy.. > > > > > > ... same procedure as implementing ADDIP, some may do, some not ... > > No you can't have optionial extra ports.. one side > must always be aware of it.. which means all sides must > be aware of it since neither will know when a NAT does > something. > > > > > > > >>And yes it is major changes since you are > >>talking about the fundamental method that associations are > >>found via.. > >> > >>And it does not help solve the single point of failure > >>issue... either.. > >>nor does it help with HB'ing and all the other things. > >> > >>In fact it solves very little of the true M-Homing NAT > problem.. which > >>IMO is a need for a Nat-2-Nat communication protocol to > allow two NATs > >>to assign the same port numbers and communicate state to each other. > >> > >>Especially since very few nats are configured per your > drawing... IMO > > > > > > > > Here I will bring again my example about application multihoming. > > Now with a better drawing, hopefully. > > None of your problems appeare ... > > > > > > ********************************************* > > Example: > > > > - A client application on host X needs Interface redundancy, > > but unfortunately SCTP can not establish a multihomed > Association due to NAPT... > > - I assume this NAPT box is able to handle SCTP like TCP ... > > > > > > SCTP (A1, Port P)----- NAPT(A2,P1)----cloud > SCTP (here single > > HOST > cloud------------+--HOST homed for > > X (B1, Port P)----- NAPT(B2,P2)----cloud > Z easier drawing....) > > > > > > - The application is smart: it creates 2 singled homed associations: > > a primary association containing Addr A as Source Address > and a secondary containing Addr B as Source Address. > > - If Association A fails, the application continues data > transfer using association B. > > > > And you see: The application has a multihoming > functionality, it uses SCTP and it is behind a NAPT! > > > > ********************************************** > > > > My vision: > > If the application can realize multihoming, SCTP should be > able to do it also. Probably better. > > > > My question: > > Why is impossible and a fundamental change to implement > this application logic within SCTP??? > > Because, in your drawing, you get to send two different INIT's > one to B-side and one to A-side. this allows propagation > of independant state in two seperate NAT's. This also > allows the SCTP stack at Z to deal with them > as just that two assocaiations.. indexed by port etc. Yes, but what is wrong about that? It is no fundamental change ... > > If you somehow magically were allowed two different ports > on the same association then the ONLY way it would work > is if Host-Z was capable of handling this strange behaviour. Yes Host-z needs to store the remote port number per path. > It would have to have all of the tracking information no, nothing more than it has by two single-homed associations ... > AND > Host-A also needs to do soemthing as well to propagate state > into the NAT it did NOT use to setup the association... and thus > communicate with Z the new port number. no, Host-A uses both NATs for setup, any NAT should handle a path similar to an independend single homed association ... > > All of which is a fundamental change to SCTP's design. > > Lets first go fix the real problem.. getting NAT's and SCTP > singly homed to work.. Sure, that is the base, and additionally a vision of multihoming may push it ... regards, Wolfgang > > Once that gets fixed we can play in the "weeds" as Melinda puts it :-D > > I do like to fish for Stripe Bass.. lets save that for another day > though ;-D > > R > > > > > > > Best regards, > > Wolfgang > > > > > >>R > >> > >> > >> > >> > >>>Best regards, Wolfgang > >>> > >>> > >>> > >>> > >>>>regards, -Qiaobing > >>>> > >>> > >>> > >> > >>-- > >>Randall Stewart > >>ITD > >>803-345-0369 815-342-5222 > >> > > > > > > > -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 > From Qiaobing.Xie@motorola.com Thu, 17 Feb 2005 15:50:02 -0800 (PST) From: Qiaobing Xie Date: Thu, 17 Feb 2005 15:50:02 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: <42152D6E.8080903@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Wolfgang, ... I thought RSERPOOL covers a failover of different Hosts, not a failover of redundant associations between the same hosts ... Nope. RSERPOOL covers failover among different endpoints. They can of cause be on the same host. regards, -Qiaobing From audet@nortel.com Thu, 17 Feb 2005 18:07:48 -0800 (PST) From: "Francois Audet" Date: Thu, 17 Feb 2005 18:07:48 -0800 (PST) Subject: RE: [Ietf-behave] New draft: Topology Complications Message-ID: <1ECE0EB50388174790F9694F77522CCF018BC554@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message Bryan, One thing worth mentioning in the VPN section, is that it is common for VPN devices (both "boxes" and PC clients) to NAT inside the tunnel. So you'd get, say, a 192.168.0.X address range at the bottom instead of the 10.1.1.1. From the corporate network however, that would still look like 10.1.1.1. It takes care of some of the issues you mention, but it obviously adds its own issues. -----Original Message-----From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bryan FordSent: Thursday, February 17, 2005 08:48To: ietf-behave@xxxxxxxxxxxxxxxxxxxSubject: [Ietf-behave] New draft: Topology Complications
Finally, the following slightly revised and expanded version of the earlier "Topology complications" document I announced on the list, is now in the official Internet-Drafts repository. "Topology complications from Network Address Translator deployments" http://www.ietf.org/internet-drafts/draft-ford-behave-top-00.txt This document identifies and provides recommendations for dealing with issues that have arisen recently from the ubiquitous deployment of network address translators (NAT), and the unconventional network topologies that are often constructed with them. First, the simplicity of administering networks through the combination of NAT and DHCP is increasingly leading to the deployment of multi-level hierarchies of inter-connected private networks involving overlapping private IP address spaces. The creation of these multi-level hierarchies is often unintentional, since each level of NAT is typically deployed by a separate administrative entity such as an ISP, a corporation, or a home user. Second, the popularity of corporate virtual private networks (VPN) in conjunction with NAT leads to problems in which the private IP address space of the network through which a remote client is attached may unintentionally conflict with the private IP address space of the corporate network into which the remote client is tunneled. This document specifies best current practice recommendations for addressing the issues identified. Since I've already received a number of positive comments on the original draft privately by E-mail, I'd like to hear public reactions to the idea of adopting this draft as a WG document, to be published sometime down the road relatively independently of the other documents. The main complication is that there is currently no corresponding WG milestone or work item for this document, so one would have to be added. Thanks! Bryan _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From baford@mit.edu Fri, 18 Feb 2005 03:38:03 -0800 (PST) From: Bryan Ford Date: Fri, 18 Feb 2005 03:38:03 -0800 (PST) Subject: Re: [Ietf-behave] New draft: Application Design Guidelines In-Reply-To: <1ECE0EB50388174790F9694F77522CCF018BC2F9@zrc2hxm0.corp.nortel.com> Message-ID: <200502181237.59787.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 17 February 2005 20:36, Francois Audet wrote: > Good job. This is great. Thanks! :) > Some minor comments: > > - Section 1.2: More importantly than "so far none of these protocols have > become widely accepted", it should be stated that it may not be feasible > or desireable in many architectures to have the application controlling > the NAT. Sounds good. How about this rewritten Section 1.2: 1.2. Explicit Communication with NATs Several protocols exist that allow applications to obtain external communication endpoints through explicit interaction with NATs in the path [SOCKS, RSIP, MIDCOM, UPNP]. None of these protocols have yet become widely accepted, however, and in many network scenarios it may not be feasible or desirable for applications to identify, locate, or control NATs in their communication path. This document therefore leaves such protocols out of scope, focusing exclusively on NAT traversal techniques that do not require the application to communicate explicitly with NATs in the path. > - It's a little unclear to me what REQ-6 is trying to say. REQ-6 is admittedly a little vague at the moment, and perhaps should be either made more specific or removed. One particular thing I had in mind when writing this requirement was that if an application wants to subject NATs in the path to a long complicated battery of tests in order to traverse symmetric NATs and such, the application ideally shouldn't force the user to wait until all these tests are done before even being able to traverse BEHAVE-compliant NATs. In other words, the task of gathering information for or setting up fancy non-BEHAVE traversal procedures shouldn't unduly delay the operation of the simple BEHAVE traversal procedure over BEHAVE-compliant NATs. But this probably isn't a very critical issue, and if we can't come up with a clear way to state it, I would be happy with eliminating at least the "formal" recommendation and just leaving the informal discussion text in the body of 2.5. > - Need a value for XX in REQ-7. Something smaller than half of 2 minutes > (to match nat-behave). My guess is 30s. We could also talk about > detecting > the timeout. I think that there were text about that in either STUN or > ICE, > I forget. In any case, should be marked as "opened issue" for now. Sure. 30s sounds reasonable to me. This keepalive period would obviously be too long for some existing NATs that have timeouts as short as 20 seconds, but 20 seconds is so unreasonably short that we can probably just classify such NATs as "broken" and assume the NAT-BEHAVE timeout. I also agree that we probably need some text discussing timeout detection, though it's not yet obvious to me what the specific recommendation(s) should be on that. I'll take a look back at STUN and ICE; thanks for the pointers. > Also, we probably need to add some material on RTP/RTCP usage. For example, > we need to discuss the fact that if RTP/RTCP address/port pairs do not > respect the parity and contiguity rule, the application MUST list them > separately (and not derive them algorithmically). Also, that if they > are advertized seperately, media must be sent to those addresses, and rules > on substracting one (as per RFC 3550 do not apply). Maybe list RFC 3605 as > as the mechanism used by SDP to list them separately. > > I agree with Dan on the symmetric RTP draft being folded in. Yes, these suggestions all sound good to me. Since (as I mentioned to Dan) I'm not yet very familiar with RTP/RTCP, would you guys mind providing some initial text on this topic to be added to the draft? Thanks, Bryan From audet@nortel.com Fri, 18 Feb 2005 10:24:42 -0800 (PST) From: "Francois Audet" Date: Fri, 18 Feb 2005 10:24:42 -0800 (PST) Subject: RE: [Ietf-behave] New draft: Application Design Guidelines Message-ID: <1ECE0EB50388174790F9694F77522CCF018BC86A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New draft: Application Design Guidelines OK. It looks like we are in synch. One minor point: I believe that you may also want to list NSIS in your list of NAT control protocol that are out-of-scope. > -----Original Message----- > From: Bryan Ford [mailto:baford@xxxxxxx] > Sent: Friday, February 18, 2005 03:38 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: Re: [Ietf-behave] New draft: Application Design Guidelines > > > On Thursday 17 February 2005 20:36, Francois Audet wrote: > > Good job. This is great. > > Thanks! :) > > > Some minor comments: > > > > - Section 1.2: More importantly than "so far none of these > protocols have > > become widely accepted", it should be stated that it may > not be feasible > > or desireable in many architectures to have the > application controlling > > the NAT. > > Sounds good. How about this rewritten Section 1.2: > > 1.2. Explicit Communication with NATs > > Several protocols exist that allow applications to obtain external > communication endpoints through explicit interaction with > NATs in the > path [SOCKS, RSIP, MIDCOM, UPNP]. None of these protocols have yet > become widely accepted, however, and in many network > scenarios it may > not be feasible or desirable for applications to identify, > locate, or > control NATs in their communication path. This document therefore > leaves such protocols out of scope, focusing exclusively on NAT > traversal techniques that do not require the application to > communicate explicitly with NATs in the path. > > > - It's a little unclear to me what REQ-6 is trying to say. > > REQ-6 is admittedly a little vague at the moment, and perhaps > should be either > made more specific or removed. One particular thing I had in > mind when > writing this requirement was that if an application wants to > subject NATs in > the path to a long complicated battery of tests in order to traverse > symmetric NATs and such, the application ideally shouldn't > force the user to > wait until all these tests are done before even being able to > traverse > BEHAVE-compliant NATs. In other words, the task of gathering > information for > or setting up fancy non-BEHAVE traversal procedures shouldn't > unduly delay > the operation of the simple BEHAVE traversal procedure over > BEHAVE-compliant > NATs. > > But this probably isn't a very critical issue, and if we > can't come up with a > clear way to state it, I would be happy with eliminating at least the > "formal" recommendation and just leaving the informal > discussion text in the > body of 2.5. > > > - Need a value for XX in REQ-7. Something smaller than half > of 2 minutes > > (to match nat-behave). My guess is 30s. We could also talk about > > detecting > > the timeout. I think that there were text about that in > either STUN > > or ICE, > > I forget. In any case, should be marked as "opened issue" for now. > > Sure. 30s sounds reasonable to me. This keepalive period > would obviously be > too long for some existing NATs that have timeouts as short > as 20 seconds, > but 20 seconds is so unreasonably short that we can probably > just classify > such NATs as "broken" and assume the NAT-BEHAVE timeout. > > I also agree that we probably need some text discussing > timeout detection, > though it's not yet obvious to me what the specific > recommendation(s) should > be on that. I'll take a look back at STUN and ICE; thanks > for the pointers. > > > Also, we probably need to add some material on RTP/RTCP usage. For > > example, we need to discuss the fact that if RTP/RTCP address/port > > pairs do not respect the parity and contiguity rule, the > application > > MUST list them separately (and not derive them > algorithmically). Also, > > that if they are advertized seperately, media must be sent to those > > addresses, and rules on substracting one (as per RFC 3550 do not > > apply). Maybe list RFC 3605 as as the mechanism used by SDP to list > > them separately. > > > > I agree with Dan on the symmetric RTP draft being folded in. > > Yes, these suggestions all sound good to me. Since (as I > mentioned to Dan) > I'm not yet very familiar with RTP/RTCP, would you guys mind > providing some > initial text on this topic to be added to the draft? > > Thanks, > Bryan > > From srisuresh@yahoo.com Sun, 20 Feb 2005 12:22:51 -0800 (PST) From: Pyda Srisuresh Date: Sun, 20 Feb 2005 12:22:51 -0800 (PST) Subject: RE: [Ietf-behave] New draft: Topology Complications In-Reply-To: <1ECE0EB50388174790F9694F77522CCF018BC554@zrc2hxm0.corp.nortel.com> Message-ID: <20050220202250.93657.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Francois, Thanks for your comments. Please see my responses inline. cheers, suresh --- Francois Audet wrote: > Bryan, > > One thing worth mentioning in the VPN section, is that it is common for VPN > devices (both "boxes" and PC clients) to NAT inside the tunnel. [suresh] You are right. Doing NAT (instead of VA) inside the remote access client is an option offered by some vendors. The NAT option will obviate mucking with routes on the client-PC. It is worth mentioning for this reason. However, this scenario carries the same caveats (as with VA) w.r.t. overlapping networks on the corporate and remote access end. > So you'd > get, say, a 192.168.0.X address range at the bottom instead of the 10.1.1.1. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [suresh] What did you mean by this? Are you saying the address pool used by the VPN server is 192.168.0/24, when the corporate uses 10.1 network? I must be missing something here. > From the corporate network however, that would still look like 10.1.1.1. > > It takes care of some of the issues you mention, but it obviously adds its > own issues. > [suresh] Sorry, I dont follow what you are saying. But, I do agree the NAT option takes care of some caveats, but adds caveats of ots own. That was principally why we didnt specify this in the first rev. We will specify this in the next rev. cheers, suresh > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bryan Ford > Sent: Thursday, February 17, 2005 08:48 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] New draft: Topology Complications > > > > Finally, the following slightly revised and expanded version of the earlier > "Topology complications" document I announced on the list, is now in the > official Internet-Drafts repository. > > > "Topology complications from Network Address Translator deployments" > http://www.ietf.org/internet-drafts/draft-ford-behave-top-00.txt > > > This document identifies and provides recommendations for dealing with > issues that have arisen recently from the ubiquitous deployment of network > address translators (NAT), and the unconventional network topologies that > are > often constructed with them. First, the simplicity of administering networks > > through the combination of NAT and DHCP is increasingly leading to the > deployment of multi-level hierarchies of inter-connected private networks > involving overlapping private IP address spaces. The creation of these > multi-level hierarchies is often unintentional, since each level of NAT is > typically deployed by a separate administrative entity such as an ISP, a > corporation, or a home user. Second, the popularity of corporate virtual > private networks (VPN) in conjunction with NAT leads to problems in which > the > private IP address space of the network through which a remote client is > attached may unintentionally conflict with the private IP address space of > the corporate network into which the remote client is tunneled. This > document > specifies best current practice recommendations for addressing the issues > identified. > > > Since I've already received a number of positive comments on the original > draft privately by E-mail, I'd like to hear public reactions to the idea of > adopting this draft as a WG document, to be published sometime down the road > > relatively independently of the other documents. The main complication is > that there is currently no corresponding WG milestone or work item for this > document, so one would have to be added. > > Thanks! > Bryan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > ===== From audet@nortel.com Sun, 20 Feb 2005 12:36:33 -0800 (PST) From: "Francois Audet" Date: Sun, 20 Feb 2005 12:36:33 -0800 (PST) Subject: RE: [Ietf-behave] New draft: Topology Complications Message-ID: <1ECE0EB50388174790F9694F77522CCF018BCBA7@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New draft: Topology Complications Yes, I think you got it right. I just saying that the VPN box (or app) is NATing inside the tunnel. I'm happy with just mentioning it in the draft, as you say. In the example below, I'm just saying that the applications running on the host think they have a 192.X address, but then the tunnel NATs it to whatever address range is used. The applications in that case need to run a STUN service inside the tunnel. This is especially useful for unmanaged NAT boxes. I've also seen in some VPN software. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pyda Srisuresh > Sent: Sunday, February 20, 2005 12:23 > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: RE: [Ietf-behave] New draft: Topology Complications > > > Francois, > > Thanks for your comments. Please see my responses inline. > > cheers, > suresh > > --- Francois Audet wrote: > > > Bryan, > > > > One thing worth mentioning in the VPN section, is that it is common > > for VPN devices (both "boxes" and PC clients) to NAT inside the > > tunnel. > > [suresh] You are right. Doing NAT (instead of VA) inside the > remote access client is an option offered by some vendors. > The NAT option will obviate mucking with routes on the > client-PC. It is worth mentioning for this reason. > > However, this scenario carries the same caveats (as with VA) > w.r.t. overlapping networks on the corporate and remote access end. > > > So > > you'd get, say, a 192.168.0.X address range at the bottom > instead of > > the 10.1.1.1. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [suresh] What did you mean by this? Are you saying the > address pool used by the VPN server is 192.168.0/24, when the > corporate uses 10.1 network? I must be missing something here. > > > From the corporate network however, that would still look like > > 10.1.1.1. > > > > It takes care of some of the issues you mention, but it > obviously adds > > its own issues. > > > > [suresh] Sorry, I dont follow what you are saying. But, I do > agree the NAT option takes care of some caveats, but adds > caveats of ots own. That was principally why we didnt specify > this in the first rev. We will specify this in the next rev. > > > cheers, > suresh > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bryan > > Ford > > Sent: Thursday, February 17, 2005 08:48 > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: [Ietf-behave] New draft: Topology Complications > > > > > > > > Finally, the following slightly revised and expanded version of the > > earlier > > "Topology complications" document I announced on the list, > is now in the > > official Internet-Drafts repository. > > > > > > "Topology complications from Network Address Translator deployments" > > http://www.ietf.org/internet-drafts/draft-ford-behave-top-00.txt > > > > > > This document identifies and provides recommendations > for dealing > > with > > issues that have arisen recently from the ubiquitous > deployment of network > > address translators (NAT), and the unconventional network > topologies that > > are > > often constructed with them. First, the simplicity of > administering networks > > > > through the combination of NAT and DHCP is increasingly > leading to the > > deployment of multi-level hierarchies of inter-connected > private networks > > involving overlapping private IP address spaces. The > creation of these > > multi-level hierarchies is often unintentional, since each > level of NAT is > > typically deployed by a separate administrative entity such > as an ISP, a > > corporation, or a home user. Second, the popularity of > corporate virtual > > private networks (VPN) in conjunction with NAT leads to > problems in which > > the > > private IP address space of the network through which a > remote client is > > attached may unintentionally conflict with the private IP > address space of > > the corporate network into which the remote client is tunneled. This > > document > > specifies best current practice recommendations for > addressing the issues > > identified. > > > > > > Since I've already received a number of positive comments on the > > original > > draft privately by E-mail, I'd like to hear public > reactions to the idea of > > adopting this draft as a WG document, to be published > sometime down the road > > > > relatively independently of the other documents. The main > > complication is > > that there is currently no corresponding WG milestone or > work item for this > > document, so one would have to be added. > > > > Thanks! > > Bryan > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > ===== > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From srisuresh@yahoo.com Mon, 21 Feb 2005 06:28:36 -0800 (PST) From: Pyda Srisuresh Date: Mon, 21 Feb 2005 06:28:36 -0800 (PST) Subject: Re: [Ietf-behave] Agenda time IETF 62 In-Reply-To: Message-ID: <20050221142835.56610.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen & Jiri, A number of individual drafts relating to behave have been published. Would it be appropriate to use a time slot in the agenda to poll interest in adapting them as WG drafts? Thanks. Below are the individual drafts I am refering to. draft-ford-behave-gen-00.txt draft-ford-behave-top-00.txt draft-ford-behave-app-00.txt draft-sivakumar-behave-nat-tcp-req-00 draft-srisuresh-behave-p2p-state-00.txt regards, suresh --- Cullen Jennings wrote: > > I am a bit late for IETF 61 so let's try for IETF 62 :-) > > On 2/15/05 11:42 AM, "Cullen Jennings" wrote: > > > > > Jiri and are starting to think about putting together the agenda for the > for > > the next IETF meeting. Please email both of us know if think you might want > > some agenda time. As always, we prefer to spend meeting time solving > problems > > we can't bring to resolution on this list. > > > > Thanks, Cullen > > us > > PS. I would prefer to see draft slides 24 hours before you present. I > think > > this could help the chairs sort out the material to be covered and to make > > best use of meeting time. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > ===== From srisuresh@yahoo.com Mon, 21 Feb 2005 07:22:15 -0800 (PST) From: Pyda Srisuresh Date: Mon, 21 Feb 2005 07:22:15 -0800 (PST) Subject: RE: [Ietf-behave] New draft: Topology Complications In-Reply-To: <1ECE0EB50388174790F9694F77522CCF018BCBA7@zrc2hxm0.corp.nortel.com> Message-ID: <20050221152214.68760.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Francois Audet wrote: > Yes, I think you got it right. > > I just saying that the VPN box (or app) is NATing inside the tunnel. > > I'm happy with just mentioning it in the draft, as you say. > [suresh] OK. will do. > In the example below, I'm just saying that the applications > running on the host think they have a 192.X address, but then the > tunnel NATs it to whatever address range is used. > [suresh] OK. > The applications in that case need to run a STUN service inside > the tunnel. > [suresh] I donot believe so. Any NAT enroute between the tunnel endpoints does not effect the applications inside the tunnel. cheers, suresh > This is especially useful for unmanaged NAT boxes. I've also > seen in some VPN software. > > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Pyda Srisuresh > > Sent: Sunday, February 20, 2005 12:23 > > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > > Subject: RE: [Ietf-behave] New draft: Topology Complications > > > > > > Francois, > > > > Thanks for your comments. Please see my responses inline. > > > > cheers, > > suresh > > > > --- Francois Audet wrote: > > > > > Bryan, > > > > > > One thing worth mentioning in the VPN section, is that it is common > > > for VPN devices (both "boxes" and PC clients) to NAT inside the > > > tunnel. > > > > [suresh] You are right. Doing NAT (instead of VA) inside the > > remote access client is an option offered by some vendors. > > The NAT option will obviate mucking with routes on the > > client-PC. It is worth mentioning for this reason. > > > > However, this scenario carries the same caveats (as with VA) > > w.r.t. overlapping networks on the corporate and remote access end. > > > > > So > > > you'd get, say, a 192.168.0.X address range at the bottom > > instead of > > > the 10.1.1.1. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > [suresh] What did you mean by this? Are you saying the > > address pool used by the VPN server is 192.168.0/24, when the > > corporate uses 10.1 network? I must be missing something here. > > > > > From the corporate network however, that would still look like > > > 10.1.1.1. > > > > > > It takes care of some of the issues you mention, but it > > obviously adds > > > its own issues. > > > > > > > [suresh] Sorry, I dont follow what you are saying. But, I do > > agree the NAT option takes care of some caveats, but adds > > caveats of ots own. That was principally why we didnt specify > > this in the first rev. We will specify this in the next rev. > > > > > > cheers, > > suresh > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bryan > > > Ford > > > Sent: Thursday, February 17, 2005 08:48 > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: [Ietf-behave] New draft: Topology Complications > > > > > > > > > > > > Finally, the following slightly revised and expanded version of the > > > earlier > > > "Topology complications" document I announced on the list, > > is now in the > > > official Internet-Drafts repository. > > > > > > > > > "Topology complications from Network Address Translator deployments" > > > http://www.ietf.org/internet-drafts/draft-ford-behave-top-00.txt > > > > > > > > > This document identifies and provides recommendations > > for dealing > > > with > > > issues that have arisen recently from the ubiquitous > > deployment of network > > > address translators (NAT), and the unconventional network > > topologies that > > > are > > > often constructed with them. First, the simplicity of > > administering networks > > > > > > through the combination of NAT and DHCP is increasingly > > leading to the > > > deployment of multi-level hierarchies of inter-connected > > private networks > > > involving overlapping private IP address spaces. The > > creation of these > > > multi-level hierarchies is often unintentional, since each > > level of NAT is > > > typically deployed by a separate administrative entity such > > as an ISP, a > > > corporation, or a home user. Second, the popularity of > > corporate virtual > > > private networks (VPN) in conjunction with NAT leads to > > problems in which > > > the > > > private IP address space of the network through which a > > remote client is > > > attached may unintentionally conflict with the private IP > > address space of > > > the corporate network into which the remote client is tunneled. This > > > document > > > specifies best current practice recommendations for > > addressing the issues > > > identified. > > > > > > > > > Since I've already received a number of positive comments on the > > > original > > > draft privately by E-mail, I'd like to hear public > > reactions to the idea of > > > adopting this draft as a WG document, to be published > > sometime down the road > > > > > > relatively independently of the other documents. The main > > > complication is > > > that there is currently no corresponding WG milestone or > > work item for this > > > document, so one would have to be added. > > > > > > Thanks! > > > Bryan > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > ===== > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > ===== From paul.hoffman@vpnc.org Mon, 21 Feb 2005 09:37:41 -0800 (PST) From: Paul Hoffman Date: Mon, 21 Feb 2005 09:37:41 -0800 (PST) Subject: Re: [Ietf-behave] Agenda time IETF 62 In-Reply-To: <20050221142835.56610.qmail@web40426.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 6:28 AM -0800 2/21/05, Pyda Srisuresh wrote: A number of individual drafts relating to behave have been published. Would it be appropriate to use a time slot in the agenda to poll interest in adapting them as WG drafts? Thanks. Below are the individual drafts I am refering to. draft-ford-behave-gen-00.txt draft-ford-behave-top-00.txt draft-ford-behave-app-00.txt draft-sivakumar-behave-nat-tcp-req-00 draft-srisuresh-behave-p2p-state-00.txt Fully agree. It is somewhat disappointing to see the amount of traffic on SCTP (given that it is not even in our charter) and nearly none on our charter items. --Paul Hoffman, Director --VPN Consortium From Qiaobing.Xie@motorola.com Mon, 21 Feb 2005 10:40:31 -0800 (PST) From: Qiaobing Xie Date: Mon, 21 Feb 2005 10:40:31 -0800 (PST) Subject: Re: [Ietf-behave] Agenda time IETF 62 In-Reply-To: <20050221142835.56610.qmail@web40426.mail.yahoo.com> Message-ID: <421A2BCC.4020501@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Yes, it would be nice if the group can take a look at the sctp-nat I-D and see if we should make it a WG draft. There is obviously interest in it. I will re-submit it once the block out is over. For the time being, it can be viewed at . regards, -Qiaobing Paul Hoffman wrote: At 6:28 AM -0800 2/21/05, Pyda Srisuresh wrote: A number of individual drafts relating to behave have been published. Would it be appropriate to use a time slot in the agenda to poll interest in adapting them as WG drafts? Thanks. Below are the individual drafts I am refering to. draft-ford-behave-gen-00.txt draft-ford-behave-top-00.txt draft-ford-behave-app-00.txt draft-sivakumar-behave-nat-tcp-req-00 draft-srisuresh-behave-p2p-state-00.txt Fully agree. It is somewhat disappointing to see the amount of traffic on SCTP (given that it is not even in our charter) and nearly none on our charter items. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From nagendra@cs.stanford.edu Mon, 21 Feb 2005 19:07:44 -0800 (PST) From: nagendra modadugu Date: Mon, 21 Feb 2005 19:07:44 -0800 (PST) Subject: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP Message-ID: <20050222030742.GA14030@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain I must apologize for the delayed notification about a new draft -- the draft got held up as a result of a buggy IPR statement (now fixed). The draft is a TCP counterpart to the NAT-UDP draft by Audet & Jennings. I have attempted to reproduce as little material possible from the NAT-UDP draft while following its template. As a result, this draft may be read as a "diff" to the NAT-UDP draft (though there is only one conflicting recommendation, for which see below). Some elements require expansion following further discussion (timer values for instance). The recommendation on "Port Preservation" in this draft (=RECOMMENDED) differs from the recommendation made in the NAT-UDP draft (a brief discussion on this issue is given in Section 7.1). If there is a consensus for "Port Preservation" preservation behavior, then this change ought to be folded into the NAT-UDP or protocol independent behavior drafts. nagendra -- http://www.ietf.org/internet-drafts/draft-modadugu-nat-tcp-00.txt Abstract This document specifies requirements for NAT devices when handling TCP traffic. In order to arrive at the requirements, basic terminology regarding NAT TCP handling is defined. The purpose of this document is to provide a specification of TCP handling by NAT devices so that TCP-using applications can work consistently. From rrs@cisco.com Tue, 22 Feb 2005 07:40:35 -0800 (PST) From: Randall Stewart Date: Tue, 22 Feb 2005 07:40:35 -0800 (PST) Subject: Re: [Ietf-behave] Agenda time IETF 62 In-Reply-To: <20050221142835.56610.qmail@web40426.mail.yahoo.com> Message-ID: <421B51D1.6090201@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Paul/Jon/Allision You raise an interesting point... I just looked over the charter for behave.. and it seems to me the IESG missed adding a XXX 05 Produce a BCP that defines SCTP behavioral requirements for NATs To its charter... all the rest of the verbage supports this item.. but like so many times SCTP is not thought about... :-D I think we need to get our chairs to approach the IESG to fix this ommission.. I don't think its a question of expanding the charter.. its just something that was missed IMO R Paul Hoffman wrote: At 6:28 AM -0800 2/21/05, Pyda Srisuresh wrote: A number of individual drafts relating to behave have been published. Would it be appropriate to use a time slot in the agenda to poll interest in adapting them as WG drafts? Thanks. Below are the individual drafts I am refering to. draft-ford-behave-gen-00.txt draft-ford-behave-top-00.txt draft-ford-behave-app-00.txt draft-sivakumar-behave-nat-tcp-req-00 draft-srisuresh-behave-p2p-state-00.txt Fully agree. It is somewhat disappointing to see the amount of traffic on SCTP (given that it is not even in our charter) and nearly none on our charter items. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Randall Stewart ITD 803-345-0369 815-342-5222 From fluffy@cisco.com Tue, 22 Feb 2005 08:25:37 -0800 (PST) From: Cullen Jennings Date: Tue, 22 Feb 2005 08:25:37 -0800 (PST) Subject: [Ietf-behave] adding SCTP at behave milestone In-Reply-To: <421B51D1.6090201@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I think that SCTP was explicitly discussed at the time we did the charter. My recollection was that we were trying hard to make the scope of this WG small enough that it had a hope of accomplishing it's goals. Now my read of the charter is that it does not rule out recommendations for NATs that come up due to SCTP. However, there is definitely no milestones for SCTP. I would be very hesitant to request any milestones for SCTP work until *after* we have got the current milestone work off to IESG. It's not that I'm forgetting about SCTP - it just a matter of prioritizing the work in an order where we can get one chunk done then move on to the next chunk instead of trying to boil the ocean of protocols. I can't remember all the reasons others had for prioritizing in various orders but I think some of the reasons that I had for putting the existing things ahead of SCTP were: 1) it's not clear to me what applications use SCTP that cross NATs; 2) it did not seem like it was currently causing huge pain; 3) it will be more complicated that the UDP or TCP work and the experience learned on those will help figure out SCTP Cullen On 2/22/05 7:37 AM, "Randall Stewart" wrote: > Paul/Jon/Allision > > You raise an interesting point... I just looked > over the charter for behave.. and it seems to > me the IESG missed adding a > > XXX 05 Produce a BCP that defines SCTP behavioral requirements for NATs > > > To its charter... all the rest of the > verbage supports this item.. but like so many times > SCTP is not thought about... :-D > > I think we need to get our chairs to approach the IESG to > fix this ommission.. I don't think its a question of expanding > the charter.. its just something that was missed IMO > > R > > Paul Hoffman wrote: >> At 6:28 AM -0800 2/21/05, Pyda Srisuresh wrote: >> >>> A number of individual drafts relating to behave have been published. >>> Would it >>> be appropriate to use a time slot in the agenda to poll interest in >>> adapting >>> them as WG drafts? Thanks. Below are the individual drafts I am >>> refering to. >>> >>> draft-ford-behave-gen-00.txt >>> draft-ford-behave-top-00.txt >>> draft-ford-behave-app-00.txt >>> draft-sivakumar-behave-nat-tcp-req-00 >>> draft-srisuresh-behave-p2p-state-00.txt >> >> >> Fully agree. It is somewhat disappointing to see the amount of traffic >> on SCTP (given that it is not even in our charter) and nearly none on >> our charter items. >> >> --Paul Hoffman, Director >> --VPN Consortium >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> > From rrs@cisco.com Tue, 22 Feb 2005 09:05:19 -0800 (PST) From: Randall Stewart Date: Tue, 22 Feb 2005 09:05:19 -0800 (PST) Subject: [Ietf-behave] Re: adding SCTP at behave milestone In-Reply-To: Message-ID: <421B65AB.9060706@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Cullen Jennings wrote: I think that SCTP was explicitly discussed at the time we did the charter. My recollection was that we were trying hard to make the scope of this WG small enough that it had a hope of accomplishing it's goals. Now my read of the charter is that it does not rule out recommendations for NATs that come up due to SCTP. However, there is definitely no milestones for SCTP. I would be very hesitant to request any milestones for SCTP work until *after* we have got the current milestone work off to IESG. It's not that I'm forgetting about SCTP - it just a matter of prioritizing the work in an order where we can get one chunk done then move on to the next chunk instead of trying to boil the ocean of protocols. Hmmm... considering that SCTP is the only transport protocol the IETF has standardized (TCP pre-dates the IETF)... I would have thought it would not be part of the "ocean" of protocols... especially since there are only 3 at the transport level.. maybe 4 if we include DCCP.. At least its nice to know it was not completely overlooked :-D I can't remember all the reasons others had for prioritizing in various orders but I think some of the reasons that I had for putting the existing things ahead of SCTP were: 1) it's not clear to me what applications use SCTP that cross NATs; 2) it did not seem like it was currently causing huge pain; 3) it will be more complicated that the UDP or TCP work and the experience learned on those will help figure out SCTP Hmm.. as long as one does not try to do the multi-homing thing across NAT then I don't think SCTP is any more hard then TCP or UDP. Its only when one trys to capture the m-homing that one gets into a sea of trouble... As to priority.. I understand.. you must try to winnow the work so it gets done... only thing in favor of getting something out there on SCTP is there seems to be only one company, as yet, that has SCTP in NAT (Q refered to them earlier.. but they remain anonomous at his request)... this then gives the IETF an opening to figure out the RIGHT thing to do and get the implementors to do it that way instead of add-hock so we are writting documents as to how things are already working vs how things aught to be working... But.... as I said... I understand.. if thats not a priority thats fine.. we can pick up the work later.. but I think Q and I will continue to work on the draft and get it closer to capturing all the issues (forgoing m-homing however).. R -- Randall Stewart ITD 803-345-0369 815-342-5222 From paul.hoffman@vpnc.org Tue, 22 Feb 2005 09:13:50 -0800 (PST) From: Paul Hoffman Date: Tue, 22 Feb 2005 09:13:50 -0800 (PST) Subject: Re: [Ietf-behave] Agenda time IETF 62 In-Reply-To: <20050221142835.56610.qmail@web40426.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Er, maybe my last comment was misinterpreted. I'm fine with SCTP being *one* of the many topics this WG covers, but having much more discussion about the drafts that cover the NAT interactions with widely-deployed protocols is a much higher concern for many of us. --Paul Hoffman, Director --VPN Consortium From audet@nortel.com Tue, 22 Feb 2005 09:22:26 -0800 (PST) From: "Francois Audet" Date: Tue, 22 Feb 2005 09:22:26 -0800 (PST) Subject: RE: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP Message-ID: <1ECE0EB50388174790F9694F77522CCF0192407D@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP Thanks Nagendra, good document. On the point concerning "port preservation" and draft-ietf-behave-nat-udp, Nagendra and I had an offline discussion. Let me reproduce here for clarity REQ-3 from draft-ietf-behave-nat-udp: REQ-3 It is RECOMMENDED that a NAT have a "Port assignment" behavior of "No port preservation". a) NAT MAY use a "Port assignment" behavior of "Port preservation". b) A NAT MUST NOT have a "Port assignment" behavior of "Port overloading". c) If the host's source port was in the range 1-1023, it is RECOMMENDED the NAT's source port also be in the same range. If the host's source port was in the range 1024-65535, it is RECOMMENDED that the NAT's source port also be in that range. Nagendra's point is that the first requirement about not recommending port preservation is not enforceable and meaningless. If ports are assigned randomly, it is possible that it will randomly be preserved. Therefore the application must be capable of dealing with the case where it is preserved. The reason we came up with this requirement in the first place is because we have noticed a lot of NATs that tried to preserve the port when not assigned (and behaved like a Cone NAT) and then switched to not-preserved AND to a symmetric NAT when the port was already in use. It is not the "preservation" that was the problem, but the switching from Cone to symmetric (non-deterministic property). In short, I agree with Nagendra. I'm not sure if we should recommend port preservation, or just not recommend anything at all. I would propose to change REQ-3 of draft-ietf-nat-behave-udp to: REQ-3 A NAT MUST NOT have a "Port assignment" behavior of "Port overloading". a) If the host's source port was in the range 1-1023, it is RECOMMENDED the NAT's source port also be in the same range. If the host's source port was in the range 1024-65535, it is RECOMMENDED that the NAT's source port also be in that range. And align the TCP document with this. The other alternative is to explicitly recommend port preservation, in which case it would look like: REQ-3 It is RECOMMENDED that a NAT have a "Port assignment" behavior of "Port preservation". a) A NAT MUST NOT have a "Port assignment" behavior of "Port overloading". b) If the host's source port was in the range 1-1023, it is RECOMMENDED the NAT's source port also be in the same range. If the host's source port was in the range 1024-65535, it is RECOMMENDED that the NAT's source port also be in that range. I prefer the first approach, but I am happy with either. Comments? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > nagendra modadugu > Sent: Monday, February 21, 2005 19:08 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP > > > > I must apologize for the delayed notification about a new > draft -- the draft got held up as a result of a buggy IPR > statement (now fixed). > > The draft is a TCP counterpart to the NAT-UDP draft by Audet > & Jennings. I have attempted to reproduce as little material > possible > from the NAT-UDP draft while following its template. As a > result, this draft may be read as a "diff" to the NAT-UDP > draft (though there is only one conflicting recommendation, > for which see below). > > Some elements require expansion following further discussion > (timer values for instance). > > The recommendation on "Port Preservation" in this draft > (=RECOMMENDED) > differs from the recommendation made in the NAT-UDP draft (a brief > discussion on this issue is given in Section 7.1). If there is a > consensus for "Port Preservation" preservation behavior, then > this change ought to be folded into the NAT-UDP or protocol > independent > behavior drafts. > > nagendra > > -- http://www.ietf.org/internet-drafts/draft-modadugu-nat-tcp-00.txt > > Abstract > > This document specifies requirements for NAT devices when handling > TCP traffic. In order to arrive at the requirements, basic > terminology regarding NAT TCP handling is defined. The purpose of > this document is to provide a specification of TCP handling by NAT > devices so that TCP-using applications can work consistently. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From fluffy@cisco.com Tue, 22 Feb 2005 09:37:50 -0800 (PST) From: Cullen Jennings Date: Tue, 22 Feb 2005 09:37:50 -0800 (PST) Subject: [Ietf-behave] Re: adding SCTP at behave milestone In-Reply-To: <421B65AB.9060706@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain > thought it would not be part of the "ocean" of protocols... especially > since there are only 3 at the transport level.. maybe 4 if we include > DCCP Ok, Ok, I agree, it's hardly an ocean :-) Perhaps a handful of small streams would be a better analogy. The streams are of course complete with log jams, waterfalls, water diversion projects, industrial waste sites, and plans to make bypasses for high-speed salmon. > > But.... as I said... I understand.. if thats not a priority thats > fine.. we can pick up the work later.. but I think Q and I will > continue to work on the draft and get it closer to capturing > all the issues (forgoing m-homing however).. > I'd never discourage anyone from pursing useful work. And it's not that SCTP could never fit into behave, it could, we just need to finish some other stuff first. Glad to see people thinking about the future but also anything you can do to accelerate the other stuff is good too. Cullen From audet@nortel.com Tue, 22 Feb 2005 09:40:23 -0800 (PST) From: "Francois Audet" Date: Tue, 22 Feb 2005 09:40:23 -0800 (PST) Subject: RE: [Ietf-behave] Re: adding SCTP at behave milestone Message-ID: <1ECE0EB50388174790F9694F77522CCF019240A7@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Re: adding SCTP at behave milestone Isn't the solution to this really simple: let people who are interested continue to work on it, with the understanding that we will go to last call on the other most important document first? My 2 cents... > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Cullen Jennings > Sent: Tuesday, February 22, 2005 09:38 > To: Randall Stewart > Cc: Behave > Subject: [Ietf-behave] Re: adding SCTP at behave milestone > > > > > thought it would not be part of the "ocean" of protocols... > especially > > since there are only 3 at the transport level.. maybe 4 if > we include > > DCCP > > Ok, Ok, I agree, it's hardly an ocean :-) Perhaps a handful > of small streams would be a better analogy. The streams are > of course complete with log jams, waterfalls, water diversion > projects, industrial waste sites, and plans to make bypasses > for high-speed salmon. > > > > > But.... as I said... I understand.. if thats not a priority thats > > fine.. we can pick up the work later.. but I think Q and I will > > continue to work on the draft and get it closer to > capturing all the > > issues (forgoing m-homing however).. > > > > I'd never discourage anyone from pursing useful work. And > it's not that SCTP could never fit into behave, it could, we > just need to finish some other stuff first. Glad to see > people thinking about the future but also anything you can do > to accelerate the other stuff is good too. > > Cullen > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From mshore@cisco.com Tue, 22 Feb 2005 09:52:35 -0800 (PST) From: Melinda Shore Date: Tue, 22 Feb 2005 09:52:35 -0800 (PST) Subject: Re: [Ietf-behave] Re: adding SCTP at behave milestone In-Reply-To: <1ECE0EB50388174790F9694F77522CCF019240A7@zrc2hxm0.corp.nortel.com> Message-ID: <7A82A376-84FA-11D9-8494-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Tuesday, February 22, 2005, at 12:40 PM, Francois Audet wrote: Isn't the solution to this really simple: let people who are interested continue to work on it, with the understanding that we will go to last call on the other most important document first? Anybody can work on anything, obviously. Working group milestones are another matter, and it makes sense to be a bit conservative in agreeing to deliver deliverables. Also, the specific question that was posed was whether or not to make Qiaobing's draft a working group document. I have nothing but respect for Qiaobing's excellent work in a number of areas, but I think that this one draft is really not very good. I don't think the multihomed traversal problem is framed very coherently and the proposed solution (a nat/nat protocol) is just wrong, for reasons I've outlined previously. Melinda From Qiaobing.Xie@motorola.com Tue, 22 Feb 2005 09:57:25 -0800 (PST) From: Qiaobing Xie Date: Tue, 22 Feb 2005 09:57:25 -0800 (PST) Subject: Re: [Ietf-behave] Re: adding SCTP at behave milestone In-Reply-To: <1ECE0EB50388174790F9694F77522CCF019240A7@zrc2hxm0.corp.nortel.com> Message-ID: <421B7200.7000409@motorola.com> MIME-Version: 1.0 Content-Type: text/plain IMO, it may not be necessary that SCTP-NAT be added as a high priority milestone. But to have a WG draft that people can find on the WG web page would be very helpful. regards, -Qiaobing Francois Audet wrote: Isn't the solution to this really simple: let people who are interested continue to work on it, with the understanding that we will go to last call on the other most important document first? My 2 cents... > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Cullen Jennings > Sent: Tuesday, February 22, 2005 09:38 > To: Randall Stewart > Cc: Behave > Subject: [Ietf-behave] Re: adding SCTP at behave milestone > > > > thought it would not be part of the "ocean" of protocols... > especially > > since there are only 3 at the transport level.. maybe 4 if > we include > > DCCP > > Ok, Ok, I agree, it's hardly an ocean :-) Perhaps a handful > of small streams would be a better analogy. The streams are > of course complete with log jams, waterfalls, water diversion > projects, industrial waste sites, and plans to make bypasses > for high-speed salmon. > > > > > But.... as I said... I understand.. if thats not a priority thats > > fine.. we can pick up the work later.. but I think Q and I will > > continue to work on the draft and get it closer to > capturing all the > > issues (forgoing m-homing however).. > > > > I'd never discourage anyone from pursing useful work. And > it's not that SCTP could never fit into behave, it could, we > just need to finish some other stuff first. Glad to see > people thinking about the future but also anything you can do > to accelerate the other stuff is good too. > > Cullen > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Qiaobing.Xie@motorola.com Tue, 22 Feb 2005 10:31:27 -0800 (PST) From: Qiaobing Xie Date: Tue, 22 Feb 2005 10:31:27 -0800 (PST) Subject: Re: [Ietf-behave] Re: adding SCTP at behave milestone In-Reply-To: <7A82A376-84FA-11D9-8494-000A95E35274@cisco.com> Message-ID: <421B7B28.8030804@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Melinda, This is why I suggested that making it a WG item would help - more people can read it more carefully and contribute to its improvement. As to the particular issue of nat/nat protocol, you may have mis-read the draft badly. I know your view on this nat/nat protocol issue (and I dislike it too), but I have no idea where you got the impression that the draft is proposing a solution based on a nat/nat protocol. Here is the only place that topic is mentioned in the draft: " This [state sync among NATs] can only be possible if there exists some inter-NAT protocol which can provide coordination amongst the NATs when the association is set up. Further study is needed for this scenario. " As to the multi-homed traversal problem, how do you want to frame it? regards, -Qiaobing Melinda Shore wrote: On Tuesday, February 22, 2005, at 12:40 PM, Francois Audet wrote: Isn't the solution to this really simple: let people who are interested continue to work on it, with the understanding that we will go to last call on the other most important document first? Anybody can work on anything, obviously. Working group milestones are another matter, and it makes sense to be a bit conservative in agreeing to deliver deliverables. Also, the specific question that was posed was whether or not to make Qiaobing's draft a working group document. I have nothing but respect for Qiaobing's excellent work in a number of areas, but I think that this one draft is really not very good. I don't think the multihomed traversal problem is framed very coherently and the proposed solution (a nat/nat protocol) is just wrong, for reasons I've outlined previously. Melinda _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From mshore@cisco.com Tue, 22 Feb 2005 10:40:27 -0800 (PST) From: Melinda Shore Date: Tue, 22 Feb 2005 10:40:27 -0800 (PST) Subject: Re: [Ietf-behave] Re: adding SCTP at behave milestone In-Reply-To: <421B7B28.8030804@motorola.com> Message-ID: <2AB8CCC9-8501-11D9-8494-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Tuesday, February 22, 2005, at 01:34 PM, Qiaobing Xie wrote: " This [state sync among NATs] can only be possible if there exists some inter-NAT protocol which can provide coordination amongst the NATs when the association is set up. Further study is needed for this scenario. Yes - what I didn't like was the assumption that the NAT was the place to "fix" the problem. As to the multi-homed traversal problem, how do you want to frame it? I'd like to see the problem decomposed into its component pieces (the address use problem being distinct from the single port number problem, for example). There also needs to be more discussion of the security implications - IPSec is going to be a real problem if the NAT is going to be tinkering with chunk contents. Melinda From ssenthil@cisco.com Tue, 22 Feb 2005 20:11:07 -0800 (PST) From: Senthil Sivakumar Date: Tue, 22 Feb 2005 20:11:07 -0800 (PST) Subject: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP In-Reply-To: <20050222030742.GA14030@cs.stanford.edu> Message-ID: <4.3.2.7.2.20050222132837.03404688@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I am surprised by this parallel effort while there is another draft on TCP behavior already submitted and waiting for reviews. I am pretty sure that you are already aware of this work (since you were a co-author and decided to withdraw at the last minute). But anyway, I don't see a lot of differences in the content in this draft from the other TCP draft that I, Kaushik and Bryan had submitted. Chairs, Could you please clarify as to what is your stand on this parallel effort? Senthil At 07:07 PM 2/21/2005 -0800, nagendra modadugu wrote: I must apologize for the delayed notification about a new draft -- the draft got held up as a result of a buggy IPR statement (now fixed). The draft is a TCP counterpart to the NAT-UDP draft by Audet & Jennings. I have attempted to reproduce as little material possible from the NAT-UDP draft while following its template. As a result, this draft may be read as a "diff" to the NAT-UDP draft (though there is only one conflicting recommendation, for which see below). Some elements require expansion following further discussion (timer values for instance). The recommendation on "Port Preservation" in this draft (=RECOMMENDED) differs from the recommendation made in the NAT-UDP draft (a brief discussion on this issue is given in Section 7.1). If there is a consensus for "Port Preservation" preservation behavior, then this change ought to be folded into the NAT-UDP or protocol independent behavior drafts. nagendra -- http://www.ietf.org/internet-drafts/draft-modadugu-nat-tcp-00.txt Abstract This document specifies requirements for NAT devices when handling TCP traffic. In order to arrive at the requirements, basic terminology regarding NAT TCP handling is defined. The purpose of this document is to provide a specification of TCP handling by NAT devices so that TCP-using applications can work consistently. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From mbhatia@nextone.com Wed, 23 Feb 2005 08:29:33 -0800 (PST) From: "Medhavi Bhatia" Date: Wed, 23 Feb 2005 08:29:33 -0800 (PST) Subject: [Ietf-behave] VAD and NATs In-Reply-To: <4.3.2.7.2.20050222132837.03404688@mira-sjcd-2.cisco.com> Message-ID: <200502231629.LAA26161@leviathan.cnchost.com> MIME-Version: 1.0 Content-Type: text/plain Hi, I am trying to see what is the proposed solution for VAD (Voice Activity Detection) for NATs. I think someone at the last ietf meeting suggested endpoints should send zero-byte UDP packets and I am not sure what NATs do today for these. Also, on the codec stream side, if empty UDP packets are received on the media stream (with no RTP headers, but sent to the right UDP ports) what is the behavior. Any pointers ? Thanks, Medhavi. From wolfgang.schruefer@siemens.com Wed, 23 Feb 2005 09:24:03 -0800 (PST) From: Schruefer Wolfgang Date: Wed, 23 Feb 2005 09:24:03 -0800 (PST) Subject: RE: [Ietf-behave] Re: adding SCTP at behave milestone Message-ID: MIME-Version: 1.0 Content-Type: text/plain Couldn't it be a compromise to split Qiaobing's draft into two drafts: - a tiny one for NAT enhancements to support singly-homed SCTP associations - and the other one for the multi-homed problem I am sure there would be a big consensus about the first one and why not start to make it an WG draft on its own ...? Best regards, Wolfgang > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Qiaobing Xie > Sent: Tuesday, February 22, 2005 7:34 PM > To: Melinda Shore > Cc: 'Behave' > Subject: Re: [Ietf-behave] Re: adding SCTP at behave milestone > > Melinda, > > This is why I suggested that making it a WG item would help - > more people can read it more > carefully and contribute to its improvement. > > As to the particular issue of nat/nat protocol, you may have > mis-read the draft badly. > > I know your view on this nat/nat protocol issue (and I > dislike it too), but I have no idea > where you got the impression that the draft is proposing a > solution based on a nat/nat protocol. > > Here is the only place that topic is mentioned in the draft: > > " This [state sync among NATs] can only be > possible if there exists some inter-NAT protocol which can provide > coordination amongst the NATs when the association is set up. > Further study is needed for this scenario. > " > > As to the multi-homed traversal problem, how do you want to frame it? > > regards, > -Qiaobing > > Melinda Shore wrote: > > > On Tuesday, February 22, 2005, at 12:40 PM, Francois Audet wrote: > > > >> Isn't the solution to this really simple: > >> let people who are interested continue to work on it, > >> with the understanding that we will go to last call > >> on the other most important document first? > > > > Anybody can work on anything, obviously. Working group milestones > > are another matter, and it makes sense to be a bit conservative > > in agreeing to deliver deliverables. > > > > Also, the specific question that was posed was whether or > not to make > > Qiaobing's draft a working group document. I have nothing > but respect > > for Qiaobing's excellent work in a number of areas, but I think that > > this one draft is really not very good. I don't think the > multihomed > > traversal problem is framed very coherently and the > proposed solution > > (a nat/nat protocol) is just wrong, for reasons I've > outlined previously. > > > > Melinda > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From Qiaobing.Xie@motorola.com Wed, 23 Feb 2005 10:53:06 -0800 (PST) From: Qiaobing Xie Date: Wed, 23 Feb 2005 10:53:06 -0800 (PST) Subject: Re: [Ietf-behave] Re: adding SCTP at behave milestone In-Reply-To: <2AB8CCC9-8501-11D9-8494-000A95E35274@cisco.com> Message-ID: <421CD1C0.8070201@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Melinda Shore wrote: On Tuesday, February 22, 2005, at 01:34 PM, Qiaobing Xie wrote: " This [state sync among NATs] can only be possible if there exists some inter-NAT protocol which can provide coordination amongst the NATs when the association is set up. Further study is needed for this scenario. Yes - what I didn't like was the assumption that the NAT was the place to "fix" the problem. The quoted sentence is by no means a proposal. It merely says that if in the future such a thing becomes available (for whatever reasons), then SCTP may be able to make use of it. This sentence can be taken out without consequence. As to the multi-homed traversal problem, how do you want to frame it? I'd like to see the problem decomposed into its component pieces (the address use problem being distinct from the single port number problem, for example). A key concept must be understood when discussing SCTP and NAT issues. That is the single-point traversal vs. multi-point traversal (described in full detail in the draft). This is *not* the same as the singly-homed SCTP association vs. multi-homed association. I sense a lot of confusion between the two concepts in the present discussion. For single-point NAT traversal, the SCTP association can be either singly-homed or multi-homed. In this case, it is very *straightforward* to make SCTP work with NAT. Anyone who understands how TCP/NAT works would be able to understand how SCTP/NAT will work in this scenario. The one vendor I mentioned earlier which has commercial products deployed in a telecom environment followed this approach. However, the real problem is with the multi-point traversal case. Frankly, I don't know if there is a solution for that. I'd say, it probably should be a research topic. How many people will be pretty happy to live with only single-point traversal? I'd say probably 99% will. For the few customers requiring extremely high availability to their networks (e.g., military or 5 Nine telecom), there are alternative ways to achieve that 5 Nine, such as using a NAT built on a HA redundant platform. > There also needs to be more discussion of the security implications - IPSec is going to be a real problem if the NAT is going to be tinkering with chunk contents. Agreed. This is the same issue facing any ALGs. regards, -Qiaobing Melinda From nagendra@cs.stanford.edu Wed, 23 Feb 2005 10:56:46 -0800 (PST) From: nagendra modadugu Date: Wed, 23 Feb 2005 10:56:46 -0800 (PST) Subject: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0192407D@zrc2hxm0.corp.nortel.com> Message-ID: <20050223185642.GA22084@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Thanks for elaborating on this point. My comments inline. > The reason we came up with this requirement in the first place is because > we have noticed a lot of NATs that tried to preserve the port when not > assigned (and behaved like a Cone NAT) and then switched to not-preserved > AND to a symmetric NAT when the port was already in use. It is not > the "preservation" that was the problem, but the switching from Cone > to symmetric (non-deterministic property). > > In short, I agree with Nagendra. I'm not sure if we should recommend > port preservation, or just not recommend anything at all. I would propose > to change REQ-3 of draft-ietf-nat-behave-udp to: > > REQ-3 A NAT MUST NOT have a "Port assignment" behavior of "Port > overloading". > a) If the host's source port was in the range 1-1023, it is > RECOMMENDED the NAT's source port also be in the same > range. If the host's source port was in the range > 1024-65535, it is RECOMMENDED that the NAT's source port > also be in that range. I'm happy with the recommendation taking this form. The primary reason I could find for recommending "Port Preservation" was the transparency a low-use NAT will provide. But upon further thought, this isn't a sufficiently compelling reason for making a recommendation. As food for thought, does port preservation make traffic analysis any easier? nagendra From Qiaobing.Xie@motorola.com Wed, 23 Feb 2005 10:57:50 -0800 (PST) From: Qiaobing Xie Date: Wed, 23 Feb 2005 10:57:50 -0800 (PST) Subject: Re: [Ietf-behave] Re: adding SCTP at behave milestone In-Reply-To: Message-ID: <421CD2D5.5070507@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Wolfgang, Please see my earlier email. The key is not singly-homed or multi-homed, rather it is single-point traversal vs. multi-point traversal. The latter is the cause of all the troubles here and any discussion over it can be taken out from the draft without problem. regards, -Qiaobing Schruefer Wolfgang wrote: Couldn't it be a compromise to split Qiaobing's draft into two drafts: - a tiny one for NAT enhancements to support singly-homed SCTP associations - and the other one for the multi-homed problem I am sure there would be a big consensus about the first one and why not start to make it an WG draft on its own ...? Best regards, Wolfgang -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Qiaobing Xie Sent: Tuesday, February 22, 2005 7:34 PM To: Melinda Shore Cc: 'Behave' Subject: Re: [Ietf-behave] Re: adding SCTP at behave milestone Melinda, This is why I suggested that making it a WG item would help - more people can read it more carefully and contribute to its improvement. As to the particular issue of nat/nat protocol, you may have mis-read the draft badly. I know your view on this nat/nat protocol issue (and I dislike it too), but I have no idea where you got the impression that the draft is proposing a solution based on a nat/nat protocol. Here is the only place that topic is mentioned in the draft: " This [state sync among NATs] can only be possible if there exists some inter-NAT protocol which can provide coordination amongst the NATs when the association is set up. Further study is needed for this scenario. " As to the multi-homed traversal problem, how do you want to frame it? regards, -Qiaobing Melinda Shore wrote: On Tuesday, February 22, 2005, at 12:40 PM, Francois Audet wrote: Isn't the solution to this really simple: let people who are interested continue to work on it, with the understanding that we will go to last call on the other most important document first? Anybody can work on anything, obviously. Working group milestones are another matter, and it makes sense to be a bit conservative in agreeing to deliver deliverables. Also, the specific question that was posed was whether or not to make Qiaobing's draft a working group document. I have nothing but respect for Qiaobing's excellent work in a number of areas, but I think that this one draft is really not very good. I don't think the multihomed traversal problem is framed very coherently and the proposed solution (a nat/nat protocol) is just wrong, for reasons I've outlined previously. Melinda _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Wed, 23 Feb 2005 11:12:22 -0800 (PST) From: "Francois Audet" Date: Wed, 23 Feb 2005 11:12:22 -0800 (PST) Subject: RE: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP Message-ID: <1ECE0EB50388174790F9694F77522CCF019248A7@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP I think the key is that port preservation can not be mandated and can not be prohibited. In other words, you have to be prepared for both. This means that it is not terribly useful for traffic analysis. That's why I'm proposing what I am proposing... > -----Original Message----- > From: nagendra modadugu [mailto:nagendra@xxxxxxxxxxxxxxx] > Sent: Wednesday, February 23, 2005 10:57 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: Re: [Ietf-behave] New draft: NAT Behavioral > Requirements for TCP > > > > Thanks for elaborating on this point. My comments inline. > > > The reason we came up with this requirement in the first place is > > because we have noticed a lot of NATs that tried to > preserve the port > > when not assigned (and behaved like a Cone NAT) and then > switched to > > not-preserved AND to a symmetric NAT when the port was > already in use. > > It is not the "preservation" that was the problem, but the > switching > > from Cone to symmetric (non-deterministic property). > > > > In short, I agree with Nagendra. I'm not sure if we should recommend > > port preservation, or just not recommend anything at all. I > would propose > > to change REQ-3 of draft-ietf-nat-behave-udp to: > > > > REQ-3 A NAT MUST NOT have a "Port assignment" behavior of "Port > > overloading". > > a) If the host's source port was in the range > 1-1023, it is > > RECOMMENDED the NAT's source port also be in the same > > range. If the host's source port was in the range > > 1024-65535, it is RECOMMENDED that the NAT's > source port > > also be in that range. > > I'm happy with the recommendation taking this form. The > primary reason I could find for recommending "Port > Preservation" was the transparency a low-use NAT will > provide. But upon further thought, this isn't a sufficiently > compelling reason for making a recommendation. > > As food for thought, does port preservation make traffic > analysis any easier? > > nagendra > > From wolfgang.schruefer@siemens.com Thu, 24 Feb 2005 00:49:53 -0800 (PST) From: Schruefer Wolfgang Date: Thu, 24 Feb 2005 00:49:53 -0800 (PST) Subject: RE: [Ietf-behave] Re: adding SCTP at behave milestone Message-ID: MIME-Version: 1.0 Content-Type: text/plain Qiaobing, my point is to find the least common denominator in the discussion ... and I think that are the NAT requirements for single-homed associations. A first step could be the NAT requirements for single-homed associations. A second step could be the NAT requirements for multi-homed associations via a single-homed traversal. A third step could be the NAT requirements for multi-homed associations via a multi-homed traversal. The first step should be easy to reach because it is almost like UDP/TCP. The first step by its own could help a lot, because all SCTP based protocols would be generally enabled to pass NATs. A single path is better than no path at all ... We should not delay this milestone by the multi-homing discussion. As an example for a future usage look at the Sigtran protocol M2PA. It is designed to use SCTP. But M2PA is not reliant on multihoming, because its upper layer MTP3 does provide redundancy ... But for the second step I am afraid a lot of discussion is needed, even if there is at least one technical solution ... it is technically much more complicated than the first step ... and it should be seen in conjunctions with solutions for the third step ... Best regards, Wolfgang > -----Original Message----- > From: Qiaobing Xie [mailto:Qiaobing.Xie@xxxxxxxxxxxx] > Sent: Wednesday, February 23, 2005 8:01 PM > To: Schruefer Wolfgang > Cc: Melinda Shore; 'Behave' > Subject: Re: [Ietf-behave] Re: adding SCTP at behave milestone > > Hi, Wolfgang, > > Please see my earlier email. The key is not singly-homed or > multi-homed, rather it is > single-point traversal vs. multi-point traversal. The latter > is the cause of all the > troubles here and any discussion over it can be taken out > from the draft without problem. > > regards, > -Qiaobing > > Schruefer Wolfgang wrote: > > > Couldn't it be a compromise to split Qiaobing's draft into > two drafts: > > > > - a tiny one for NAT enhancements to support singly-homed > SCTP associations > > - and the other one for the multi-homed problem > > > > I am sure there would be a big consensus about the first > one and why not start to make it an WG draft on its own ...? > > > > Best regards, > > Wolfgang > > From Qiaobing.Xie@motorola.com Thu, 24 Feb 2005 18:01:14 -0800 (PST) From: Qiaobing Xie Date: Thu, 24 Feb 2005 18:01:14 -0800 (PST) Subject: Re: [Ietf-behave] Re: adding SCTP at behave milestone In-Reply-To: Message-ID: <421E8798.6070409@motorola.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Wolfgang, Schruefer Wolfgang wrote: Qiaobing, my point is to find the least common denominator in the discussion ... and I think that are the NAT requirements for single-homed associations. A first step could be the NAT requirements for single-homed associations. A second step could be the NAT requirements for multi-homed associations via a single-homed traversal. A third step could be the NAT requirements for multi-homed associations via a multi-homed traversal. This sounds to me a good plan. The first step should be easy to reach because it is almost like UDP/TCP. The first step by its own could help a lot, because all SCTP based protocols would be generally enabled to pass NATs. A single path is better than no path at all ... We should not delay this milestone by the multi-homing discussion. As an example for a future usage look at the Sigtran protocol M2PA. It is designed to use SCTP. But M2PA is not reliant on multihoming, because its upper layer MTP3 does provide redundancy ... Agreed. But for the second step I am afraid a lot of discussion is needed, even if there is at least one technical solution ... it is technically much more complicated than the first step ... and it should be seen in conjunctions with solutions for the third step ... Yes, the 2nd step can certainly benefit from more discussion and input from the group. But I am not sure we would want to tie it with the 3rd step. In fact I see a stronger linkage between the 2nd step and the 1st step. The 3rd step is hard and I am not sure there will ever be a solution for it in the foreseeable future. The 2nd step has very good practical value (see the example below) and we really should not deny it simply because we don't know how to do the 3rd step. ** Example of multi-homed associations via a single-point traversal: A dentist has several machines in her office which run SCTP over two redundant networks - 10.x.x.x and 196.x.x.x - since for some reason the dentist needs non-interrupt protection against network gear failures in her office. The dentist also needs to connect to outside world and she wants the same non-interrupt protection against ISP failures as well. So she signs up with 2 ADSL services from two different providers. Now the dentist gets an SCTP-enabled NAT (which supports multi-homed associations via a single-point traversal). The NAT comes with two interfaces going inside and two interfaces for external. And the dentist connects the two internal interfaces to the two local networks in her office and the two external interfaces to the two ADSLs. Now she can have multi-homed SCTP associations to the outside world through a single-point NAT traversal. In this example, even though the NAT is still a single point of failure, the dentist gets a lot of redundancy, comparing to only using single-homed SCTP assoc and one ADSL. regards, -Qiaobing Best regards, Wolfgang From wolfgang.schruefer@siemens.com Fri, 25 Feb 2005 00:42:13 -0800 (PST) From: Schruefer Wolfgang Date: Fri, 25 Feb 2005 00:42:13 -0800 (PST) Subject: RE: [Ietf-behave] Re: adding SCTP at behave milestone Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Qiaobing, I fully agree ... ... but how to proceed? ... would it help to set up seperate drafts for each step? Best regards, Wolfgang > > Hi, Wolfgang, > > Schruefer Wolfgang wrote: > > > Qiaobing, > > > > my point is to find the least common denominator in the > > discussion ... and I think that are the NAT requirements for > > single-homed associations. > > > > A first step could be the NAT requirements for single-homed > > associations. > > A second step could be the NAT requirements for multi-homed > > associations via a single-homed traversal. > > A third step could be the NAT requirements for multi-homed > > associations via a multi-homed traversal. > > This sounds to me a good plan. > > > > > The first step should be easy to reach because it is almost > > like UDP/TCP. > > The first step by its own could help a lot, because all > > SCTP based protocols would be generally enabled to pass NATs. > > A single path is better than no path at all ... We should not > > delay this milestone by the multi-homing discussion. > > > > As an example for a future usage look at the Sigtran > > protocol M2PA. It is designed to use SCTP. But M2PA is not > > reliant on multihoming, because its upper layer MTP3 does > > provide redundancy ... > > Agreed. > > > But for the second step I am afraid a lot of discussion is > > needed, even if there is at least one technical solution ... > > it is technically much more complicated than the first step > > ... and it should be seen in conjunctions with solutions for > > the third step ... > > Yes, the 2nd step can certainly benefit from more discussion > and input from the group. But I am not sure we would want to > tie it with the 3rd step. In fact I see a stronger linkage > between the 2nd step and the 1st step. The 3rd step is hard > and I am not sure there will ever be a solution for it in the > foreseeable future. > > The 2nd step has very good practical value (see the example > below) and we really should not deny it simply because we > don't know how to do the 3rd step. > > ** Example of multi-homed associations via a single-point traversal: > > A dentist has several machines in her office which run SCTP > over two redundant networks - 10.x.x.x and 196.x.x.x - since > for some reason the dentist needs non-interrupt protection > against network gear failures in her office. > > The dentist also needs to connect to outside world and she > wants the same non-interrupt protection against ISP failures > as well. So she signs up with 2 ADSL services from two > different providers. Now the dentist gets an SCTP-enabled NAT > (which supports multi-homed associations via a single-point > traversal). The NAT comes with two interfaces going inside > and two interfaces for external. And the dentist connects the > two internal interfaces to the two local networks in her > office and the two external interfaces to the two ADSLs. Now > she can have multi-homed SCTP associations to the outside > world through a single-point NAT traversal. > > In this example, even though the NAT is still a single point > of failure, the dentist gets a lot of redundancy, comparing > to only using single-homed SCTP assoc and one ADSL. > > regards, > -Qiaobing > > > > > > > Best regards, > > Wolfgang > > > > > From nagendra@cs.stanford.edu Fri, 25 Feb 2005 10:53:57 -0800 (PST) From: nagendra modadugu Date: Fri, 25 Feb 2005 10:53:57 -0800 (PST) Subject: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP In-Reply-To: <20050222030742.GA14030@cs.stanford.edu> Message-ID: <20050225185354.GA21987@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain > I am surprised by this parallel effort while there is another draft > on TCP behavior already submitted and waiting for reviews. I am > pretty sure that you are already aware of this work (since you > were a co-author and decided to withdraw at the last minute). Well, I don't think there's anything wrong in principle with multiple drafts -- and from what I hear, multiple submissions are fairly common. > But anyway, I don't see a lot of differences in the content in this > draft from the other TCP draft that I, Kaushik and Bryan had > submitted. While there are obviously a lot of technical features in common, I feel that my draft has a fairly different architectural philosophy, which, in my mind, justified a new draft. In particular, my goal is to provide the minimum number of requirements to get interoperable behavior. * First, my draft relaxes a number of technical constraints that you assumed. For instance I feel that SM=Y is superfluous. Similarly, I don't see applications running on the NAT needing special treatment with regards to port assignment (i.e. "No Port Overloading" requirement covers this case). * Second, I don't believe NAT devices should be required to implement TCP keepalive messages -- especially since this feature is easily implemented in clients and servers that may be affected by premature binding expiry. Of course, an implementor that chooses to provide this feature, or other features outside the requirements is not prevented from doing so. * Similarly, I would prefer not to require TCP stream reconstruction, as such support can easily be implemented in an ALG if required. * Finally, as an editorial matter, I have avoided discussion on protocol independent issues -- I feel that these are better dealt with in another document, either the UDP draft or Bryan's new proposal. Also, I have followed the NAT-UDP draft template for describing the requirements, isolating behavior description from requirements. Obviously, it would be possible to generate a series of deltas to turn your document into one I liked better, but I felt that at the end of the day it was cleaner to just generate the document I liked to see and then let the WG decide how best to proceed. nagendra From kbiswas@cisco.com Fri, 25 Feb 2005 18:28:20 -0800 (PST) From: Kaushik Biswas Date: Fri, 25 Feb 2005 18:28:20 -0800 (PST) Subject: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP In-Reply-To: <4.3.2.7.2.20050222132837.03404688@mira-sjcd-2.cisco.com> Message-ID: <4.3.2.7.2.20050225175128.05274008@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Well typically one is expected to give comments on an existing submission and it is discussed in the list as to whether these comments are technically reasonable. If individuals in the list upon reading a draft feels that instead of giving his/her comments on an existing draft (and getting it discussed in the alias), he/she just goes ahead and takes content from this draft and submits his own, that will lead to lots of chaos and wastage of valuable time. Think of the chaos it would have generated if individual who gave comments on the UDP draft would have instead gone ahead and submitted a new one based on that. -Kaushik At 10:53 AM 2/25/2005 -0800, nagendra modadugu wrote: > I am surprised by this parallel effort while there is another draft > on TCP behavior already submitted and waiting for reviews. I am > pretty sure that you are already aware of this work (since you > were a co-author and decided to withdraw at the last minute). Well, I don't think there's anything wrong in principle with multiple drafts -- and from what I hear, multiple submissions are fairly common. > But anyway, I don't see a lot of differences in the content in this > draft from the other TCP draft that I, Kaushik and Bryan had > submitted. While there are obviously a lot of technical features in common, I feel that my draft has a fairly different architectural philosophy, which, in my mind, justified a new draft. In particular, my goal is to provide the minimum number of requirements to get interoperable behavior. * First, my draft relaxes a number of technical constraints that you assumed. For instance I feel that SM=Y is superfluous. Similarly, I don't see applications running on the NAT needing special treatment with regards to port assignment (i.e. "No Port Overloading" requirement covers this case). * Second, I don't believe NAT devices should be required to implement TCP keepalive messages -- especially since this feature is easily implemented in clients and servers that may be affected by premature binding expiry. Of course, an implementor that chooses to provide this feature, or other features outside the requirements is not prevented from doing so. * Similarly, I would prefer not to require TCP stream reconstruction, as such support can easily be implemented in an ALG if required. * Finally, as an editorial matter, I have avoided discussion on protocol independent issues -- I feel that these are better dealt with in another document, either the UDP draft or Bryan's new proposal. Also, I have followed the NAT-UDP draft template for describing the requirements, isolating behavior description from requirements. Obviously, it would be possible to generate a series of deltas to turn your document into one I liked better, but I felt that at the end of the day it was cleaner to just generate the document I liked to see and then let the WG decide how best to proceed. nagendra _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Sat, 26 Feb 2005 14:12:42 -0800 (PST) From: Cullen Jennings Date: Sat, 26 Feb 2005 14:12:42 -0800 (PST) Subject: [Ietf-behave] multiple individual drafts on the same topic In-Reply-To: <4.3.2.7.2.20050222132837.03404688@mira-sjcd-2.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 2/22/05 7:20 PM, "Senthil Sivakumar" wrote: > > Chairs, > Could you please clarify as to what is your stand on this > parallel effort? My goal as a chair on this topic of the TCP draft is to bring the WG to consensus on what we should say about TCP and document that. Preferably sooner than later. Keep in mind this is that is is still at a somewhat early stage, a few months ago the WG was discussing if it was even interested in solving this problem of direct TCP connection between two devices that are both behind NATs. Now we are into the details of how to do it - that is all good. Sometimes a contributor can say "I think we should make this change to a draft" and the WG can debate the pro and cons to that. Other times the contributor is saying "I think of this in a different way and many changes are needed." Often in case like this, more than a 15 line email is needed. If these two drafts help the WG have something concrete to discuss about what they like or don't like about them and what changes they want, I view that as good. This is apple pie but I greatly prefer "I don't like A and I think B would be better and here is why" instead of just "I don't like A." These drafts are both individual contributions and there is nothing the chairs, IESG, or IAB could do to stop them being contributed. That said, I was aware of this draft before it was submitted and I did nothing to discourage it. If any contributor in the WG wants agenda time to stand up and explain to the group why they think B is better than A, I would prefer that B was written down in a way the WG could understand and concretely think about. Writing a draft is a mightily fine way to do that. Where will we go from here ... Well presumably these drafts will help us nail down the possibilities and what the WG wants. I expect significant discussion and closure of issues at the upcoming meeting. Once we get the bulk of these issues forming into consensus (and I hope this happens at the next meeting), I would expect to form a WG draft on this. Just to be clear - a *single* WG draft on this. There is a range of ways this could happen. I will describe what I see and the best case and worst case for the chairs. The best case for the chairs is that a group of existing authors and or other contributors to the WG come to the chairs with an excellent proposal that says haw they are going to take the input from the group, the existing documents, and form a new document that to the best of their abilities represents what the WG wants. (Oh, yah, an in the best case we get no less than 1 of these proposals and also no more than 1). The worst case for the chairs is that the chairs have to go and pick an Document Editor for the document and that editor takes the input from the WG, meetings, mailing lists, and existing documents and forms a new document to represent what the WG wants. The chairs will be listening very closely to what parts of any documents the WG wants to take forward into a WG document and will do our best to get us to something with rough consensus without excessive delay. The discussion around these individual contributions and how we figure out what we want the WG document to say is more important that the number of documents. If we needed 10 drafts to document the various views on how to do this and drive through to consensus on one draft, I'd be fine with 10 drafts. I have seen several WG where having more than one proposal has stopped endless arguments about I don't like A but have no better idea and has resulted in a better understanding of what the core issues are and the end result was a much better RFC when it was done. I've been involved in total failures where we evaluated alternative proposal until the industry had done proprietary solutions and moved so far forward that any standard was close to irrelevant because it was too late. This is not an let's for the design team to form the processes for the committee to evaluate the proposal sort of situation. We are going to take these and use them to describe what the WG wants and we are going to do it soon. Cullen with my "Chair-on-a-Rant" hat on :-) From fluffy@cisco.com Sat, 26 Feb 2005 15:09:42 -0800 (PST) From: Cullen Jennings Date: Sat, 26 Feb 2005 15:09:42 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Qiaobing, if you ever rev your draft-xie-tsvwg-sctp-nat-00 document can you please try to include this comment in. On 2/16/05 5:59 AM, "Melinda Shore" wrote: > On Wednesday, February 16, 2005, at 08:55 AM, Spencer Dawkins wrote: >> It seems to me that inserting a single point of failure, regardless of >> its reliability, into a multihoming solution isn't quite solving the >> right problem. > > This should probably be engraved somewhere for posterity. > > Melinda From fluffy@cisco.com Sat, 26 Feb 2005 15:11:07 -0800 (PST) From: Cullen Jennings Date: Sat, 26 Feb 2005 15:11:07 -0800 (PST) Subject: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP In-Reply-To: <4213B508.8090305@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 2/16/05 1:03 PM, "Qiaobing Xie" wrote: >> It seems to me that inserting a single point of failure, regardless of >> its reliability, into a multihoming solution isn't quite solving the >> right problem. > > You are absolutely right and this is noted in the draft. Sorry for my previous message - I missed this when I read the draft. From fluffy@cisco.com Sat, 26 Feb 2005 21:14:30 -0800 (PST) From: Cullen Jennings Date: Sat, 26 Feb 2005 21:14:30 -0800 (PST) Subject: [Ietf-behave] Draft #1 of the agenda for IETF 62 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hello all, The chairs are still working on the agenda but we were thinking something along the following lines. Look like a reasonable starting point? It is arranged around concentrating more time on finishing our earlier milestones and then less time to deal with things that are further out. We will refine this somewhat but just wanted to get a feel if there was any big topics we are omitting. The reading list should not get larger than this and it might get smaller as we figure out exact presenters and timing. Behavior Engineering for Hindrance Avoidance (BEHAVE) MONDAY, March 7, 2005 at 0900-1130 ================================== Chairs: Jiri Kuthan Cullen Jennings Agenda draft #1: 9:00 Agenda Bashing Chairs 9:05 Unicast UDP draft-ietf-behave-nat-udp-00 9:35 Multicast UDP draft-wing-behave-multicast-00 (may drop next item) 9:50 STUN revisions draft-ietf-behave-rfc3489bis-01 (not requested) 10:00 BCP For Black Box Testing Chairs 10:05 Testing Results http://nutss.gforge.cis.cornell.edu/stunt-client.php http://bgp.lcs.mit.edu/~dga/view.cgi draft-jennings-behave-test-results-00 10:15 TCP behavior draft-sivakumar-behave-nat-tcp-req-00 draft-modadugu-nat-tcp-00 11:00 BCP for design techniques draft-ford-behave-app-00 draft-ford-behave-top-00 Time Permitting draft-ford-behave-gen-00 draft-srisuresh-behave-p2p-state-00 Mail Archive: http://list.sipfoundry.org/archive/ietf-behave From srisuresh@yahoo.com Sun, 27 Feb 2005 07:56:12 -0800 (PST) From: Pyda Srisuresh Date: Sun, 27 Feb 2005 07:56:12 -0800 (PST) Subject: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP In-Reply-To: <20050225185354.GA21987@cs.stanford.edu> Message-ID: <20050227155611.88121.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Nagendra, Please see my comments inline. cheers, suresh --- nagendra modadugu wrote: > > > I am surprised by this parallel effort while there is another draft > > on TCP behavior already submitted and waiting for reviews. I am > > pretty sure that you are already aware of this work (since you > > were a co-author and decided to withdraw at the last minute). > > Well, I don't think there's anything wrong in principle with > multiple drafts -- and from what I hear, multiple submissions > are fairly common. > [suresh] Agree, there can be multiple drafts on the same topic. But, the WG adopts just one in the end as WG draft. > > But anyway, I don't see a lot of differences in the content in this > > draft from the other TCP draft that I, Kaushik and Bryan had > > submitted. > > While there are obviously a lot of technical features in common, I feel > that my draft has a fairly different architectural philosophy, which, in > my mind, justified a new draft. In particular, my goal is to > provide the minimum number of requirements to get interoperable > behavior. > [suresh] Having a small no. of requirements doesnt in itself constitute a reason to have a different draft. I am all in favor of being crisp about requirements. Sometimes, it is reasonable to elaborate on a sibject to ensure that the requirement(s) is well understood. In any case, I donot see this as a big issue. As for the architectural philosophy - Are you referign to the architeture of a NAT device, or, the architecture of the drafts? I assume, you are referring to the latter, not the former. draft-ford-gen covers the general NAT architecture, common terminology etc.. I believe, TCP-behave and UDP-behave drafts should focus on the nuances as pertaining the TCP & UDP flows. > * First, my draft relaxes a number of technical constraints that > you assumed. For instance I feel that SM=Y is superfluous. [suresh] I do think, it is importsnt to state that a NAT maintain a light-weight state for TCP NAT-sessions. This is further explained later in conjunction with the timers and TCP states themselves. Unlike UDP, the stateful nature of TCP calls for this recommendation. This is also the reason why TCP NAT-sessions are not aggregated with wild-card ports, unlike UDP NAT-sessions. Given this, Why do you consider it superfluous to state SM=Yes? > Similarly, I don't see applications running on the NAT needing > special treatment with regards to port assignment (i.e. "No Port > Overloading" requirement covers this case). [suresh] I dont see what the point of contention here is. Sivakumar's draft recommends NAT implementors to set aside non-overlapping port blocks a) for its own end-host usage purposes, and b) for NAT functional use. I do like this recommendation. Many commercial boxes loose this distinction and mess themselves. So, I think it is useful to have this. Are you saying it is not necessary to state this in the TCP-behave draft? My prefernce would be to move this recommendation to behave-gen draft - because this is not TCP or UDP specific. I donot see the term "port overloading" used in Sivakumar's draft. However, I do see him refering to "port binding". I suspect, what you refer to as "not overloading a port" is same as mainining "port binding". My personal preference is to stick to the term "port binding" (TCP or UDP) and use that. The terms "address Binding" and "Port Binding" have been in use in the past and I woudl suggest reusing these terms in this WG. This is touched upon quite extensively in ford-behave-gen draft. I believe, both you and Sivakumar are recommending that NATs MUST maintain TCP port bindings. This, I believe, is the most important of all the resommendations this WG can make - for TCP as well as for UDP. > > * Second, I don't believe NAT devices should be required to > implement TCP keepalive messages -- especially since this feature [suresh] I agree. > is easily implemented in clients and servers that may be affected > by premature binding expiry. Of course, an implementor that chooses [suresh] I donot understand what you say about "premature binding expiry". How does implementing TCP keepalives result in premature binding expiry? What did you mean by "premature binding expiry" and how are clients/servers effected by this? > to provide this feature, or other features outside the requirements > is not prevented from doing so. [suresh] I am not in favor of NAT devices doing the keep-alives either. Clearly, there are some benefits to the NAT devices doing this. We should seek input from the list on this. Folks on the list may have differing opinions. However, I dont believe, this is a cause enough to diagree working on a single draft. > > * Similarly, I would prefer not to require TCP stream reconstruction, > as such support can easily be implemented in an ALG if required. > [suresh] I believe, fragmentation handling, as a whole, belongs in portocol-independent general behavior draft (ex: ford-behave-gen) - Not TCP or UDP behave drafts. I agree, the sivakumar draft can do with some rework in this area. I sent the authors some comments already on this. > * Finally, as an editorial matter, I have avoided discussion on protocol > independent issues -- I feel that these are better dealt with in > another document, either the UDP draft or Bryan's new proposal. > Also, I have followed the NAT-UDP draft template for describing the > requirements, isolating behavior description from requirements. > [suresh] There is no template per se to describe the recommendations. UDP-Behave draft just happens to be the first draft adopted by the WG. We are still at an infancy stage in this WG - We still need to work out which recommendations go in what draft (gen-behave, TCP-behave, UDP-behave)and what are the terms to use across the drafts etc. > Obviously, it would be possible to generate a series of deltas to > turn your document into one I liked better, but I felt that at > the end of the day it was cleaner to just generate the document > I liked to see and then let the WG decide how best to proceed. > [suresh] I disagree with your above comment. From what I can tell, there is a difference in style between the two drafts - listing the requirements in one-place, followed by discussion vs the requirements collected through discussion (and I suspect, Sivakumar meant to summarize the requirements in the end). We can poll the WG to see which style they pefer. My own preference is for the latter. The eventual TCP-Behave draft should adapt whichever style the WG prefers to go with. In summary, I believe, there is much to be gained by your working with the authors of sivakumar draft than otherwise. Thats my 2c. > nagendra > cheers, suresh ===== From srisuresh@yahoo.com Sun, 27 Feb 2005 08:49:15 -0800 (PST) From: Pyda Srisuresh Date: Sun, 27 Feb 2005 08:49:15 -0800 (PST) Subject: Re: [Ietf-behave] Draft #1 of the agenda for IETF 62 In-Reply-To: Message-ID: <20050227164914.47216.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen & Jiri, I believe, draft-ford-behave-gen should not be left to the end on a time-permitting basis. This, in my mind, is a key draft that lays the foundation for general NAT design principles independent of TCP/UDP and the terms used across all behave drafts. As such this should be given a higher priority and covered early on in the list. Thanks. regards, suresh --- Cullen Jennings wrote: > > Hello all, > > The chairs are still working on the agenda but we were thinking something > along the following lines. Look like a reasonable starting point? It is > arranged around concentrating more time on finishing our earlier milestones > and then less time to deal with things that are further out. We will refine > this somewhat but just wanted to get a feel if there was any big topics we > are omitting. The reading list should not get larger than this and it might > get smaller as we figure out exact presenters and timing. > > > Behavior Engineering for Hindrance Avoidance (BEHAVE) > > > MONDAY, March 7, 2005 at 0900-1130 > ================================== > > > Chairs: > Jiri Kuthan > Cullen Jennings > > > Agenda draft #1: > 9:00 Agenda Bashing > Chairs > > 9:05 Unicast UDP > draft-ietf-behave-nat-udp-00 > > 9:35 Multicast UDP > draft-wing-behave-multicast-00 > > (may drop next item) > 9:50 STUN revisions > draft-ietf-behave-rfc3489bis-01 (not requested) > > 10:00 BCP For Black Box Testing > Chairs > > 10:05 Testing Results > http://nutss.gforge.cis.cornell.edu/stunt-client.php > http://bgp.lcs.mit.edu/~dga/view.cgi > draft-jennings-behave-test-results-00 > > 10:15 TCP behavior > draft-sivakumar-behave-nat-tcp-req-00 > draft-modadugu-nat-tcp-00 > > 11:00 BCP for design techniques > draft-ford-behave-app-00 > draft-ford-behave-top-00 > > Time Permitting > draft-ford-behave-gen-00 > draft-srisuresh-behave-p2p-state-00 > > > Mail Archive: http://list.sipfoundry.org/archive/ietf-behave > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > ===== From baford@mit.edu Mon, 28 Feb 2005 04:42:03 -0800 (PST) From: Bryan Ford Date: Mon, 28 Feb 2005 04:42:03 -0800 (PST) Subject: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP In-Reply-To: <20050222030742.GA14030@cs.stanford.edu> Message-ID: <200502281342.00407.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Hi Nagendra, I wanted to address one of the specific technical concerns you brought up about the difference between your TCP draft and ours. (Suresh's comments already adequately express my thouths regarding the others.) On Friday 25 February 2005 19:53, nagendra modadugu wrote: > While there are obviously a lot of technical features in common, I feel > that my draft has a fairly different architectural philosophy, which, in > my mind, justified a new draft. In particular, my goal is to > provide the minimum number of requirements to get interoperable > behavior. > [...] > * Second, I don't believe NAT devices should be required to > implement TCP keepalive messages -- especially since this feature > is easily implemented in clients and servers that may be affected > by premature binding expiry. Of course, an implementor that chooses > to provide this feature, or other features outside the requirements > is not prevented from doing so. I think this issue concerns some text I contributed to this draft, and which probably indeed at least needs to be clarified in the text and perhaps hashed out some more on the list. Our draft does NOT require, or even try to suggest, that NATs send TCP keep-alives in order to keep TCP connections open (which is usually what TCP keep-alives are for, of course). The draft DOES suggest (but does NOT require) that NATs may use TCP keep-alive packets as a way to "probe" an idle TCP connection whose session timer has expired and which the NAT is about to delete. Just to be perfectly clear: there is NO suggestion that NATs should ever "keep a TCP session alive" by sending keep-alives. The suggestion is only that NATs can use "packets that look like TCP keep-alives" in order to "probe" an idle session just before deleting it, giving the endpoints one last chance to indicate that the connection is still alive. The specific relevant text from section 3.3 of draft-sivakumar-behave-nat-tcp-req-00 is as follows: When the NAT's session timer expires, it SHOULD NOT immediately delete its database entry for the session, since TCP sessions are legitimately allowed to go idle for arbitrary lengths of time with no exchanged traffic. Instead, the NAT SHOULD enter a special "probe" state, in which it sends TCP keep-alive packets to the internal endpoint, using the technique described in section 4.2.3.6 of [HOST], in order to detect whether the internal endpoint still considers the connection to be open. If the NAT receives an ACK or other traffic from the internal endpoint, it resets the session timer and re-enters the "active" state. If the NAT receives a RST from the internal endpoint, it enters the "closed" state and starts the close timer as described below. If the NAT receives no response from the internal endpoint after sending several keep-alive packets, the NAT assumes that the internal endpoint is dead and again enters the "closed" state. Note that the above paragraph contains no MUSTs - this is merely "recommended", not "required" behavior. By implementing this recommended behavior, the NAT basically gives the endpoints "one last chance" to indicate that a long-idle TCP session is still in use before deleting it. The beneficial effect of this behavior is that it enables the NAT to preserve the traditional semantics of TCP more fully, in which TCP sessions can legitimately go idle for absolutely arbitrary lengths of time without being disconnected. The purpose of this WG is to help evolve NATs to be less intrusive to applications, and this is one way they can do so fairly easily. I did not write this recommendation as a MUST, however, because this behavior does add a bit more complexity to the NAT's TCP state machine, and it is not difficult for "NAT-aware" applications to send "real" keep-alives if they need to hold idle sessions open for long periods. On the other hand, use of TCP keep-alives by applications has historically been discouraged (e.g., see section 4.2.3.6 of RFC 1122), and it would seem we should at least do what we can to minimize the need for them. A few paragraphs farther down in our draft there is a paragraph discussing recommendations for particular timeout values related to this issue: A NAT MUST have a session timeout. The NAT's session timat minimum eout MUST be configurable. The session timeout MUST by default be at least 60 minutes if the NAT uses TCP keep-alives to probe the session after the session timeout expires, and the session timeout MUST by default be atleast 120 minutes if the NAT just silently deletes the database entry for the session after the session timeout expires. The specific timeout values recommended here were thrown into the draft at the last minute basically because we needed to propose _some_ specific numbers as a starting point, but the numbers in the above paragraph don't actually reflect my original intention when writing the text related to TCP session "probes". My intention was actually that the second number - the one that applies if the NAT just silently deletes idle TCP connections without probing them - should be MUCH, MUCH larger than the one that applies if the NAT knows how to probe idle TCP connections to see if they are actually still alive. For example, the minimum session timeout might be 60 minutes if the NAT can probe the connection, but the minimum session timeout might be 12-24 HOURS if the NAT just silently deletes apparently-idle TCP connections without probing them first. This gives NAT implementors at least two good options for preserving the traditional "semantic persistence" of TCP connections: either implement a fairly trivial TCP state machine but have a very generous session timeout, or implement a somewhat smarter TCP state machine and be able to reclaim translation state for idle TCP sessions much more quickly. I probably did not adequately explain the reasoning that went into this part of the draft before now, but hopefully the above will make it clearer. Further comments and discussion on this topic is welcome of course. Thanks, Bryan From baford@mit.edu Mon, 28 Feb 2005 04:48:23 -0800 (PST) From: Bryan Ford Date: Mon, 28 Feb 2005 04:48:23 -0800 (PST) Subject: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP In-Reply-To: <20050227155611.88121.qmail@web40425.mail.yahoo.com> Message-ID: <200502281348.20568.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Hi Nagendra, I agree with Suresh's comments below on the "multiple drafts" issue, and in particular I agree that while there's nothing wrong with having two drafts to work from, in this case the technical differences between the two drafts seem to be minor enough that it should be easy to resolve them by discussion on a case-by-case basis. I, at least, found it much easier to learn what the important differences are in your draft from reading the summary of those differences you posted to the mailing list, than from reading the draft itself. (I guess, like most everyone else, I'm just lazy and want to be spoon-fed: just tell me what the important issues are, rather than making me go figure them out for myself. :) ) But with that said, now that the important issues are on the table, I think we're moving forward just fine. A few more minor comments inline below, and one larger one in a separate message... On Sunday 27 February 2005 16:56, Pyda Srisuresh wrote: > Nagendra, > > Please see my comments inline. > > cheers, > suresh > > --- nagendra modadugu wrote: > > > I am surprised by this parallel effort while there is another draft > > > on TCP behavior already submitted and waiting for reviews. I am > > > pretty sure that you are already aware of this work (since you > > > were a co-author and decided to withdraw at the last minute). > > > > Well, I don't think there's anything wrong in principle with > > multiple drafts -- and from what I hear, multiple submissions > > are fairly common. > > [suresh] Agree, there can be multiple drafts on the same topic. But, the WG > adopts just one in the end as WG draft. > > > > But anyway, I don't see a lot of differences in the content in this > > > draft from the other TCP draft that I, Kaushik and Bryan had > > > submitted. > > > > While there are obviously a lot of technical features in common, I feel > > that my draft has a fairly different architectural philosophy, which, in > > my mind, justified a new draft. In particular, my goal is to > > provide the minimum number of requirements to get interoperable > > behavior. > > [suresh] Having a small no. of requirements doesnt in itself constitute a > reason to have a different draft. I am all in favor of being crisp about > requirements. Sometimes, it is reasonable to elaborate on a sibject to > ensure that the requirement(s) is well understood. In any case, I donot see > this as a big issue. > > As for the architectural philosophy - Are you referign to the architeture > of a NAT device, or, the architecture of the drafts? I assume, you are > referring to the latter, not the former. draft-ford-gen covers the general > NAT architecture, common terminology etc.. I believe, TCP-behave and > UDP-behave drafts should focus on the nuances as pertaining the TCP & UDP > flows. > > > * First, my draft relaxes a number of technical constraints that > > you assumed. For instance I feel that SM=Y is superfluous. > > [suresh] I do think, it is importsnt to state that a NAT maintain a > light-weight state for TCP NAT-sessions. This is further explained later in > conjunction with the timers and TCP states themselves. Unlike UDP, the > stateful nature of TCP calls for this recommendation. This is also the > reason why TCP NAT-sessions are not aggregated with wild-card ports, unlike > UDP NAT-sessions. Given this, Why do you consider it superfluous to state > SM=Yes? Agree with Suresh. > > Similarly, I don't see applications running on the NAT needing > > special treatment with regards to port assignment (i.e. "No Port > > Overloading" requirement covers this case). > > [suresh] I dont see what the point of contention here is. Sivakumar's draft > recommends NAT implementors to set aside non-overlapping port blocks a) for > its own end-host usage purposes, and b) for NAT functional use. I do like > this recommendation. Many commercial boxes loose this distinction and mess > themselves. So, I think it is useful to have this. Are you saying it is not > necessary to state this in the TCP-behave draft? My prefernce would be to > move this recommendation to behave-gen draft - because this is not TCP or > UDP specific. > > I donot see the term "port overloading" used in Sivakumar's draft. However, > I do see him refering to "port binding". I suspect, what you refer to as > "not overloading a port" is same as mainining "port binding". My personal > preference is to stick to the term "port binding" (TCP or UDP) and use > that. The terms "address Binding" and "Port Binding" have been in use in > the past and I woudl suggest reusing these terms in this WG. This is > touched upon quite extensively in ford-behave-gen draft. > > I believe, both you and Sivakumar are recommending that NATs MUST maintain > TCP port bindings. This, I believe, is the most important of all the > resommendations this WG can make - for TCP as well as for UDP. 100% agree with Suresh. > > * Second, I don't believe NAT devices should be required to > > implement TCP keepalive messages -- especially since this feature > > [suresh] I agree. > > > is easily implemented in clients and servers that may be affected > > by premature binding expiry. Of course, an implementor that chooses > > [suresh] I donot understand what you say about "premature binding expiry". > How does implementing TCP keepalives result in premature binding expiry? > What did you mean by "premature binding expiry" and how are clients/servers > effected by this? > > > to provide this feature, or other features outside the requirements > > is not prevented from doing so. > > [suresh] I am not in favor of NAT devices doing the keep-alives either. > Clearly, there are some benefits to the NAT devices doing this. We should > seek input from the list on this. Folks on the list may have differing > opinions. > > However, I dont believe, this is a cause enough to diagree working on a > single draft. Please see my separate message to the BEHAVE list regarding this issue. > > * Similarly, I would prefer not to require TCP stream reconstruction, > > as such support can easily be implemented in an ALG if required. > > [suresh] I believe, fragmentation handling, as a whole, belongs in > portocol-independent general behavior draft (ex: ford-behave-gen) - Not TCP > or UDP behave drafts. > > I agree, the sivakumar draft can do with some rework in this area. I sent > the authors some comments already on this. Agree with Suresh. > > * Finally, as an editorial matter, I have avoided discussion on protocol > > independent issues -- I feel that these are better dealt with in > > another document, either the UDP draft or Bryan's new proposal. > > Also, I have followed the NAT-UDP draft template for describing the > > requirements, isolating behavior description from requirements. > > [suresh] There is no template per se to describe the recommendations. > UDP-Behave draft just happens to be the first draft adopted by the WG. We > are still at an infancy stage in this WG - We still need to work out which > recommendations go in what draft (gen-behave, TCP-behave, UDP-behave)and > what are the terms to use across the drafts etc. Agree fully with both Nagendra and Suresh: any protocol-independent issues remaining in the TCP draft should be moved to gen-behave. > > Obviously, it would be possible to generate a series of deltas to > > turn your document into one I liked better, but I felt that at > > the end of the day it was cleaner to just generate the document > > I liked to see and then let the WG decide how best to proceed. > > [suresh] I disagree with your above comment. From what I can tell, there is > a difference in style between the two drafts - listing the requirements in > one-place, followed by discussion vs the requirements collected through > discussion (and I suspect, Sivakumar meant to summarize the requirements in > the end). We can poll the WG to see which style they pefer. My own > preference is for the latter. The eventual TCP-Behave draft should adapt > whichever style the WG prefers to go with. My preference is to list the recommendations both in-line as part of the discussion, and separately in a concise summary at the end. That's what we did in gen-behave anyway. But that's just my $.02; as Suresh says, I'll go with whichever style the WG prefers. Cheers, Bryan From baford@mit.edu Mon, 28 Feb 2005 07:08:48 -0800 (PST) From: Bryan Ford Date: Mon, 28 Feb 2005 07:08:48 -0800 (PST) Subject: Re: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: Message-ID: <200502281608.44581.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Just a quick comment on an earlier part of the UDP unicast discussion, which I'm just now trying to catch up with... :) On Wednesday 20 October 2004 21:02, Dan Wing wrote: > > >All of the R-Services (rlogin, rsh, rexec, rwho) run over TCP, though, > > >don't they? So I believe they're out of scope for this document. > > > > Yes you are right most of them are TCP based, but the point I am > > trying to make is that there are weird behaving applications like these > > that existed for a long time that may not work with the proposed > > behavior. > > > > >Other than NFS's and RPC's similar reliance on ports < 1024, I'm not > > >aware of any UDP-based application that expects the UDP source port to > > >be < 1024. > > > > Me neither, at this time. > > Okay, I see your point. > > It agree it might be useful to encourage NATs to preserve the source UDP > port if it's below 1024, just in the event there are non-standard > applications that use this as a (weak) distributed authentication > mechanism. > > At the same time, it would be good to encourage UDP applications to > quit doing this stuff. However, that pedagogy around application > design probably doesn't belong in -ietf-behave-nat-. True. This pedagogy belongs in -behave-app-, and I've made a note to add some mention of this in the next rev of draft-ford-behave-app-??.txt. Perhaps as part of a slightly longer discussion of how apps can properly secure cross-NAT connections including those created by hole punching. Also... On Tuesday 26 October 2004 08:31, Dan Wing wrote: > BEHAVE needs a "how a UDP application can use a BEHAVE-capable NAT" > document, which would provide guidance. For example, it could explain > things such as: > > - use symmetric UDP behavior (for RTP applications, this would be > draft-wing-mmusic-symmetric-rtprtcp-01). > - use RFC3605 ("Real Time Control Protocol (RTCP) attribute in Session > Description Protocol (SDP)") > - keep NAT bindings alive by sending UDP messages from inside-to- > outside > - learn public NAT bindings using STUN > - know when STUN isn't necessary (for example, many folks think > STUN is necessary for SIP signaling itself, but STUN is for the > media stream). > - leak RTP and RTCP packets early (either RTP No-Op packets, silence > packets, STUN packets to the peer, STUN packets to the STUN server) > - when on hold or silence suppression, leak media to keep NAT > binding open > > many of these apply to VoIP applications, but many also apply to any > other application behind a BEHAVE NAT that wants to use UDP as its > transport. Yes - excellent list; I've copied it into my "to-do" notes for draft-ford-behave-app-??.txt, to work on when I have the time. (Text suggestions from you or others is welcome, of course.) > I would like to see such a document added to the WG's agenda. I've been assuming that this topic is more-or-less covered by this existing WG item: Dec 05 Produce a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches ...or is this different from what you had in mind? Cheers, Bryan From baford@mit.edu Mon, 28 Feb 2005 07:14:33 -0800 (PST) From: Bryan Ford Date: Mon, 28 Feb 2005 07:14:33 -0800 (PST) Subject: Re: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <4.3.2.7.2.20041020172354.02460a88@mira-sjcd-3.cisco.com> Message-ID: <200502281614.30810.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 21 October 2004 02:50, Kaushik Biswas wrote: > In addition, couple of points: > > (1) Why should hairpinning be a must: > REQ-9: A NAT MUST support "Hairpinning" behavior. Hairpinning allows two > endpoints on the internal side of the NAT to communicate even if they only > use each other's external IP addresses and ports. > > This may be a nice-to-have support in a NAT, but why should it be a must. > > The inside host A should be trying to reach the inside host B, via the > private-address and not via the NAT'd address of B. Why come through NAT > and add an extra-hit in processing-time. Because that optimization is only possible with single-level NAT. Without hairpinning support, hole punching is not possible at all under increasingly-common multi-level NAT scenarios in which the endpoints share one level of NAT but reside behind two different "second-level" NATs. This issue is discussed more extensively in draft-ford-behave-top-00.txt (Section 2) and draft-ford-behave-gen-00.txt (Section 6). Cheers, Bryan From baford@mit.edu Mon, 28 Feb 2005 08:07:16 -0800 (PST) From: Bryan Ford Date: Mon, 28 Feb 2005 08:07:16 -0800 (PST) Subject: Re: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: Message-ID: <200502281707.11805.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 26 October 2004 10:38, Robert Sanders wrote: > Dan Wing wrote: > >BEHAVE needs a "how a UDP application can use a BEHAVE-capable NAT" > >document, which would provide guidance. > > If this usage differs from how the UDP application might use a > non-BEHAVE-capable NAT, or from the scenarios described in > draft-ietf-sipping-nat-scenarios et cetera, it would also be useful to > show how an application might *detect* a well-BEHAVEd NAT. I'm not at all sure that such detection is really necessary: for the most part I think we should just be recommending that apps assume that NATs are well-BEHAVEd going forward, and perhaps make a few specific exceptions as necessary to account for particularly common forms of "bad" legacy behavior. On the other hand, if it is useful for applications to be able to distinguish reliably between BEHAVE NATs and non-BEHAVE NATs, then I can think of at least one relatively simple technical solution to this problem, which would operate completely "in-band" and is both transport-independent and require no explicit communication with NAT (e.g., MIDCOM, NSIS, etc.). Basically, we could define a new IP header option, which applications can attach to the initial packets in a new transport session they're establishing if desired. The application places in this IP option a copy of its source IP address and transport-level port number. Non-BEHAVE NATs will (hopefully) just ignore this option, translating only the IP address and port number in the main IP/TCP/UDP headers. BEHAVE NATs would first compare the address/port in the option against the address/port in the main headers, translate the option too if they match, and zero or remove the option if they don't match. The application at the receiving end can then determine what's on the path as follows: 1. If the IP option was preserved and has the same address/port as in the main IP/TCP/UDP headers, then ALL of the NATs in the path (if any) are well-BEHAVEd. 2. If the IP option disappeared or arrived with an address/port number that doesn't match the info in the main IP/TCP/UDP headers, then there is at least one NAT in the path that is not BEHAVE-compliant. A variant of this idea was discussed in one of the early P2P-over-NAT drafts I wrote with Pyda Srisuresh, draft-ford-midcom-p2p-00.txt. Anyway, to reiterate what I said above, I'm not at all convinced that "well-BEHAVEd NAT detection" is really necessary or even a good idea, but I at least wanted to lay this option on the table in case it seems useful. > I know that NAT type detection has been deprecated in RFC3489bis, and > that the problem of detection has become more complex than originally > estimated. Requiring more than one internal IP address to fully > disambiguate the behavior of "non-deterministic" NATs is problematic. > So perhaps precise detection is not feasible in many cases. > > The question I have is whether the purpose of BEHAVE is to specify an > ideal NAT's behavior and then to provide usage guidelines for > applications working through a compliant set of NATs, or to recommend > NAT behaviors that increase the efficiency or reliability of existing > techniques. If it's the latter case then BEHAVE shouldn't need its own > usage document. Any application which wishes to function through non > well-BEHAVEd NATs, or through non-traditional NAT scenarios such as > twice NAT, couldn't limit itself to techniques dependent upon BEHAVE > compliance. I think the purpose of BEHAVE is some combination of these goals. We need to specify "ideal NAT behavior" strongly and coherently enough so that applications have a definite, practical design path they can take and be certain of working reliably over future BEHAVE-compliant NATs in all typical deployment scenarios. At the same time, it is important that this "ideal NAT behavior" be consistent and compatible with existing widespread techniques whenever possible. Ultimately, we have to live with the fact that with legacy NATs, all bets are off - applications may or may not work, and there's no way an application can make itself 100% reliable with existing NATs, so that cannot be our goal. But our goal can be to make sure that future applications can be (at least pretty darn close to) 100% reliable with future BEHAVE-compliant NATs; that should be our goal. And to do that it's clearly important for us to specify exactly how applications can best take advantage of the more predictable behavior of well-BEHAVEd NATs. Cheers, Bryan From dwing@cisco.com Mon, 28 Feb 2005 08:19:01 -0800 (PST) From: Dan Wing Date: Mon, 28 Feb 2005 08:19:01 -0800 (PST) Subject: Re: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: Message-ID: <754E8FE0-89A4-11D9-B4E5-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Feb 28, 2005, at 7:08 AM, Bryan Ford wrote: ... I would like to see such a document added to the WG's agenda. I've been assuming that this topic is more-or-less covered by this existing WG item: Dec 05 Produce a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches ...or is this different from what you had in mind? Same thing. -d From ssenthil@cisco.com Mon, 28 Feb 2005 15:34:32 -0800 (PST) From: Senthil Sivakumar Date: Mon, 28 Feb 2005 15:34:32 -0800 (PST) Subject: Re: [Ietf-behave] New drafts In-Reply-To: <200502171727.54140.baford@mit.edu> Message-ID: <4.3.2.7.2.20050228130017.01cf9d38@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I think this is an useful effort mainly because a lot of port and address binding behavior is common to both TCP and UDP. We realized this when writing our TCP draft and hence there are a lot of references to unicast UDP draft. Having a generic draft that addresses the common requirements to both TCP and UDP is good. Some comments on the specifics. Some comments. Section 1.1 Applicability statement. The paragraph "Many enterprise NATs have special requirements for security, multihoming and so forth, which may impose restrictions on the NAT's behavior. Such extra requirements are outside the scope of this..." I would suggest that removing this paragraph since it suggests that this draft recommends certain requirements that may not fit into enterprise NAT requirements, but I didnt see anything specific that would prevent enterprise networks from adopting this draft as a general behavior.. Address Maps Table: The "Address Maps" table represents the NAT's static configuration database, which is controlled more-or-less directly by the user or network administrator. The Address Maps table determines the type of NAT functionality the device implements, for example, such as Basic NAT, NAPT, Bidirectional NAT, Twice-NAT, or a combination thereof. The Address Maps table also contains any permanent mappings the user may have configured between IP addresses or endpoints on the External and Internal realms: for example, a mapping between port 80 on the NAT's public IP address and a particular Web server located on the internal network. I think the name Address maps table should be changed to Static map table. This would include, 1. Static Address bindings. 2. Static port bindings. 3. Static port to application mapping (for example look for FTP in a port number other than 21, say 2021). 4. Table that holds information on ALGs turned on by network admin. I am a little unclear on this para "One possible design approach that is specifically forbidden, however, is to use IP-level or higher-level packet contents to distinguish between ..." as to why you particularly forbid doing NAT based on IP addresses. How do you expect NAT to happen in one-armed routing case, where there is only one physical interface (There may be a logical port though).. Also, when you say an internal and external interface is identified below IP layer, how do you classify the explicitly classified ports as internal and external? Also, after classifying the ports/interfaces as internal and external, is it ok to now to make a decision to NAT only based on IP address. I think this is a crucial feature that a lot of people are using today and I don't see any reason why it should be forbidden. Also, as long as a NAT has intelligence to clearly identify the internal and external realms, why should we force a restriction? REQ-2 should also include ICMP in addition to the other protocols mentioned. Even though it does not fall into the transport protocols category it is an integral part of any NAT implementation. If you think we want to keep it separately that is fine too.. Minor one. Why is REQ-4 RECOMMENDED but not a MUST. I think it should be a must because with the non-paired source address causes inconsistent behavior of NATs arbitrarily assigning addresses. DHCP configured NATs. I think this section is beyond just DHCP, because other mechanisms like dial up can be used to obtain the upstream IP address. Also this should be beyond the scope of this document, IMO. We should just state that it is the responsibility of the admin to make sure they avoid mis-configurations of NAT. I suggest the REQs 8 & 9 be removed but stated as general recommendations but not as NAT requirements. The reason is it is beyond NAT and involves other protocols such as DHCP but not limited to DHCP alone.. Thanks Senthil At 05:27 PM 2/17/2005 +0100, Bryan Ford wrote: Hi folks, If you don't mind me interrupting the SCTP debate, there are three new BEHAVE-related drafts available at the ietf's Internet-Drafts archive. Unfortunately the IETF Secratariat may not forward the "official" availability announcement to this list because I forgot to ask them to in my submission. :( The first one is as follows; I'll announce the others in separate messages... "Design Principles and General Behavioral Requirements for Network Address Translators (BEH-GEN)" http://www.ietf.org/internet-drafts/draft-ford-behave-gen-00.txt Abstract: This document discusses design principles and behavioral properties required to make Network Address Translators (NAT) more predictable and compatible with diverse application protocols. First, this document presents a concrete architectural model for NAT devices and defines important terms used in conjunction with NAT design. This architectural model sets the stage for a set of concrete recommendations for NAT implementors and vendors, as being contemplated by the BEHAVE working group. The recommendations made by this document are independent of transport protocol; a set of companion documents provide behavioral recommendations specific to particular transport protocols. The intent of this draft is to fill the current "gap" between the current UDP behavior draft (draft-ietf-behave-nat-udp-00.txt) and the preliminary TCP draft (draft-sivakumar-behave-nat-tcp-req-00.txt), by defining general principles, terminology, and specific NAT behavioral requirements that are transport-independent or at least common to both TCP and UDP. At the moment the initial TCP draft is having to make awkward cross-references to parts of the UDP draft to talk about such common behavioral requirements, making it unclear precisely what parts of the UDP document are also supposed to apply to TCP and what parts are not. And there's currently no place at all for requirements like, "NATs MUST support both TCP and UDP". To fix these problems, I've taken the transport-independent portions of the UDP document, and transplanted them (with considerable editing) into this new "general principles" draft, along with some new content that hasn't appeared yet in either draft. The intent is that the transplanted sections from the original UDP draft can then be removed or trimmed drastically, and both the UDP and TCP documents can simply refer to the common transport-independent document, without the TCP document having to make frequent awkward cross-references to the UDP document. The specific sections of the original UDP draft that I'm proposing to move into the "general" document in this way are: 4.1 Address and Port Mapping 5.1 Filtering of Unsolicited Packets 7. Hairpinning Behavior 10. ICMP Behavior (#10, ICMP Behavior, doesn't yet appear in the General draft because I ran out of time.) If the BEHAVE group accepts the proposed document organization, then at least the General and UDP documents would probably need to be published together first, but the other related documents could still be published later in their own time as outlined in the original working group schedule. Now that we have working drafts for UDP, and TCP, however, it might be worth at least considering the option of trying to push them through together, in order to ensure consistency and coherent organization. But I'm also sympathetic to the reality that "IETF NAT documents are historically hard to publish", and that we shouldn't hold all the documents back unnecessarily if one or two prove particularly controversial. (It's pretty clear that TCP and UDP shouldn't wait for a consensus to develop on SCTP, for example. :)) I'm mainly just proposing that, however and whenever we publish these various documents, we should at least work on them together with a goal of making them mutually consistent and well-organized, and that's what the proposed "Design Principles and General Requirements" draft is about. Comments and reactions appreciated. Thanks, Bryan _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Mon, 28 Feb 2005 18:56:07 -0800 (PST) From: "Francois Audet" Date: Mon, 28 Feb 2005 18:56:07 -0800 (PST) Subject: RE: [Ietf-behave] New draft on UDP unicast behavior Message-ID: <1ECE0EB50388174790F9694F77522CCF01A0C256@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New draft on UDP unicast behavior Here is my take: - I don't like this idea of a new IP header option (you don't either, so this is good). I think it is very important that the NAT vendors that are BEHAVE-compliant TODAY, don't get penalized to look like they are not compliant because of this flag. It would result in extreme measures (like forcing a TURN server) when there is really no need. - I also don't like forcing hyper-complex diagnostics on the application to determine if the NAT is behave compliant. However, it is certainly an option for the application writer. We could recommend that the application treats un-usable NATs gratefully (e.g., provide a warning, etc.). To me, it means that if your code arrives to the conclusion that it won't work (because the NAT is bad), it would treat it gracefully. - Personnally, I think an application could at least determine if the NAT has an "external NAT mapping is endpoint independent" for UDP address and port mapping behavior. And then take appropriate action (use TURN, display an error message, etc.). But again, I don't think we should mandate any of this. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Bryan Ford > Sent: Monday, February 28, 2005 08:07 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] New draft on UDP unicast behavior > > > On Tuesday 26 October 2004 10:38, Robert Sanders wrote: > > Dan Wing wrote: > > >BEHAVE needs a "how a UDP application can use a > BEHAVE-capable NAT" > > >document, which would provide guidance. > > > > If this usage differs from how the UDP application might use a > > non-BEHAVE-capable NAT, or from the scenarios described in > > draft-ietf-sipping-nat-scenarios et cetera, it would also > be useful to > > show how an application might *detect* a well-BEHAVEd NAT. > > I'm not at all sure that such detection is really necessary: > for the most part > I think we should just be recommending that apps assume that NATs are > well-BEHAVEd going forward, and perhaps make a few specific > exceptions as > necessary to account for particularly common forms of "bad" > legacy behavior. > > On the other hand, if it is useful for applications to be > able to distinguish > reliably between BEHAVE NATs and non-BEHAVE NATs, then I can > think of at > least one relatively simple technical solution to this > problem, which would > operate completely "in-band" and is both > transport-independent and require no > explicit communication with NAT (e.g., MIDCOM, NSIS, etc.). > Basically, we > could define a new IP header option, which applications can > attach to the > initial packets in a new transport session they're > establishing if desired. > The application places in this IP option a copy of its source > IP address and > transport-level port number. Non-BEHAVE NATs will > (hopefully) just ignore > this option, translating only the IP address and port number > in the main > IP/TCP/UDP headers. BEHAVE NATs would first compare the > address/port in the > option against the address/port in the main headers, > translate the option too > if they match, and zero or remove the option if they don't > match. The > application at the receiving end can then determine what's on > the path as > follows: > > 1. If the IP option was preserved and has the same > address/port as in the main > IP/TCP/UDP headers, then ALL of the NATs in the path (if any) are > well-BEHAVEd. > 2. If the IP option disappeared or arrived with an > address/port number that > doesn't match the info in the main IP/TCP/UDP headers, then > there is at least > one NAT in the path that is not BEHAVE-compliant. > > A variant of this idea was discussed in one of the early > P2P-over-NAT drafts I > wrote with Pyda Srisuresh, draft-ford-midcom-p2p-00.txt. > > Anyway, to reiterate what I said above, I'm not at all convinced that > "well-BEHAVEd NAT detection" is really necessary or even a > good idea, but I > at least wanted to lay this option on the table in case it > seems useful. > > > I know that NAT type detection has been deprecated in > RFC3489bis, and > > that the problem of detection has become more complex than > originally > > estimated. Requiring more than one internal IP address to fully > > disambiguate the behavior of "non-deterministic" NATs is > problematic. > > So perhaps precise detection is not feasible in many cases. > > > > The question I have is whether the purpose of BEHAVE is to > specify an > > ideal NAT's behavior and then to provide usage guidelines for > > applications working through a compliant set of NATs, or to > recommend > > NAT behaviors that increase the efficiency or reliability > of existing > > techniques. If it's the latter case then BEHAVE shouldn't need its > > own usage document. Any application which wishes to > function through > > non well-BEHAVEd NATs, or through non-traditional NAT > scenarios such > > as twice NAT, couldn't limit itself to techniques dependent upon > > BEHAVE compliance. > > I think the purpose of BEHAVE is some combination of these > goals. We need to > specify "ideal NAT behavior" strongly and coherently enough so that > applications have a definite, practical design path they can > take and be > certain of working reliably over future BEHAVE-compliant NATs > in all typical > deployment scenarios. At the same time, it is important that > this "ideal NAT > behavior" be consistent and compatible with existing > widespread techniques > whenever possible. Ultimately, we have to live with the fact > that with > legacy NATs, all bets are off - applications may or may not > work, and there's > no way an application can make itself 100% reliable with > existing NATs, so > that cannot be our goal. But our goal can be to make sure > that future > applications can be (at least pretty darn close to) 100% > reliable with future > BEHAVE-compliant NATs; that should be our goal. And to do > that it's clearly > important for us to specify exactly how applications can best > take advantage > of the more predictable behavior of well-BEHAVEd NATs. > > Cheers, > Bryan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From baford@mit.edu Tue, 1 Mar 2005 02:49:17 -0800 (PST) From: Bryan Ford Date: Tue, 1 Mar 2005 02:49:17 -0800 (PST) Subject: Re: [Ietf-behave] New draft on UDP unicast behavior In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01A0C256@zrc2hxm0.corp.nortel.com> Message-ID: <200503011149.15450.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Hi Francois, On Tuesday 01 March 2005 03:55, Francois Audet wrote: > Here is my take: > > - I don't like this idea of a new IP header option (you don't either, > so this is good). I think it is very important that the NAT vendors > that are BEHAVE-compliant TODAY, don't get penalized to look like > they are not compliant because of this flag. It would result in > extreme measures (like forcing a TURN server) when there is > really no need. > > - I also don't like forcing hyper-complex diagnostics on the application > to determine if the NAT is behave compliant. However, it is certainly > an option for the application writer. We could recommend that the > application treats un-usable NATs gratefully (e.g., provide > a warning, etc.). To me, it means that if your code arrives to the > conclusion that it won't work (because the NAT is bad), it would > treat it gracefully. > > - Personnally, I think an application could at least determine if > the NAT has an "external NAT mapping is endpoint independent" for UDP > address and port mapping behavior. And then take appropriate > action (use TURN, display an error message, etc.). But again, > I don't think we should mandate any of this. Agreed on all points. > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Bryan Ford > > Sent: Monday, February 28, 2005 08:07 > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Ietf-behave] New draft on UDP unicast behavior > > > > On Tuesday 26 October 2004 10:38, Robert Sanders wrote: > > > Dan Wing wrote: > > > >BEHAVE needs a "how a UDP application can use a > > > > BEHAVE-capable NAT" > > > > > >document, which would provide guidance. > > > > > > If this usage differs from how the UDP application might use a > > > non-BEHAVE-capable NAT, or from the scenarios described in > > > draft-ietf-sipping-nat-scenarios et cetera, it would also > > > > be useful to > > > > > show how an application might *detect* a well-BEHAVEd NAT. > > > > I'm not at all sure that such detection is really necessary: > > for the most part > > I think we should just be recommending that apps assume that NATs are > > well-BEHAVEd going forward, and perhaps make a few specific > > exceptions as > > necessary to account for particularly common forms of "bad" > > legacy behavior. > > > > On the other hand, if it is useful for applications to be > > able to distinguish > > reliably between BEHAVE NATs and non-BEHAVE NATs, then I can > > think of at > > least one relatively simple technical solution to this > > problem, which would > > operate completely "in-band" and is both > > transport-independent and require no > > explicit communication with NAT (e.g., MIDCOM, NSIS, etc.). > > Basically, we > > could define a new IP header option, which applications can > > attach to the > > initial packets in a new transport session they're > > establishing if desired. > > The application places in this IP option a copy of its source > > IP address and > > transport-level port number. Non-BEHAVE NATs will > > (hopefully) just ignore > > this option, translating only the IP address and port number > > in the main > > IP/TCP/UDP headers. BEHAVE NATs would first compare the > > address/port in the > > option against the address/port in the main headers, > > translate the option too > > if they match, and zero or remove the option if they don't > > match. The > > application at the receiving end can then determine what's on > > the path as > > follows: > > > > 1. If the IP option was preserved and has the same > > address/port as in the main > > IP/TCP/UDP headers, then ALL of the NATs in the path (if any) are > > well-BEHAVEd. > > 2. If the IP option disappeared or arrived with an > > address/port number that > > doesn't match the info in the main IP/TCP/UDP headers, then > > there is at least > > one NAT in the path that is not BEHAVE-compliant. > > > > A variant of this idea was discussed in one of the early > > P2P-over-NAT drafts I > > wrote with Pyda Srisuresh, draft-ford-midcom-p2p-00.txt. > > > > Anyway, to reiterate what I said above, I'm not at all convinced that > > "well-BEHAVEd NAT detection" is really necessary or even a > > good idea, but I > > at least wanted to lay this option on the table in case it > > seems useful. > > > > > I know that NAT type detection has been deprecated in > > > > RFC3489bis, and > > > > > that the problem of detection has become more complex than > > > > originally > > > > > estimated. Requiring more than one internal IP address to fully > > > disambiguate the behavior of "non-deterministic" NATs is > > > > problematic. > > > > > So perhaps precise detection is not feasible in many cases. > > > > > > The question I have is whether the purpose of BEHAVE is to > > > > specify an > > > > > ideal NAT's behavior and then to provide usage guidelines for > > > applications working through a compliant set of NATs, or to > > > > recommend > > > > > NAT behaviors that increase the efficiency or reliability > > > > of existing > > > > > techniques. If it's the latter case then BEHAVE shouldn't need its > > > own usage document. Any application which wishes to > > > > function through > > > > > non well-BEHAVEd NATs, or through non-traditional NAT > > > > scenarios such > > > > > as twice NAT, couldn't limit itself to techniques dependent upon > > > BEHAVE compliance. > > > > I think the purpose of BEHAVE is some combination of these > > goals. We need to > > specify "ideal NAT behavior" strongly and coherently enough so that > > applications have a definite, practical design path they can > > take and be > > certain of working reliably over future BEHAVE-compliant NATs > > in all typical > > deployment scenarios. At the same time, it is important that > > this "ideal NAT > > behavior" be consistent and compatible with existing > > widespread techniques > > whenever possible. Ultimately, we have to live with the fact > > that with > > legacy NATs, all bets are off - applications may or may not > > work, and there's > > no way an application can make itself 100% reliable with > > existing NATs, so > > that cannot be our goal. But our goal can be to make sure > > that future > > applications can be (at least pretty darn close to) 100% > > reliable with future > > BEHAVE-compliant NATs; that should be our goal. And to do > > that it's clearly > > important for us to specify exactly how applications can best > > take advantage > > of the more predictable behavior of well-BEHAVEd NATs. > > > > Cheers, > > Bryan > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From baford@mit.edu Tue, 1 Mar 2005 04:12:21 -0800 (PST) From: Bryan Ford Date: Tue, 1 Mar 2005 04:12:21 -0800 (PST) Subject: Re: [Ietf-behave] New drafts In-Reply-To: <4.3.2.7.2.20050228130017.01cf9d38@mira-sjcd-2.cisco.com> Message-ID: <200503011312.17180.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Hi Senthil, Thanks for your comments - responses inline. On Tuesday 01 March 2005 00:34, Senthil Sivakumar wrote: > I think this is an useful effort mainly because a lot of port and > address binding behavior is common to both TCP and UDP. > We realized this when writing our TCP draft and hence there > are a lot of references to unicast UDP draft. Having a generic > draft that addresses the common requirements to both TCP > and UDP is good. > > Some comments on the specifics. > > Some comments. > > Section 1.1 Applicability statement. > > The paragraph > "Many enterprise NATs have special requirements for security, > multihoming and so forth, which may impose restrictions on the NAT's > behavior. Such extra requirements are outside the scope of this..." > > I would suggest that removing this paragraph since it suggests that > this draft recommends certain requirements that may not fit > into enterprise NAT requirements, but I didnt see anything specific > that would prevent enterprise networks from adopting this draft > as a general behavior.. This text was originally derived from the behave-udp draft by Francois and Cullen. I'm OK with removing it, and I think someone else suggested doing so too, but perhaps Francois or Cullen would like to comment? > Address Maps Table: > > The "Address Maps" table represents the NAT's static configuration > database, which is controlled more-or-less directly by the user or > network administrator. The Address Maps table determines the type > of NAT functionality the device implements, for example, such as > Basic NAT, NAPT, Bidirectional NAT, Twice-NAT, or a combination > thereof. The Address Maps table also contains any permanent > mappings the user may have configured between IP addresses or > endpoints on the External and Internal realms: for example, a > mapping between port 80 on the NAT's public IP address and a > particular Web server located on the internal network. > > I think the name Address maps table should be changed to Static map table. > This would include, > > 1. Static Address bindings. > 2. Static port bindings. > 3. Static port to application mapping (for example look for FTP in a port > number > other than 21, say 2021). > 4. Table that holds information on ALGs turned on by network admin. I'm OK in principle with this suggestion, but I'm a bit leery about going into too much detail about what exactly a NAT's static configuration database contains (or should contain), as it seems to be wandering at least dangerously close to out-of-scope for what we're trying to accomplish. > I am a little unclear on this para > "One possible design approach that is specifically forbidden, however, > is to use IP-level or higher-level packet contents to distinguish between > ..." > > as to why you particularly forbid doing NAT based on IP addresses. How do > you expect NAT to happen in one-armed routing case, where there is only > one physical interface (There may be a logical port though).. In my understanding, one-armed routing is typically done by using 802.11Q VLAN tags to multiplex multiple logically separate Ethernet segments onto a single physical interface, and the NAT or router then routes or NATs between those separate Ethernet segments. As the text of the draft points out, this "standard" one-armed routing scenario is fine. But if the NAT has _no_ way to distinguish the two "sides" other than by IP addresses alone, it's likely to create (a) massive security holes because hosts on either side can easily forge packets that look like they came from the opposite side, and (b) massive confusion in general if the IP address domains on the two sides of the NAT numerically overlap. > REQ-2 should also include ICMP in addition to the other protocols > mentioned. Even though it does not fall into the transport protocols > category it is an integral > part of any NAT implementation. If you think we want to keep it separately > that is fine too.. Yes, I'm fine with including ICMP in REQ-2. > Minor one. > > Why is REQ-4 RECOMMENDED but not a MUST. I think it should be a must > because with the non-paired source address causes inconsistent behavior of > NATs arbitrarily assigning addresses. I don't think REQ-4 necessarily needs to be a MUST as long as REQ-3 is a MUST, because it is REQ-3 that enables applications to predict the port numbers it needs to use for hole punching purposes. For example, if a NAT supports REQ-3 but not REQ-4, and an application on node A communicates from two local endpoints A:a1 and A:a2, then the NAT might translate A:a1 to public endpoint B:b and might translate A:a2 to public C:c (not only different public port numbers but different IP addresses). But that doesn't cause any problem for hole-punching applications because the application has to anticipate that its two original port numbers a1 and a2 will be translated to two different public port numbers in an unrelated and unpredictable fashion anyway. Since the NAT-friendly application can't expect to control the NAT's assignment of its precise public endpoints anyway, why should it care whether its two public endpoints happen to have the same public IP address? > DHCP configured NATs. > > I think this section is beyond just DHCP, because other mechanisms like > dial up can be used to obtain the upstream IP address. But "dial up" mechanisms usually use DHCP somewhere underneath, don't they? At least my impression was that PPP-based dial-up protocols usually first set up a tunnel for IP packets and then use DHCP to assign the dial-up node its IP address and other network-layer parameters. I'm not extremely familiar with the operation of dial-up protocols, though, so I could be wrong, and if so the wording of this section should indeed be generalized to include them explicitly. > Also this should be > beyond the scope of this document, IMO. We should just state that it > is the responsibility of the admin to make sure they avoid > mis-configurations of NAT. Unfortunately, as our "topologies" document discusses in greater detail, it is very often the case that overlapping private IP address regions are unavoidable even if all the system administrators involved know what they're doing. The problem is that the NAT often (nay, _usually_) falls exactly on an administrative boundary, and the administrator who manages the private IP address realm on one side of the NAT is different from the administrator who manages the private IP address realm on the other side. Neither can necessarily control what the other one does, and in the common case where the "downstream" administrator is an ordinary clueless user deploying a consumer-level DHCP-configured NAT, there's no way the user can be expected to know how to configure his NAT so as to avoid his private "downstream" IP address space conflicting with his ISP's private "upstream" IP address space. The NAT itself has to deal with this problem somehow if we ever want it to work reliably in increasingly-common multi-level NAT scenarios. (In fact I've recently received E-mail from someone who was bitten by this precise problem.) > I suggest the REQs 8 & 9 be removed but stated as general recommendations > but not as NAT requirements. The reason is it is beyond NAT and involves > other protocols such as DHCP but not limited to DHCP alone.. I don't agree in this case, for the reasons stated above - but I do realize that this section pushes the current boundaries of what has been discussed so far on the BEHAVE list and in related documents, and other people are likely to have different ideas on this topic as well. For that reason I'd very much like to see more discussion on the BEHAVE list about this topic. Thanks, Cheers, > > Thanks > Senthil > > At 05:27 PM 2/17/2005 +0100, Bryan Ford wrote: > >Hi folks, > > > >If you don't mind me interrupting the SCTP debate, there are three new > >BEHAVE-related drafts available at the ietf's Internet-Drafts archive. > >Unfortunately the IETF Secratariat may not forward the "official" > >availability announcement to this list because I forgot to ask them to in > > my submission. :( The first one is as follows; I'll announce the others > > in separate messages... > > > > > >"Design Principles and General Behavioral Requirements for Network Address > >Translators (BEH-GEN)" > >http://www.ietf.org/internet-drafts/draft-ford-behave-gen-00.txt > > > >Abstract: > > This document discusses design principles and behavioral properties > >required to make Network Address Translators (NAT) more predictable and > >compatible with diverse application protocols. First, this document > > presents a concrete architectural model for NAT devices and defines > > important terms used in conjunction with NAT design. This architectural > > model sets the stage for a set of concrete recommendations for NAT > > implementors and vendors, as being contemplated by the BEHAVE working > > group. The recommendations made by this document are independent of > > transport protocol; a set of companion documents provide behavioral > > recommendations specific to particular transport protocols. > > > > > >The intent of this draft is to fill the current "gap" between the current > > UDP behavior draft (draft-ietf-behave-nat-udp-00.txt) and the preliminary > > TCP draft (draft-sivakumar-behave-nat-tcp-req-00.txt), by defining > > general principles, terminology, and specific NAT behavioral requirements > > that are transport-independent or at least common to both TCP and UDP. > > At the moment the initial TCP draft is having to make awkward > > cross-references to parts of the UDP draft to talk about such common > > behavioral requirements, making it unclear precisely what parts of the > > UDP document are also supposed to apply to TCP and what parts are not. > > And there's currently no place at all for requirements like, "NATs MUST > > support both TCP and UDP". > > > >To fix these problems, I've taken the transport-independent portions of > > the UDP document, and transplanted them (with considerable editing) into > > this new "general principles" draft, along with some new content that > > hasn't appeared yet in either draft. The intent is that the transplanted > > sections from the original UDP draft can then be removed or trimmed > > drastically, and both the UDP and TCP documents can simply refer to the > > common transport-independent document, without the TCP document having to > > make frequent awkward cross-references to the UDP document. > > > >The specific sections of the original UDP draft that I'm proposing to move > >into the "general" document in this way are: > > > >4.1 Address and Port Mapping > >5.1 Filtering of Unsolicited Packets > >7. Hairpinning Behavior > >10. ICMP Behavior > > > >(#10, ICMP Behavior, doesn't yet appear in the General draft because I ran > >out > >of time.) > > > >If the BEHAVE group accepts the proposed document organization, then at > > least the General and UDP documents would probably need to be published > > together first, but the other related documents could still be published > > later in their own time as outlined in the original working group > > schedule. Now that we have working drafts for UDP, and TCP, however, it > > might be worth at least considering the option of trying to push them > > through together, in order to ensure consistency and coherent > > organization. But I'm also sympathetic to the reality that "IETF NAT > > documents are historically hard to publish", and that we shouldn't hold > > all the documents back unnecessarily if one or two prove particularly > > controversial. (It's pretty clear that TCP and UDP shouldn't wait for a > > consensus to develop on SCTP, for example. :)) I'm mainly just proposing > > that, however and whenever we publish these various documents, we should > > at least work on them together with a goal of making them mutually > > consistent and well-organized, and that's what the proposed "Design > > Principles and General Requirements" draft is about. > > > >Comments and reactions appreciated. > > > >Thanks, > >Bryan > >_______________________________________________ > >Ietf-behave mailing list > >Ietf-behave@xxxxxxxxxxxxxxxxxxx > >https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Tue, 1 Mar 2005 08:12:15 -0800 (PST) From: Cullen Jennings Date: Tue, 1 Mar 2005 08:12:15 -0800 (PST) Subject: Re: [Ietf-behave] New drafts In-Reply-To: <200503011312.17180.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 3/1/05 4:12 AM, "Bryan Ford" wrote: >> The paragraph >> "Many enterprise NATs have special requirements for security, >> multihoming and so forth, which may impose restrictions on the NAT's >> behavior. Such extra requirements are outside the scope of this..." >> >> I would suggest that removing this paragraph since it suggests that >> this draft recommends certain requirements that may not fit >> into enterprise NAT requirements, but I didnt see anything specific >> that would prevent enterprise networks from adopting this draft >> as a general behavior.. > > This text was originally derived from the behave-udp draft by Francois and > Cullen. I'm OK with removing it, and I think someone else suggested doing so > too, but perhaps Francois or Cullen would like to comment? This text happened out of a discussion that happened in one of the WG meetings. Greg Leovitz was one of the key people at the microphone. The essence of the discussion was that there are very good reasons to build security devices that violate the rules in the behave documents. For example, you might want if Host A inside the NAT forms UDP connection to two different external places, the external places can not tell that both requests came from A. Now a NAT that did that would not be behave compliant. However, it is a fine thing to build. What we need to somehow capture is that behave compliant allows a certain set of things - however there are good reasons that a device might choose not to be behave compliant. What vendors could not live with is that if our documents said they could not claim their devices was behave compliant just because it had configurable features that made it non compliant when used. Am I making any sense? Cullen (not as chair) From fluffy@cisco.com Tue, 1 Mar 2005 08:15:39 -0800 (PST) From: Cullen Jennings Date: Tue, 1 Mar 2005 08:15:39 -0800 (PST) Subject: [Ietf-behave] Threads and subjects on the email list Message-ID: MIME-Version: 1.0 Content-Type: text/plain We have several embedded threads in many emails with less than optimal subjects. Anything folks can do to try improve this will make it easier for others to follow the discussion ... perhaps start some new threads? Cullen (not as chair) From audet@nortel.com Tue, 1 Mar 2005 09:36:07 -0800 (PST) From: "Francois Audet" Date: Tue, 1 Mar 2005 09:36:07 -0800 (PST) Subject: RE: [Ietf-behave] New drafts Message-ID: <1ECE0EB50388174790F9694F77522CCF01A0C54B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] New drafts Yes: that was exactly it. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Cullen Jennings > Sent: Tuesday, March 01, 2005 08:12 > To: Bryan Ford; Senthil Sivakumar > Cc: Behave > Subject: Re: [Ietf-behave] New drafts > > > On 3/1/05 4:12 AM, "Bryan Ford" wrote: > > >> The paragraph > >> "Many enterprise NATs have special requirements for security, > >> multihoming and so forth, which may impose restrictions on > the NAT's > >> behavior. Such extra requirements are outside the scope of > >> this..." > >> > >> I would suggest that removing this paragraph since it > suggests that > >> this draft recommends certain requirements that may not fit into > >> enterprise NAT requirements, but I didnt see anything > specific that > >> would prevent enterprise networks from adopting this draft as a > >> general behavior.. > > > > This text was originally derived from the behave-udp draft > by Francois > > and Cullen. I'm OK with removing it, and I think someone else > > suggested doing so too, but perhaps Francois or Cullen > would like to > > comment? > > > This text happened out of a discussion that happened in one > of the WG meetings. Greg Leovitz was one of the key people at > the microphone. The essence of the discussion was that there > are very good reasons to build security devices that violate > the rules in the behave documents. For example, you might > want if Host A inside the NAT forms UDP connection to two > different external places, the external places can not tell > that both requests came from A. Now a NAT that did that would > not be behave compliant. However, it is a fine thing to > build. What we need to somehow capture is that behave > compliant allows a certain set of things - however there are > good reasons that a device might choose not to be behave > compliant. What vendors could not live with is that if our > documents said they could not claim their devices was behave > compliant just because it had configurable features that made > it non compliant when used. > > Am I making any sense? > > Cullen (not as chair) > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From fluffy@cisco.com Tue, 1 Mar 2005 17:16:31 -0800 (PST) From: Cullen Jennings Date: Tue, 1 Mar 2005 17:16:31 -0800 (PST) Subject: [Ietf-behave] Second draft of Agenda for IETF 62 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Behavior Engineering for Hindrance Avoidance (BEHAVE) MONDAY, March 7, 2005 at 0900-1130 ================================== Agenda draft #2: 9:00 Agenda Bashing Chairs 9:05 Unicast UDP Francois Audet draft-ietf-behave-nat-udp-00 9:45 Multicast UDP Dan Wing draft-wing-behave-multicast-00 10:00 Testing Results Status Chairs http://nutss.gforge.cis.cornell.edu/stunt-client.php http://bgp.lcs.mit.edu/~dga/view.cgi draft-jennings-behave-test-results-00 10:05 What To Test? Open Discussion & Chairs 10:15 TCP Behavior Pyda Srisuresh draft-sivakumar-behave-nat-tcp-req-00 10:30 TCP Behavior Nagendra Modadugu draft-modadugu-nat-tcp-00 10:45 TCP Behavior Open Discussion & Chairs 11:00 BCP for Design Techniques Pyda Srisuresh draft-ford-behave-app-00 draft-ford-behave-top-00 11:15 What To Put In Design Techniques Open Discussion & Chairs 11:30 Finish From fluffy@cisco.com Tue, 1 Mar 2005 18:23:42 -0800 (PST) From: Cullen Jennings Date: Tue, 1 Mar 2005 18:23:42 -0800 (PST) Subject: [Ietf-behave] New supplemental web page for behave Message-ID: MIME-Version: 1.0 Content-Type: text/plain http://ietf.cse.ucsc.edu/behave/ Email me mistakes, omissions, updates, etc... From fluffy@cisco.com Wed, 2 Mar 2005 10:56:11 -0800 (PST) From: Cullen Jennings Date: Wed, 2 Mar 2005 10:56:11 -0800 (PST) Subject: [Ietf-behave] Third draft of agenda for ietf 62 Message-ID: MIME-Version: 1.0 Content-Type: text/plain This version added in draft-iab-nat-traversal-considerations-00 Agenda (draft #3): 9:00 Agenda Bashing Chairs 9:05 IAB NAT Update IAB (Jonathan Rosenberg) draft-iab-nat-traversal-considerations-00 9:15 Unicast UDP Francois Audet draft-ietf-behave-nat-udp-00 9:55 Multicast UDP Dan Wing draft-wing-behave-multicast-00 10:10 Testing Results Status Chairs http://nutss.gforge.cis.cornell.edu/stunt-client.php http://bgp.lcs.mit.edu/~dga/view.cgi draft-jennings-behave-test-results-00 10:15 What To Test? Open Discussion & Chairs 10:25 TCP Behavior Pyda Srisuresh draft-sivakumar-behave-nat-tcp-req-00 10:40 TCP Behavior Nagendra Modadugu draft-modadugu-nat-tcp-00 10:55 TCP Behavior Open Discussion & Chairs 11:10 BCP for Design Techniques Pyda Srisuresh draft-ford-behave-app-00 draft-ford-behave-top-00 11:20 What To Put In Design Techniques Open Discussion & Chairs 11:30 Finish From fluffy@cisco.com Wed, 2 Mar 2005 11:01:32 -0800 (PST) From: Cullen Jennings Date: Wed, 2 Mar 2005 11:01:32 -0800 (PST) Subject: [Ietf-behave] Agenda web page with links to documents ... Message-ID: MIME-Version: 1.0 Content-Type: text/plain http://ietf.cse.ucsc.edu/behave/behave62/ From nagendra@cs.stanford.edu Wed, 2 Mar 2005 14:01:20 -0800 (PST) From: nagendra modadugu Date: Wed, 2 Mar 2005 14:01:20 -0800 (PST) Subject: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP In-Reply-To: <20050225185354.GA21987@cs.stanford.edu> Message-ID: <20050302220116.GC31301@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain My comments inline: * Pyda Srisuresh [2005-02-27 07:56:11 -0800]: > As for the architectural philosophy - Are you referign to the architeture of a > NAT device, or, the architecture of the drafts? I assume, you are referring to > the latter, not the former. draft-ford-gen covers the general NAT > architecture, > common terminology etc.. I believe, TCP-behave and UDP-behave drafts should > focus on the nuances as pertaining the TCP & UDP flows. I hope I've successfully conveyed the scope in my draft (i.e. no coverage of (TCP) protocol-independent behavior and requirements). > > * First, my draft relaxes a number of technical constraints that > > you assumed. For instance I feel that SM=Y is superfluous. > > [suresh] I do think, it is importsnt to state that a NAT maintain a > light-weight state for TCP NAT-sessions. This is further explained later in > conjunction with the timers and TCP states themselves. Unlike UDP, the > stateful > nature of TCP calls for this recommendation. This is also the reason why TCP > NAT-sessions are not aggregated with wild-card ports, unlike UDP NAT-sessions. > Given this, Why do you consider it superfluous to state SM=Yes? This was a minor case, if only to point out a recommendation I find superfluous: sure, I agree that a NAT needs to maintain per connection state -- however, the recommendation that various timers be implemented covers the required behavior. Unless of course, there is a pathalogical case where a NAT correctly implements the Connecting/Established/Closing timers, is SM=N, and is eventually behaviorally non-complaint? > > Similarly, I don't see applications running on the NAT needing > > special treatment with regards to port assignment (i.e. "No Port > > Overloading" requirement covers this case). > > [suresh] I dont see what the point of contention here is. Sivakumar's draft > recommends NAT implementors to set aside non-overlapping port blocks a) for > its > own end-host usage purposes, and b) for NAT functional use. I do like this > recommendation. Many commercial boxes loose this distinction and mess > themselves. So, I think it is useful to have this. Are you saying it is not > necessary to state this in the TCP-behave draft? My prefernce would be to move > this recommendation to behave-gen draft - because this is not TCP or UDP > specific. By "messed themselves", you mean that some commercial boxes "overload" (i.e. assign a port to more than one endpoint internal to the NAT, including applications residing on the NAT device)? That's entirely possible, though I don't think I've seen any indication of this specific behavior in Cullen's [STUN-results] draft. Nonetheless, my point was that I see it as confusing to somehow distinguish between apps running on the NAT and endpoints internal to the NAT -- the end result of "overloading" regardless of how it happens has been ruled against by the "No Port Overloading" requirement in draft [UDP-REQ]. If it makes things clearer, it may be worthwhile providing an example of bad behavior you describe -- instead of a mention of port blocks (since port assignment, even for applications residing on the NAT device, could be dynamic, and non-sequential -- properties that are contradicted by the description "port blocks"). > I donot see the term "port overloading" used in Sivakumar's draft. However, I > do see him refering to "port binding". I suspect, what you refer to as "not > overloading a port" is same as mainining "port binding". My personal > preference > is to stick to the term "port binding" (TCP or UDP) and use that. The terms > "address Binding" and "Port Binding" have been in use in the past and I woudl > suggest reusing these terms in this WG. This is touched upon quite extensively > in ford-behave-gen draft. There's some confusion here. No do I not mean "Port binding". "Port overloading" is introduced as bad behavior in draft [UDP-REQ]. > > * Second, I don't believe NAT devices should be required to > > implement TCP keepalive messages -- especially since this feature > > [suresh] I agree. > > > is easily implemented in clients and servers that may be affected > > by premature binding expiry. Of course, an implementor that chooses > > [suresh] I donot understand what you say about "premature binding expiry". How > does implementing TCP keepalives result in premature binding expiry? What did > you mean by "premature binding expiry" and how are clients/servers effected by > this? "Premature binding expiry" refers to the problem where a binding for an established TCP connection is deleted as a result of inactivity. > > to provide this feature, or other features outside the requirements > > is not prevented from doing so. > > [suresh] I am not in favor of NAT devices doing the keep-alives either. > Clearly, there are some benefits to the NAT devices doing this. We should seek > input from the list on this. Folks on the list may have differing opinions. Agreed. > > * Similarly, I would prefer not to require TCP stream reconstruction, > > as such support can easily be implemented in an ALG if required. > > > > [suresh] I believe, fragmentation handling, as a whole, belongs in > portocol-independent general behavior draft (ex: ford-behave-gen) - Not TCP or > UDP behave drafts. > > I agree, the sivakumar draft can do with some rework in this area. I sent the > authors some comments already on this. By fragmentation, I assume you're referring to IP-fragmentation. If so, then agreed: IP-fragmentation discussion belongs elsewhere. This is not however my read of [draft-sivakumar] Section 3.5.2, which seems to be talking about more than IP-fragmentation. nagendra From nagendra@cs.stanford.edu Wed, 2 Mar 2005 15:28:07 -0800 (PST) From: nagendra modadugu Date: Wed, 2 Mar 2005 15:28:07 -0800 (PST) Subject: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP In-Reply-To: <20050222030742.GA14030@cs.stanford.edu> Message-ID: <20050302232804.GA10502@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain My comments inline: > > * Second, I don't believe NAT devices should be required to > > implement TCP keepalive messages -- especially since this feature > > is easily implemented in clients and servers that may be affected > > by premature binding expiry. Of course, an implementor that chooses > > to provide this feature, or other features outside the requirements > > is not prevented from doing so. > > I think this issue concerns some text I contributed to this draft, and which > probably indeed at least needs to be clarified in the text and perhaps hashed > out some more on the list. > > Our draft does NOT require, or even try to suggest, that NATs send TCP > keep-alives in order to keep TCP connections open (which is usually what TCP > keep-alives are for, of course). The draft DOES suggest (but does NOT > require) that NATs may use TCP keep-alive packets as a way to "probe" an idle > TCP connection whose session timer has expired and which the NAT is about to > delete. Just to be perfectly clear: there is NO suggestion that NATs should > ever "keep a TCP session alive" by sending keep-alives. The suggestion is > only that NATs can use "packets that look like TCP keep-alives" in order to > "probe" an idle session just before deleting it, giving the endpoints one > last chance to indicate that the connection is still alive. Sure, I don't think I misunderstand what you mean by the NAT sending out TCP keep-alive messages for the purpose of connection liveness testing. I don't disagree that connection liveness testing can be useful -- there are problems associated with implementing keep-alives at the NAT though, e.g.: - an internal host opens a TCP connection to an external server. The internal host creates a socket with SO_KEEPALIVE. - the NAT device sends a TCP keep-alive message to the internal host, to which the internal host responds with an ACK (also with the side-effect that the internal host refreshs it's connection idle timer). - now if the external endpoint is dead, the internal host will not find out. This problem can be fixed by ensuring that the session timer is longer than keep-alive timers for TCP implementations -- but it seems like unnecessary mucking into a protocol that has already has an mechanism for dealing with liveness testing. I not against mentioning keep-alive as a possible solution for dealing with idle connections, but there is a problem with suggesting that a NAT device "SHOULD" implement TCP connection liveness probing in this manner -- as per Section 2 of [UDP-REQ]: "A NAT that complies with all of the mandatory requirements of this specification (i.e., the "MUST"), is "compliant with this specification." A NAT that complies with all of the requirements of this specification (i.e., including the "RECOMMENDED" and SHOULD) is "fully compliant with all the mandatory and recommended requirements of this specification." Hence a NAT device that does not implement recommendations marked "SHOULD" is reduced from "fully compliant" to "compliant". So perhaps you meant "MAY"? This is a topic well worth discussing at the meeting on Monday. There might be useful scenarios I'm not thinking of -- the only experience I've had is my idle ssh connections getting dropped. > I did not write this recommendation as a MUST, however, because this behavior > does add a bit more complexity to the NAT's TCP state machine, and it is not > difficult for "NAT-aware" applications to send "real" keep-alives if they > need to hold idle sessions open for long periods. On the other hand, use of > TCP keep-alives by applications has historically been discouraged (e.g., see > section 4.2.3.6 of RFC 1122), and it would seem we should at least do what we > can to minimize the need for them. Agreed. But the part of problem is that the solution being suggested here for minimizing the need for keep-alive is implementing keep-alive at the NAT -- which isn't quite in tune with the end-to-end design principle. nagendra From kbiswas@cisco.com Thu, 3 Mar 2005 15:01:37 -0800 (PST) From: Kaushik Biswas Date: Thu, 3 Mar 2005 15:01:37 -0800 (PST) Subject: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP In-Reply-To: <20050227155611.88121.qmail@web40425.mail.yahoo.com> Message-ID: <4.3.2.7.2.20050303140120.0420b890@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain My comments inline... At 02:01 PM 3/2/2005 -0800, nagendra modadugu wrote: My comments inline: * Pyda Srisuresh [2005-02-27 07:56:11 -0800]: > As for the architectural philosophy - Are you referign to the architeture of a > NAT device, or, the architecture of the drafts? I assume, you are referring to > the latter, not the former. draft-ford-gen covers the general NAT architecture, > common terminology etc.. I believe, TCP-behave and UDP-behave drafts should > focus on the nuances as pertaining the TCP & UDP flows. I hope I've successfully conveyed the scope in my draft (i.e. no coverage of (TCP) protocol-independent behavior and requirements). > > * First, my draft relaxes a number of technical constraints that > > you assumed. For instance I feel that SM=Y is superfluous. > > [suresh] I do think, it is importsnt to state that a NAT maintain a > light-weight state for TCP NAT-sessions. This is further explained later in > conjunction with the timers and TCP states themselves. Unlike UDP, the stateful > nature of TCP calls for this recommendation. This is also the reason why TCP > NAT-sessions are not aggregated with wild-card ports, unlike UDP NAT-sessions. > Given this, Why do you consider it superfluous to state SM=Yes? This was a minor case, if only to point out a recommendation I find superfluous: sure, I agree that a NAT needs to maintain per connection state -- however, the recommendation that various timers be implemented covers the required behavior. Unless of course, there is a pathalogical case where a NAT correctly implements the Connecting/Established/Closing timers, is SM=N, and is eventually behaviorally non-complaint? It is important for NAT to maintain a light-weight TCP State Machine so as to keep track of syns, acks, fins, rsts exchanged for this session, not only for managing NAT timers but also for other reasons like filtering, seq-ack adjustment (if applicable),etc. Actually even for managing timers one would need to have some form of state-machine intelligence in NAT. > > Similarly, I don't see applications running on the NAT needing > > special treatment with regards to port assignment (i.e. "No Port > > Overloading" requirement covers this case). > > [suresh] I dont see what the point of contention here is. Sivakumar's draft > recommends NAT implementors to set aside non-overlapping port blocks a) for its > own end-host usage purposes, and b) for NAT functional use. I do like this > recommendation. Many commercial boxes loose this distinction and mess > themselves. So, I think it is useful to have this. Are you saying it is not > necessary to state this in the TCP-behave draft? My prefernce would be to move > this recommendation to behave-gen draft - because this is not TCP or UDP > specific. By "messed themselves", you mean that some commercial boxes "overload" (i.e. assign a port to more than one endpoint internal to the NAT, including applications residing on the NAT device)? That's entirely possible, though I don't think I've seen any indication of this specific behavior in Cullen's [STUN-results] draft. Nonetheless, my point was that I see it as confusing to somehow distinguish between apps running on the NAT and endpoints internal to the NAT -- the end result of "overloading" regardless of how it happens has been ruled against by the "No Port Overloading" requirement in draft [UDP-REQ]. If it makes things clearer, it may be worthwhile providing an example of bad behavior you describe -- instead of a mention of port blocks (since port assignment, even for applications residing on the NAT device, could be dynamic, and non-sequential -- properties that are contradicted by the description "port blocks"). The NAT router can run other applications as well in addition to NAT'ing the hosts on the private-domain. It becomes important for NAT to work in harmony with the other applications who will be sharing the same address as NAT is (I am talking about NAPT/PAT here). Say for eg: the NAT is happening using the interface-address: 171.1.1.1 and there is a endpoint on the private-domain sending traffic to the public-side. Say the private-ip is 1.1.1.1 and private-port is 1024, after going through NAT this will get translated to say 171.1.1.1, 1024. Now if there is no harmony between NAT and the local TCP stack then the local TCP stack can generate traffic with source-address and port as 171.1.1.1, 1024. As a result when the response comes back there will be a conflict as to whether it is for NAT or for the local-TCP stack. Port-reservation solves this sort of contentions. NAT need not be aware of what application the local TCP stack runs, just that whenever NAT is using the interface-address for doing port-translation there needs to be some sync with the local-TCP stack. Whether this requires to be a MUST or a SHOULD can be discussed but it needs a recommendation. > I donot see the term "port overloading" used in Sivakumar's draft. However, I > do see him refering to "port binding". I suspect, what you refer to as "not > overloading a port" is same as mainining "port binding". My personal preference > is to stick to the term "port binding" (TCP or UDP) and use that. The terms > "address Binding" and "Port Binding" have been in use in the past and I woudl > suggest reusing these terms in this WG. This is touched upon quite extensively > in ford-behave-gen draft. There's some confusion here. No do I not mean "Port binding". "Port overloading" is introduced as bad behavior in draft [UDP-REQ]. > > * Second, I don't believe NAT devices should be required to > > implement TCP keepalive messages -- especially since this feature > > [suresh] I agree. > > > is easily implemented in clients and servers that may be affected > > by premature binding expiry. Of course, an implementor that chooses > > [suresh] I donot understand what you say about "premature binding expiry". How > does implementing TCP keepalives result in premature binding expiry? What did > you mean by "premature binding expiry" and how are clients/servers effected by > this? "Premature binding expiry" refers to the problem where a binding for an established TCP connection is deleted as a result of inactivity. > > to provide this feature, or other features outside the requirements > > is not prevented from doing so. > > [suresh] I am not in favor of NAT devices doing the keep-alives either. > Clearly, there are some benefits to the NAT devices doing this. We should seek > input from the list on this. Folks on the list may have differing opinions. Agreed. > > * Similarly, I would prefer not to require TCP stream reconstruction, > > as such support can easily be implemented in an ALG if required. > > > > [suresh] I believe, fragmentation handling, as a whole, belongs in > portocol-independent general behavior draft (ex: ford-behave-gen) - Not TCP or > UDP behave drafts. > > I agree, the sivakumar draft can do with some rework in this area. I sent the > authors some comments already on this. By fragmentation, I assume you're referring to IP-fragmentation. If so, then agreed: IP-fragmentation discussion belongs elsewhere. This is not however my read of [draft-sivakumar] Section 3.5.2, which seems to be talking about more than IP-fragmentation. Other than IP fragmentation NATs have to deal with TCP Segmentations as well when deep-packet inspection are to be done just as we have to deal with seq/ack fixups. The section 3.5.2 of sivakumar-draft talks about TCP Segmentation. Agree with Suresh that IP Fragmentation probably needs to reside in ford-behave-gen, but at the time of writting sivakumar-draft, behave-gen wasn't around. Again this is a recommendation and not a mandatory requirement and only when deep-packet inspection is enabled. -Kaushik nagendra _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Sat, 5 Mar 2005 20:34:30 -0800 (PST) From: Pyda Srisuresh Date: Sat, 5 Mar 2005 20:34:30 -0800 (PST) Subject: TCP Keep Alives (was:: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP) In-Reply-To: <20050302232804.GA10502@cs.stanford.edu> Message-ID: <20050306043429.33174.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Nagendra, Please see my comments inline. cheers, suresh --- nagendra modadugu wrote: > My comments inline: > > > > * Second, I don't believe NAT devices should be required to > > > implement TCP keepalive messages -- especially since this feature > > > is easily implemented in clients and servers that may be affected > > > by premature binding expiry. Of course, an implementor that chooses > > > to provide this feature, or other features outside the requirements > > > is not prevented from doing so. > > > > I think this issue concerns some text I contributed to this draft, and > which > > probably indeed at least needs to be clarified in the text and perhaps > hashed > > out some more on the list. > > > > Our draft does NOT require, or even try to suggest, that NATs send TCP > > keep-alives in order to keep TCP connections open (which is usually what > TCP > > keep-alives are for, of course). The draft DOES suggest (but does NOT > > require) that NATs may use TCP keep-alive packets as a way to "probe" an > idle > > TCP connection whose session timer has expired and which the NAT is about > to > > delete. Just to be perfectly clear: there is NO suggestion that NATs > should > > ever "keep a TCP session alive" by sending keep-alives. The suggestion is > > only that NATs can use "packets that look like TCP keep-alives" in order to > > > "probe" an idle session just before deleting it, giving the endpoints one > > last chance to indicate that the connection is still alive. > > Sure, I don't think I misunderstand what you mean by the NAT sending out > TCP keep-alive messages for the purpose of connection liveness testing. > I don't disagree that connection liveness testing can be useful -- there > are problems associated with implementing keep-alives at the NAT though, > e.g.: > > - an internal host opens a TCP connection to an external server. The > internal host creates a socket with SO_KEEPALIVE. [suresh] The above socket option is commonly used on the servers, not the clients. That is what section 4.2.3.6 of RFC 1122 recommens as well - A TCP keep-alive mechanism should only be invoked in server applications that might otherwise hang indefinitely and consume resources if client crashes or aborts a connection during a network failure. I.e., the assumption above that TCP clients use SO_SOCKET option is not a common practice in client-server applications. > - the NAT device sends a TCP keep-alive message to the internal host, > to which the internal host responds with an ACK (also with the > side-effect that the internal host refreshs it's connection idle > timer). > - now if the external endpoint is dead, the internal host will not > find out. > > This problem can be fixed by ensuring that the session timer > is longer than keep-alive timers for TCP implementations -- but it > seems like unnecessary mucking into a protocol that has already > has an mechanism for dealing with liveness testing. > [suresh] I donot think, it is a good idea for NAT to make assumptions about what the keep-alive timeout might be in applications. It is often in the order of 2 hrs, but can vary. So, I wouldnt suggest going down the path of setting NAT session timers to be longer than Keep-alive timeouts. You do make a good point about the pitfall of NAT doing keep-alives on the client-side alone, and not on the server side. As you say, the caveat is that NAT will be unable to detect liveness on the server side unless NAt does keep-alive on the server side too. But, the reality with most client-server apps is that Servers are often busy and woudl rather not be bothered with addiitonal chatty keep-alives. So, I believe, if we keep-alives are to be done at all by NAT, they should probably be restricted to client side only. Clients can learn ofservers going away when there is real data to be transferred. Now, let me point out a scenario where keep-alives are needed and can be useful. Say, NAT did not do keep-alives, but has session timeout enforced on TCP onnections. Let us also Say, the server end of the application doesnt use the SO_KEEPALIVE option. So, if there is a hiatus of no activity on the TCP connection, NAt simply clears the TCP NAT Session. When the client attemts to send data after the hiatus of no-activity, NAT would simply drop the packet (or send RST in some cases). So, the client reinitiates a new TCP connection with the same server and life goes on for the client. However,the server has accumulated a whole bunch of connections initiated from the same client, even though the client itself believes it has just one session outstanding with the server. At some point, the session count on the server will overwhelm the server and the server woudl simply stop accepting new sessons. This is a disaster/meltdown on the serer. I believe, MS Outlook is one such application effected in this kind of a scenario. A solution that works for the above situation is as follows - At the end of each TCP Session timeout, NAT issues a keep-alive to the client (as suggested in the sivakumar draft). If the client responds with a RST (that is an indication that the client doesnt know of the session), NAT would simply forward the RST to the server. Both sides are happy. If the client sends an ACK back, NAT could reset the TCP NAT session activity timer. However, if the the client doesnt respond to the keep-alive(it is not mandatory that clients shoudl respond to the keep-alives), NAT may simply send a RST to the client as well as the server. By doign this, NAT forces both sides to clear the connections. Servers such as MS-Exchange server woudl not melt down when the NAT enroute behaves as above. > I not against mentioning keep-alive as a possible solution for dealing > with idle connections, but there is a problem with suggesting that a > NAT device "SHOULD" implement TCP connection liveness probing in this > manner -- as per Section 2 of [UDP-REQ]: > > "A NAT that complies with all of the mandatory requirements of this > specification (i.e., the "MUST"), is "compliant with this > specification." A NAT that complies with all of the requirements of > this specification (i.e., including the "RECOMMENDED" and SHOULD) is > "fully compliant with all the mandatory and recommended requirements > of this specification." > > Hence a NAT device that does not implement recommendations marked "SHOULD" > is reduced from "fully compliant" to "compliant". So perhaps you meant > "MAY"? > [suresh] The subtle distinctions you site between "fully compliant", vs. "compliant" is VERY confusing and is not a common practice in the IETF, AFAIK. The common practice, I believe, is that an implementation is considered "compliant" to a standard (or BSP), when the implementation meets all the MUSTs. SHOULDs are highly recommended, but not enforced. MAY is optional. When an implementation does not meet even a single MUST, then the implementation is considered "non-compliant". I hope, we can get some consensus on this from the list. > This is a topic well worth discussing at the meeting on Monday. There > might be useful scenarios I'm not thinking of -- the only experience I've > had is my idle ssh connections getting dropped. > [suresh] I agree, this is worth discussing. There are conceivably severeal scenarios that wouls benefit when NAT actively sends keep-alives and RSTs in some cases. Please see my note above. > > I did not write this recommendation as a MUST, however, because this > behavior > > does add a bit more complexity to the NAT's TCP state machine, and it is > not > > difficult for "NAT-aware" applications to send "real" keep-alives if they > > need to hold idle sessions open for long periods. On the other hand, use > of > > TCP keep-alives by applications has historically been discouraged (e.g., > see > > section 4.2.3.6 of RFC 1122), and it would seem we should at least do what > we > > can to minimize the need for them. > > Agreed. But the part of problem is that the solution being suggested > here for minimizing the need for keep-alive is implementing keep-alive > at the NAT -- which isn't quite in tune with the end-to-end design principle. [suresh] Please see my note above. > > nagendra > cheers, suresh From srisuresh@yahoo.com Sat, 5 Mar 2005 21:02:36 -0800 (PST) From: Pyda Srisuresh Date: Sat, 5 Mar 2005 21:02:36 -0800 (PST) Subject: Re: [Ietf-behave] New draft: NAT Behavioral Requirements for TCP In-Reply-To: <20050302220116.GC31301@cs.stanford.edu> Message-ID: <20050306050235.91794.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- nagendra modadugu wrote: > My comments inline: > > * Pyda Srisuresh [2005-02-27 07:56:11 -0800]: > > > As for the architectural philosophy - Are you referign to the architeture > of a > > NAT device, or, the architecture of the drafts? I assume, you are referring > to > > the latter, not the former. draft-ford-gen covers the general NAT > architecture, > > common terminology etc.. I believe, TCP-behave and UDP-behave drafts should > > focus on the nuances as pertaining the TCP & UDP flows. > > I hope I've successfully conveyed the scope in my draft (i.e. no > coverage of (TCP) protocol-independent behavior and requirements). > [suresh] OK. > > > * First, my draft relaxes a number of technical constraints that > > > you assumed. For instance I feel that SM=Y is superfluous. > > > > [suresh] I do think, it is importsnt to state that a NAT maintain a > > light-weight state for TCP NAT-sessions. This is further explained later in > > conjunction with the timers and TCP states themselves. Unlike UDP, the > stateful > > nature of TCP calls for this recommendation. This is also the reason why > TCP > > NAT-sessions are not aggregated with wild-card ports, unlike UDP > NAT-sessions. > > Given this, Why do you consider it superfluous to state SM=Yes? > > This was a minor case, if only to point out a recommendation I find > superfluous: > sure, I agree that a NAT needs to maintain per connection state -- however, [suresh] That soudns good. That is the key point here, I believe. > the > recommendation that various timers be implemented covers the required > behavior. [suresh] Yes. You are right, the Sivakumar draft also talks about timers associated with each state of the TCP NAT session. > Unless of course, there is a pathalogical case where a NAT correctly > implements the Connecting/Established/Closing timers, is SM=N, and is > eventually behaviorally non-complaint? > [suresh] I donot understand your comment here. Are you saying, it is possible that a NAT correctly implement the three timers, but not maintain the state, ie, SM=NO? How do you mean? Please explain. > > > Similarly, I don't see applications running on the NAT needing > > > special treatment with regards to port assignment (i.e. "No Port > > > Overloading" requirement covers this case). > > > > [suresh] I dont see what the point of contention here is. Sivakumar's draft > > recommends NAT implementors to set aside non-overlapping port blocks a) for > its > > own end-host usage purposes, and b) for NAT functional use. I do like this > > recommendation. Many commercial boxes loose this distinction and mess > > themselves. So, I think it is useful to have this. Are you saying it is not > > necessary to state this in the TCP-behave draft? My prefernce would be to > move > > this recommendation to behave-gen draft - because this is not TCP or UDP > > specific. > > By "messed themselves", you mean that some commercial boxes "overload" > (i.e. assign a port to more than one endpoint internal to the NAT, > including applications residing on the NAT device)? That's entirely > possible, though I don't think I've seen any indication of this specific > behavior in Cullen's [STUN-results] draft. > [suresh] Well, if all the boxes out there do this right, what is the problem with stating what you believe to be obvious as a requirement? > Nonetheless, my point was that I see it as confusing to somehow > distinguish between apps running on the NAT and endpoints internal to > the NAT -- the end result of "overloading" regardless of how it happens > has been ruled against by the "No Port Overloading" requirement in > draft [UDP-REQ]. If it makes things clearer, it may be worthwhile > providing an example of bad behavior you describe -- instead of a > mention of port blocks (since port assignment, even for applications > residing on the NAT device, could be dynamic, and non-sequential -- > properties that are contradicted by the description "port blocks"). > [suresh] I woudl argue,this type of a requirement belongs in the genral recommendations draft such as draft-ford-behave-gen, not in behave-udp or behave-tcp. As for providing an illustration, that is not a bad idea. That could be done. > > I donot see the term "port overloading" used in Sivakumar's draft. However, > I > > do see him refering to "port binding". I suspect, what you refer to as "not > > overloading a port" is same as mainining "port binding". My personal > preference > > is to stick to the term "port binding" (TCP or UDP) and use that. The terms > > "address Binding" and "Port Binding" have been in use in the past and I > woudl > > suggest reusing these terms in this WG. This is touched upon quite > extensively > > in ford-behave-gen draft. > > There's some confusion here. No do I not mean "Port binding". > "Port overloading" is introduced as bad behavior in draft [UDP-REQ]. > [suresh] OK. Like I said earlier, I believe, this belongs in a general recommendations draft. > > > * Second, I don't believe NAT devices should be required to > > > implement TCP keepalive messages -- especially since this feature > > > > [suresh] I agree. > > > > > is easily implemented in clients and servers that may be affected > > > by premature binding expiry. Of course, an implementor that chooses > > > > [suresh] I donot understand what you say about "premature binding expiry". > How > > does implementing TCP keepalives result in premature binding expiry? What > did > > you mean by "premature binding expiry" and how are clients/servers effected > by > > this? > > "Premature binding expiry" refers to the problem where a binding > for an established TCP connection is deleted as a result of inactivity. > [suresh] Say, A TCP NAT session has expired due to inactivity. Say, the Port binding associated with the NAT session expired sometime after the NAT session has expired. I asume, this is what you refer to as "binding expiry". If so, I am in sync with you so far. However, I stil do not understand how implementing Keep-alives will result in premature Binding expiry. In fact, it is just the opposite. When keep-alives are implemented, that dramatically decreases the chances of the NAT session prematurely expiring and hence, in turn, decreases the chances of expiring TCP port binding prematurely. > > > to provide this feature, or other features outside the requirements > > > is not prevented from doing so. > > > > [suresh] I am not in favor of NAT devices doing the keep-alives either. > > Clearly, there are some benefits to the NAT devices doing this. We should > seek > > input from the list on this. Folks on the list may have differing opinions. > > Agreed. > > > > * Similarly, I would prefer not to require TCP stream reconstruction, > > > as such support can easily be implemented in an ALG if required. > > > > > > > [suresh] I believe, fragmentation handling, as a whole, belongs in > > portocol-independent general behavior draft (ex: ford-behave-gen) - Not TCP > or > > UDP behave drafts. > > > > I agree, the sivakumar draft can do with some rework in this area. I sent > the > > authors some comments already on this. > > By fragmentation, I assume you're referring to IP-fragmentation. If so, > then agreed: IP-fragmentation discussion belongs elsewhere. This is not > however my read of [draft-sivakumar] Section 3.5.2, which seems to be > talking about more than IP-fragmentation. [suresh] You are right. I didnot go past the IP fragmentation issue. The sivekumar draft does talk about out-of-order segment handling. Then again, it does this only in the context of the NAT device supporting embedded ALGs. This is not mandated when the NAT does not support ALGs. > > nagendra > cheers, suresh From spencer@mcsr-labs.org Mon, 7 Mar 2005 15:27:10 -0800 (PST) From: "Spencer Dawkins" Date: Mon, 7 Mar 2005 15:27:10 -0800 (PST) Subject: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets Message-ID: <000701c5236d$44310d80$e8878182@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain My understanding from this morning's meeting was that we were leaning toward not requiring Behave-conformant NATs to process out-of-order TCP fragments, with the expectation that endpoints would be doing Path MTU discovery anyway, so fragmentation shouldn't be an issue. I ran into Mark Allman this afternoon and asked him if he had an opinion on the robustness of Path MTU discovery on the Internet. He does, and has recently co-authored a paper that discusses this (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). In section 4.3 of the paper, he's seeing that about one-third of the 85,000 servers identified by the NLANR Web Caching project don't attempt Path MTU discovery at all, and another 17 percent attempt it and fail. The failure rate is even higher for a list of 500 popular web server (35%). So I'm wondering if we need to think about this a little more? Spencer p.s. I copied Mark, just in case I'm misunderstanding the paper... From srisuresh@yahoo.com Mon, 7 Mar 2005 15:57:31 -0800 (PST) From: Pyda Srisuresh Date: Mon, 7 Mar 2005 15:57:31 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets Message-ID: <20050307235730.78688.qmail@web40423.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Spencer Dawkins wrote: > My understanding from this morning's meeting was that we were leaning > toward not requiring Behave-conformant NATs to process out-of-order > TCP fragments, with the expectation that endpoints would be doing Path > MTU discovery anyway, so fragmentation shouldn't be an issue. > [suresh] If you are talking about processing out of order IP fragments in general, I believe, the chairs said we would take this to the list. If NATs do not handle IP fragments correctly, it is a major problem for applications that use IP fragments (ex: NFS over UDP). I believe, this is a MUST for NATs. regards, suresh > I ran into Mark Allman this afternoon and asked him if he had an > opinion on the robustness of Path MTU discovery on the Internet. He > does, and has recently co-authored a paper that discusses this > (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). > In section 4.3 of the paper, he's seeing that about one-third of the > 85,000 servers identified by the NLANR Web Caching project don't > attempt Path MTU discovery at all, and another 17 percent attempt it > and fail. The failure rate is even higher for a list of 500 popular > web server (35%). > > So I'm wondering if we need to think about this a little more? > > Spencer > > p.s. I copied Mark, just in case I'm misunderstanding the paper... > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Mon, 7 Mar 2005 18:03:42 -0800 (PST) From: Cullen Jennings Date: Mon, 7 Mar 2005 18:03:42 -0800 (PST) Subject: [Ietf-behave] few random notes from Message-ID: MIME-Version: 1.0 Content-Type: text/plain Below is some raw unprocessed notes I took - may be right or wrong. I will merge with official notes later. Need to sync up with Fernando Gont and Mark Allman and others about ICMP processing with respect to TCP in NATs. draft-gont-tcpm-icmp-attacks Discussion on topic of security - The topic of randomized IP addressed. Requirements here are not for all NATs in the world. Need to carefully check all our SHOULD and explain when can/can not do them. On UDP ALG - recommend that default setting is ON for DNS and FTP and off for all others. Long discussion - of symmetric definition in STUN RFC. No objections to moving multicast to WG item More things for testing: Router Alter options MTU handling Deterministic behavior - more than one Hairpin work / external or internal address used Comment that NATs should not send messages to try and keep the session alive by testing liveness of the applications on either end. TCP timers - need to say we need to mindful when we pick these values Other behaviors - based on service type or destination of address - can enforce different types of rules. Greg work with Nagendra to bring up a few cases about this on the list. Question - about source port. Do any protocol need source port stay the same. Some suggestions IKE implementations are broke and follow this - need to get examples of version that do. RST stuff - want to provide hint to NAT implementers - if we drop immediately then we might break stuff. Don't want NAT do RST unless track SEQ numbers. RST , set timer to low value. This is a Firewall. Seq# readjustment - need to deal with this for ALG such DNS/FTP. Need discussion around what do do with out of order fragment. From jdrosen@cisco.com Wed, 9 Mar 2005 14:11:33 -0800 (PST) From: Jonathan Rosenberg Date: Wed, 9 Mar 2005 14:11:33 -0800 (PST) Subject: [Ietf-behave] remove nat type definitions from rfc3489bis Message-ID: <422F748E.3040408@cisco.com> MIME-Version: 1.0 Content-Type: text/plain During the behave meeting at this IETF, we had a lengthy and not too productive debate about the precise meaning of symmetric NAT. The current draft-ietf-behave-rfc3489bis-01, as well as rfc3489, defines the terms for the various NAT types. The new udp-behave draft spends some time, in section 6, trying to map the new definitions in udp-behave with the definitions in rfc3489. I think that this serves no purpose. The behave drafts are clear, I think, that the terminology in RFC3489 was problematic, and that it was better to define a set of orthogonal behaviors that could be named. Thus, I think that it is a futile exercise to try and go back and clarify what we mean by "symmetric nat" by mapping the new behaviors in udp-behave to the concepts in 3489. I would instead propose that: 1. we remove the definitions of symmetric/full-cone/port-restricted/etc. from rfc3489bis. These definitions are not used anymore except for the IAB considerations section, where they are not really needed. 2. We remove all the stuff in behave-udp that tries to give new meaning to those terms 3. behave-udp update its references to rfc3489bis whenever it needs to mention stun Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From audet@nortel.com Wed, 9 Mar 2005 14:21:36 -0800 (PST) From: "Francois Audet" Date: Wed, 9 Mar 2005 14:21:36 -0800 (PST) Subject: RE: [Ietf-behave] remove nat type definitions from rfc3489bis Message-ID: <1ECE0EB50388174790F9694F77522CCF01B321CD@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] remove nat type definitions from rfc3489bis Thank you Jonathan, you must have read my mind ;^) I fully support your recommendation. Unless I hear any compelling reason on the mailing list on why it shouldn't be done, I will remove completely from draft-ietf-behave-nat-udp section 6 and all material concerning the legacy terminology Cone/Symmetric. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jonathan Rosenberg > Sent: Wednesday, March 09, 2005 14:11 > To: Behave > Subject: [Ietf-behave] remove nat type definitions from rfc3489bis > > > During the behave meeting at this IETF, we had a lengthy and not too > productive debate about the precise meaning of symmetric NAT. The > current draft-ietf-behave-rfc3489bis-01, as well as rfc3489, > defines the > terms for the various NAT types. The new udp-behave draft spends some > time, in section 6, trying to map the new definitions in > udp-behave with > the definitions in rfc3489. > > I think that this serves no purpose. > > The behave drafts are clear, I think, that the terminology in RFC3489 > was problematic, and that it was better to define a set of orthogonal > behaviors that could be named. Thus, I think that it is a futile > exercise to try and go back and clarify what we mean by > "symmetric nat" > by mapping the new behaviors in udp-behave to the concepts in 3489. > > I would instead propose that: > > 1. we remove the definitions of > symmetric/full-cone/port-restricted/etc. > from rfc3489bis. These definitions are not used anymore > except for the > IAB considerations section, where they are not really needed. > > 2. We remove all the stuff in behave-udp that tries to give > new meaning > to those terms > > 3. behave-udp update its references to rfc3489bis whenever it > needs to > mention stun > > Comments? > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From dwing@cisco.com Wed, 9 Mar 2005 14:49:40 -0800 (PST) From: Dan Wing Date: Wed, 9 Mar 2005 14:49:40 -0800 (PST) Subject: Re: [Ietf-behave] remove nat type definitions from rfc3489bis In-Reply-To: <422F748E.3040408@cisco.com> Message-ID: <869932CC-90ED-11D9-9270-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I believe you still need a definition of symmetric (or whatever term you'd like to use) to explain the type of NAT that doesn't work with STUN. Perhaps the term non-STUN-friendly is sufficient, though? -d On Mar 9, 2005, at 2:11 PM, Jonathan Rosenberg wrote: During the behave meeting at this IETF, we had a lengthy and not too productive debate about the precise meaning of symmetric NAT. The current draft-ietf-behave-rfc3489bis-01, as well as rfc3489, defines the terms for the various NAT types. The new udp-behave draft spends some time, in section 6, trying to map the new definitions in udp-behave with the definitions in rfc3489. I think that this serves no purpose. The behave drafts are clear, I think, that the terminology in RFC3489 was problematic, and that it was better to define a set of orthogonal behaviors that could be named. Thus, I think that it is a futile exercise to try and go back and clarify what we mean by "symmetric nat" by mapping the new behaviors in udp-behave to the concepts in 3489. I would instead propose that: 1. we remove the definitions of symmetric/full-cone/port-restricted/etc. from rfc3489bis. These definitions are not used anymore except for the IAB considerations section, where they are not really needed. 2. We remove all the stuff in behave-udp that tries to give new meaning to those terms 3. behave-udp update its references to rfc3489bis whenever it needs to mention stun Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Wed, 9 Mar 2005 15:22:11 -0800 (PST) From: "Francois Audet" Date: Wed, 9 Mar 2005 15:22:11 -0800 (PST) Subject: RE: [Ietf-behave] remove nat type definitions from rfc3489bis Message-ID: <1ECE0EB50388174790F9694F77522CCF01B32247@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] remove nat type definitions from rfc3489bis Yes, it is already in there: Good NAT == External NAT mapping is Endpoint Independent Bad NAT == External NAT mapping is Endpoint Dependent > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wing > Sent: Wednesday, March 09, 2005 14:50 > To: Jonathan Rosenberg > Cc: Behave > Subject: Re: [Ietf-behave] remove nat type definitions from rfc3489bis > > > I believe you still need a definition of symmetric (or whatever term > you'd like to use) to explain the type of NAT that doesn't work with > STUN. Perhaps the term non-STUN-friendly is sufficient, though? > > -d > > On Mar 9, 2005, at 2:11 PM, Jonathan Rosenberg wrote: > > > During the behave meeting at this IETF, we had a lengthy and not too > > productive debate about the precise meaning of symmetric NAT. The > > current draft-ietf-behave-rfc3489bis-01, as well as > rfc3489, defines > > the terms for the various NAT types. The new udp-behave > draft spends > > some time, in section 6, trying to map the new definitions in > > udp-behave with the definitions in rfc3489. > > > > I think that this serves no purpose. > > > > The behave drafts are clear, I think, that the terminology > in RFC3489 > > was problematic, and that it was better to define a set of > orthogonal > > behaviors that could be named. Thus, I think that it is a futile > > exercise to try and go back and clarify what we mean by "symmetric > > nat" by mapping the new behaviors in udp-behave to the concepts in > > 3489. > > > > I would instead propose that: > > > > 1. we remove the definitions of > > symmetric/full-cone/port-restricted/etc. from rfc3489bis. These > > definitions are not used anymore except for the IAB considerations > > section, where they are not really needed. > > > > 2. We remove all the stuff in behave-udp that tries to give new > > meaning to those terms > > > > 3. behave-udp update its references to rfc3489bis whenever > it needs to > > mention stun > > > > Comments? > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Director, Service Provider VoIP Architecture Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From srisuresh@yahoo.com Wed, 9 Mar 2005 17:27:04 -0800 (PST) From: Pyda Srisuresh Date: Wed, 9 Mar 2005 17:27:04 -0800 (PST) Subject: Re: [Ietf-behave] remove nat type definitions from rfc3489bis Message-ID: <20050310012703.75430.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain First off, Much thanks to Jonathan for clearing this up about the terminology on Symmetric NAT & Cone NATs. As Dan points out, these terms are already out there in use by NAT endors and NAT users. We need clarification of these terms, not abandon them completely. Joanthan is dropping these terms from 3489bis. If we abandon the terms entirely, we will need to coin new terms. Given the wide use of these terms, I suggest we redefine these terms accurately in the behave-gen draft. All behave drafts will refer the definition provided in the gen draft for these terms. Any comments? Thanks. regards, suresh --- Dan Wing wrote: > I believe you still need a definition of symmetric (or whatever term > you'd like to use) to explain the type of NAT that doesn't work with > STUN. Perhaps the term non-STUN-friendly is sufficient, though? > > -d > > On Mar 9, 2005, at 2:11 PM, Jonathan Rosenberg wrote: > > > During the behave meeting at this IETF, we had a lengthy and not too > > productive debate about the precise meaning of symmetric NAT. The > > current draft-ietf-behave-rfc3489bis-01, as well as rfc3489, defines > > the terms for the various NAT types. The new udp-behave draft spends > > some time, in section 6, trying to map the new definitions in > > udp-behave with the definitions in rfc3489. > > > > I think that this serves no purpose. > > > > The behave drafts are clear, I think, that the terminology in RFC3489 > > was problematic, and that it was better to define a set of orthogonal > > behaviors that could be named. Thus, I think that it is a futile > > exercise to try and go back and clarify what we mean by "symmetric > > nat" by mapping the new behaviors in udp-behave to the concepts in > > 3489. > > > > I would instead propose that: > > > > 1. we remove the definitions of > > symmetric/full-cone/port-restricted/etc. from rfc3489bis. These > > definitions are not used anymore except for the IAB considerations > > section, where they are not really needed. > > > > 2. We remove all the stuff in behave-udp that tries to give new > > meaning to those terms > > > > 3. behave-udp update its references to rfc3489bis whenever it needs to > > mention stun > > > > Comments? > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Director, Service Provider VoIP Architecture Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From jdrosen@cisco.com Wed, 9 Mar 2005 18:07:04 -0800 (PST) From: Jonathan Rosenberg Date: Wed, 9 Mar 2005 18:07:04 -0800 (PST) Subject: Re: [Ietf-behave] remove nat type definitions from rfc3489bis In-Reply-To: <20050310012703.75430.qmail@web40426.mail.yahoo.com> Message-ID: <422FABB4.1080804@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I don't think it is our objective to obliterate the definition from the world's vocabulary. It is our objective to define sufficient terminology to convey the requirements we need to convey in the documents we are trying to produce. I believe the terminology defined in the udp-behave draft, which uses terms for each individual component behavior, is the ideal way to do that. The fact that we cannot agree on what a symmetric NAT is, merely elucidates that point. -Jonathan R. Pyda Srisuresh wrote: First off, Much thanks to Jonathan for clearing this up about the terminology on Symmetric NAT & Cone NATs. As Dan points out, these terms are already out there in use by NAT endors and NAT users. We need clarification of these terms, not abandon them completely. Joanthan is dropping these terms from 3489bis. If we abandon the terms entirely, we will need to coin new terms. Given the wide use of these terms, I suggest we redefine these terms accurately in the behave-gen draft. All behave drafts will refer the definition provided in the gen draft for these terms. Any comments? Thanks. regards, suresh --- Dan Wing wrote: I believe you still need a definition of symmetric (or whatever term you'd like to use) to explain the type of NAT that doesn't work with STUN. Perhaps the term non-STUN-friendly is sufficient, though? -d On Mar 9, 2005, at 2:11 PM, Jonathan Rosenberg wrote: During the behave meeting at this IETF, we had a lengthy and not too productive debate about the precise meaning of symmetric NAT. The current draft-ietf-behave-rfc3489bis-01, as well as rfc3489, defines the terms for the various NAT types. The new udp-behave draft spends some time, in section 6, trying to map the new definitions in udp-behave with the definitions in rfc3489. I think that this serves no purpose. The behave drafts are clear, I think, that the terminology in RFC3489 was problematic, and that it was better to define a set of orthogonal behaviors that could be named. Thus, I think that it is a futile exercise to try and go back and clarify what we mean by "symmetric nat" by mapping the new behaviors in udp-behave to the concepts in 3489. I would instead propose that: 1. we remove the definitions of symmetric/full-cone/port-restricted/etc. from rfc3489bis. These definitions are not used anymore except for the IAB considerations section, where they are not really needed. 2. We remove all the stuff in behave-udp that tries to give new meaning to those terms 3. behave-udp update its references to rfc3489bis whenever it needs to mention stun Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From srisuresh@yahoo.com Wed, 9 Mar 2005 19:36:37 -0800 (PST) From: Pyda Srisuresh Date: Wed, 9 Mar 2005 19:36:37 -0800 (PST) Subject: Re: [Ietf-behave] remove nat type definitions from rfc3489bis In-Reply-To: <422FABB4.1080804@cisco.com> Message-ID: <20050310033636.95268.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Jonathan Rosenberg wrote: > I don't think it is our objective to obliterate the definition from the > world's vocabulary. [suresh] What I am saying is to keep the terms, but revise the definitions. I.e., Donot obliterate the terms, but define them more precisely in another draft, so the terms can be used with the revised definition. At this time, behave-nat-udp draft and srisuresh-behave-p2p-state use these terms. Even if behave-udp draft can do away with the terms, these terms have use in srsuresh-behave-p2p-state draft. > It is our objective to define sufficient terminology > to convey the requirements we need to convey in the documents we are > trying to produce. I believe the terminology defined in the udp-behave > draft, which uses terms for each individual component behavior, is the > ideal way to do that. [suresh] Sure. When use of these terms are not necessary, using different set of terminology to carry the same intent seems reasonable. > The fact that we cannot agree on what a symmetric > NAT is, merely elucidates that point. [suresh] We agree that the definition of symmetric NAT & Cone NATs in 3489 is problematic. But, that is not to say, we cannot fix it. Here is a suggestion for revised definitions. Please comment if the following revised definitions meet the intent. Thanks. Symmetric NAT - A variation NAPT that does NOT use port binding for TCP/UDP sessions originating from private hosts. If a TCP/UDP endpoint on a private host, denoted by the tuple of (IP address, port no), originated multiple sessions, a new public TCP/UDP port is assigned to translate the private endpoint in each new session. Port Restricted Cone NAT - A variation of NAPT that uses Port Binding for TCP/UDP sessions originating from private hosts and would permit packets in the inbound direction for just the sessions the private host had initiated. If a TCP/UDP endpoint on a private host, denoted by the tuple of (IP address, port no), originated multiple sessions, the same public TCP/UDP port is assigned to translate the private endpoint in each new session. Further, only the packets that belong to the sessions initiated by the private host are permitted on the inbound. Address Restricted Cone NAT - A variation of NAPT that uses Port Binding for TCP/UDP sessions originating from private hosts, but differs in how it permits inbound UDP packets from Port Restricted Cone NAT as follows. Subsequent to creating a UDP port binding for an endpoint on a private host, Address-restricted Cone NAT will accept incoming UDP packets to the corresponding public port from only those external endpoints whose IP address match the address of external endpoint to which the private endpoint had initiated outgoing sessions. Full Cone NAT - A variation NAPT that uses Port Binding for TCP/UDP sessions originating from private hosts, but differs in how it permits inbound UDP packets from Address/Port Restrictd Cone NATs as follows. Subsequent to creating a UDP port binding for an endpoint on a private host, Full Cone NAT will accept incoming UDP packets to the corresponding public port from any external endpoint. regards, suresh > > -Jonathan R. > > > Pyda Srisuresh wrote: > > > First off, Much thanks to Jonathan for clearing this up about the > terminology > > on Symmetric NAT & Cone NATs. > > > > As Dan points out, these terms are already out there in use by NAT endors > and > > NAT users. We need clarification of these terms, not abandon them > completely. > > Joanthan is dropping these terms from 3489bis. If we abandon the terms > > entirely, we will need to coin new terms. Given the wide use of these > terms, I > > suggest we redefine these terms accurately in the behave-gen draft. All > behave > > drafts will refer the definition provided in the gen draft for these terms. > > > > > Any comments? Thanks. > > > > regards, > > suresh > > > > --- Dan Wing wrote: > > > >>I believe you still need a definition of symmetric (or whatever term > >>you'd like to use) to explain the type of NAT that doesn't work with > >>STUN. Perhaps the term non-STUN-friendly is sufficient, though? > >> > >>-d > >> > >>On Mar 9, 2005, at 2:11 PM, Jonathan Rosenberg wrote: > >> > >> > >>>During the behave meeting at this IETF, we had a lengthy and not too > >>>productive debate about the precise meaning of symmetric NAT. The > >>>current draft-ietf-behave-rfc3489bis-01, as well as rfc3489, defines > >>>the terms for the various NAT types. The new udp-behave draft spends > >>>some time, in section 6, trying to map the new definitions in > >>>udp-behave with the definitions in rfc3489. > >>> > >>>I think that this serves no purpose. > >>> > >>>The behave drafts are clear, I think, that the terminology in RFC3489 > >>>was problematic, and that it was better to define a set of orthogonal > >>>behaviors that could be named. Thus, I think that it is a futile > >>>exercise to try and go back and clarify what we mean by "symmetric > >>>nat" by mapping the new behaviors in udp-behave to the concepts in > >>>3489. > >>> > >>>I would instead propose that: > >>> > >>>1. we remove the definitions of > >>>symmetric/full-cone/port-restricted/etc. from rfc3489bis. These > >>>definitions are not used anymore except for the IAB considerations > >>>section, where they are not really needed. > >>> > >>>2. We remove all the stuff in behave-udp that tries to give new > >>>meaning to those terms > >>> > >>>3. behave-udp update its references to rfc3489bis whenever it needs to > >>>mention stun > >>> > >>>Comments? > >>> > >>>-Jonathan R. > >>> > >>>-- > >>>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>>Director, Service Provider VoIP Architecture Parsippany, NJ > >>>07054-2711 > >>>Cisco Systems > >>>jdrosen@xxxxxxxxx FAX: (973) 952-5050 > >>>http://www.jdrosen.net PHONE: (973) 952-5000 > >>>http://www.cisco.com > >>>_______________________________________________ > >>>Ietf-behave mailing list > >>>Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>> > >> > >>_______________________________________________ > >>Ietf-behave mailing list > >>Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > From audet@nortel.com Thu, 10 Mar 2005 06:59:52 -0800 (PST) From: "Francois Audet" Date: Thu, 10 Mar 2005 06:59:52 -0800 (PST) Subject: RE: [Ietf-behave] remove nat type definitions from rfc3489bis Message-ID: <1ECE0EB50388174790F9694F77522CCF01B32404@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] remove nat type definitions from rfc3489bis Exactly. The fact that we spent 90% of the presentation's time arguing about what symmetric NAT meant proves that the terminoly is indeed problematic. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jonathan Rosenberg > Sent: Wednesday, March 09, 2005 18:07 > To: Pyda Srisuresh > Cc: Behave > Subject: Re: [Ietf-behave] remove nat type definitions from rfc3489bis > > > I don't think it is our objective to obliterate the > definition from the > world's vocabulary. It is our objective to define sufficient > terminology > to convey the requirements we need to convey in the documents we are > trying to produce. I believe the terminology defined in the > udp-behave > draft, which uses terms for each individual component > behavior, is the > ideal way to do that. The fact that we cannot agree on what a > symmetric > NAT is, merely elucidates that point. > > -Jonathan R. > > > Pyda Srisuresh wrote: > > > First off, Much thanks to Jonathan for clearing this up about the > > terminology on Symmetric NAT & Cone NATs. > > > > As Dan points out, these terms are already out there in use by NAT > > endors and NAT users. We need clarification of these terms, not > > abandon them completely. Joanthan is dropping these terms from > > 3489bis. If we abandon the terms entirely, we will need to coin new > > terms. Given the wide use of these terms, I suggest we > redefine these > > terms accurately in the behave-gen draft. All behave drafts > will refer > > the definition provided in the gen draft for these terms. > > > > Any comments? Thanks. > > > > regards, > > suresh > > > > --- Dan Wing wrote: > > > >>I believe you still need a definition of symmetric (or whatever term > >>you'd like to use) to explain the type of NAT that doesn't > work with > >>STUN. Perhaps the term non-STUN-friendly is sufficient, though? > >> > >>-d > >> > >>On Mar 9, 2005, at 2:11 PM, Jonathan Rosenberg wrote: > >> > >> > >>>During the behave meeting at this IETF, we had a lengthy > and not too > >>>productive debate about the precise meaning of symmetric NAT. The > >>>current draft-ietf-behave-rfc3489bis-01, as well as > rfc3489, defines > >>>the terms for the various NAT types. The new udp-behave > draft spends > >>>some time, in section 6, trying to map the new definitions in > >>>udp-behave with the definitions in rfc3489. > >>> > >>>I think that this serves no purpose. > >>> > >>>The behave drafts are clear, I think, that the terminology > in RFC3489 > >>>was problematic, and that it was better to define a set of > orthogonal > >>>behaviors that could be named. Thus, I think that it is a futile > >>>exercise to try and go back and clarify what we mean by "symmetric > >>>nat" by mapping the new behaviors in udp-behave to the concepts in > >>>3489. > >>> > >>>I would instead propose that: > >>> > >>>1. we remove the definitions of > >>>symmetric/full-cone/port-restricted/etc. from rfc3489bis. These > >>>definitions are not used anymore except for the IAB considerations > >>>section, where they are not really needed. > >>> > >>>2. We remove all the stuff in behave-udp that tries to give new > >>>meaning to those terms > >>> > >>>3. behave-udp update its references to rfc3489bis whenever > it needs > >>>to > >>>mention stun > >>> > >>>Comments? > >>> > >>>-Jonathan R. > >>> > >>>-- > >>>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>>Director, Service Provider VoIP Architecture Parsippany, NJ > >>>07054-2711 > >>>Cisco Systems > >>>jdrosen@xxxxxxxxx FAX: > (973) 952-5050 > >>>http://www.jdrosen.net PHONE: > (973) 952-5000 > >>>http://www.cisco.com > _______________________________________________ > >>>Ietf-behave mailing list > >>>Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>> > >> > >>_______________________________________________ > >>Ietf-behave mailing list > >>Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From jdrosen@cisco.com Fri, 11 Mar 2005 01:25:26 -0800 (PST) From: Jonathan Rosenberg Date: Fri, 11 Mar 2005 01:25:26 -0800 (PST) Subject: Re: [Ietf-behave] remove nat type definitions from rfc3489bis In-Reply-To: <20050310033636.95268.qmail@web40429.mail.yahoo.com> Message-ID: <423163F9.1010803@cisco.com> MIME-Version: 1.0 Content-Type: text/plain inline. Pyda Srisuresh wrote: --- Jonathan Rosenberg wrote: I don't think it is our objective to obliterate the definition from the world's vocabulary. [suresh] What I am saying is to keep the terms, but revise the definitions. I.e., Donot obliterate the terms, but define them more precisely in another draft, so the terms can be used with the revised definition. At this time, behave-nat-udp draft and srisuresh-behave-p2p-state use these terms. Even if behave-udp draft can do away with the terms, these terms have use in srsuresh-behave-p2p-state draft. That is a separate issue; this is your own individual draft - you are free to put whatever text you want in it. If we agree that none of the documents the group is working on are require the definition, then we can move on. The fact that we cannot agree on what a symmetric NAT is, merely elucidates that point. [suresh] We agree that the definition of symmetric NAT & Cone NATs in 3489 is problematic. But, that is not to say, we cannot fix it. Here is a suggestion for revised definitions. Please comment if the following revised definitions meet the intent. Thanks. Our solution to fix it was to recognize that it would be better to define NATs based on specific behavioral axes, which are spelled out and more rigorously defined in the udp-behave draft. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From srisuresh@yahoo.com Sun, 13 Mar 2005 23:31:18 -0800 (PST) From: Pyda Srisuresh Date: Sun, 13 Mar 2005 23:31:18 -0800 (PST) Subject: [Ietf-behave] Comments on draft-ietf-behave-nat-udp-00.txt Message-ID: <20050314073117.51780.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Francois & Cullen, Had a chance to review your draft. My comments are largely centered around terminology and TCP/UDP common concepts. Some are non-standard terms. Some relate to terms that are not UDP specific and apply to both TCP & UDP. I believe, terms that apply to both TCP & UDP behave drafts shoudl not be replicated/redefined in both drafts, rather they should go into a single behave-gen draft. Likewise, recommendations that relate to IP/ICMP processing belong in behave-gen draft. Lastly, all behave drafts advising the NAT vendors should use common terminology so it is not confusing when switching between the behave documents. As such, I believe, all behave drafts shoudl refer a single behave-gen draft that centralizes all the behave terminology. My detailed comments below. 1. Terminology and Common concepts Section 4 (NAPT behavior) - This whole section describes generic NAT issues. Instead, this shoudl refer the behave-gen draft. Section 4.1 describes the translation behavior in terms of "External NAT mapping" or "Address and port Mapping" . Why not use the standard term "Address/port Binding" for this? Port Binding support or the lack of is the major distinction between Cone NATs and symmetric NAT as far as translation behavior is concerned. As for the filering behavior, section 5 and 5.1 describe "endpoint address and port dependent", "endpoint address dependent", and "endpoint address and port independent" behavior in details. My own preference would be to charcaterize the filterign behavior in terms of ?Port Restricted Cone NAT?, ?Address Restricted Cone NAT? and ?Full Cone NAT?. But, if you prefer a different terminology, I understand. We should probably poll the list on this. In either case, I believe, the characterizations shoudl be centralied in a single behave-gen draft. Section 4.1 defines "Arbitrary" and "Paired" Address Pooling ? These are apparently new terms to describe dynamic address bind and static address binding. Why not reuse the existign terms? Section 4.2 discusses "Port Asisgnment" behavior, "Port preservation" behavior , "port overloading" etc. All these concepts are not UDP specific (and have been discussed in TCP draft as well). As such, this is another set of terms that should be centralized in behave-gen draft. Same goes with discussion of Well-known ports, registered ports, dynamic ports etc. Sections 4.3 & 4.4 discuss "Mapping Refresh Direction" and "Mapping Refresh Scope". These are new terms and are confusing. The term "Mapping" here is used to refer to "NAT Sesions" and "Binding" at different times. Why not use existing terms "NAT Session Idle timeout" and "Bind Idle timeout". The concepts are identical for both TCP and UDP. The TCP draft uses these existing terms. Also, a lot of text of was spent describing whether idletime should be refreshed on inbound packets or outbound packets or both. By definition, the idletime for a NAT Session should be reset when there is traffic in either direction of the sessions. Likewise, the idletime for a Bind is reset when there is at least one NAT Session using the Bind. Vendors may choose to implement the idletime processing any whichway they like. I dont believe, the behave draft needs to go into the implementation details of refresh processing. Section 7 discusses Multi Level Nat and Hairpinnign behavior. Once again, these concepts are not UDP specific. Suggest refering behave-gen draft for these. Section 8 refers to ALGs. Section 10 refers to ICMP behavior. Section 11 & Section refer to IP fragmentation and Path MTU message procssing. All these are not UDP specific and shoudl be referred from a single behave-gen draft. 2. Recommendations: REQ-2 : This says - "It is RECOMMENDED that a NAT have an "IP address pooling" behavior of "Paired". Note that this requirement is not applicable to NATs that do not support IP address pooling". I suspect, this means it shoudl be possible to configure a NAt for static address maps, so it genrates static address binds. Why? This depends on how the NAT is configured. If you are saying, it shoudl be possible to configure a NAT with static address/port maps, why not also say that it shoudl be possible to configure a NAT with dynamic address maps? To me, this seems like a superfluous requirement. REQ-3 - This belongs in the behave-gen draft, I believe. REQ-5: This is UDP NAT Session idletimeout. REQ-6: Assumign, you are referign to "NAT Session idel timeout" and ""Bind Idle timeout", the implementations details of idletime refreshing is not relevant here, IMHO. REQ-7: I agree with your recommendation for "Address restricted Cone NAT" filterign behavior. Here is one reason why I think this makes sense. TFTP is a popular protocol during bringup time. In TFTP protocol (ref: RFC 1350), the initiating client sends a TFTP request with UDP SrcPort set to XX and DestPort set to 69. The TFTP servr responds back with SrcPort set to YY and DestPort set to XX. As you will notice, the TFTP would not work with a Port Restricted Cone NAT, but will work with an Address restricted Cone NAT. Considerign that UDP doesnt enforce a strict session behavior (unlike TCP), I would suggest that the NATs be recommended to support Address Restricted Cone NAt behavior rather than Port Restricted Cone NAT behavior. REQ-8: This is hairpin translation behvaior. I believem, this shoudl be moved to behave-gen draft. REQ-9 - Well, we discussed this in the WG meeting. I guess, the consensus was to enable certain default ALGs (FTP & DNS). REQ-10 - Agree with this. But, this needs a hint on what you mean. Fundamentally, a binding in use by a NAT Session does not change in the middle o f the NAT Session use, unless the NAT Session has idle timedout and this is the only NAT Session usign the Bind. So, how exactly shoudl the user enforce this - in what scenario, did you mean? REQ-11,12,13 - They elogn to behave-gen draft. Thats all for now. regards, suresh From fluffy@cisco.com Tue, 15 Mar 2005 11:02:17 -0800 (PST) From: Cullen Jennings Date: Tue, 15 Mar 2005 11:02:17 -0800 (PST) Subject: Re: [Ietf-behave] remove nat type definitions from rfc3489bis In-Reply-To: <422F748E.3040408@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Not as chair ... Yes - I think that sounds like a really good idea. W On 3/9/05 4:11 PM, "Jonathan Rosenberg" wrote: > During the behave meeting at this IETF, we had a lengthy and not too > productive debate about the precise meaning of symmetric NAT. The > current draft-ietf-behave-rfc3489bis-01, as well as rfc3489, defines the > terms for the various NAT types. The new udp-behave draft spends some > time, in section 6, trying to map the new definitions in udp-behave with > the definitions in rfc3489. > > I think that this serves no purpose. > > The behave drafts are clear, I think, that the terminology in RFC3489 > was problematic, and that it was better to define a set of orthogonal > behaviors that could be named. Thus, I think that it is a futile > exercise to try and go back and clarify what we mean by "symmetric nat" > by mapping the new behaviors in udp-behave to the concepts in 3489. > > I would instead propose that: > > 1. we remove the definitions of symmetric/full-cone/port-restricted/etc. > from rfc3489bis. These definitions are not used anymore except for the > IAB considerations section, where they are not really needed. > > 2. We remove all the stuff in behave-udp that tries to give new meaning > to those terms > > 3. behave-udp update its references to rfc3489bis whenever it needs to > mention stun > > Comments? > > -Jonathan R. From fluffy@cisco.com Tue, 15 Mar 2005 17:09:35 -0800 (PST) From: Cullen Jennings Date: Tue, 15 Mar 2005 17:09:35 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050307235730.78688.qmail@web40423.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Not as chair I look forward to getting the TCP folks input on this but I believe one of the issues in trying to say that devices should process out of order packets is what to do about the DOS attacks this creates if lots of out of order packets are sent. Right now I don't see how we could recommend that a NAT process out of order packets because we would need to say that if you got lots of them, then the NAT would need to stop doing the out of order processing or else it would run out of memory. This would be exactly the sort of non deterministic behavior that we are trying to stop. Cullen On 3/7/05 5:57 PM, "Pyda Srisuresh" wrote: > > --- Spencer Dawkins wrote: >> My understanding from this morning's meeting was that we were leaning >> toward not requiring Behave-conformant NATs to process out-of-order >> TCP fragments, with the expectation that endpoints would be doing Path >> MTU discovery anyway, so fragmentation shouldn't be an issue. >> > [suresh] If you are talking about processing out of order IP fragments in > general, I believe, the chairs said we would take this to the list. If NATs do > not handle IP fragments correctly, it is a major problem for applications that > use IP fragments (ex: NFS over UDP). I believe, this is a MUST for NATs. > > regards, > suresh > >> I ran into Mark Allman this afternoon and asked him if he had an >> opinion on the robustness of Path MTU discovery on the Internet. He >> does, and has recently co-authored a paper that discusses this >> (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). >> In section 4.3 of the paper, he's seeing that about one-third of the >> 85,000 servers identified by the NLANR Web Caching project don't >> attempt Path MTU discovery at all, and another 17 percent attempt it >> and fail. The failure rate is even higher for a list of 500 popular >> web server (35%). >> >> So I'm wondering if we need to think about this a little more? >> >> Spencer >> >> p.s. I copied Mark, just in case I'm misunderstanding the paper... >> >> >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Tue, 15 Mar 2005 17:32:51 -0800 (PST) From: Cullen Jennings Date: Tue, 15 Mar 2005 17:32:51 -0800 (PST) Subject: Re: [Ietf-behave] remove nat type definitions from rfc3489bis In-Reply-To: <20050310033636.95268.qmail@web40429.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 3/9/05 9:36 PM, "Pyda Srisuresh" wrote: > suresh] We agree that the definition of symmetric NAT & Cone NATs in 3489 is > problematic. But, that is not to say, we cannot fix it. Here is a suggestion > for revised definitions. Please comment if the following revised definitions > meet the intent. Thanks. > > Symmetric NAT - A variation NAPT that does NOT use port binding for TCP/UDP > sessions originating from private hosts. If a TCP/UDP endpoint on a private > host, denoted by the tuple of (IP address, port no), originated multiple > sessions, a new public TCP/UDP port is assigned to translate the private > endpoint in each new session. > > Port Restricted Cone NAT - A variation of NAPT that uses Port Binding for > TCP/UDP sessions originating from private hosts and would permit packets in > the > inbound direction for just the sessions the private host had initiated. If a > TCP/UDP endpoint on a private host, denoted by the tuple of (IP address, port > no), originated multiple sessions, the same public TCP/UDP port is assigned to > translate the private endpoint in each new session. Further, only the packets > that belong to the sessions initiated by the private host are permitted on the > inbound. > > Address Restricted Cone NAT - A variation of NAPT that uses Port Binding for > TCP/UDP sessions originating from private hosts, but differs in how it permits > inbound UDP packets from Port Restricted Cone NAT as follows. Subsequent to > creating a UDP port binding for an endpoint on a private host, > Address-restricted Cone NAT will accept incoming UDP packets to the > corresponding public port from only those external endpoints whose IP address > match the address of external endpoint to which the private endpoint had > initiated outgoing sessions. > > Full Cone NAT - A variation NAPT that uses Port Binding for TCP/UDP sessions > originating from private hosts, but differs in how it permits inbound UDP > packets from Address/Port Restrictd Cone NATs as follows. Subsequent to > creating a UDP port binding for an endpoint on a private host, Full Cone NAT > will accept incoming UDP packets to the corresponding public port from any > external endpoint. not as chair. I find all these definitions horribly under specified and there has been many many emails discussing that we don't have common agreement on terms like binding. The terminology that is in the current drafts is understood and was selected because it was stuff that people did agree on the meaning of it. Unless we find a need to define these terms, I see it as a long and frustrating exercise with no strong benefit when it is done. From kbiswas@cisco.com Tue, 15 Mar 2005 21:45:37 -0800 (PST) From: Kaushik Biswas Date: Tue, 15 Mar 2005 21:45:37 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050307235730.78688.qmail@web40423.mail.yahoo.com> Message-ID: <4.3.2.7.2.20050315211112.02e2fb28@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Valid point. In my opinion we should be putting a MAY against this requirement in the TCP draft on the same lines as UDP draft has. In the Security Section there is discussion cautioning NAT implementers about this. This might need to be expanded. Kaushik At 05:09 PM 3/15/2005 -0800, Cullen Jennings wrote: Not as chair I look forward to getting the TCP folks input on this but I believe one of the issues in trying to say that devices should process out of order packets is what to do about the DOS attacks this creates if lots of out of order packets are sent. Right now I don't see how we could recommend that a NAT process out of order packets because we would need to say that if you got lots of them, then the NAT would need to stop doing the out of order processing or else it would run out of memory. This would be exactly the sort of non deterministic behavior that we are trying to stop. Cullen On 3/7/05 5:57 PM, "Pyda Srisuresh" wrote: > > --- Spencer Dawkins wrote: >> My understanding from this morning's meeting was that we were leaning >> toward not requiring Behave-conformant NATs to process out-of-order >> TCP fragments, with the expectation that endpoints would be doing Path >> MTU discovery anyway, so fragmentation shouldn't be an issue. >> > [suresh] If you are talking about processing out of order IP fragments in > general, I believe, the chairs said we would take this to the list. If NATs do > not handle IP fragments correctly, it is a major problem for applications that > use IP fragments (ex: NFS over UDP). I believe, this is a MUST for NATs. > > regards, > suresh > >> I ran into Mark Allman this afternoon and asked him if he had an >> opinion on the robustness of Path MTU discovery on the Internet. He >> does, and has recently co-authored a paper that discusses this >> (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). >> In section 4.3 of the paper, he's seeing that about one-third of the >> 85,000 servers identified by the NLANR Web Caching project don't >> attempt Path MTU discovery at all, and another 17 percent attempt it >> and fail. The failure rate is even higher for a list of 500 popular >> web server (35%). >> >> So I'm wondering if we need to think about this a little more? >> >> Spencer >> >> p.s. I copied Mark, just in case I'm misunderstanding the paper... >> >> >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From matthews@nimcatnetworks.com Wed, 16 Mar 2005 05:40:19 -0800 (PST) From: Philip Matthews Date: Wed, 16 Mar 2005 05:40:19 -0800 (PST) Subject: [Ietf-behave] A comment on draft-iab-nat-traversal-considerations-00 Message-ID: <4238373C.50902@nimcatnetworks.com> MIME-Version: 1.0 Content-Type: text/plain [I originally CC'ed this to the SIPPING list by mistake. My apologies to those who see it twice.] http://www.ietf.org/internet-drafts/draft-iab-nat-traversal-considerations-00.txt Jonathan: Here is my one major comment on this document. In a separate e-mail message, I will post a number of minor and editorial comments. In section 3, the document states that there are three logical components involved (client, NAT, and server) and thus 7 combinations of modifications that can be made. The document then proceeds to classify each existing NAT traversal solution into one of these 7 approaches. In section 4, the document then discusses considerations for selecting a solution. What is not really clear, however, is whether the discussion in section 4 is meant to talk about the 7 approaches in general, or the specific existing solutions mentioned in the document. At times, the document seems to talk about the properties of a specific existing solution, while at other times the document seems to talk about the properties of a general approach (i.e., one of the 7). For example, much of section 4 talks about the problems with the ALG approach. Since no specific examples of ALGs are discussed, it seems that any specific solution that involves modifying the NAT alone is covered by this discussion, and thus much of section 4 is really a discussion of the properties of the "Modifying the NAT" approach. In my opinion, the document would be much more useful if it presented a systematic exploration of the strengths and weaknesses of *each* of the 7 approaches. That is, rather than discussing the properties of a specific solution within one of the 7 general approaches, the document would discuss the properties of each approach in general. As mentioned above, the document already seems to do this for the approach of "Modifying the NAT". Unfortunately, because there is no similar discussion about the properties of the other approaches, these sections read somewhat like a rant against ALGs rather than a reasoned discussion. Certainly, as I read these sections, I was thinking that some of these comments also applied to other approaches. So specifically, I suggest organizing the document so that it systematically goes through each of the 7 approaches and talks about the security and other properties of the approach in general, and only talks about specific solutions within the approach when necessary to illustrate a point. Doing this would help focus IETF work into certain approaches. For example, it might become clear that only one or two approaches are really suitable, and the IETF should focus its efforts into developing solutions within these approaches. - Philip From matthews@nimcatnetworks.com Wed, 16 Mar 2005 05:44:53 -0800 (PST) From: Philip Matthews Date: Wed, 16 Mar 2005 05:44:53 -0800 (PST) Subject: [Ietf-behave] Minor and editorial comments on draft-iab-nat-traversal-considerations-00 Message-ID: <4238384F.3020704@nimcatnetworks.com> MIME-Version: 1.0 Content-Type: text/plain [I originally CC'ed this to the SIPPING list by mistake. My apologies to those who see it twice.] http://www.ietf.org/internet-drafts/draft-iab-nat-traversal-considerations-00.txt Jonathan: Here are some minor and editorial comments on this document. In a separate e-mail message, I will post my one major comment. - Philip MINOR COMMENTS *) The terminology and discussion in this document is mostly oriented towards client-server applications. However, on close reading, it seems that much of the discussion is also applicable to peer-to-peer applications. (For example, Figure 1 does show a line between clients, so reading "peer" for "client" makes it applicable to peer-to-peer work). It would be nice if the terminology and discussion could be changed slightly to make this wider applicability more obvious. *) In a number of places, this document uses the term "Service Provider". To me the term "Service Provider" in an IETF document is a synonym for "Internet Service Provider", and in the context of this draft I automatically think of the ISP that is providing a client with access to the Internet. However, the document seems to use the term "Service Provider" to mean the organization that controls the servers shown in Figure 1. I suggest the document just say "the organization controlling the servers" and shorten this to "server manager" where necessary. *) Mostly the document says "the NAT" or "a NAT" to mean a box, but at times it says just "NAT" to mean the technology. I suggest the document uses "NAT" to mean the box, and "Network Address Translation" to refer to the technology. *) [Section 3.2] The long discussion of TURN in comparison to the very short discussion of STUN and Teredo seems odd and out-of-place. A one-sentence description of TURN with a reference would seem more appropriate. *) [Section 3.3] In the description of an SBC, you may wish to clarify that an SBC looks at addresses and ports in the received IP/TCP/UDP header rather than the addresses and ports in the SIP message headers. *) [Section 3.3] The document says "... making the SIP network look more like a pure client/server network". Rather than what? I believe you mean "... rather than a pure peer-to-peer SIP network". If so, I suggest you should either explain why this is interested or important, or just drop the entire comment altogether. *) [Section 3.6] Could you give examples of protocols engineered to traverse NATs? *) [Section 4.1.1] "... IP addresses or domain names ... are exactly the parts of the message that are the most critical to protect." I don't agree that these are the most critical to protect in every case. For example, if I am worried about protecting my SIP call, personally I would first encrypt the media stream, and only then would I try to ensure the media stream went to the right place. And similarly with e-mail. I suggest you simply delete the words "... the most ...". *) [Section 4.1.1] You may wish to mention the problem of a message being delivered to the wrong host. For example, section 2.4 of draft-ford-behave-app-00 gives an example of this, and I suspect that examples of how NATs can misroute packets in certain race conditions can also be constructed. These are not really attacks, but they have a similar effect. *) [Section 4.1.1] It would be nice to see a justification for the statements in the last paragraph of this section. *) [Section 4.1.2] I found the discussion in paragraphs 3 onward difficult to follow. First of all, it took me a while to understand that the references to "... these attacks ..." in various paragraphs are all referring back to the attacks documented in RFC 3489. Second, since I had not read this RFC, the discussion was very cryptic. To make this document more self-contained, I suggest you give a brief summary of these attacks. *) [Section 4.3] This section talks about the visibility that a service provider has into problems. But users and the administrator of the network behind the NAT also want visibility into problems! This is especially true for peer-to-peer applications, but is also true for client-server applications. (I suspect that simply removing references to "service provider" would make much of the discussion in this section more general.) EDITORIAL COMMENTS *) [Section 1, 3rd PP] "... selection of general technique ...". Missing "a". *) [Section 1, 4th PP] "... a matching outbound communications ...". Remove the "s". *) [Section 2, first PP after Figure 1] "... is shown in Figure 1 In this model, ...". Missing ".". *) [Section 3.1, first PP] "RFC ... defines an Application Layer Gateway as ... translation agents ...". Singular/plural mismatch. *) [Section 4.1.1, 1st PP] "... assumes uniquess ...". Misspelled "uniqueness". *) [Section 4.1.1, Eavesdropping PP] "the attacker can modify ... to point to themselves". Singular/plural mismatch. *) [Section 4.1.1, Service Disruption PP] "... this will likely disrupt operation of the protocol, ...". Suggest inserting "the" before "operation". *) [Section 4.1.1, Service Disruption PP] "... the client receives no service.". Suggest rewording as "... the client does not receive any service". *) [Section 4.1.1, 2nd PP on page 10] "... as opposed to in the clients ...". Suggest inserting the word "residing" between "to" and "in". *) [Section 4.1.2, 1st PP] "... another class of attacks are possible depending on the way in which the traversal technique ...". Suggest replacing with "... another class of attacks depend on the way the traversal technique ..." *) [Section 4.4, 3rd PP] "... less brittle. service providers ...". Missing initial capital letter. From srisuresh@yahoo.com Wed, 16 Mar 2005 07:53:18 -0800 (PST) From: Pyda Srisuresh Date: Wed, 16 Mar 2005 07:53:18 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets Message-ID: <20050316155318.89539.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, I think, there are two parts to this. First, the processing of IP fragments (In-order or out-of-order). Should NATs support IP fragments? Second, the processing of out-of-order IP fragments. Should, NATs support out-of-order IP fragments? I believe, IP fragment support is a MUST because this is a fundamental aspect of IP, and NATs providing transparancy to IP should support transparant traversal of IP fragments. Once IP fragment traversal is supported, the memory issues remain the same no matter whether frgaments come in order or out of order. So, I believe, the answer is YES to both. Please see my responses inline. cheers, suresh --- Cullen Jennings wrote: > > Not as chair > > I look forward to getting the TCP folks input on this but I believe one of > the issues in trying to say that devices should process out of order packets > is what to do about the DOS attacks this creates if lots of out of order > packets are sent. > > Right now I don't see how we could recommend that a NAT process out of order > packets because we would need to say that if you got lots of them, then the > NAT would need to stop doing the out of order processing or else it would > run out of memory. [suresh] Yes, there can be lots of frgaments - no matter whether they came in order of out of order. Are you saying, NATs should not support IP fragments at all? As for memory requirements, a NAT perhaps needs to set aside a percentage of in-flight packet buffers for fragment reassembly. When NAT runs out of memory, it will drop unassembled fragments. Else, it will forward the assembled packets. Why is this a problem? NATs have to do this to fight various types of DoS attacks. > This would be exactly the sort of non deterministic > behavior that we are trying to stop. > [suresh] I disagree. Packets are often dropped in the network for various reasons - such as devices not having receive buffers at a certain bursty instance. But, IP is resilient to deal with this type of occasional non-deterministic behavior (i.e., packet drops). Packets will be dropped with or without IP fragment support on a NAT under some bursty instances or DoS scenarios. cheers, suresh > Cullen > > > On 3/7/05 5:57 PM, "Pyda Srisuresh" wrote: > > > > > --- Spencer Dawkins wrote: > >> My understanding from this morning's meeting was that we were leaning > >> toward not requiring Behave-conformant NATs to process out-of-order > >> TCP fragments, with the expectation that endpoints would be doing Path > >> MTU discovery anyway, so fragmentation shouldn't be an issue. > >> > > [suresh] If you are talking about processing out of order IP fragments in > > general, I believe, the chairs said we would take this to the list. If NATs > do > > not handle IP fragments correctly, it is a major problem for applications > that > > use IP fragments (ex: NFS over UDP). I believe, this is a MUST for NATs. > > > > regards, > > suresh > > > >> I ran into Mark Allman this afternoon and asked him if he had an > >> opinion on the robustness of Path MTU discovery on the Internet. He > >> does, and has recently co-authored a paper that discusses this > >> (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). > >> In section 4.3 of the paper, he's seeing that about one-third of the > >> 85,000 servers identified by the NLANR Web Caching project don't > >> attempt Path MTU discovery at all, and another 17 percent attempt it > >> and fail. The failure rate is even higher for a list of 500 popular > >> web server (35%). > >> > >> So I'm wondering if we need to think about this a little more? > >> > >> Spencer > >> > >> p.s. I copied Mark, just in case I'm misunderstanding the paper... > >> > >> > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Wed, 16 Mar 2005 08:51:50 -0800 (PST) From: Cullen Jennings Date: Wed, 16 Mar 2005 08:51:50 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <4.3.2.7.2.20050315211112.02e2fb28@mira-sjcd-3.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I think much the UDP discussion led to the idea that the MAY in the document are not very useful. We are trying to describe a set of characteristics on how a NAT behaves that allows applications to make assumptions that they can reply on. The MAY don't help this in many cases. I agree with you that this is the sort of stuff where we want to provide advice and cautions to the NAT implementers that warn them about the consequences of certain implementations. Cullen (not as chair) On 3/15/05 9:45 PM, "Kaushik Biswas" wrote: > Valid point. In my opinion we should be putting a MAY against this > requirement in the TCP draft on the same lines as UDP draft has. In the > Security Section there is discussion cautioning NAT implementers about > this. This might need to be expanded. > > Kaushik > > At 05:09 PM 3/15/2005 -0800, Cullen Jennings wrote: > >> Not as chair >> >> I look forward to getting the TCP folks input on this but I believe one of >> the issues in trying to say that devices should process out of order packets >> is what to do about the DOS attacks this creates if lots of out of order >> packets are sent. >> >> Right now I don't see how we could recommend that a NAT process out of order >> packets because we would need to say that if you got lots of them, then the >> NAT would need to stop doing the out of order processing or else it would >> run out of memory. This would be exactly the sort of non deterministic >> behavior that we are trying to stop. >> >> Cullen >> >> >> On 3/7/05 5:57 PM, "Pyda Srisuresh" wrote: >> >>> >>> --- Spencer Dawkins wrote: >>>> My understanding from this morning's meeting was that we were leaning >>>> toward not requiring Behave-conformant NATs to process out-of-order >>>> TCP fragments, with the expectation that endpoints would be doing Path >>>> MTU discovery anyway, so fragmentation shouldn't be an issue. >>>> >>> [suresh] If you are talking about processing out of order IP fragments in >>> general, I believe, the chairs said we would take this to the list. If >> NATs do >>> not handle IP fragments correctly, it is a major problem for >> applications that >>> use IP fragments (ex: NFS over UDP). I believe, this is a MUST for NATs. >>> >>> regards, >>> suresh >>> >>>> I ran into Mark Allman this afternoon and asked him if he had an >>>> opinion on the robustness of Path MTU discovery on the Internet. He >>>> does, and has recently co-authored a paper that discusses this >>>> (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). >>>> In section 4.3 of the paper, he's seeing that about one-third of the >>>> 85,000 servers identified by the NLANR Web Caching project don't >>>> attempt Path MTU discovery at all, and another 17 percent attempt it >>>> and fail. The failure rate is even higher for a list of 500 popular >>>> web server (35%). >>>> >>>> So I'm wondering if we need to think about this a little more? >>>> >>>> Spencer >>>> >>>> p.s. I copied Mark, just in case I'm misunderstanding the paper... >>>> >>>> >>>> _______________________________________________ >>>> Ietf-behave mailing list >>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >>>> >>> >>> >>> _______________________________________________ >>> Ietf-behave mailing list >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Wed, 16 Mar 2005 11:23:31 -0800 (PST) From: Cullen Jennings Date: Wed, 16 Mar 2005 11:23:31 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050316155318.89539.qmail@web40429.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain inline (not as chair) On 3/16/05 7:53 AM, "Pyda Srisuresh" wrote: > Cullen, > > I think, there are two parts to this. > > First, the processing of IP fragments (In-order or out-of-order). Should NATs > support IP fragments? > Second, the processing of out-of-order IP fragments. Should, NATs support > out-of-order IP fragments? agree on these two questions > > I believe, IP fragment support is a MUST because this is a fundamental aspect > of IP, and NATs providing transparancy to IP should support transparant > traversal of IP fragments. ok - perhaps > Once IP fragment traversal is supported, the memory > issues remain the same no matter whether frgaments come in order or out of > order. So, I believe, the answer is YES to both. not sure I agree on your logic that only way to forward in order fragments is to store and reassemble them. If the fragments arrive in order, you can save the port forward state for the flow when the first one arrives then forward each fragment as it arrives without storing any of the fragments. I think there are NATs today that have implemented this both ways. For the NATs that do reassemble out of order packets, clearly they can only do this with a limited number - so the question is can an endpoint rely on that behavior. > > Please see my responses inline. > > cheers, > suresh > > --- Cullen Jennings wrote: >> >> Not as chair >> >> I look forward to getting the TCP folks input on this but I believe one of >> the issues in trying to say that devices should process out of order packets >> is what to do about the DOS attacks this creates if lots of out of order >> packets are sent. >> >> Right now I don't see how we could recommend that a NAT process out of order >> packets because we would need to say that if you got lots of them, then the >> NAT would need to stop doing the out of order processing or else it would >> run out of memory. > > [suresh] Yes, there can be lots of frgaments - no matter whether they came in > order of out of order. Are you saying, NATs should not support IP fragments at > all? > > As for memory requirements, a NAT perhaps needs to set aside a percentage of > in-flight packet buffers for fragment reassembly. When NAT runs out of memory, > it will drop unassembled fragments. Else, it will forward the assembled > packets. Why is this a problem? NATs have to do this to fight various types of > DoS attacks. > >> This would be exactly the sort of non deterministic >> behavior that we are trying to stop. >> > [suresh] I disagree. Packets are often dropped in the network for various > reasons - such as devices not having receive buffers at a certain bursty > instance. But, IP is resilient to deal with this type of occasional > non-deterministic behavior (i.e., packet drops). Packets will be dropped with > or without IP fragment support on a NAT under some bursty instances or DoS > scenarios. > > cheers, > suresh > >> Cullen >> >> >> On 3/7/05 5:57 PM, "Pyda Srisuresh" wrote: >> >>> >>> --- Spencer Dawkins wrote: >>>> My understanding from this morning's meeting was that we were leaning >>>> toward not requiring Behave-conformant NATs to process out-of-order >>>> TCP fragments, with the expectation that endpoints would be doing Path >>>> MTU discovery anyway, so fragmentation shouldn't be an issue. >>>> >>> [suresh] If you are talking about processing out of order IP fragments in >>> general, I believe, the chairs said we would take this to the list. If NATs >> do >>> not handle IP fragments correctly, it is a major problem for applications >> that >>> use IP fragments (ex: NFS over UDP). I believe, this is a MUST for NATs. >>> >>> regards, >>> suresh >>> >>>> I ran into Mark Allman this afternoon and asked him if he had an >>>> opinion on the robustness of Path MTU discovery on the Internet. He >>>> does, and has recently co-authored a paper that discusses this >>>> (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). >>>> In section 4.3 of the paper, he's seeing that about one-third of the >>>> 85,000 servers identified by the NLANR Web Caching project don't >>>> attempt Path MTU discovery at all, and another 17 percent attempt it >>>> and fail. The failure rate is even higher for a list of 500 popular >>>> web server (35%). >>>> >>>> So I'm wondering if we need to think about this a little more? >>>> >>>> Spencer >>>> >>>> p.s. I copied Mark, just in case I'm misunderstanding the paper... >>>> >>>> >>>> _______________________________________________ >>>> Ietf-behave mailing list >>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >>>> >>> >>> >>> _______________________________________________ >>> Ietf-behave mailing list >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> From ssenthil@cisco.com Wed, 16 Mar 2005 15:11:41 -0800 (PST) From: Senthil Sivakumar Date: Wed, 16 Mar 2005 15:11:41 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050307235730.78688.qmail@web40423.mail.yahoo.com> Message-ID: <4.3.2.7.2.20050316143446.03aa28e8@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain At 05:09 PM 3/15/2005 -0800, Cullen Jennings wrote: Not as chair I look forward to getting the TCP folks input on this but I believe one of the issues in trying to say that devices should process out of order packets is what to do about the DOS attacks this creates if lots of out of order packets are sent. Right now I don't see how we could recommend that a NAT process out of order packets because we would need to say that if you got lots of them, then the NAT would need to stop doing the out of order processing or else it would run out of memory. This would be exactly the sort of non deterministic behavior that we are trying to stop. Conversely, if you don't recommend NATs to process out of order fragments, some NATs will store the fragments until the first fragment is received, some might drop them, some might just forward them (if they can). This causes non-deterministic behavior as well. Now the solution for preventing NATs from DoS attacks could be that there is a threshold for the number of fragments that can be queued and the time it can be queued. I believe these thresholds will vary based on the memory, CPU and network latency. Senthil Cullen On 3/7/05 5:57 PM, "Pyda Srisuresh" wrote: > > --- Spencer Dawkins wrote: >> My understanding from this morning's meeting was that we were leaning >> toward not requiring Behave-conformant NATs to process out-of-order >> TCP fragments, with the expectation that endpoints would be doing Path >> MTU discovery anyway, so fragmentation shouldn't be an issue. >> > [suresh] If you are talking about processing out of order IP fragments in > general, I believe, the chairs said we would take this to the list. If NATs do > not handle IP fragments correctly, it is a major problem for applications that > use IP fragments (ex: NFS over UDP). I believe, this is a MUST for NATs. > > regards, > suresh > >> I ran into Mark Allman this afternoon and asked him if he had an >> opinion on the robustness of Path MTU discovery on the Internet. He >> does, and has recently co-authored a paper that discusses this >> (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). >> In section 4.3 of the paper, he's seeing that about one-third of the >> 85,000 servers identified by the NLANR Web Caching project don't >> attempt Path MTU discovery at all, and another 17 percent attempt it >> and fail. The failure rate is even higher for a list of 500 popular >> web server (35%). >> >> So I'm wondering if we need to think about this a little more? >> >> Spencer >> >> p.s. I copied Mark, just in case I'm misunderstanding the paper... >> >> >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Wed, 16 Mar 2005 16:16:36 -0800 (PST) From: Cullen Jennings Date: Wed, 16 Mar 2005 16:16:36 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <4.3.2.7.2.20050316143446.03aa28e8@mira-sjcd-2.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sounds like we are saying about the same thing. If the amount of memory is set to 0 then one thing happens, if it is set above that, then something else happens. I think the end story for the applications is going to be they can't make assumptions about what will happen to out of order fragments. On 3/16/05 2:42 PM, "Senthil Sivakumar" wrote: > At 05:09 PM 3/15/2005 -0800, Cullen Jennings wrote: > >> Not as chair >> >> I look forward to getting the TCP folks input on this but I believe one of >> the issues in trying to say that devices should process out of order packets >> is what to do about the DOS attacks this creates if lots of out of order >> packets are sent. >> >> Right now I don't see how we could recommend that a NAT process out of order >> packets because we would need to say that if you got lots of them, then the >> NAT would need to stop doing the out of order processing or else it would >> run out of memory. This would be exactly the sort of non deterministic >> behavior that we are trying to stop. > > Conversely, if you don't recommend NATs to process out of order fragments, > some NATs will store the fragments until the first fragment is received, > some might > drop them, some might just forward them (if they can). This causes > non-deterministic > behavior as well. > > Now the solution for preventing NATs from DoS attacks could be that there > is a threshold > for the number of fragments that can be queued and the time it can be > queued. I believe > these thresholds will vary based on the memory, CPU and network latency. > > Senthil > > >> Cullen >> >> >> On 3/7/05 5:57 PM, "Pyda Srisuresh" wrote: >> >>> >>> --- Spencer Dawkins wrote: >>>> My understanding from this morning's meeting was that we were leaning >>>> toward not requiring Behave-conformant NATs to process out-of-order >>>> TCP fragments, with the expectation that endpoints would be doing Path >>>> MTU discovery anyway, so fragmentation shouldn't be an issue. >>>> >>> [suresh] If you are talking about processing out of order IP fragments in >>> general, I believe, the chairs said we would take this to the list. If >> NATs do >>> not handle IP fragments correctly, it is a major problem for >> applications that >>> use IP fragments (ex: NFS over UDP). I believe, this is a MUST for NATs. >>> >>> regards, >>> suresh >>> >>>> I ran into Mark Allman this afternoon and asked him if he had an >>>> opinion on the robustness of Path MTU discovery on the Internet. He >>>> does, and has recently co-authored a paper that discusses this >>>> (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). >>>> In section 4.3 of the paper, he's seeing that about one-third of the >>>> 85,000 servers identified by the NLANR Web Caching project don't >>>> attempt Path MTU discovery at all, and another 17 percent attempt it >>>> and fail. The failure rate is even higher for a list of 500 popular >>>> web server (35%). >>>> >>>> So I'm wondering if we need to think about this a little more? >>>> >>>> Spencer >>>> >>>> p.s. I copied Mark, just in case I'm misunderstanding the paper... >>>> >>>> >>>> _______________________________________________ >>>> Ietf-behave mailing list >>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >>>> >>> >>> >>> _______________________________________________ >>> Ietf-behave mailing list >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Wed, 16 Mar 2005 16:23:51 -0800 (PST) From: "Francois Audet" Date: Wed, 16 Mar 2005 16:23:51 -0800 (PST) Subject: RE: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets Message-ID: <1ECE0EB50388174790F9694F77522CCF01BF5F5B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Requiring NATs to process Out-of-orderfragmented TCP packets Exactly. This is something for the Application document. I really don't see the "big NAT/router vendors" changing the current practice on fragments, with all the security holes it has created. It may be different for a small residential NAT. In either case, it is something the applications have to be able to deal with. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Cullen Jennings > Sent: Wednesday, March 16, 2005 16:17 > To: Senthil Sivakumar > Cc: Mark Allman; Behave > Subject: Re: [Ietf-behave] Requiring NATs to process > Out-of-orderfragmented TCP packets > > > > Sounds like we are saying about the same thing. If the amount > of memory is set to 0 then one thing happens, if it is set > above that, then something else happens. I think the end > story for the applications is going to be they can't make > assumptions about what will happen to out of order fragments. > > > On 3/16/05 2:42 PM, "Senthil Sivakumar" wrote: > > > At 05:09 PM 3/15/2005 -0800, Cullen Jennings wrote: > > > >> Not as chair > >> > >> I look forward to getting the TCP folks input on this but > I believe > >> one of the issues in trying to say that devices should > process out of > >> order packets is what to do about the DOS attacks this creates if > >> lots of out of order packets are sent. > >> > >> Right now I don't see how we could recommend that a NAT > process out > >> of order packets because we would need to say that if you > got lots of > >> them, then the NAT would need to stop doing the out of order > >> processing or else it would run out of memory. This would > be exactly > >> the sort of non deterministic behavior that we are trying to stop. > > > > Conversely, if you don't recommend NATs to process out of order > > fragments, some NATs will store the fragments until the > first fragment > > is received, some might drop them, some might just forward > them (if > > they can). This causes non-deterministic > > behavior as well. > > > > Now the solution for preventing NATs from DoS attacks could be that > > there is a threshold for the number of fragments that can be queued > > and the time it can be queued. I believe > > these thresholds will vary based on the memory, CPU and > network latency. > > > > Senthil > > > > > >> Cullen > >> > >> > >> On 3/7/05 5:57 PM, "Pyda Srisuresh" wrote: > >> > >>> > >>> --- Spencer Dawkins wrote: > >>>> My understanding from this morning's meeting was that we were > >>>> leaning toward not requiring Behave-conformant NATs to process > >>>> out-of-order TCP fragments, with the expectation that endpoints > >>>> would be doing Path MTU discovery anyway, so fragmentation > >>>> shouldn't be an issue. > >>>> > >>> [suresh] If you are talking about processing out of order IP > >>> fragments in general, I believe, the chairs said we would > take this > >>> to the list. If > >> NATs do > >>> not handle IP fragments correctly, it is a major problem for > >> applications that > >>> use IP fragments (ex: NFS over UDP). I believe, this is a > MUST for > >>> NATs. > >>> > >>> regards, > >>> suresh > >>> > >>>> I ran into Mark Allman this afternoon and asked him if he had an > >>>> opinion on the robustness of Path MTU discovery on the > Internet. He > >>>> does, and has recently co-authored a paper that discusses this > >>>> (available at > >>>> http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). > >>>> In section 4.3 of the paper, he's seeing that about > one-third of the > >>>> 85,000 servers identified by the NLANR Web Caching project don't > >>>> attempt Path MTU discovery at all, and another 17 > percent attempt it > >>>> and fail. The failure rate is even higher for a list of > 500 popular > >>>> web server (35%). > >>>> > >>>> So I'm wondering if we need to think about this a little more? > >>>> > >>>> Spencer > >>>> > >>>> p.s. I copied Mark, just in case I'm misunderstanding > the paper... > >>>> > >>>> > >>>> _______________________________________________ > >>>> Ietf-behave mailing list > >>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Ietf-behave mailing list > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From dwing@cisco.com Wed, 16 Mar 2005 16:48:18 -0800 (PST) From: Dan Wing Date: Wed, 16 Mar 2005 16:48:18 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: Message-ID: <3FF9608E-967E-11D9-97EA-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Mar 16, 2005, at 4:16 PM, Cullen Jennings wrote: Sounds like we are saying about the same thing. If the amount of memory is set to 0 then one thing happens, if it is set above that, then something else happens. I think the end story for the applications is going to be they can't make assumptions about what will happen to out of order fragments. Which is a nice way of saying "if fragmentation occurs, everything could break." This makes it sounds like applications need to prevent the network from fragmenting packets, then, which means they MUST do PMTUD for both UDP and for TCP? -d From ssenthil@cisco.com Wed, 16 Mar 2005 16:58:46 -0800 (PST) From: Senthil Sivakumar Date: Wed, 16 Mar 2005 16:58:46 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <4.3.2.7.2.20050316143446.03aa28e8@mira-sjcd-2.cisco.com> Message-ID: <4.3.2.7.2.20050316162418.02b09bf8@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain The end application may not see the complete data if NAT drops or don't know how to process fragments. So either you have to make NATs support fragments and/or the end hosts do PMTU discovery to ensure no fragmentation occurs in the network. I would say you have to do both. The recommendation should be NATs should support handling fragments but at the same time protect itself from attacks. Senthil At 04:16 PM 3/16/2005 -0800, Cullen Jennings wrote: Sounds like we are saying about the same thing. If the amount of memory is set to 0 then one thing happens, if it is set above that, then something else happens. I think the end story for the applications is going to be they can't make assumptions about what will happen to out of order fragments. On 3/16/05 2:42 PM, "Senthil Sivakumar" wrote: > At 05:09 PM 3/15/2005 -0800, Cullen Jennings wrote: > >> Not as chair >> >> I look forward to getting the TCP folks input on this but I believe one of >> the issues in trying to say that devices should process out of order packets >> is what to do about the DOS attacks this creates if lots of out of order >> packets are sent. >> >> Right now I don't see how we could recommend that a NAT process out of order >> packets because we would need to say that if you got lots of them, then the >> NAT would need to stop doing the out of order processing or else it would >> run out of memory. This would be exactly the sort of non deterministic >> behavior that we are trying to stop. > > Conversely, if you don't recommend NATs to process out of order fragments, > some NATs will store the fragments until the first fragment is received, > some might > drop them, some might just forward them (if they can). This causes > non-deterministic > behavior as well. > > Now the solution for preventing NATs from DoS attacks could be that there > is a threshold > for the number of fragments that can be queued and the time it can be > queued. I believe > these thresholds will vary based on the memory, CPU and network latency. > > Senthil > > >> Cullen >> >> >> On 3/7/05 5:57 PM, "Pyda Srisuresh" wrote: >> >>> >>> --- Spencer Dawkins wrote: >>>> My understanding from this morning's meeting was that we were leaning >>>> toward not requiring Behave-conformant NATs to process out-of-order >>>> TCP fragments, with the expectation that endpoints would be doing Path >>>> MTU discovery anyway, so fragmentation shouldn't be an issue. >>>> >>> [suresh] If you are talking about processing out of order IP fragments in >>> general, I believe, the chairs said we would take this to the list. If >> NATs do >>> not handle IP fragments correctly, it is a major problem for >> applications that >>> use IP fragments (ex: NFS over UDP). I believe, this is a MUST for NATs. >>> >>> regards, >>> suresh >>> >>>> I ran into Mark Allman this afternoon and asked him if he had an >>>> opinion on the robustness of Path MTU discovery on the Internet. He >>>> does, and has recently co-authored a paper that discusses this >>>> (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). >>>> In section 4.3 of the paper, he's seeing that about one-third of the >>>> 85,000 servers identified by the NLANR Web Caching project don't >>>> attempt Path MTU discovery at all, and another 17 percent attempt it >>>> and fail. The failure rate is even higher for a list of 500 popular >>>> web server (35%). >>>> >>>> So I'm wondering if we need to think about this a little more? >>>> >>>> Spencer >>>> >>>> p.s. I copied Mark, just in case I'm misunderstanding the paper... >>>> >>>> >>>> _______________________________________________ >>>> Ietf-behave mailing list >>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >>>> >>> >>> >>> _______________________________________________ >>> Ietf-behave mailing list >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave From kbiswas@cisco.com Wed, 16 Mar 2005 16:59:52 -0800 (PST) From: Kaushik Biswas Date: Wed, 16 Mar 2005 16:59:52 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: Message-ID: <4.3.2.7.2.20050316165528.02dd17f8@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain At 04:48 PM 3/16/2005 -0800, Dan Wing wrote: On Mar 16, 2005, at 4:16 PM, Cullen Jennings wrote: Sounds like we are saying about the same thing. If the amount of memory is set to 0 then one thing happens, if it is set above that, then something else happens. I think the end story for the applications is going to be they can't make assumptions about what will happen to out of order fragments. Which is a nice way of saying "if fragmentation occurs, everything could break." This makes it sounds like applications need to prevent the network from fragmenting packets, then, which means they MUST do PMTUD for both UDP and for TCP? And a good chunk of the ones don't do PMTUD. Spencer had fwd'd a paper for the same to the alias. Being a box-in-middle NAT is most likely to get out of order fragments. Kaushik -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From nagendra@cs.stanford.edu Wed, 16 Mar 2005 20:09:47 -0800 (PST) From: nagendra modadugu Date: Wed, 16 Mar 2005 20:09:47 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: Message-ID: <20050317040942.GA18877@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain > >Sounds like we are saying about the same thing. If the amount of > >memory is > >set to 0 then one thing happens, if it is set above that, then > >something > >else happens. I think the end story for the applications is going to > >be they > >can't make assumptions about what will happen to out of order > >fragments. > > Which is a nice way of saying "if fragmentation occurs, everything could > break." > > This makes it sounds like applications need to prevent the network from > fragmenting packets, then, which means they MUST do PMTUD for both UDP > and for TCP? I'm for processing of in-order fragments--from what I discovered while working on DTLS, PMTUD is rarely turned on, and some OS's don't even correctly implement getsockopt() to return the MTU value received in an ICMP MTU exceeded message. This makes it hard for even MTU-mindful applications to do the right thing. Out-of-order fragments is a wash--it doesn't seem to be worth the effort (even though an DoS attack against a buffering-NAT isn't particularly effective). Discussion below. Out-of-order Fragments: Suppose buffering of fragments is supported by the NAT, so that IP packets can be correctly reconstructed and forwarded. An attacker could do the following: (1) Generate an IP packet with SA={IP of some popular server, e.g. some IMAP server}, DA={external IP address of the NAT}. (2) Fragment the IP packet into F1, F2, .., Fn, such that the TCP header lies entirely in F1. (3) Transmit F2, F3, .., Fn (skipping F1). (4) The NAT buffers all the fragments received since, the (SA,SD) pair is likely to be a valid tuple for current connections, and the NAT has no further information upon which to filter the fragments (typically port numbers). This is potentially a bad situation--an attacker can force the NAT to buffer packets (a) without having to be on a connection path, and (b) can be successful with a very high probability. The way to counter such an attack is to timeout fragment buffering. One way to implement this is for the NAT to fix a time window in which all the fragments for an IP packet must arrive--to be generous, say 100ms. So if the attacker can attack at line rate, say 10Mbps, then the NAT needs to buffer at most ~125kB of data (100ms worth of data). It's possible that the numbers I've picked are way off, but if they're anywhere close to realistic, the attack isn't terribly effective--it doesn't take much memory on part of the NAT to implement out-of-order fragment processing. Besides which, attacking at line rate is indicative of a much bigger problem. I recall hearing a story about a Juniper 'bug' in their routers that resulted in reordering packets. Apparently, this bug had caused some software to break, eventually forcing Juniper to fix the bug. If any of this story is true, then I'm leaning towards concluding that out-of-order packets are a rareity (if packet N+1 is received before packet N, then chances are that packet N has been dropped along the way) in which case out-of-order fragment processing is not much use anyway. Of course, things could go terribly wrong if the timer code is buggy, or timer values are too large--which is not an unlikely scenario. In-order-fragments: In-order fragments can be easily processed without need for buffering based on their IP identifier fields. Since there is no buffering, the worst an attacker can do is slip packets through the NAT from the outside (an attack that can also be accomplished without employing IP fragments). From srisuresh@yahoo.com Wed, 16 Mar 2005 22:51:01 -0800 (PST) From: Pyda Srisuresh Date: Wed, 16 Mar 2005 22:51:01 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: Message-ID: <20050317065057.64257.qmail@web40422.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > > inline (not as chair) > > On 3/16/05 7:53 AM, "Pyda Srisuresh" wrote: > > > Cullen, > > > > I think, there are two parts to this. > > > > First, the processing of IP fragments (In-order or out-of-order). Should > NATs > > support IP fragments? > > Second, the processing of out-of-order IP fragments. Should, NATs support > > out-of-order IP fragments? > agree on these two questions > > > > > I believe, IP fragment support is a MUST because this is a fundamental > aspect > > of IP, and NATs providing transparancy to IP should support transparant > > traversal of IP fragments. > ok - perhaps > > > Once IP fragment traversal is supported, the memory > > issues remain the same no matter whether frgaments come in order or out of > > order. So, I believe, the answer is YES to both. > not sure I agree on your logic that only way to forward in order fragments > is to store and reassemble them. If the fragments arrive in order, you can > save the port forward state for the flow when the first one arrives then > forward each fragment as it arrives without storing any of the fragments. I > think there are NATs today that have implemented this both ways. For the > NATs that do reassemble out of order packets, clearly they can only do this > with a limited number - so the question is can an endpoint rely on that > behavior. > [suresh] Cullen - You do bring up a clever way in which NATs do not have to reassemble the fragments when they come in order. But, what sort of determinism does in-order-fragment support alone provide to the apps? Apps have no way to know how the underlying stack orders the fragments. Some send in order and some send out of order. Worse yet, apps certainly have no control over the network that can also reorder the fragments. It woudlnt be right for the apps to say they wont work on the hosts and networks that will order fragments out of sequence. So, the only logical conslusion woudl be for the apps to assume no fragment support in the network that involves NAT traversal. That would be BAD. As for memory constraints, there are several things in a NAT box that memory constraints could make it non-deterministics. NAT box could be short of packet buffers to process packets at line rate and drop packets. NAT box could be short of memory to process large number of NAT sessions as well, and so on... where do you draw the line on nonpdeterministic behavior from memory constraints. cheers, suresh > > > > > > Please see my responses inline. > > > > cheers, > > suresh > > > > --- Cullen Jennings wrote: > >> > >> Not as chair > >> > >> I look forward to getting the TCP folks input on this but I believe one of > >> the issues in trying to say that devices should process out of order > packets > >> is what to do about the DOS attacks this creates if lots of out of order > >> packets are sent. > >> > >> Right now I don't see how we could recommend that a NAT process out of > order > >> packets because we would need to say that if you got lots of them, then > the > >> NAT would need to stop doing the out of order processing or else it would > >> run out of memory. > > > > [suresh] Yes, there can be lots of frgaments - no matter whether they came > in > > order of out of order. Are you saying, NATs should not support IP fragments > at > > all? > > > > As for memory requirements, a NAT perhaps needs to set aside a percentage > of > > in-flight packet buffers for fragment reassembly. When NAT runs out of > memory, > > it will drop unassembled fragments. Else, it will forward the assembled > > packets. Why is this a problem? NATs have to do this to fight various types > of > > DoS attacks. > > > >> This would be exactly the sort of non deterministic > >> behavior that we are trying to stop. > >> > > [suresh] I disagree. Packets are often dropped in the network for various > > reasons - such as devices not having receive buffers at a certain bursty > > instance. But, IP is resilient to deal with this type of occasional > > non-deterministic behavior (i.e., packet drops). Packets will be dropped > with > > or without IP fragment support on a NAT under some bursty instances or DoS > > scenarios. > > > > cheers, > > suresh > > > >> Cullen > >> > >> > >> On 3/7/05 5:57 PM, "Pyda Srisuresh" wrote: > >> > >>> > >>> --- Spencer Dawkins wrote: > >>>> My understanding from this morning's meeting was that we were leaning > >>>> toward not requiring Behave-conformant NATs to process out-of-order > >>>> TCP fragments, with the expectation that endpoints would be doing Path > >>>> MTU discovery anyway, so fragmentation shouldn't be an issue. > >>>> > >>> [suresh] If you are talking about processing out of order IP fragments in > >>> general, I believe, the chairs said we would take this to the list. If > NATs > >> do > >>> not handle IP fragments correctly, it is a major problem for applications > >> that > >>> use IP fragments (ex: NFS over UDP). I believe, this is a MUST for NATs. > >>> > >>> regards, > >>> suresh > >>> > >>>> I ran into Mark Allman this afternoon and asked him if he had an > >>>> opinion on the robustness of Path MTU discovery on the Internet. He > >>>> does, and has recently co-authored a paper that discusses this > >>>> (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps). > >>>> In section 4.3 of the paper, he's seeing that about one-third of the > >>>> 85,000 servers identified by the NLANR Web Caching project don't > >>>> attempt Path MTU discovery at all, and another 17 percent attempt it > >>>> and fail. The failure rate is even higher for a list of 500 popular > >>>> web server (35%). > >>>> > >>>> So I'm wondering if we need to think about this a little more? > >>>> > >>>> Spencer > >>>> > >>>> p.s. I copied Mark, just in case I'm misunderstanding the paper... > >>>> > >>>> > >>>> _______________________________________________ > >>>> Ietf-behave mailing list > >>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Ietf-behave mailing list > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > From srisuresh@yahoo.com Wed, 16 Mar 2005 23:22:26 -0800 (PST) From: Pyda Srisuresh Date: Wed, 16 Mar 2005 23:22:26 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets Message-ID: <20050317072226.69328.qmail@web40422.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- nagendra modadugu wrote: > > >Sounds like we are saying about the same thing. If the amount of > > >memory is > > >set to 0 then one thing happens, if it is set above that, then > > >something > > >else happens. I think the end story for the applications is going to > > >be they > > >can't make assumptions about what will happen to out of order > > >fragments. > > > > Which is a nice way of saying "if fragmentation occurs, everything could > > break." > > > > This makes it sounds like applications need to prevent the network from > > fragmenting packets, then, which means they MUST do PMTUD for both UDP > > and for TCP? > > I'm for processing of in-order fragments--from what I discovered while > working on DTLS, PMTUD is rarely turned on, and some OS's don't even > correctly implement getsockopt() to return the MTU value received in an > ICMP MTU exceeded message. This makes it hard for even MTU-mindful > applications to do the right thing. > [suresh] You are right, Path MTU discovery is rarely turned on. Many applications (especially UDP based) are not even MTU mindful. > Out-of-order fragments is a wash--it doesn't seem to be worth the effort > (even though an DoS attack against a buffering-NAT isn't particularly > effective). > > Discussion below. > > > Out-of-order Fragments: > > Suppose buffering of fragments is supported by the NAT, so that IP > packets can be correctly reconstructed and forwarded. An attacker could > do the following: > > (1) Generate an IP packet with SA={IP of some popular server, e.g. > some IMAP server}, DA={external IP address of the NAT}. > (2) Fragment the IP packet into F1, F2, .., Fn, such that the TCP > header lies entirely in F1. > (3) Transmit F2, F3, .., Fn (skipping F1). > (4) The NAT buffers all the fragments received since, the (SA,SD) pair > is likely to be a valid tuple for current connections, and the NAT > has no further information upon which to filter the fragments > (typically port numbers). > > This is potentially a bad situation--an attacker can force the NAT to buffer > packets (a) without having to be on a connection path, and (b) can be > successful with a very high probability. > > The way to counter such an attack is to timeout fragment buffering. > One way to implement this is for the NAT to fix a time window in which > all the fragments for an IP packet must arrive--to be generous, say 100ms. > So if the attacker can attack at line rate, say 10Mbps, then the NAT > needs to buffer at most ~125kB of data (100ms worth of data). > > It's possible that the numbers I've picked are way off, but if they're > anywhere close to realistic, the attack isn't terribly effective--it doesn't > take much memory on part of the NAT to implement out-of-order fragment > processing. Besides which, attacking at line rate is indicative of a > much bigger problem. > [suresh] It sounds like what you are saying is that it is not a big deal for a NAT to support out-of-order fragments through reassembly and that fragment based Dos attack is something NATs can handle. If I understood you correctly, I agree with what the assessment. > I recall hearing a story about a Juniper 'bug' in their routers that > resulted in reordering packets. Apparently, this bug had caused some > software to break, eventually forcing Juniper to fix the bug. [suresh] Nagendra - this is less to do with fragments and more to do with reorderign the IP packets itself. I believe, Juniper was reorderig IP packets (TCP and UDP alike) while forwarding due to some internal bandwidth problems within their core router. I suspect, many TCP stacks are sensitive to receiving out-of-sequence segments. > If any of this story is true, then I'm leaning towards concluding that > out-of-order packets are a rareity (if packet N+1 is received before > packet N, then chances are that packet N has been dropped along the > way) in which case out-of-order fragment processing is not much use > anyway. > [suresh] That is not true. Let me not name the OSes. Suffices to say, many PC and server stacks do send IP fragments in reverse order. Also, as you say, the network could also cause the fragments to arrive Out of order sometimes. So, both these are actually good reasons for NAT to support out-of-order fragment reassembly. > Of course, things could go terribly wrong if the timer code is buggy, > or timer values are too large--which is not an unlikely scenario. > > > In-order-fragments: > > In-order fragments can be easily processed without need for buffering > based on their IP identifier fields. Since there is no buffering, the > worst an attacker can do is slip packets through the NAT from the outside > (an attack that can also be accomplished without employing IP fragments). [suresh] I replied to Cullen in a different thread. So, I wont expand on this further here. I believe, support of in-order-fragments alone, tantamounts to no support of fragmentation. cheers, suresh From nagendra@cs.stanford.edu Thu, 17 Mar 2005 01:43:12 -0800 (PST) From: nagendra modadugu Date: Thu, 17 Mar 2005 01:43:12 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050317072226.69328.qmail@web40422.mail.yahoo.com> Message-ID: <20050317094308.GA3824@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain (Sorry Mark, you might be feeling SPAMMED--this is the last message I'll send directly to you.) > [suresh] It sounds like what you are saying is that it is not a big deal for a > NAT to support out-of-order fragments through reassembly and that fragment > based Dos attack is something NATs can handle. If I understood you correctly, > I > agree with what the assessment. I have made a number of assumptions, both about the numbers and also regarding how a NAT might respond to out-of-order fragments. Someone needs to comment on these assumptions. Even if the assumptions work out--I don't see out-of-order fragment processing as worthwhile, unless someone has *real data* to backup the claim that IP packets are routinely re-ordered. > > I recall hearing a story about a Juniper 'bug' in their routers that > > resulted in reordering packets. Apparently, this bug had caused some > > software to break, eventually forcing Juniper to fix the bug. > > [suresh] Nagendra - this is less to do with fragments and more to do with > reorderign the IP packets itself. I believe, Juniper was reorderig IP packets > (TCP and UDP alike) while forwarding due to some internal bandwidth problems > within their core router. I suspect, many TCP stacks are sensitive to > receiving > out-of-sequence segments. Ummmm ... in what way precisely are IP fragments not also IP packets? > > If any of this story is true, then I'm leaning towards concluding that > > out-of-order packets are a rareity (if packet N+1 is received before > > packet N, then chances are that packet N has been dropped along the > > way) in which case out-of-order fragment processing is not much use > > anyway. > > > [suresh] That is not true. Let me not name the OSes. Suffices to say, many PC > and server stacks do send IP fragments in reverse order. Also, as you say, the > network could also cause the fragments to arrive Out of order sometimes. Again, I refer to the Juniper story. Can you name the platforms that fragment IP packets at source? > So, both these are actually good reasons for NAT to support out-of-order > fragment reassembly. I'm still don't think so, but I'll elaborate on this point separately. Note that there are also a number of implementation caveats. nagendra From baford@mit.edu Thu, 17 Mar 2005 06:49:17 -0800 (PST) From: Bryan Ford Date: Thu, 17 Mar 2005 06:49:17 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050317072226.69328.qmail@web40422.mail.yahoo.com> Message-ID: <200503170949.15293.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Comments inline. On Thursday 17 March 2005 02:22, Pyda Srisuresh wrote: > --- nagendra modadugu wrote: > > > >Sounds like we are saying about the same thing. If the amount of > > > >memory is > > > >set to 0 then one thing happens, if it is set above that, then > > > >something > > > >else happens. I think the end story for the applications is going to > > > >be they > > > >can't make assumptions about what will happen to out of order > > > >fragments. > > > > > > Which is a nice way of saying "if fragmentation occurs, everything > > > could break." > > > > > > This makes it sounds like applications need to prevent the network from > > > fragmenting packets, then, which means they MUST do PMTUD for both UDP > > > and for TCP? > > > > I'm for processing of in-order fragments--from what I discovered while > > working on DTLS, PMTUD is rarely turned on, and some OS's don't even > > correctly implement getsockopt() to return the MTU value received in an > > ICMP MTU exceeded message. This makes it hard for even MTU-mindful > > applications to do the right thing. > > [suresh] You are right, Path MTU discovery is rarely turned on. Many > applications (especially UDP based) are not even MTU mindful. > > > Out-of-order fragments is a wash--it doesn't seem to be worth the effort > > (even though an DoS attack against a buffering-NAT isn't particularly > > effective). > > > > Discussion below. > > > > > > Out-of-order Fragments: > > > > Suppose buffering of fragments is supported by the NAT, so that IP > > packets can be correctly reconstructed and forwarded. An attacker could > > do the following: > > > > (1) Generate an IP packet with SA={IP of some popular server, e.g. > > some IMAP server}, DA={external IP address of the NAT}. > > (2) Fragment the IP packet into F1, F2, .., Fn, such that the TCP > > header lies entirely in F1. > > (3) Transmit F2, F3, .., Fn (skipping F1). > > (4) The NAT buffers all the fragments received since, the (SA,SD) pair > > is likely to be a valid tuple for current connections, and the NAT > > has no further information upon which to filter the fragments > > (typically port numbers). > > > > This is potentially a bad situation--an attacker can force the NAT to > > buffer packets (a) without having to be on a connection path, and (b) can > > be successful with a very high probability. > > > > The way to counter such an attack is to timeout fragment buffering. > > One way to implement this is for the NAT to fix a time window in which > > all the fragments for an IP packet must arrive--to be generous, say > > 100ms. So if the attacker can attack at line rate, say 10Mbps, then the > > NAT needs to buffer at most ~125kB of data (100ms worth of data). > > > > It's possible that the numbers I've picked are way off, but if they're > > anywhere close to realistic, the attack isn't terribly effective--it > > doesn't take much memory on part of the NAT to implement out-of-order > > fragment processing. Besides which, attacking at line rate is indicative > > of a much bigger problem. > > [suresh] It sounds like what you are saying is that it is not a big deal > for a NAT to support out-of-order fragments through reassembly and that > fragment based Dos attack is something NATs can handle. If I understood you > correctly, I agree with what the assessment. > > > I recall hearing a story about a Juniper 'bug' in their routers that > > resulted in reordering packets. Apparently, this bug had caused some > > software to break, eventually forcing Juniper to fix the bug. > > [suresh] Nagendra - this is less to do with fragments and more to do with > reorderign the IP packets itself. I believe, Juniper was reorderig IP > packets (TCP and UDP alike) while forwarding due to some internal bandwidth > problems within their core router. I suspect, many TCP stacks are sensitive > to receiving out-of-sequence segments. > > > If any of this story is true, then I'm leaning towards concluding that > > out-of-order packets are a rareity (if packet N+1 is received before > > packet N, then chances are that packet N has been dropped along the > > way) in which case out-of-order fragment processing is not much use > > anyway. > > [suresh] That is not true. Let me not name the OSes. Suffices to say, many > PC and server stacks do send IP fragments in reverse order. Also, as you > say, the network could also cause the fragments to arrive Out of order > sometimes. I think it may be useful to make a distinction between "slightly out-of-order fragments" and "seriously out-of-order fragments". If the multiple fragments comprising a logical datagram are received out of their "natural" order (e.g., because the originating host OS sent them in reverse order), but the fragments of one datagram are at least not (badly) intermixed with the fragments of previous or subsequent datagrams, then that is an example of "slightly out-of-order". I think that NATs MUST be able to deal with such "slightly out-of-order" packets, for the reasons Suresh cites. If on the other hand fragments 2, 3, and 4 of datagram A arrive first, then all of datagrams B, C, D, ..., then fragment 1 of datagram A finally arrives after several or many other datagrams have been seen, that is a "seriously out-of-order fragment". It is obviously unreasonable to expect NATs to handle seriously out-of-order fragments beyond a certain point, for the well-known security reasons. And I think that Nagendra is right that many TCP/IP stacks (we can call them buggy TCP/IP stacks if you like, but they definitely exist) start behaving very poorly if routers in the network start routinely reordering packets, hence the Juniper experience. I would like to propose the following as a "starting point" for the NAT fragment handling requirements: 1. NATs MUST at the very minimum be able to handle a datagram whose fragments appear in an arbitrary order on the wire but "all together", not intermixed with fragments of other datagrams. 2. NATs MUST protect themselves from fragmentation-based DoS attacks. I personally think #1, the lower bound, should probably be raised somewhat beyond the "absolute bare minimum" suggested above, if we can agree on a suitable way to specify how "out-of-order" a packet's fragments need to be before the NAT is no longer required to handle them. Nagendra's suggestion of a time window seems perfectly good to me, but the metric could alternatively be based on packet count (i.e., the NAT is only required to hold on to fragments within an N-packet window after the first fragment arrives), or byte count. We could leave the choice of metric to the NAT designer, but specify a minimum required value in each case. I don't have enough experience with fragmentation issues to make a suggestion as to what exactly would be best here. My point is merely that NATs really need to support _some_ kind of out-of-order fragment handling, at the very least so as to be able to handle the "slightly out of order" fragments that some TCP/IP stacks actually generate on the originating endpoint. Cheers, Bryan > > So, both these are actually good reasons for NAT to support out-of-order > fragment reassembly. > > > Of course, things could go terribly wrong if the timer code is buggy, > > or timer values are too large--which is not an unlikely scenario. > > > > > > In-order-fragments: > > > > In-order fragments can be easily processed without need for buffering > > based on their IP identifier fields. Since there is no buffering, the > > worst an attacker can do is slip packets through the NAT from the outside > > (an attack that can also be accomplished without employing IP fragments). > > [suresh] I replied to Cullen in a different thread. So, I wont expand on > this further here. I believe, support of in-order-fragments alone, > tantamounts to no support of fragmentation. > > cheers, > suresh > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From mshore@cisco.com Thu, 17 Mar 2005 06:59:42 -0800 (PST) From: Melinda Shore Date: Thu, 17 Mar 2005 06:59:42 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <200503170949.15293.baford@mit.edu> Message-ID: <23BBA0DE-96F5-11D9-BB81-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Thursday, March 17, 2005, at 09:49 AM, Bryan Ford wrote: I would like to propose the following as a "starting point" for the NAT fragment handling requirements: 1. NATs MUST at the very minimum be able to handle a datagram whose fragments appear in an arbitrary order on the wire but "all together", not intermixed with fragments of other datagrams. 2. NATs MUST protect themselves from fragmentation-based DoS attacks. It seems to me that the second should be a SHOULD. We have firewalls to deal with that sort of problem and I have some serious reservations about NATs dinking around with TCP machinery. Melinda From dwing@cisco.com Thu, 17 Mar 2005 07:16:01 -0800 (PST) From: Dan Wing Date: Thu, 17 Mar 2005 07:16:01 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050317072226.69328.qmail@web40422.mail.yahoo.com> Message-ID: <77BDA0DD-96F7-11D9-B029-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain (I'm glad everyone is familiar with the poor characteristics of PMTUD, and that we have to put requirements on NATs to handle IP fragments.) On Mar 17, 2005, at 1:43 AM, nagendra modadugu wrote: Can you name the platforms that fragment IP packets at source? There are rumors that Linux did (does) this; I don't know if that's still the case, but Google hasn't found a mention about the behavior being different in recent Linux releases. But I haven't checked sources. Justification, according to this post, is it helps performance of the sending system: http://www.ussg.iu.edu/hypermail/linux/kernel/0001.1/1196.html More information here: http://www.google.com/search?q=linux+fragment+reverse+order -d From baford@mit.edu Thu, 17 Mar 2005 07:18:24 -0800 (PST) From: Bryan Ford Date: Thu, 17 Mar 2005 07:18:24 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <23BBA0DE-96F5-11D9-BB81-000A95E35274@cisco.com> Message-ID: <200503171018.14743.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 17 March 2005 09:59, Melinda Shore wrote: > On Thursday, March 17, 2005, at 09:49 AM, Bryan Ford wrote: > > I would like to propose the following as a "starting point" for the NAT > > fragment handling requirements: > > > > 1. NATs MUST at the very minimum be able to handle a datagram whose > > fragments > > appear in an arbitrary order on the wire but "all together", not > > intermixed > > with fragments of other datagrams. > > > > 2. NATs MUST protect themselves from fragmentation-based DoS attacks. > > It seems to me that the second should be a SHOULD. We have firewalls > to deal with that sort of problem and I have some serious reservations > about NATs dinking around with TCP machinery. Sure, I have no problem with that. Cheers, Bryan From dwing@cisco.com Thu, 17 Mar 2005 07:29:50 -0800 (PST) From: Dan Wing Date: Thu, 17 Mar 2005 07:29:50 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050317072226.69328.qmail@web40422.mail.yahoo.com> Message-ID: <648A4528-96F9-11D9-B029-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Mar 17, 2005, at 6:49 AM, Bryan Ford wrote: I think it may be useful to make a distinction between "slightly out-of-order fragments" and "seriously out-of-order fragments". If the NAT's inbound traffic is 'quiet' (such as a residential NAT with only one UDP stream that is getting fragmented). But if there are two streams that are being fragmented, the NAT would start to behave erratically if the fragments are considered "seriously" out of order by the NAT. This could work okay for a quiescent residential NAT but wouldn't work well for a busier SOHO NAT such as at a coffeeshop (they're often the same $50 802.11 device, of course). And Linux appears to always send UDP fragments "seriously" out of order -- fragment #1 with the UDP header is sent last. If the multiple fragments comprising a logical datagram are received out of their "natural" order (e.g., because the originating host OS sent them in reverse order), but the fragments of one datagram are at least not (badly) intermixed with the fragments of previous or subsequent datagrams, then that is an example of "slightly out-of-order". I think that NATs MUST be able to deal with such "slightly out-of-order" packets, for the reasons Suresh cites. If on the other hand fragments 2, 3, and 4 of datagram A arrive first, then all of datagrams B, C, D, ..., then fragment 1 of datagram A finally arrives after several or many other datagrams have been seen, that is a "seriously out-of-order fragment". It is obviously unreasonable to expect NATs to handle seriously out-of-order fragments beyond a certain point, for the well-known security reasons. And I think that Nagendra is right that many TCP/IP stacks (we can call them buggy TCP/IP stacks if you like, but they definitely exist) start behaving very poorly if routers in the network start routinely reordering packets, hence the Juniper experience. The problem with TCP performance is with TCP _segments_ arriving out of order, not TCP fragments arriving out of order. The IP stack reassembles out of order fragments, but the TCP stack handles putting the TCP segments into their correct order. One thing I'm unclear on -- do you want the NAT to re-order the fragmented packets? I don't see this as a requirement, and I don't see much advantage to the NAT sending the packets to the host in-order (#1...N), backwards (#N..1), or in exactly the same order the NAT received them. I would like to propose the following as a "starting point" for the NAT fragment handling requirements: 1. NATs MUST at the very minimum be able to handle a datagram whose fragments appear in an arbitrary order on the wire but "all together", not intermixed with fragments of other datagrams. 2. NATs MUST protect themselves from fragmentation-based DoS attacks. I don't quite agree with separating "all together" from "slightly together" as part of (1). -d I personally think #1, the lower bound, should probably be raised somewhat beyond the "absolute bare minimum" suggested above, if we can agree on a suitable way to specify how "out-of-order" a packet's fragments need to be before the NAT is no longer required to handle them. Nagendra's suggestion of a time window seems perfectly good to me, but the metric could alternatively be based on packet count (i.e., the NAT is only required to hold on to fragments within an N-packet window after the first fragment arrives), or byte count. We could leave the choice of metric to the NAT designer, but specify a minimum required value in each case. I don't have enough experience with fragmentation issues to make a suggestion as to what exactly would be best here. My point is merely that NATs really need to support _some_ kind of out-of-order fragment handling, at the very least so as to be able to handle the "slightly out of order" fragments that some TCP/IP stacks actually generate on the originating endpoint. Cheers, Bryan So, both these are actually good reasons for NAT to support out-of-order fragment reassembly. Of course, things could go terribly wrong if the timer code is buggy, or timer values are too large--which is not an unlikely scenario. In-order-fragments: In-order fragments can be easily processed without need for buffering based on their IP identifier fields. Since there is no buffering, the worst an attacker can do is slip packets through the NAT from the outside (an attack that can also be accomplished without employing IP fragments). [suresh] I replied to Cullen in a different thread. So, I wont expand on this further here. I believe, support of in-order-fragments alone, tantamounts to no support of fragmentation. cheers, suresh _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Thu, 17 Mar 2005 08:23:58 -0800 (PST) From: Pyda Srisuresh Date: Thu, 17 Mar 2005 08:23:58 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <648A4528-96F9-11D9-B029-0003938AF740@cisco.com> Message-ID: <20050317162358.99535.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain I agree. Please see my comments below. cheers, suresh --- Dan Wing wrote: > > On Mar 17, 2005, at 6:49 AM, Bryan Ford wrote: > > I think it may be useful to make a distinction between "slightly > > out-of-order > > fragments" and "seriously out-of-order fragments". > > If the NAT's inbound traffic is 'quiet' (such as a residential NAT with > only > one UDP stream that is getting fragmented). But if there are two > streams that > are being fragmented, the NAT would start to behave erratically if the > fragments > are considered "seriously" out of order by the NAT. This could work > okay for > a quiescent residential NAT but wouldn't work well for a busier SOHO > NAT such > as at a coffeeshop (they're often the same $50 802.11 device, of > course). > > And Linux appears to always send UDP fragments "seriously" out of order > -- > fragment #1 with the UDP header is sent last. > > > If the multiple fragments comprising a logical datagram are received > > out of > > their "natural" order (e.g., because the originating host OS sent them > > in > > reverse order), but the fragments of one datagram are at least not > > (badly) > > intermixed with the fragments of previous or subsequent datagrams, > > then that > > is an example of "slightly out-of-order". I think that NATs MUST be > > able to > > deal with such "slightly out-of-order" packets, for the reasons Suresh > > cites. > > > > If on the other hand fragments 2, 3, and 4 of datagram A arrive first, > > then > > all of datagrams B, C, D, ..., then fragment 1 of datagram A finally > > arrives > > after several or many other datagrams have been seen, that is a > > "seriously > > out-of-order fragment". It is obviously unreasonable to expect NATs to > > handle seriously out-of-order fragments beyond a certain point, for the > > well-known security reasons. And I think that Nagendra is right that > > many > > TCP/IP stacks (we can call them buggy TCP/IP stacks if you like, but > > they > > definitely exist) start behaving very poorly if routers in the network > > start > > routinely reordering packets, hence the Juniper experience. > > The problem with TCP performance is with TCP _segments_ arriving out of > order, > not TCP fragments arriving out of order. The IP stack reassembles out > of > order fragments, but the TCP stack handles putting the TCP segments into > their correct order. > [suresh] Yup. > One thing I'm unclear on -- do you want the NAT to re-order the > fragmented > packets? I don't see this as a requirement, and I don't see much > advantage > to the NAT sending the packets to the host in-order (#1...N), backwards > (#N..1), or in exactly the same order the NAT received them. > [suresh] I agree. The whole reason that NAT needs to reassemble fragments is so NAT can match the reassembled IP datagram against the NAT sessions it manages. NAT is unable to do this with fragments. Once frags are assembled, I agree with Dan, there is no need for a requirement on the ordering of fragments out of NAT. Depending upon the implmentations, the IP stack may even be out of bounds from NAT and hence unenforceable. > > I would like to propose the following as a "starting point" for the NAT > > fragment handling requirements: > > > > 1. NATs MUST at the very minimum be able to handle a datagram whose > > fragments > > appear in an arbitrary order on the wire but "all together", not > > intermixed > > with fragments of other datagrams. > > > > 2. NATs MUST protect themselves from fragmentation-based DoS attacks. > > I don't quite agree with separating "all together" from "slightly > together" as part of (1). > [suresh] My thinking likewise. cheers, suresh > -d > > > I personally think #1, the lower bound, should probably be raised > > somewhat > > beyond the "absolute bare minimum" suggested above, if we can agree on > > a > > suitable way to specify how "out-of-order" a packet's fragments need > > to be > > before the NAT is no longer required to handle them. Nagendra's > > suggestion > > of a time window seems perfectly good to me, but the metric could > > alternatively be based on packet count (i.e., the NAT is only required > > to > > hold on to fragments within an N-packet window after the first fragment > > arrives), or byte count. We could leave the choice of metric to the > > NAT > > designer, but specify a minimum required value in each case. I don't > > have > > enough experience with fragmentation issues to make a suggestion as to > > what > > exactly would be best here. My point is merely that NATs really need > > to > > support _some_ kind of out-of-order fragment handling, at the very > > least so > > as to be able to handle the "slightly out of order" fragments that some > > TCP/IP stacks actually generate on the originating endpoint. > > > > Cheers, > > Bryan > > > >> > >> So, both these are actually good reasons for NAT to support > >> out-of-order > >> fragment reassembly. > >> > >>> Of course, things could go terribly wrong if the timer code is buggy, > >>> or timer values are too large--which is not an unlikely scenario. > >>> > >>> > >>> In-order-fragments: > >>> > >>> In-order fragments can be easily processed without need for buffering > >>> based on their IP identifier fields. Since there is no buffering, > >>> the > >>> worst an attacker can do is slip packets through the NAT from the > >>> outside > >>> (an attack that can also be accomplished without employing IP > >>> fragments). > >> > >> [suresh] I replied to Cullen in a different thread. So, I wont expand > >> on > >> this further here. I believe, support of in-order-fragments alone, > >> tantamounts to no support of fragmentation. > >> > >> cheers, > >> suresh > >> > >> > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > From baford@mit.edu Thu, 17 Mar 2005 08:56:27 -0800 (PST) From: Bryan Ford Date: Thu, 17 Mar 2005 08:56:27 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050317072226.69328.qmail@web40422.mail.yahoo.com> Message-ID: <200503171156.21726.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 17 March 2005 10:29, Dan Wing wrote: > On Mar 17, 2005, at 6:49 AM, Bryan Ford wrote: > > I think it may be useful to make a distinction between "slightly > > out-of-order > > fragments" and "seriously out-of-order fragments". > > If the NAT's inbound traffic is 'quiet' (such as a residential NAT with > only > one UDP stream that is getting fragmented). But if there are two > streams that > are being fragmented, the NAT would start to behave erratically if the > fragments > are considered "seriously" out of order by the NAT. This could work > okay for > a quiescent residential NAT but wouldn't work well for a busier SOHO > NAT such > as at a coffeeshop (they're often the same $50 802.11 device, of > course). OK, excellent point (as in, duhh, why didn't I think of that :)). Even if the routers keep the fragments between a particular pair of IP endpoints in-order (which I believe most routers these days try very hard to do), the convergence of multiple fragmented streams from different source endpoints destined for a single target endpoint can cause the fragments to become "seriously out-of-order" with respect to each other at the receiver and at intermediate NATs. There definitely appears to be no "one size fits all" solution to this problem, and as a result I think my original suggestion still more-or-less stands: the decision on how seriously out-of-order fragments a NAT can handle ultimately probably needs to be left to the NAT designer and/or administrator. But even the "quiet residential NAT" at least needs to be able to handle the "slightly out of order" fragments sent by Linux boxes even in the absence of intermixing of streams, and even residential NATs probably SHOULD be able to handle at least a few fragmented streams from different sources being intermixed together in the network. For large NATs the appropriate thresholds are probably different. Perhaps one appropriate approach would be to recommend a minimum metric based on the number of simultaneous TCP streams the NAT is designed to be able to handle. This is an issue NAT designers have to think about anyway, since they usually have to decide how big to let the NAT's TCP session table grow, and perhaps other related internal limits. We could suggest, for example, that if a NAT is intended to be able to handle N simultaneously active TCP sessions crossing the NAT, then it SHOULD have enough fragment reordering buffer space so that a packet will be reassembled and forwarded correctly as long as its fragments appear within a window of N*M*K received bytes, where M is some reasonable maximum expected TCP segment size (e.g., 1500 for a typical Ethernet-oriented NAT), and K is some constant "fudge factor". That way, in the (admittedly simplistic) case where fragments from the N active TCP streams are getting multiplexed together more-or-less fairly by intermediate routers, a given M-byte TCP segment's fragments should appear at the NAT within a window of N*M total received bytes. The fudge factor K accounts for unfairness we wish to tolerate in how the streams are multiplexed: e.g., if there are only two streams (N=2) but one stream is getting only one byte through the pipe for the other's three, then a fudge factor K=2 will (I think) still allow both streams to get handled properly, but K=1 would kill the slower stream. Note that I'm not suggesting a particular mechanism or metric by which NATs "should" decide how long to keep out-of-order fragments. My purpose here is only to suggest one possible approach we might take to derive a "rule of thumb" that NAT designers could use to calculate a reasonable fragment re-ordering window size for a NAT of a particular size/capacity. I don't have any experimental evidence supporting the above rule of thumb in particular (or any other), and I will gladly defer to anyone who can suggest a better one. > And Linux appears to always send UDP fragments "seriously" out of order > -- > fragment #1 with the UDP header is sent last. > > > If the multiple fragments comprising a logical datagram are received > > out of > > their "natural" order (e.g., because the originating host OS sent them > > in > > reverse order), but the fragments of one datagram are at least not > > (badly) > > intermixed with the fragments of previous or subsequent datagrams, > > then that > > is an example of "slightly out-of-order". I think that NATs MUST be > > able to > > deal with such "slightly out-of-order" packets, for the reasons Suresh > > cites. > > > > If on the other hand fragments 2, 3, and 4 of datagram A arrive first, > > then > > all of datagrams B, C, D, ..., then fragment 1 of datagram A finally > > arrives > > after several or many other datagrams have been seen, that is a > > "seriously > > out-of-order fragment". It is obviously unreasonable to expect NATs to > > handle seriously out-of-order fragments beyond a certain point, for the > > well-known security reasons. And I think that Nagendra is right that > > many > > TCP/IP stacks (we can call them buggy TCP/IP stacks if you like, but > > they > > definitely exist) start behaving very poorly if routers in the network > > start > > routinely reordering packets, hence the Juniper experience. > > The problem with TCP performance is with TCP _segments_ arriving out of > order, > not TCP fragments arriving out of order. The IP stack reassembles out > of > order fragments, but the TCP stack handles putting the TCP segments into > their correct order. Yes, now that you mention it, I believe you're right. > One thing I'm unclear on -- do you want the NAT to re-order the > fragmented > packets? I don't see this as a requirement, and I don't see much > advantage > to the NAT sending the packets to the host in-order (#1...N), backwards > (#N..1), or in exactly the same order the NAT received them. I was wondering that too. There may be a slight benefit to NATs at least gathering the fragments of a packet together and forwarding them all together (rather than still intermixed with fragments of other packets as it may have received them). This may reduce the chance that the fragments will subsequently get "too far out of order" for the receiver or subsequent NATs to piece back together - thus making the NAT effectively behave as sort of a "misorder-reducing device" along the network path. But I believe NATs will probably do this anyway regardless of the exact order in which they transmit the fragments (original received order, or some fixed order), and so far I don't really see any benefit in specifying anything regarding this aspect of NAT behavior. > > I would like to propose the following as a "starting point" for the NAT > > fragment handling requirements: > > > > 1. NATs MUST at the very minimum be able to handle a datagram whose > > fragments > > appear in an arbitrary order on the wire but "all together", not > > intermixed > > with fragments of other datagrams. > > > > 2. NATs MUST protect themselves from fragmentation-based DoS attacks. > > I don't quite agree with separating "all together" from "slightly > together" as part of (1). Yes, you're right, it's unfortunately not that simple due to the convergence of multiple fragmented streams. But see my suggestions above. Bryan > > -d > > > I personally think #1, the lower bound, should probably be raised > > somewhat > > beyond the "absolute bare minimum" suggested above, if we can agree on > > a > > suitable way to specify how "out-of-order" a packet's fragments need > > to be > > before the NAT is no longer required to handle them. Nagendra's > > suggestion > > of a time window seems perfectly good to me, but the metric could > > alternatively be based on packet count (i.e., the NAT is only required > > to > > hold on to fragments within an N-packet window after the first fragment > > arrives), or byte count. We could leave the choice of metric to the > > NAT > > designer, but specify a minimum required value in each case. I don't > > have > > enough experience with fragmentation issues to make a suggestion as to > > what > > exactly would be best here. My point is merely that NATs really need > > to > > support _some_ kind of out-of-order fragment handling, at the very > > least so > > as to be able to handle the "slightly out of order" fragments that some > > TCP/IP stacks actually generate on the originating endpoint. > > > > Cheers, > > Bryan > > > >> So, both these are actually good reasons for NAT to support > >> out-of-order > >> fragment reassembly. > >> > >>> Of course, things could go terribly wrong if the timer code is buggy, > >>> or timer values are too large--which is not an unlikely scenario. > >>> > >>> > >>> In-order-fragments: > >>> > >>> In-order fragments can be easily processed without need for buffering > >>> based on their IP identifier fields. Since there is no buffering, > >>> the > >>> worst an attacker can do is slip packets through the NAT from the > >>> outside > >>> (an attack that can also be accomplished without employing IP > >>> fragments). > >> > >> [suresh] I replied to Cullen in a different thread. So, I wont expand > >> on > >> this further here. I believe, support of in-order-fragments alone, > >> tantamounts to no support of fragmentation. > >> > >> cheers, > >> suresh > >> > >> > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave From baford@mit.edu Thu, 17 Mar 2005 10:07:34 -0800 (PST) From: Bryan Ford Date: Thu, 17 Mar 2005 10:07:34 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050317174518.189E577A013@guns.icir.org> Message-ID: <200503171307.27562.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Hi Mark, Very nice work; your paper answers a lot of important questions. Thanks for pointing it out! Bryan On Thursday 17 March 2005 12:45, Mark Allman wrote: > > > > I'm for processing of in-order fragments--from what I discovered > > > > while working on DTLS, PMTUD is rarely turned on, > > > > > > [suresh] You are right, Path MTU discovery is rarely turned on. Many > > > applications (especially UDP based) are not even MTU mindful. > > I have not been following this thread, but some of my least favorite > comments to hear around the IETF are hand-wavy conjecture about how the > network works and what the traffic looks like. So, let me try to > re-iterate and expand on what Spencer said based on his reading of our > paper... > > (1) Of the 80K+ web servers we probed we were able to make good data > connections to 71K+ web servers and found: > > About one-third did not set DF, meaning the majority of servers did > in fact express a desire to use PMTUD. > > 47% of the servers used PMTUD just fine. > > 20% of the servers were not able to use PMTUD. I.e., they did not > respond to ICMP "too big" messages by reducing their packet size. > Presumably this is caused by some middlebox blocking the ICMP. > > None of the servers did PMTUD black hole discovery. I.e., in the > absence of an ICMP "too big" or a data acknowledgment none of the > servers responded by reducing the segment size. > > (2) Our study only covers TCP and HTTP. > > (3) I would be highly surprised if non-HTTP TCP traffic showed > drastically different PMTUD usage patterns from HTTP traffic. I > have been surprised before. > > (4) Our study does not consider non-TCP traffic at all. I can't even > begin to conjecture about UDP. But, I will offer a quick > measurement. I crunched all the UDP packets that traversed ICSI's > border yesterday (@M+) and found none had DF lit up. It's possible > that ICSI is abnormal, but probably not *that* abnormal. > > Our paper is: > > Alberto Medina, Mark Allman, Sally Floyd. Measuring Interactions > Between Transport Protocols and Middleboxes. ACM SIGCOMM/USENIX > Internet Measurement Conference, Taormina, Sicily, Italy, October > 2004. > http://www.icir.org/mallman/papers/tcp-evo-imc04.ps > > (section 4.2 is on PMTUD) > > For the interested, a longer version of the paper with more results > (but, not more PMTUD results) is: > > Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of > Transport Protocols in the Internet. December 2004. Under > submission. > http://www.icir.org/mallman/papers/tcp-evo-submit2.ps > > Enjoy! > > allman > > > > -- > Mark Allman -- ICIR -- http://www.icir.org/mallman/ From ssenthil@cisco.com Thu, 17 Mar 2005 11:12:38 -0800 (PST) From: Senthil Sivakumar Date: Thu, 17 Mar 2005 11:12:38 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <648A4528-96F9-11D9-B029-0003938AF740@cisco.com> Message-ID: <4.3.2.7.2.20050317105221.037521b8@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Processing in-order fragments is very similar to processing a regular non-fragmented packet as far as NAT is concerned (it is a different discussion if NAT supports ALGs). The whole discussion of fragment processing is relevant to receiving out-of-order fragments where the L4 information is not present in the IP packet received. NAT cannot translate this packet correctly if it is doing PAT unless it has the L4 information. So a NAT could 1. let the packet go without translation (bad, packet won't reach its destination) 2. Drop the packet (bad, same as above) 3. Queue the packet (with a timer/some mechanism to prevent Dos attacks on itself) The behavior as it exists today in terms of dealing with out of order fragments is non-deterministic and hence we should propose a predictable behavior, so, 3, seems to be the most logical choice. Senthil From dwing@cisco.com Thu, 17 Mar 2005 13:24:57 -0800 (PST) From: Dan Wing Date: Thu, 17 Mar 2005 13:24:57 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <23BBA0DE-96F5-11D9-BB81-000A95E35274@cisco.com> Message-ID: <02C5BCBF-972B-11D9-B029-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Mar 17, 2005, at 6:59 AM, Melinda Shore wrote: On Thursday, March 17, 2005, at 09:49 AM, Bryan Ford wrote: I would like to propose the following as a "starting point" for the NAT fragment handling requirements: 1. NATs MUST at the very minimum be able to handle a datagram whose fragments appear in an arbitrary order on the wire but "all together", not intermixed with fragments of other datagrams. 2. NATs MUST protect themselves from fragmentation-based DoS attacks. It seems to me that the second should be a SHOULD. We have firewalls to deal with that sort of problem and I have some serious reservations about NATs dinking around with TCP machinery. TCP segments != IP fragments. What's the dinking around with TCP machinery you're concerned with? -d From fluffy@cisco.com Fri, 18 Mar 2005 17:38:16 -0800 (PST) From: Cullen Jennings Date: Fri, 18 Mar 2005 17:38:16 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <200503171018.14743.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 3/17/05 7:18 AM, "Bryan Ford" wrote: >>> 1. NATs MUST at the very minimum be able to handle a datagram whose >>> fragments >>> appear in an arbitrary order on the wire but "all together", not >>> intermixed >>> with fragments of other datagrams. This sounds like a very contrived sort of scenario - image I had a application that worked when it was the only applications, but then periodically failed when other applications where behind the same NAT. This does not sound like a good situation. I'm not really in agreement with requirements that make NATs do something that helps some of the time but don't solve any problem for the application a bunch of the time. Cullen (not as chair) From audet@nortel.com Sat, 19 Mar 2005 12:56:22 -0800 (PST) From: "Francois Audet" Date: Sat, 19 Mar 2005 12:56:22 -0800 (PST) Subject: RE: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets Message-ID: <1ECE0EB50388174790F9694F77522CCF01C508BB@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Requiring NATs to process Out-of-orderfragmented TCP packets Agree. Those are operational nightmares. I'd rather it just plain doesn't work and you have to buy a new NAT. It's a lot cheaper than paying people to figure out why it fails unpredictably. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Cullen Jennings > Sent: Friday, March 18, 2005 17:38 > To: Bryan Ford; Melinda L Shore > Cc: Behave > Subject: Re: [Ietf-behave] Requiring NATs to process > Out-of-orderfragmented TCP packets > > > On 3/17/05 7:18 AM, "Bryan Ford" wrote: > > >>> 1. NATs MUST at the very minimum be able to handle a > datagram whose > >>> fragments appear in an arbitrary order on the wire but "all > >>> together", not intermixed > >>> with fragments of other datagrams. > > This sounds like a very contrived sort of scenario - image I > had a application that worked when it was the only > applications, but then periodically failed when other > applications where behind the same NAT. This does not sound > like a good situation. > > I'm not really in agreement with requirements that make NATs > do something that helps some of the time but don't solve any > problem for the application a bunch of the time. > > Cullen (not as chair) _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From srisuresh@yahoo.com Mon, 21 Mar 2005 06:09:58 -0800 (PST) From: Pyda Srisuresh Date: Mon, 21 Mar 2005 06:09:58 -0800 (PST) Subject: RE: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets Message-ID: <20050321140958.14046.qmail@web40422.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain The alternative is to make NAT predictable and work with IP fragments irrespective of the order in which the fragments arrive. cheers, suresh --- Francois Audet wrote: > Agree. > > Those are operational nightmares. I'd rather it just plain doesn't > work and you have to buy a new NAT. It's a lot cheaper > than paying people to figure out why it fails > unpredictably. > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Cullen Jennings > > Sent: Friday, March 18, 2005 17:38 > > To: Bryan Ford; Melinda L Shore > > Cc: Behave > > Subject: Re: [Ietf-behave] Requiring NATs to process > > Out-of-orderfragmented TCP packets > > > > > > On 3/17/05 7:18 AM, "Bryan Ford" wrote: > > > > >>> 1. NATs MUST at the very minimum be able to handle a > > datagram whose > > >>> fragments appear in an arbitrary order on the wire but "all > > >>> together", not intermixed > > >>> with fragments of other datagrams. > > > > This sounds like a very contrived sort of scenario - image I > > had a application that worked when it was the only > > applications, but then periodically failed when other > > applications where behind the same NAT. This does not sound > > like a good situation. > > > > I'm not really in agreement with requirements that make NATs > > do something that helps some of the time but don't solve any > > problem for the application a bunch of the time. > > > > Cullen (not as chair) _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From paul.hoffman@vpnc.org Mon, 21 Mar 2005 08:17:44 -0800 (PST) From: Paul Hoffman Date: Mon, 21 Mar 2005 08:17:44 -0800 (PST) Subject: [Ietf-behave] BEHAVE and SHOULD Message-ID: MIME-Version: 1.0 Content-Type: text/plain Greetings again. This last long thread on requiring NATs to process out-of-order fragmented TCP packets has shown a procedural problem, namely that folks seem to be stretching the definitions of MUST and SHOULD. This is bad, given that those definitions are supposed to be IETF-wide and stable. At the risk of sounding too un-technical, could everyone go read RFC 2119 again? It's surprisingly short and concise: there are two pages of content. See . For those who don't want to even read two pages, a short quote should suffice: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Given that, I have no idea why we would not say that all kinds of NATs SHOULD process out-of-order fragmented TCP packets correctly. Saying that tells implementers that they have to have some code to process out-of-order fragments, but their software may stop doing so in particular circumstances, like them running out fragment buffers. The implications of having too few fragment buffers is that their NATs will cause silent and confusing damage to the data stream. If someone researches the problem and discovers that it is their NAT causing the damage, such a NAT may get poor reviews in public. Note that determining the number of fragment buffers is fairly easy to test in a lab environment. --Paul Hoffman, Director --VPN Consortium From fluffy@cisco.com Mon, 21 Mar 2005 19:41:55 -0800 (PST) From: Cullen Jennings Date: Mon, 21 Mar 2005 19:41:55 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets In-Reply-To: <20050321140958.14046.qmail@web40422.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain There are several mentions on the thread of alternatives that no client software can count on so they don't help much. There are also alternatives that have a trivial DOS attack against the NAT. If you have an alternative that solves this problem and does not have the trivial DOS attacks against the NAT, I think people would be interested in it but as far as I can tell from the list traffic, people don't get what that proposal is yet. On 3/21/05 6:09 AM, "Pyda Srisuresh" wrote: > > The alternative is to make NAT predictable and work with IP fragments > irrespective of the order in which the fragments arrive. > > cheers, > suresh > > --- Francois Audet wrote: >> Agree. >> >> Those are operational nightmares. I'd rather it just plain doesn't >> work and you have to buy a new NAT. It's a lot cheaper >> than paying people to figure out why it fails >> unpredictably. >> >>> -----Original Message----- >>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of >>> Cullen Jennings >>> Sent: Friday, March 18, 2005 17:38 >>> To: Bryan Ford; Melinda L Shore >>> Cc: Behave >>> Subject: Re: [Ietf-behave] Requiring NATs to process >>> Out-of-orderfragmented TCP packets >>> >>> >>> On 3/17/05 7:18 AM, "Bryan Ford" wrote: >>> >>>>>> 1. NATs MUST at the very minimum be able to handle a >>> datagram whose >>>>>> fragments appear in an arbitrary order on the wire but "all >>>>>> together", not intermixed >>>>>> with fragments of other datagrams. >>> >>> This sounds like a very contrived sort of scenario - image I >>> had a application that worked when it was the only >>> applications, but then periodically failed when other >>> applications where behind the same NAT. This does not sound >>> like a good situation. >>> >>> I'm not really in agreement with requirements that make NATs >>> do something that helps some of the time but don't solve any >>> problem for the application a bunch of the time. >>> >>> Cullen (not as chair) _______________________________________________ >>> Ietf-behave mailing list >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >>> >>> >>> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> From srisuresh@yahoo.com Wed, 23 Mar 2005 06:49:44 -0800 (PST) From: Pyda Srisuresh Date: Wed, 23 Mar 2005 06:49:44 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets Message-ID: <20050323144944.2317.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, DoS attacks can occur in many ways - IP fragment based attacks, ICMP attacks, TCP SYN attacks, UDP flooding etc.. I believe, NATs SHOULD defend themselves against trivial DoS attacks. The subject of defending against trivial DoS attacks shoudl be discussed as a separate thread, and not be tied to IP fragmentation support or TCP support etc. I will be happy to start a new thread to discuss the requirement on NATs to defend against trivial DoS attacks. However, we should have a closure on the fragmentation support issue prior to hopping on the DOS thread. I believe, Requiring NATs to support IP fragmentation will be the way to close this. By doing this, apps can expect a deterministic behavior from NATs. cheers, suresh --- Cullen Jennings wrote: > > There are several mentions on the thread of alternatives that no client > software can count on so they don't help much. There are also alternatives > that have a trivial DOS attack against the NAT. If you have an alternative > that solves this problem and does not have the trivial DOS attacks against > the NAT, I think people would be interested in it but as far as I can tell > from the list traffic, people don't get what that proposal is yet. > > On 3/21/05 6:09 AM, "Pyda Srisuresh" wrote: > > > > > The alternative is to make NAT predictable and work with IP fragments > > irrespective of the order in which the fragments arrive. > > > > cheers, > > suresh > > > > --- Francois Audet wrote: > >> Agree. > >> > >> Those are operational nightmares. I'd rather it just plain doesn't > >> work and you have to buy a new NAT. It's a lot cheaper > >> than paying people to figure out why it fails > >> unpredictably. > >> > >>> -----Original Message----- > >>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > >>> Cullen Jennings > >>> Sent: Friday, March 18, 2005 17:38 > >>> To: Bryan Ford; Melinda L Shore > >>> Cc: Behave > >>> Subject: Re: [Ietf-behave] Requiring NATs to process > >>> Out-of-orderfragmented TCP packets > >>> > >>> > >>> On 3/17/05 7:18 AM, "Bryan Ford" wrote: > >>> > >>>>>> 1. NATs MUST at the very minimum be able to handle a > >>> datagram whose > >>>>>> fragments appear in an arbitrary order on the wire but "all > >>>>>> together", not intermixed > >>>>>> with fragments of other datagrams. > >>> > >>> This sounds like a very contrived sort of scenario - image I > >>> had a application that worked when it was the only > >>> applications, but then periodically failed when other > >>> applications where behind the same NAT. This does not sound > >>> like a good situation. > >>> > >>> I'm not really in agreement with requirements that make NATs > >>> do something that helps some of the time but don't solve any > >>> problem for the application a bunch of the time. > >>> > >>> Cullen (not as chair) _______________________________________________ > >>> Ietf-behave mailing list > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>> > >>> > >>> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > > From srisuresh@yahoo.com Wed, 23 Mar 2005 06:54:36 -0800 (PST) From: Pyda Srisuresh Date: Wed, 23 Mar 2005 06:54:36 -0800 (PST) Subject: [Ietf-behave] RFC 4008 on Definitions of Managed Objects for Network Address Translators (NAT) Message-ID: <20050323145436.3630.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Folks, Below is the announcement of the availability of NAT MIB in RFC 4008. FYI. cheers, suresh > > > To: ietf-announce@xxxxxxxx > From: rfc-editor@xxxxxxxxxxxxxx > Date: Tue, 22 Mar 2005 16:28:01 -0800 > CC: rfc-editor@xxxxxxxxxxxxxx > Subject: RFC 4008 on Definitions of Managed Objects for Network Address > Translators (NAT) > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 4008 > > Title: Definitions of Managed Objects for > Network Address Translators (NAT) > Author(s): R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, > C. Wang > Status: Standards Track > Date: March 2005 > Mailbox: rrohit74@xxxxxxxxxxx, srisuresh@xxxxxxxxx, > raraghun@xxxxxxxxx, npai@xxxxxxxxx, > cliffwang2000@xxxxxxxxx > Pages: 64 > Characters: 125696 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-nat-natmib-09.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4008.txt > > > This memo defines a portion of the Management Information Base (MIB) > for devices implementing Network Address Translator (NAT) function. > This MIB module may be used for configuration as well as monitoring > of a device capable of NAT function. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@xxxxxxxxx Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@xxxxxxxxxxxxxxx > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@xxxxxxxxxxxxxx with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@xxxxxxxxxxxxxx > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@xxxxxxxxxxxxxxx Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@xxxxxxxxxxxxxxx Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ midcom mailing list midcom@xxxxxxxx https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@xxxxxxxx https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@xxxxxxxx https://www1.ietf.org/mailman/listinfo/midcom From fluffy@cisco.com Wed, 23 Mar 2005 16:47:06 -0800 (PST) From: Cullen Jennings Date: Wed, 23 Mar 2005 16:47:06 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets In-Reply-To: <20050323144944.2317.qmail@web40425.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 3/23/05 6:49 AM, "Pyda Srisuresh" wrote: > I believe, Requiring NATs to support IP > fragmentation will be the way to close this. Can you provide a concise explanation of how NATs should behave on this. Then provide a sample of idea of one way that they might protect themselves from the using up all the memory problem. As a pointed out in my previous email, you keep asserting there is a solution to this problem. I am unaware of what it is so it makes me concerned to say that everyone must do something that I don't know how they can do it. Cullen (not as chair) From ssenthil@cisco.com Wed, 23 Mar 2005 18:30:12 -0800 (PST) From: Senthil Sivakumar Date: Wed, 23 Mar 2005 18:30:12 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain My suggestion is: "NATs should handle IP fragments that are seen in order and out of order. When an in order fragment is seen NAT should store the L4 information of the first fragment so that it can match the subsequent fragments that do not carry L4 headers. No buffering of the fragments is required in case of in order fragments. For out of order fragments, NAT must store the fragment until the first fragment is seen. The fragments should be stored for a period of N seconds before discarding them. NATs must not store more than X fragments per flow and must not store more than fragments for Y flows at any point of time" The values of N, X and Y are to be determined by the network administrator who best knows the latency of his/her network, capability of the box. Senthil On Wed, 23 Mar 2005, Cullen Jennings wrote: > On 3/23/05 6:49 AM, "Pyda Srisuresh" wrote: > > > I believe, Requiring NATs to support IP > > fragmentation will be the way to close this. > > Can you provide a concise explanation of how NATs should behave on this. > Then provide a sample of idea of one way that they might protect themselves > from the using up all the memory problem. As a pointed out in my previous > email, you keep asserting there is a solution to this problem. I am unaware > of what it is so it makes me concerned to say that everyone must do > something that I don't know how they can do it. > > Cullen (not as chair) > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From paul.hoffman@vpnc.org Wed, 23 Mar 2005 19:17:57 -0800 (PST) From: Paul Hoffman Date: Wed, 23 Mar 2005 19:17:57 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 6:30 PM -0800 3/23/05, Senthil Sivakumar wrote: My suggestion is: "NATs should handle IP fragments that are seen in order and out of order. When an in order fragment is seen NAT should store the L4 information of the first fragment so that it can match the subsequent fragments that do not carry L4 headers. No buffering of the fragments is required in case of in order fragments. For out of order fragments, NAT must store the fragment until the first fragment is seen. The fragments should be stored for a period of N seconds before discarding them. NATs must not store more than X fragments per flow and must not store more than fragments for Y flows at any point of time" The values of N, X and Y are to be determined by the network administrator who best knows the latency of his/her network, capability of the box. Given the definition of SHOULD from RFC 2119 (which is normatively referenced in the drafts), a different wording might be: NATs SHOULD handle IP fragments that are seen in order and out of order. When an in order fragment is seen, a NAT SHOULD store the L4 information of the first fragment so that it can match the subsequent fragments that do not carry L4 headers. No buffering of the fragments is required in case of in order fragments. For out of order fragments, a NAT SHOULD store the fragment until the first fragment is seen. The fragments SHOULD be stored for an administrator-assigned period of time before discarding them. A NATs SHOULD allow the administrator to assign the number fragments to be stored per flow, and SHOULD allow the administrator to assign the number of total fragmented flows being held. --Paul Hoffman, Director --VPN Consortium From kbiswas@cisco.com Wed, 23 Mar 2005 21:05:54 -0800 (PST) From: Kaushik Biswas Date: Wed, 23 Mar 2005 21:05:54 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets In-Reply-To: Message-ID: <4.3.2.7.2.20050323204944.02ea21e8@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain To add to this: these configurable values of N, X & Y will give attempt towards providing a deterministic behavior of the NAT under fragmentation. One more observation. DOS attacks can even occur at the endpoint and one can argue that reachability to this endpoint is not deterministic (or guaranteed) even when there is no NAT in picture. Kaushik At 06:30 PM 3/23/2005 -0800, Senthil Sivakumar wrote: My suggestion is: "NATs should handle IP fragments that are seen in order and out of order. When an in order fragment is seen NAT should store the L4 information of the first fragment so that it can match the subsequent fragments that do not carry L4 headers. No buffering of the fragments is required in case of in order fragments. For out of order fragments, NAT must store the fragment until the first fragment is seen. The fragments should be stored for a period of N seconds before discarding them. NATs must not store more than X fragments per flow and must not store more than fragments for Y flows at any point of time" The values of N, X and Y are to be determined by the network administrator who best knows the latency of his/her network, capability of the box. Senthil On Wed, 23 Mar 2005, Cullen Jennings wrote: > On 3/23/05 6:49 AM, "Pyda Srisuresh" wrote: > > > I believe, Requiring NATs to support IP > > fragmentation will be the way to close this. > > Can you provide a concise explanation of how NATs should behave on this. > Then provide a sample of idea of one way that they might protect themselves > from the using up all the memory problem. As a pointed out in my previous > email, you keep asserting there is a solution to this problem. I am unaware > of what it is so it makes me concerned to say that everyone must do > something that I don't know how they can do it. > > Cullen (not as chair) > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Thu, 24 Mar 2005 08:39:51 -0800 (PST) From: Pyda Srisuresh Date: Thu, 24 Mar 2005 08:39:51 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets Message-ID: <20050324163951.52721.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Here is what I would sugegst. A NAT device MUST be capable of processing all fragments of an inbound IP datagram. These fragments cannot be assumed to arrive in order. The NAT device must retain the assembly state pertaining to a fragmentation ID until all fragments of the IP datagram are processed. By doing this, NAT is able to process all fragments pertaining to an IP datagram using the same NAT Session the IP datagram belongs to. As with any stateful processing, there may be exceptions and limitations on how long a state can be retained and how many simultaneous states a NAT device can retain at once. Thsi depends on the design and memory limitations of a NAT device and is not within the scope of this document. cheers, suresh --- Paul Hoffman wrote: > At 6:30 PM -0800 3/23/05, Senthil Sivakumar wrote: > >My suggestion is: > > > >"NATs should handle IP fragments that are seen in order and out of order. > >When an in order fragment is seen NAT should store the L4 information of > >the first fragment so that it can match the subsequent fragments that do > >not carry L4 headers. No buffering of the fragments is required in case of > >in order fragments. For out of order fragments, NAT must store the > >fragment until the first fragment is seen. The fragments should be stored > >for a period of N seconds before discarding them. NATs must not store more > >than X fragments per flow and must not store more than fragments for Y > >flows at any point of time" > > > >The values of N, X and Y are to be determined by the network administrator > >who best knows the latency of his/her network, capability of the box. > > Given the definition of SHOULD from RFC 2119 (which is normatively > referenced in the drafts), a different wording might be: > > NATs SHOULD handle IP fragments that are seen in order and out of order. > When an in order fragment is seen, a NAT SHOULD store the L4 > information of the first fragment so that it can match the subsequent > fragments that do not carry L4 headers. No buffering of the fragments is > required in case of in order fragments. For out of order fragments, a > NAT SHOULD store the fragment until the first fragment is seen. The > fragments SHOULD be stored for an administrator-assigned period of time > before discarding them. A NATs SHOULD allow the administrator to assign > the number fragments to be stored per flow, and SHOULD allow the > administrator to assign the number of total fragmented flows being held. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From audet@nortel.com Thu, 24 Mar 2005 09:57:15 -0800 (PST) From: "Francois Audet" Date: Thu, 24 Mar 2005 09:57:15 -0800 (PST) Subject: RE: [Ietf-behave] Requiring NATs to process Out-of-order fragment edTCP packets Message-ID: <1ECE0EB50388174790F9694F77522CCF01CB9F49@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Requiring NATs to process Out-of-order fragmentedTCP packets The MUST in the first paragraph is contradicted by the second paragraph which implies it should be a SHOULD. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pyda Srisuresh > Sent: Thursday, March 24, 2005 08:40 > To: Behave > Subject: Re: [Ietf-behave] Requiring NATs to process > Out-of-order fragmentedTCP packets > > > > Here is what I would sugegst. > > A NAT device MUST be capable of processing all fragments of > an inbound IP datagram. These fragments cannot be assumed to > arrive in order. The NAT device must retain the assembly > state pertaining to a fragmentation ID until all fragments of > the IP datagram are processed. By doing this, NAT is able to > process all fragments pertaining to an IP datagram using the > same NAT Session the IP datagram belongs to. > > As with any stateful processing, there may be exceptions and > limitations on how long a state can be retained and how many > simultaneous states a NAT device can retain at once. Thsi > depends on the design and memory limitations of a NAT > device and is not within the scope of this document. > > cheers, > suresh > > > --- Paul Hoffman wrote: > > At 6:30 PM -0800 3/23/05, Senthil Sivakumar wrote: > > >My suggestion is: > > > > > >"NATs should handle IP fragments that are seen in order and out of > > >order. When an in order fragment is seen NAT should store the L4 > > >information of the first fragment so that it can match the > subsequent > > >fragments that do not carry L4 headers. No buffering of > the fragments > > >is required in case of in order fragments. For out of order > > >fragments, NAT must store the fragment until the first fragment is > > >seen. The fragments should be stored for a period of N > seconds before > > >discarding them. NATs must not store more than X fragments > per flow > > >and must not store more than fragments for Y flows at any point of > > >time" > > > > > >The values of N, X and Y are to be determined by the network > > >administrator who best knows the latency of his/her network, > > >capability of the box. > > > > Given the definition of SHOULD from RFC 2119 (which is normatively > > referenced in the drafts), a different wording might be: > > > > NATs SHOULD handle IP fragments that are seen in order and out of > > order. When an in order fragment is seen, a NAT SHOULD store the L4 > > information of the first fragment so that it can match the > subsequent > > fragments that do not carry L4 headers. No buffering of the > fragments > > is required in case of in order fragments. For out of order > fragments, > > a NAT SHOULD store the fragment until the first fragment is > seen. The > > fragments SHOULD be stored for an administrator-assigned period of > > time before discarding them. A NATs SHOULD allow the > administrator to > > assign the number fragments to be stored per flow, and SHOULD allow > > the administrator to assign the number of total fragmented > flows being > > held. > > > > --Paul Hoffman, Director > > --VPN Consortium _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From paul.hoffman@vpnc.org Thu, 24 Mar 2005 10:41:24 -0800 (PST) From: Paul Hoffman Date: Thu, 24 Mar 2005 10:41:24 -0800 (PST) Subject: RE: [Ietf-behave] Requiring NATs to process Out-of-order fragment edTCP packets In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01CB9F49@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 12:56 PM -0500 3/24/05, Francois Audet wrote: The MUST in the first paragraph is contradicted by the second paragraph which implies it should be a SHOULD. Agree. --Paul Hoffman, Director --VPN Consortium From dwing@cisco.com Thu, 24 Mar 2005 13:09:26 -0800 (PST) From: Dan Wing Date: Thu, 24 Mar 2005 13:09:26 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: Message-ID: <02A366F2-9CA9-11D9-A5D3-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Mar 23, 2005, at 7:17 PM, Paul Hoffman wrote: At 6:30 PM -0800 3/23/05, Senthil Sivakumar wrote: My suggestion is: "NATs should handle IP fragments that are seen in order and out of order. When an in order fragment is seen NAT should store the L4 information of the first fragment so that it can match the subsequent fragments that do not carry L4 headers. No buffering of the fragments is required in case of in order fragments. For out of order fragments, NAT must store the fragment until the first fragment is seen. The fragments should be stored for a period of N seconds before discarding them. NATs must not store more than X fragments per flow and must not store more than fragments for Y flows at any point of time" The values of N, X and Y are to be determined by the network administrator who best knows the latency of his/her network, capability of the box. Given the definition of SHOULD from RFC 2119 (which is normatively referenced in the drafts), a different wording might be: NATs SHOULD handle IP fragments that are seen in order and out of order. When an in order fragment is seen, a NAT SHOULD store the L4 information of the first fragment so that it can match the subsequent fragments that do not carry L4 headers. No buffering of the fragments is required in case of in order fragments. For out of order fragments, a NAT SHOULD store the fragment until the first fragment is seen. The fragments SHOULD be stored for an administrator-assigned period of time before discarding them. A NATs SHOULD allow the administrator to assign the number fragments to be stored per flow, and SHOULD allow the administrator to assign the number of total fragmented flows being held. If you receive a fragment, you don't know which flow it belongs to because a fragment only contains the source and destination IP addresses, but you need the full 5-tuple (src/dest IP, protocol, src/dest port) to know the flow associated with a fragment. You can't identify the "flow" - you can only identify the source IP address that (purportedly) sent you the fragment. There are lots of ways a vendor could provide for protection while trying to avoid interfering with a valid flow, and the vendor might have cool techniques to do so. How about instead of your last two sentences we just say: A NAT SHOULD allow out-of-order fragment behavior to be adjusted by the administrator, such as the number, duration, or source IP address of fragments kept by the NAT or a combination of these parameters. We need to explain if it's important for the NAT to reassemble the packets before sending to the internal host; that's missing from your proposed text. What do we want to say about overlapping IP fragments? -d From fluffy@cisco.com Thu, 24 Mar 2005 13:14:46 -0800 (PST) From: Cullen Jennings Date: Thu, 24 Mar 2005 13:14:46 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Ok, that proposal is concrete and I get it. Thank you. Now the application developer that is trying to write a client that will work through a NAT that does this can not make any assumptions about how the NAT has been configured. So I don't see how behave specifying this one way or another makes any difference to what applications can work or not. On 3/23/05 6:30 PM, "Senthil Sivakumar" wrote: > My suggestion is: > > "NATs should handle IP fragments that are seen in order and out of order. > When an in order fragment is seen NAT should store the L4 information of > the first fragment so that it can match the subsequent fragments that do > not carry L4 headers. No buffering of the fragments is required in case of > in order fragments. For out of order fragments, NAT must store the > fragment until the first fragment is seen. The fragments should be stored > for a period of N seconds before discarding them. NATs must not store more > than X fragments per flow and must not store more than fragments for Y > flows at any point of time" > > The values of N, X and Y are to be determined by the network administrator > who best knows the latency of his/her network, capability of the box. > > Senthil > > On Wed, 23 Mar 2005, Cullen Jennings wrote: > >> On 3/23/05 6:49 AM, "Pyda Srisuresh" wrote: >> >>> I believe, Requiring NATs to support IP >>> fragmentation will be the way to close this. >> >> Can you provide a concise explanation of how NATs should behave on this. >> Then provide a sample of idea of one way that they might protect themselves >> from the using up all the memory problem. As a pointed out in my previous >> email, you keep asserting there is a solution to this problem. I am unaware >> of what it is so it makes me concerned to say that everyone must do >> something that I don't know how they can do it. >> >> Cullen (not as chair) >> >> >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> From paul.hoffman@vpnc.org Thu, 24 Mar 2005 13:48:57 -0800 (PST) From: Paul Hoffman Date: Thu, 24 Mar 2005 13:48:57 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 1:09 PM -0800 3/24/05, Dan Wing wrote: There are lots of ways a vendor could provide for protection while trying to avoid interfering with a valid flow, and the vendor might have cool techniques to do so. How about instead of your last two sentences we just say: A NAT SHOULD allow out-of-order fragment behavior to be adjusted by the administrator, such as the number, duration, or source IP address of fragments kept by the NAT or a combination of these parameters. Sounds fine. We need to explain if it's important for the NAT to reassemble the packets before sending to the internal host; that's missing from your proposed text. It's missing because I don't particularly believe it. To the internal host, the NAT looks like the upstream router. Routers don't normally reassemble packets, do they? What do we want to say about overlapping IP fragments? If by "overlapping IP fragments" you mean multiple fragmented flows, why should we say anything in particular about them. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Thu, 24 Mar 2005 17:52:58 -0800 (PST) From: Paul Hoffman Date: Thu, 24 Mar 2005 17:52:58 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 1:14 PM -0800 3/24/05, Cullen Jennings wrote: Now the application developer that is trying to write a client that will work through a NAT that does this can not make any assumptions about how the NAT has been configured. So I don't see how behave specifying this one way or another makes any difference to what applications can work or not. It doesn't, but it doesn't need to. The WG charter says "This working group proposes to generate requirements documents and best current practices to enable NATs to function in as deterministic a fashion as possible." It also says "The behavior that will be considered includes IP fragmentation...". Having IP fragmentation work in as deterministic a fashion as possible fits squarely into the charter, yes? --Paul Hoffman, Director --VPN Consortium From srisuresh@yahoo.com Thu, 24 Mar 2005 18:41:36 -0800 (PST) From: Pyda Srisuresh Date: Thu, 24 Mar 2005 18:41:36 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets Message-ID: <20050325024136.95515.qmail@web40428.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > > Ok, that proposal is concrete and I get it. Thank you. > > Now the application developer that is trying to write a client that will > work through a NAT that does this can not make any assumptions about how the > NAT has been configured. So I don't see how behave specifying this one way > or another makes any difference to what applications can work or not. > [suresh] When applications send large chunks of data with no reverence to MTU size, the NAT devices along the traversal will not block the fragments from traversing. For example, aplication like NFS can work across a NAT device. cheers, suresh > > On 3/23/05 6:30 PM, "Senthil Sivakumar" wrote: > > > My suggestion is: > > > > "NATs should handle IP fragments that are seen in order and out of order. > > When an in order fragment is seen NAT should store the L4 information of > > the first fragment so that it can match the subsequent fragments that do > > not carry L4 headers. No buffering of the fragments is required in case of > > in order fragments. For out of order fragments, NAT must store the > > fragment until the first fragment is seen. The fragments should be stored > > for a period of N seconds before discarding them. NATs must not store more > > than X fragments per flow and must not store more than fragments for Y > > flows at any point of time" > > > > The values of N, X and Y are to be determined by the network administrator > > who best knows the latency of his/her network, capability of the box. > > > > Senthil > > > > On Wed, 23 Mar 2005, Cullen Jennings wrote: > > > >> On 3/23/05 6:49 AM, "Pyda Srisuresh" wrote: > >> > >>> I believe, Requiring NATs to support IP > >>> fragmentation will be the way to close this. > >> > >> Can you provide a concise explanation of how NATs should behave on this. > >> Then provide a sample of idea of one way that they might protect > themselves > >> from the using up all the memory problem. As a pointed out in my previous > >> email, you keep asserting there is a solution to this problem. I am > unaware > >> of what it is so it makes me concerned to say that everyone must do > >> something that I don't know how they can do it. > >> > >> Cullen (not as chair) > >> > >> > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > From srisuresh@yahoo.com Thu, 24 Mar 2005 19:02:02 -0800 (PST) From: Pyda Srisuresh Date: Thu, 24 Mar 2005 19:02:02 -0800 (PST) Subject: RE: [Ietf-behave] Requiring NATs to process Out-of-order fragment edTCP packets Message-ID: <20050325030202.63577.qmail@web40422.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Francois, I believe, the requirement is a MUST, not a SHOULD. The second parapgraph is not written to dilute the first into a SHOULD. The second paragraph indicates that there can be resource limits in a NAT device that might not permit the NAT device to retain state forever. For example, one of the fragments could have been lost in the network and may never arrive. So, NAT device would not want to hold the reassemply state forever. There may be also be situations where the device is unable to create a state for a certain datagram when it is out of memory resource. Essentialy, these reflect the operational aspects in real-time, but does not change the requirement in the first paragraph. cheers, suresh --- Francois Audet wrote: > The MUST in the first paragraph is contradicted by the second > paragraph which implies it should be a SHOULD. > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Pyda Srisuresh > > Sent: Thursday, March 24, 2005 08:40 > > To: Behave > > Subject: Re: [Ietf-behave] Requiring NATs to process > > Out-of-order fragmentedTCP packets > > > > > > > > Here is what I would sugegst. > > > > A NAT device MUST be capable of processing all fragments of > > an inbound IP datagram. These fragments cannot be assumed to > > arrive in order. The NAT device must retain the assembly > > state pertaining to a fragmentation ID until all fragments of > > the IP datagram are processed. By doing this, NAT is able to > > process all fragments pertaining to an IP datagram using the > > same NAT Session the IP datagram belongs to. > > > > As with any stateful processing, there may be exceptions and > > limitations on how long a state can be retained and how many > > simultaneous states a NAT device can retain at once. Thsi > > depends on the design and memory limitations of a NAT > > device and is not within the scope of this document. > > > > cheers, > > suresh > > > > > > --- Paul Hoffman wrote: > > > At 6:30 PM -0800 3/23/05, Senthil Sivakumar wrote: > > > >My suggestion is: > > > > > > > >"NATs should handle IP fragments that are seen in order and out of > > > >order. When an in order fragment is seen NAT should store the L4 > > > >information of the first fragment so that it can match the > > subsequent > > > >fragments that do not carry L4 headers. No buffering of > > the fragments > > > >is required in case of in order fragments. For out of order > > > >fragments, NAT must store the fragment until the first fragment is > > > >seen. The fragments should be stored for a period of N > > seconds before > > > >discarding them. NATs must not store more than X fragments > > per flow > > > >and must not store more than fragments for Y flows at any point of > > > >time" > > > > > > > >The values of N, X and Y are to be determined by the network > > > >administrator who best knows the latency of his/her network, > > > >capability of the box. > > > > > > Given the definition of SHOULD from RFC 2119 (which is normatively > > > referenced in the drafts), a different wording might be: > > > > > > NATs SHOULD handle IP fragments that are seen in order and out of > > > order. When an in order fragment is seen, a NAT SHOULD store the L4 > > > information of the first fragment so that it can match the > > subsequent > > > fragments that do not carry L4 headers. No buffering of the > > fragments > > > is required in case of in order fragments. For out of order > > fragments, > > > a NAT SHOULD store the fragment until the first fragment is > > seen. The > > > fragments SHOULD be stored for an administrator-assigned period of > > > time before discarding them. A NATs SHOULD allow the > > administrator to > > > assign the number fragments to be stored per flow, and SHOULD allow > > > the administrator to assign the number of total fragmented > > flows being > > > held. > > > > > > --Paul Hoffman, Director > > > --VPN Consortium _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From spencer@mcsr-labs.org Fri, 25 Mar 2005 03:19:17 -0800 (PST) From: "Spencer Dawkins" Date: Fri, 25 Mar 2005 03:19:17 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmentedTCP packets In-Reply-To: <20050325030202.63577.qmail@web40422.mail.yahoo.com> Message-ID: <15aa01c5312c$a43fbdd0$e8878182@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain I believe, the requirement is a MUST, not a SHOULD. The second parapgraph is not written to dilute the first into a SHOULD. The second paragraph indicates that there can be resource limits in a NAT device that might not permit the NAT device to retain state forever. For example, one of the fragments could have been lost in the network and may never arrive. So, NAT device would not want to hold the reassemply state forever. There may be also be situations where the device is unable to create a state for a certain datagram when it is out of memory resource. Essentialy, these reflect the operational aspects in real-time, but does not change the requirement in the first paragraph. This is actually the way I read Suresh's previous e-mail - NATs MUST do this, if they do anything, but a NAT that has crashed (for example) is allowed to treat this as a SHOULD, since no device that has crashed will be doing anything of the sort :-) What I think the proposal is saying is that applications can rely on this behavior unless the NAT is is being DOS-attacked, and applications can't always rely on MUST-strength behavior during a DOS attack whether we're talking about a NAT or not. Did I understand your point, Suresh? Spencer From srisuresh@yahoo.com Fri, 25 Mar 2005 05:51:26 -0800 (PST) From: Pyda Srisuresh Date: Fri, 25 Mar 2005 05:51:26 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmentedTCP packets Message-ID: <20050325135126.10629.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Spencer Dawkins wrote: > > I believe, the requirement is a MUST, not a SHOULD. The second > > parapgraph is > > not written to dilute the first into a SHOULD. > > > > The second paragraph indicates that there can be resource limits in > > a NAT > > device that might not permit the NAT device to retain state forever. > > For > > example, one of the fragments could have been lost in the network > > and may > > never arrive. So, NAT device would not want to hold the reassemply > > state > > forever. There may be also be situations where the device is unable > > to create a > > state for a certain datagram when it is out of memory resource. > > Essentialy, > > these reflect the operational aspects in real-time, but does not > > change the > > requirement in the first paragraph. > > This is actually the way I read Suresh's previous e-mail - NATs MUST > do this, if they do anything, but a NAT that has crashed (for example) > is allowed to treat this as a SHOULD, since no device that has crashed > will be doing anything of the sort :-) > > What I think the proposal is saying is that applications can rely on > this behavior unless the NAT is is being DOS-attacked, and [suresh] I am saying that the applications should be able to rely on the NAT devices doing the fragment processing correctly. However, that is not to say that there are no situations where the NAT device will not drop IP datagrams. Yes, Packets may be dropped during DoS attacks. > applications can't always rely on MUST-strength behavior during a DOS > attack whether we're talking about a NAT or not. > [suresh] Yes indeed. > Did I understand your point, Suresh? > [suresh] I think so. Thanks. > Spencer > cheers, suresh From dwing@cisco.com Fri, 25 Mar 2005 08:48:02 -0800 (PST) From: Dan Wing Date: Fri, 25 Mar 2005 08:48:02 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Mar 24, 2005, at 1:48 PM, Paul Hoffman wrote: We need to explain if it's important for the NAT to reassemble the packets before sending to the internal host; that's missing from your proposed text. It's missing because I don't particularly believe it. To the internal host, the NAT looks like the upstream router. Routers don't normally reassemble packets, do they? Correct, they don't. However, routers don't hold onto packets, either, which is what we're asking the NAT to do with out-of-order packets. See below, because my question about reassembly is related to my question about overlapping fragments. What do we want to say about overlapping IP fragments? If by "overlapping IP fragments" you mean multiple fragmented flows, why should we say anything in particular about them. No, I mean overlapping IP fragments. For example, if I receive two fragments like this: src=1.2.3.4, dest=4.5.6.7, offset=100, length=200 src=1.2.3.4, dest=4.5.6.7, offset=150, length=200 notice that the lengths and offsets overlap. Should the NAT allow the second one to overlap the first, or discard the whole set of them, or should it store each of them separately and let the host handle the overlap (and retain the exact order they were received from the network), or what. I ask this because it happens with unacknowledged TCP segments in normal operation, but can happen with IP fragments in certain crafted attacks and we may want to say something about it. -d From audet@nortel.com Fri, 25 Mar 2005 08:58:31 -0800 (PST) From: "Francois Audet" Date: Fri, 25 Mar 2005 08:58:31 -0800 (PST) Subject: RE: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente dTCP packets Message-ID: <1ECE0EB50388174790F9694F77522CCF01CBA35C@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Requiring NATs to process Out-of-orderfragmentedTCP packets Understood what you mean. But the wording is wrong. You can't have a MUST, and then a paragraph that explains the exception. You'd have to say something like "Unless the conditions of the next paragraph occurs, a NAT MUST bla bla bla". > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pyda Srisuresh > Sent: Friday, March 25, 2005 05:51 > To: Spencer Dawkins; 'Behave' > Subject: Re: [Ietf-behave] Requiring NATs to process > Out-of-orderfragmentedTCP packets > > > > --- Spencer Dawkins wrote: > > > I believe, the requirement is a MUST, not a SHOULD. The second > > > parapgraph is > > > not written to dilute the first into a SHOULD. > > > > > > The second paragraph indicates that there can be resource > limits in > > > a NAT > > > device that might not permit the NAT device to retain > state forever. > > > For > > > example, one of the fragments could have been lost in the network > > > and may > > > never arrive. So, NAT device would not want to hold the > reassemply > > > state > > > forever. There may be also be situations where the device > is unable > > > to create a > > > state for a certain datagram when it is out of memory resource. > > > Essentialy, > > > these reflect the operational aspects in real-time, but does not > > > change the > > > requirement in the first paragraph. > > > > This is actually the way I read Suresh's previous e-mail - NATs MUST > > do this, if they do anything, but a NAT that has crashed > (for example) > > is allowed to treat this as a SHOULD, since no device that > has crashed > > will be doing anything of the sort :-) > > > > What I think the proposal is saying is that applications can rely on > > this behavior unless the NAT is is being DOS-attacked, and > > [suresh] I am saying that the applications should be able to > rely on the NAT devices doing the fragment processing > correctly. However, that is not to say that there are no > situations where the NAT device will not drop IP datagrams. > Yes, Packets may be dropped during DoS attacks. > > > applications can't always rely on MUST-strength behavior > during a DOS > > attack whether we're talking about a NAT or not. > > > [suresh] Yes indeed. > > > Did I understand your point, Suresh? > > > [suresh] I think so. Thanks. > > > Spencer > > > cheers, > suresh > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From fluffy@cisco.com Sat, 26 Mar 2005 07:07:56 -0800 (PST) From: Cullen Jennings Date: Sat, 26 Mar 2005 07:07:56 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Now, have no problem saying that a device MAY store out of order fragments. However, I will be very against any text which implies that an application can depend on them doing this because clearly we can't depend on it in a wide variety of cases. Because of this, saying MUST does not help any developers and just means that less NATs will be behave compliant with no real gain. This is an all round loose in my mind. So let me sketch a counter proposal .... We say that devices MUST forward fragments that arrive in order. We say that device MAY forward packets out of order and describe how if they do this they may want to limit the number of stored packets per session and how long they store them. Cullen (not as chair) PS. We need clear requirements that help residential style NATs. No administrator adjustment are likely to happen on these. On 3/24/05 1:48 PM, "Paul Hoffman" wrote: > At 1:09 PM -0800 3/24/05, Dan Wing wrote: >> There are lots of ways a vendor could provide for protection while >> trying to avoid interfering with a valid flow, and the vendor might >> have cool techniques to do so. How about instead of your last two >> sentences we just say: >> >> A NAT SHOULD allow out-of-order fragment behavior to >> be adjusted by the administrator, such as the number, >> duration, or source IP address of fragments kept by >> the NAT or a combination of these parameters. > > Sounds fine. > >> We need to explain if it's important for the NAT to reassemble the >> packets before sending to the internal host; that's missing from >> your proposed text. > > It's missing because I don't particularly believe it. To the internal > host, the NAT looks like the upstream router. Routers don't normally > reassemble packets, do they? > >> What do we want to say about overlapping IP fragments? > > If by "overlapping IP fragments" you mean multiple fragmented flows, > why should we say anything in particular about them. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From spencer@mcsr-labs.org Sat, 26 Mar 2005 11:34:57 -0800 (PST) From: "Spencer Dawkins" Date: Sat, 26 Mar 2005 11:34:57 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmented TCP packets In-Reply-To: Message-ID: <16fc01c5323b$0e131cc0$e8878182@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain My confusion is rising slightly :-) Now, have no problem saying that a device MAY store out of order fragments. However, I will be very against any text which implies that an application can depend on them doing this because clearly we can't depend on it in a wide variety of cases. Because of this, saying MUST does not help any developers and just means that less NATs will be behave compliant with no real gain. This is an all round loose in my mind. So let me sketch a counter proposal .... We say that devices MUST forward fragments that arrive in order. This would be lovely. We say that device MAY forward packets out of order and describe how if they do this they may want to limit the number of stored packets per session and how long they store them. I thought we were discussing whether this should be a MUST or a SHOULD (hence my confusion). Is the point that there are enough ways that something can go wrong that an application couldn't count on out-of-order fragments being forwarded anyway? If this IS the case, we should be headed towards advising applications that care about packet delivery to turn on DF, because sudden fragment reordering MAY cause a fragmented stream of packets to disappear in a puff of smoke. Not that P-MTU discovery works particularly well in the open Internet, but if you are persistent, you can probe for common MTU sizes until something works. Cullen (not as chair) PS. We need clear requirements that help residential style NATs. No administrator adjustment are likely to happen on these. It is interesting to conjure about the expected service life of residential NATs/DSL modems/cable modems... From srisuresh@yahoo.com Sun, 27 Mar 2005 10:38:57 -0800 (PST) From: Pyda Srisuresh Date: Sun, 27 Mar 2005 10:38:57 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets Message-ID: <20050327183857.18306.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Dan, You raise several good points. Please see my comments inline below. cheers, suresh --- Dan Wing wrote: > On Mar 23, 2005, at 7:17 PM, Paul Hoffman wrote: > > > At 6:30 PM -0800 3/23/05, Senthil Sivakumar wrote: > >> My suggestion is: > >> > >> "NATs should handle IP fragments that are seen in order and out of > >> order. > >> When an in order fragment is seen NAT should store the L4 information > >> of > >> the first fragment so that it can match the subsequent fragments that > >> do > >> not carry L4 headers. No buffering of the fragments is required in > >> case of > >> in order fragments. For out of order fragments, NAT must store the > >> fragment until the first fragment is seen. The fragments should be > >> stored > >> for a period of N seconds before discarding them. NATs must not store > >> more > >> than X fragments per flow and must not store more than fragments for Y > >> flows at any point of time" > >> > >> The values of N, X and Y are to be determined by the network > >> administrator > >> who best knows the latency of his/her network, capability of the box. > > > > Given the definition of SHOULD from RFC 2119 (which is normatively > > referenced in the drafts), a different wording might be: > > > > NATs SHOULD handle IP fragments that are seen in order and out of > > order. > > When an in order fragment is seen, a NAT SHOULD store the L4 > > information of the first fragment so that it can match the subsequent > > fragments that do not carry L4 headers. No buffering of the fragments > > is > > required in case of in order fragments. For out of order fragments, a > > NAT SHOULD store the fragment until the first fragment is seen. The > > fragments SHOULD be stored for an administrator-assigned period of time > > before discarding them. A NATs SHOULD allow the administrator to assign > > the number fragments to be stored per flow, and SHOULD allow the > > administrator to assign the number of total fragmented flows being > > held. > > If you receive a fragment, you don't know which flow it belongs to > because a fragment only contains the source and destination IP > addresses, but you need the full 5-tuple (src/dest IP, protocol, > src/dest port) to know the flow associated with a fragment. You can't > identify the "flow" - you can only identify the source IP address that > (purportedly) sent you the fragment. > > There are lots of ways a vendor could provide for protection while > trying to avoid interfering with a valid flow, and the vendor might > have cool techniques to do so. How about instead of your last two > sentences we just say: > > A NAT SHOULD allow out-of-order fragment behavior to > be adjusted by the administrator, such as the number, > duration, or source IP address of fragments kept by > the NAT or a combination of these parameters. > [suresh] Why do you believe, this is a SHOULD and not a MUST? When this is a SHOULD, there is no guarantee that the behave compliant NATs would support fragments. Apps that use fragments (including several VPN tunnels) cannot count on the intermediate NATs to support fragmented IP datagrams. I donot understand, why we would want to make this a SHOULD. > > We need to explain if it's important for the NAT to reassemble the > packets before sending to the internal host; that's missing from your > proposed text. > [suresh] Yup, I agree. The NAT device must retain the assembly state pertaining to a fragmentation ID until all fragments of the IP datagram are processed. Only then is NAT able to process all fragments pertaining to an IP datagram using the same NAT Session the IP datagram belongs to. Fragment reassembly is a way to retain the assemby state. But, there may be alternatives. That is why the text I suggested above avoids suggesting "reassembly" as the only means. > What do we want to say about overlapping IP fragments? > [suresh] You do raise a good point with overlapping IP fragments in the case of NAPT implementations. After all, IP datagrams are disntiguished from each other by the tuple of (SrcIP, DestIp, Protocol, PktId). When datagrames from multiple source IP addresses directed to the same external dest address are translated into a single IP address (as with NAPT) , there is a possibility of pktId overlap when multiple private hosts endup using the same pkt ID. Many NAPT implementations do not deal well with overlaping IP pkt IDs during fragment processing. As an FYI, this shortcoming is identified in section 6.3 of RFC 3022. Any thoughts from the list on whether we should make a recommendation on how NAPTs should deal with overlapping fragment IDs? > -d cheers, suresh From srisuresh@yahoo.com Sun, 27 Mar 2005 11:36:14 -0800 (PST) From: Pyda Srisuresh Date: Sun, 27 Mar 2005 11:36:14 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets Message-ID: <20050327193614.48048.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dan Wing wrote: > > On Mar 24, 2005, at 1:48 PM, Paul Hoffman wrote: > > > >> We need to explain if it's important for the NAT to reassemble the > >> packets before sending to the internal host; that's missing from your > >> proposed text. > > > > It's missing because I don't particularly believe it. To the internal > > host, the NAT looks like the upstream router. Routers don't normally > > reassemble packets, do they? > > Correct, they don't. However, routers don't hold onto packets, either, > which is what we're asking the NAT to do with out-of-order packets. > See below, because my question about reassembly is related to my > question about overlapping fragments. > [suresh] You are abolutely right. The NAT device is not a regular router. Regular routers donot route between address realms. Unlike the regular routers, NATs do and NATs are also stateful. NATs must retain the assembly state pertaining to a fragmentation ID until all fragments of the IP datagram are processed. Only then is NAT able to process all fragments pertaining to an IP datagram using the same NAT Session the IP datagram belongs to. The packetId overlap on the outbound pkts outfrom NAPT is an issue in two cases. a) when NAPT fragments them on the way out, or b) when an intermediate node between NAPT and external server fragments thackets on the way out. The receiving node is confused when assembling pakcets from overlapped pkt Ids. > >> What do we want to say about overlapping IP fragments? > > > > If by "overlapping IP fragments" you mean multiple fragmented flows, > > why should we say anything in particular about them. > > No, I mean overlapping IP fragments. For example, if I receive two > fragments like this: > > src=1.2.3.4, dest=4.5.6.7, offset=100, length=200 > src=1.2.3.4, dest=4.5.6.7, offset=150, length=200 > > notice that the lengths and offsets overlap. Should the NAT allow the > second one to overlap the first, or discard the whole set of them, or > should it store each of them separately and let the host handle the > overlap (and retain the exact order they were received from the > network), or what. I ask this because it happens with unacknowledged > TCP segments in normal operation, but can happen with IP fragments in > certain crafted attacks and we may want to say something about it. > [suresh] Yup. Ideally speaking, NAPTs ought to further translate all outgoing PktIDs from itself so the tuple of (SrcIP, DestIp, Protocol, PktId) for all outgoing packets is unique and distinguishable across packets coming out of the NAPT device. This will ensure there is no pktID overlap issue for the external servers. I am in favor making this pktID non-overlap requirement a SHOULD. > -d > cheers, suresh From srisuresh@yahoo.com Sun, 27 Mar 2005 11:59:08 -0800 (PST) From: Pyda Srisuresh Date: Sun, 27 Mar 2005 11:59:08 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets Message-ID: <20050327195908.15374.qmail@web40422.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > > Now, have no problem saying that a device MAY store out of order fragments. [suresh] I think it is a good idea to mention storing and reassemply as an option for frgament processign, not just for out-of-order packets. The NAT device must retain the assembly state pertaining to a fragmentation ID until all fragments of the IP datagram are processed. > However, I will be very against any text which implies that an application > can depend on them doing this because clearly we can't depend on it in a > wide variety of cases. [suresh] What are the cases where the apps cannot depend upon? Are Dos attacks and memory considerations on the NAT box the scenarios you are concerned about. Those are what I heard so far on the list. Are there others? Heck, routers in the network have exactly the same issues with Dos attacks and memory considerations. They cannot guarantee 100% IP forwarding. The paradigm of IP networking is one of "best effort packet forwarding", not the guaranteed packet forwarding (as with, say, X.25). Since when has it become a requirement that NATs have to provide guaraneed pkt forwarding? The MUST simpy implies that the NAT devices MUST attempt to process fragments, not guarantee processing 100% of the time. > Because of this, saying MUST does not help any > developers and just means that less NATs will be behave compliant with no > real gain. This is an all round loose in my mind. > [suresh] I disagree. See my comment above. > So let me sketch a counter proposal .... > > We say that devices MUST forward fragments that arrive in order. > > We say that device MAY forward packets out of order and describe how if they > do this they may want to limit the number of stored packets per session and > how long they store them. > [suresh] I disagree with the proposal. This serves no useful purpose. cheers, suresh > > Cullen (not as chair) > > > PS. We need clear requirements that help residential style NATs. No > administrator adjustment are likely to happen on these. > > > On 3/24/05 1:48 PM, "Paul Hoffman" wrote: > > > At 1:09 PM -0800 3/24/05, Dan Wing wrote: > >> There are lots of ways a vendor could provide for protection while > >> trying to avoid interfering with a valid flow, and the vendor might > >> have cool techniques to do so. How about instead of your last two > >> sentences we just say: > >> > >> A NAT SHOULD allow out-of-order fragment behavior to > >> be adjusted by the administrator, such as the number, > >> duration, or source IP address of fragments kept by > >> the NAT or a combination of these parameters. > > > > Sounds fine. > > > >> We need to explain if it's important for the NAT to reassemble the > >> packets before sending to the internal host; that's missing from > >> your proposed text. > > > > It's missing because I don't particularly believe it. To the internal > > host, the NAT looks like the upstream router. Routers don't normally > > reassemble packets, do they? > > > >> What do we want to say about overlapping IP fragments? > > > > If by "overlapping IP fragments" you mean multiple fragmented flows, > > why should we say anything in particular about them. > > > > --Paul Hoffman, Director > > --VPN Consortium > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From dwing@cisco.com Mon, 28 Mar 2005 06:38:16 -0800 (PST) From: Dan Wing Date: Mon, 28 Mar 2005 06:38:16 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050327183857.18306.qmail@web40429.mail.yahoo.com> Message-ID: <1EC3A6E3-9F43-11D9-B355-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Mar 27, 2005, at 10:38 AM, Pyda Srisuresh wrote: There are lots of ways a vendor could provide for protection while trying to avoid interfering with a valid flow, and the vendor might have cool techniques to do so. How about instead of your last two sentences we just say: A NAT SHOULD allow out-of-order fragment behavior to be adjusted by the administrator, such as the number, duration, or source IP address of fragments kept by the NAT or a combination of these parameters. [suresh] Why do you believe, this is a SHOULD and not a MUST? When this is a SHOULD, there is no guarantee that the behave compliant NATs would support fragments. Apps that use fragments (including several VPN tunnels) cannot count on the intermediate NATs to support fragmented IP datagrams. I donot understand, why we would want to make this a SHOULD. My suggested text only discusses the administrator's ability to adjust the behavior. I don't see an interoperability requirement to require the administrator to adjust the out-of-order behavior. We need to explain if it's important for the NAT to reassemble the packets before sending to the internal host; that's missing from your proposed text. [suresh] Yup, I agree. The NAT device must retain the assembly state pertaining to a fragmentation ID until all fragments of the IP datagram are processed. Only then is NAT able to process all fragments pertaining to an IP datagram using the same NAT Session the IP datagram belongs to. Fragment reassembly is a way to retain the assemby state. But, there may be alternatives. That is why the text I suggested above avoids suggesting "reassembly" as the only means. What do we want to say about overlapping IP fragments? [suresh] You do raise a good point with overlapping IP fragments in the case of NAPT implementations. After all, IP datagrams are disntiguished from each other by the tuple of (SrcIP, DestIp, Protocol, PktId). When datagrames from multiple source IP addresses directed to the same external dest address are translated into a single IP address (as with NAPT) , there is a possibility of pktId overlap when multiple private hosts endup using the same pkt ID. Many NAPT implementations do not deal well with overlaping IP pkt IDs during fragment processing. As an FYI, this shortcoming is identified in section 6.3 of RFC 3022. Sorry, I hadn't even considered Fragment ID overlap. I was only considering a defective IP stack sending fragments, or an attacker sending fragments, which have their fragmentation offsets overlap. Reading section 6.3 of RFC3022, this same problem with overlapping fragment IDs from different flows is experienced by host IP stacks. Have you looked at Linux or FreeBSD sources to see what they do around identical fragment IDs? Any thoughts from the list on whether we should make a recommendation on how NAPTs should deal with overlapping fragment IDs? -d -d cheers, suresh From dwing@cisco.com Mon, 28 Mar 2005 06:38:17 -0800 (PST) From: Dan Wing Date: Mon, 28 Mar 2005 06:38:17 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050327193614.48048.qmail@web40425.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain We're both describing a slightly different problem with IP fragments. You're describing a problem where an IP packet is fragmented (in the network, or by the sending host) into several fragments and when it arrives at the NAT there are already identical fragment IDs from another IP packet that arrived earlier, which could confuse the NAT if it's only using the fragment ID to reassemble the IP fragments. I'm describing a problem where a defective IP stack in a host/router/NAT sends an IP packet as fragmented IP packets, and those fragments have overlapping payload segments. I expect you'd see this only with a really buggy IP stack, or in certain kinds of attacks. I think both problems with IP fragments are worth describing in an I-D. -d On Mar 27, 2005, at 11:36 AM, Pyda Srisuresh wrote: --- Dan Wing wrote: On Mar 24, 2005, at 1:48 PM, Paul Hoffman wrote: We need to explain if it's important for the NAT to reassemble the packets before sending to the internal host; that's missing from your proposed text. It's missing because I don't particularly believe it. To the internal host, the NAT looks like the upstream router. Routers don't normally reassemble packets, do they? Correct, they don't. However, routers don't hold onto packets, either, which is what we're asking the NAT to do with out-of-order packets. See below, because my question about reassembly is related to my question about overlapping fragments. [suresh] You are abolutely right. The NAT device is not a regular router. Regular routers donot route between address realms. Unlike the regular routers, NATs do and NATs are also stateful. NATs must retain the assembly state pertaining to a fragmentation ID until all fragments of the IP datagram are processed. Only then is NAT able to process all fragments pertaining to an IP datagram using the same NAT Session the IP datagram belongs to. The packetId overlap on the outbound pkts outfrom NAPT is an issue in two cases. a) when NAPT fragments them on the way out, or b) when an intermediate node between NAPT and external server fragments thackets on the way out. The receiving node is confused when assembling pakcets from overlapped pkt Ids. What do we want to say about overlapping IP fragments? If by "overlapping IP fragments" you mean multiple fragmented flows, why should we say anything in particular about them. No, I mean overlapping IP fragments. For example, if I receive two fragments like this: src=1.2.3.4, dest=4.5.6.7, offset=100, length=200 src=1.2.3.4, dest=4.5.6.7, offset=150, length=200 notice that the lengths and offsets overlap. Should the NAT allow the second one to overlap the first, or discard the whole set of them, or should it store each of them separately and let the host handle the overlap (and retain the exact order they were received from the network), or what. I ask this because it happens with unacknowledged TCP segments in normal operation, but can happen with IP fragments in certain crafted attacks and we may want to say something about it. [suresh] Yup. Ideally speaking, NAPTs ought to further translate all outgoing PktIDs from itself so the tuple of (SrcIP, DestIp, Protocol, PktId) for all outgoing packets is unique and distinguishable across packets coming out of the NAPT device. This will ensure there is no pktID overlap issue for the external servers. I am in favor making this pktID non-overlap requirement a SHOULD. -d cheers, suresh From srisuresh@yahoo.com Mon, 28 Mar 2005 08:24:35 -0800 (PST) From: Pyda Srisuresh Date: Mon, 28 Mar 2005 08:24:35 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets Message-ID: <20050328162434.3784.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dan Wing wrote: > We're both describing a slightly different problem with IP fragments. [suresh] Ah, I see. > You're describing a problem where an IP packet is fragmented (in the > network, or by the sending host) into several fragments and when it > arrives at the NAT there are already identical fragment IDs from > another IP packet that arrived earlier, which could confuse the NAT if > it's only using the fragment ID to reassemble the IP fragments. > [suresh] I dont see any confusion for the NAT in sortign out the sequence/assembly of the incoming fragments, because the the tuples of (SrcIP, DestIP, PktId, Protocol) are different for these packets. > I'm describing a problem where a defective IP stack in a > host/router/NAT sends an IP packet as fragmented IP packets, and those > fragments have overlapping payload segments. I expect you'd see this > only with a really buggy IP stack, or in certain kinds of attacks. [suresh] I see. > > I think both problems with IP fragments are worth describing in an I-D. > [suresh] Sounds good. cheers, suresh > -d > > > On Mar 27, 2005, at 11:36 AM, Pyda Srisuresh wrote: > > > > > --- Dan Wing wrote: > >> > >> On Mar 24, 2005, at 1:48 PM, Paul Hoffman wrote: > >>> > >>>> We need to explain if it's important for the NAT to reassemble the > >>>> packets before sending to the internal host; that's missing from > >>>> your > >>>> proposed text. > >>> > >>> It's missing because I don't particularly believe it. To the internal > >>> host, the NAT looks like the upstream router. Routers don't normally > >>> reassemble packets, do they? > >> > >> Correct, they don't. However, routers don't hold onto packets, > >> either, > >> which is what we're asking the NAT to do with out-of-order packets. > >> See below, because my question about reassembly is related to my > >> question about overlapping fragments. > >> > > > > [suresh] You are abolutely right. The NAT device is not a regular > > router. > > Regular routers donot route between address realms. Unlike the regular > > routers, > > NATs do and NATs are also stateful. NATs must retain the assembly state > > pertaining to a fragmentation ID until all fragments of the IP > > datagram are > > processed. Only then is NAT able to process all fragments pertaining > > to an IP > > datagram using the same NAT Session the IP datagram belongs to. > > > > The packetId overlap on the outbound pkts outfrom NAPT is an issue in > > two > > cases. a) when NAPT fragments them on the way out, or b) when an > > intermediate > > node between NAPT and external server fragments thackets on the way > > out. The > > receiving node is confused when assembling pakcets from overlapped pkt > > Ids. > > > >>>> What do we want to say about overlapping IP fragments? > >>> > >>> If by "overlapping IP fragments" you mean multiple fragmented flows, > >>> why should we say anything in particular about them. > >> > >> No, I mean overlapping IP fragments. For example, if I receive two > >> fragments like this: > >> > >> src=1.2.3.4, dest=4.5.6.7, offset=100, length=200 > >> src=1.2.3.4, dest=4.5.6.7, offset=150, length=200 > >> > >> notice that the lengths and offsets overlap. Should the NAT allow the > >> second one to overlap the first, or discard the whole set of them, or > >> should it store each of them separately and let the host handle the > >> overlap (and retain the exact order they were received from the > >> network), or what. I ask this because it happens with unacknowledged > >> TCP segments in normal operation, but can happen with IP fragments in > >> certain crafted attacks and we may want to say something about it. > >> > > > > [suresh] Yup. Ideally speaking, NAPTs ought to further translate all > > outgoing > > PktIDs from itself so the tuple of (SrcIP, DestIp, Protocol, PktId) > > for all > > outgoing packets is unique and distinguishable across packets coming > > out of the > > NAPT device. This will ensure there is no pktID overlap issue for the > > external > > servers. I am in favor making this pktID non-overlap requirement a > > SHOULD. > > > > > >> -d > >> > > > > cheers, > > suresh > > > From dwing@cisco.com Mon, 28 Mar 2005 08:40:25 -0800 (PST) From: Dan Wing Date: Mon, 28 Mar 2005 08:40:25 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050328162434.3784.qmail@web40427.mail.yahoo.com> Message-ID: <1C2363DC-9FA8-11D9-B355-0003938AF740@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Mar 28, 2005, at 8:24 AM, Pyda Srisuresh wrote: --- Dan Wing wrote: We're both describing a slightly different problem with IP fragments. [suresh] Ah, I see. You're describing a problem where an IP packet is fragmented (in the network, or by the sending host) into several fragments and when it arrives at the NAT there are already identical fragment IDs from another IP packet that arrived earlier, which could confuse the NAT if it's only using the fragment ID to reassemble the IP fragments. [suresh] I dont see any confusion for the NAT in sortign out the sequence/assembly of the incoming fragments, because the the tuples of (SrcIP, DestIP, PktId, Protocol) are different for these packets. Sure, but the DestIP is the same (it's the IP address of the NAT), and we're assuming the Fragment ID and Protocol are the same. So the only thing that could be different in the two fragments is the SrcIP. But if the sender is transmitting two UDP streams, both of which are being fragmented by the time our NAT is receiving the two streams, I see how a NAT (or a host) could get confused. I'll dig up some FreeBSD sources and see how FreeBSD handles this, because I don't understand how it could do this well. I'm describing a problem where a defective IP stack in a host/router/NAT sends an IP packet as fragmented IP packets, and those fragments have overlapping payload segments. I expect you'd see this only with a really buggy IP stack, or in certain kinds of attacks. [suresh] I see. I think both problems with IP fragments are worth describing in an I-D. [suresh] Sounds good. cheers, suresh -d On Mar 27, 2005, at 11:36 AM, Pyda Srisuresh wrote: --- Dan Wing wrote: On Mar 24, 2005, at 1:48 PM, Paul Hoffman wrote: We need to explain if it's important for the NAT to reassemble the packets before sending to the internal host; that's missing from your proposed text. It's missing because I don't particularly believe it. To the internal host, the NAT looks like the upstream router. Routers don't normally reassemble packets, do they? Correct, they don't. However, routers don't hold onto packets, either, which is what we're asking the NAT to do with out-of-order packets. See below, because my question about reassembly is related to my question about overlapping fragments. [suresh] You are abolutely right. The NAT device is not a regular router. Regular routers donot route between address realms. Unlike the regular routers, NATs do and NATs are also stateful. NATs must retain the assembly state pertaining to a fragmentation ID until all fragments of the IP datagram are processed. Only then is NAT able to process all fragments pertaining to an IP datagram using the same NAT Session the IP datagram belongs to. The packetId overlap on the outbound pkts outfrom NAPT is an issue in two cases. a) when NAPT fragments them on the way out, or b) when an intermediate node between NAPT and external server fragments thackets on the way out. The receiving node is confused when assembling pakcets from overlapped pkt Ids. What do we want to say about overlapping IP fragments? If by "overlapping IP fragments" you mean multiple fragmented flows, why should we say anything in particular about them. No, I mean overlapping IP fragments. For example, if I receive two fragments like this: src=1.2.3.4, dest=4.5.6.7, offset=100, length=200 src=1.2.3.4, dest=4.5.6.7, offset=150, length=200 notice that the lengths and offsets overlap. Should the NAT allow the second one to overlap the first, or discard the whole set of them, or should it store each of them separately and let the host handle the overlap (and retain the exact order they were received from the network), or what. I ask this because it happens with unacknowledged TCP segments in normal operation, but can happen with IP fragments in certain crafted attacks and we may want to say something about it. [suresh] Yup. Ideally speaking, NAPTs ought to further translate all outgoing PktIDs from itself so the tuple of (SrcIP, DestIp, Protocol, PktId) for all outgoing packets is unique and distinguishable across packets coming out of the NAPT device. This will ensure there is no pktID overlap issue for the external servers. I am in favor making this pktID non-overlap requirement a SHOULD. -d cheers, suresh From srisuresh@yahoo.com Mon, 28 Mar 2005 09:41:27 -0800 (PST) From: Pyda Srisuresh Date: Mon, 28 Mar 2005 09:41:27 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <1C2363DC-9FA8-11D9-B355-0003938AF740@cisco.com> Message-ID: <20050328174127.21067.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dan Wing wrote: > > On Mar 28, 2005, at 8:24 AM, Pyda Srisuresh wrote: > > > > > --- Dan Wing wrote: > >> We're both describing a slightly different problem with IP fragments. > > > > [suresh] Ah, I see. > > > >> You're describing a problem where an IP packet is fragmented (in the > >> network, or by the sending host) into several fragments and when it > >> arrives at the NAT there are already identical fragment IDs from > >> another IP packet that arrived earlier, which could confuse the NAT if > >> it's only using the fragment ID to reassemble the IP fragments. > >> > > [suresh] I dont see any confusion for the NAT in sortign out the > > sequence/assembly of the incoming fragments, because the the tuples of > > (SrcIP, > > DestIP, PktId, Protocol) are different for these packets. > > Sure, but the DestIP is the same (it's the IP address of the NAT), and > we're > assuming the Fragment ID and Protocol are the same. So the only thing > that > could be different in the two fragments is the SrcIP. But if the sender > is transmitting two UDP streams, both of which are being fragmented by > the time our NAT is receiving the two streams, I see how a NAT (or a > host) > could get confused. I'll dig up some FreeBSD sources and see how > FreeBSD > handles this, because I don't understand how it could do this well. > [suresh] Dan - Essentially my point is that there is no issue in NAPT assembling fragments coming from multiple private hosts even if directed to the same external destination, because tuple of (SrcIP, DestIp, Prot, PktId) are different for these IP pkts in the private realm. Now, if you talk about IP datagrams coming in from an external server to the NAPT external IP address, Once again, I dont see why the NAPT shoudl get confused. Even if the same external node is sending multiple UDP streams to the NAPT external address, the individual IP datagrams should have a unique tuple of (SrcIP, DestIP, Protocol, PktId). cheers, suresh From srisuresh@yahoo.com Mon, 28 Mar 2005 09:49:17 -0800 (PST) From: Pyda Srisuresh Date: Mon, 28 Mar 2005 09:49:17 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets Message-ID: <20050328174917.22710.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dan Wing wrote: > > On Mar 27, 2005, at 10:38 AM, Pyda Srisuresh wrote: > > >> There are lots of ways a vendor could provide for protection while > >> trying to avoid interfering with a valid flow, and the vendor might > >> have cool techniques to do so. How about instead of your last two > >> sentences we just say: > >> > >> A NAT SHOULD allow out-of-order fragment behavior to > >> be adjusted by the administrator, such as the number, > >> duration, or source IP address of fragments kept by > >> the NAT or a combination of these parameters. > >> > > > > [suresh] Why do you believe, this is a SHOULD and not a MUST? When > > this is a > > SHOULD, there is no guarantee that the behave compliant NATs would > > support > > fragments. Apps that use fragments (including several VPN tunnels) > > cannot count > > on the intermediate NATs to support fragmented IP datagrams. I donot > > understand, why we would want to make this a SHOULD. > > My suggested text only discusses the administrator's ability to adjust > the behavior. [suresh] Administrator's ability to tune the parameters for fragment processing is different from making the fragment prcessing a requirement, IMHO. We can talk about tuning after the requirement is mandated. > I don't see an interoperability requirement to require > the administrator to adjust the out-of-order behavior. > [suresh] Not sure, I understand this. Are you saying that you agree that NATs must be required to support out of order fragment processing, but that there shoudl bo no interoperability requirement on adjustign the parameters of fragment processing (ex: fragment reassembly). If so, I agree. cheers, suresh From nagendra@cs.stanford.edu Mon, 28 Mar 2005 22:17:27 -0800 (PST) From: nagendra modadugu Date: Mon, 28 Mar 2005 22:17:27 -0800 (PST) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmented TCP packets In-Reply-To: <20050328162434.3784.qmail@web40427.mail.yahoo.com> Message-ID: <20050329061722.GA26100@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain > >>You're describing a problem where an IP packet is fragmented (in the > >>network, or by the sending host) into several fragments and when it > >>arrives at the NAT there are already identical fragment IDs from > >>another IP packet that arrived earlier, which could confuse the NAT if > >>it's only using the fragment ID to reassemble the IP fragments. > >> > >[suresh] I dont see any confusion for the NAT in sortign out the > >sequence/assembly of the incoming fragments, because the the tuples of > >(SrcIP, > >DestIP, PktId, Protocol) are different for these packets. > > Sure, but the DestIP is the same (it's the IP address of the NAT), and > we're > assuming the Fragment ID and Protocol are the same. So the only thing > that > could be different in the two fragments is the SrcIP. But if the sender > is transmitting two UDP streams, both of which are being fragmented by > the time our NAT is receiving the two streams, I see how a NAT (or a > host) > could get confused. I'll dig up some FreeBSD sources and see how > FreeBSD > handles this, because I don't understand how it could do this well. The problem of the IP ID field colliding appears a bit contrived--especially when packets are originating from one host (barring, of course, a buggy IP stack). Or are there other circumstances under which this is a issue worth consideration? If it does somehow happen, then there's no further information the recipient has in order to distinguish the fragments as belonging to two seperate IP packets, or is there? nagendra From ssenthil@cisco.com Thu, 7 Apr 2005 10:17:58 -0700 (PDT) From: Senthil Sivakumar Date: Thu, 7 Apr 2005 10:17:58 -0700 (PDT) Subject: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <4.3.2.7.2.20050131160434.0329d6a0@mira-sjcd-2.cisco.com> Message-ID: <4.3.2.7.2.20050407101345.03056008@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain The next revision of TCP Behavior draft is available at: http://www.ietf.org/internet-drafts/draft-sivakumar-behave-nat-tcp-req-01.txt This revision captures the WG discussions on this topic. Please review this and let us know your comments. Senthil From srisuresh@yahoo.com Sun, 10 Apr 2005 08:14:10 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 10 Apr 2005 08:14:10 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior Message-ID: <20050410151410.42130.qmail@web40428.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Folks, The revised behave-tcp draft (i.e., sivakumar-behave-nat-tcp-req draft cited below) is completely reworked in that issues that are not tcp-specific (IP fragmentation, port reservation, Path MTU handling, ICMP error handling etc) are moved to the behave-gen draft. The next rev of ford-behave-gen draft will include these. Below are additional highlights of the behave-tcp draft. 1. A consolidated requirements summary section lists a total of 6 requirements. 2. A new "Hints to implementors" section is added. Text relating to supporting embedded ALGs is moved to be under this section. Do send in your comments and thoughts on the draft, so we can have a discussion. Thanks. Let me start off by soliciting comments on the following specific items. 1. Timeout recommendations: Recommended value for SYN timeout: 30 secs Recommended value for TCP session timeout: 30 mins. Recommended value for close timeout: 2 x MSL or 4 mins. Do we have work group consensus on these values? 2. NAT initiated TCP-keppalives: We made this requirement to be a MAY. We did this because the session timeout recommendation is reasonably large (i.e., 30 mins above) and we donot need to mandate NAT devices to send in keep-alives. Any comments? 3. NAT initiated RST: We made this as a SHOULD requirement. We did this because NAT retains state of an end-to-end TCP session. Upon session timeout, simply loosing the session state without notifying the end nodes would leave the endnodes in zombie state. Considering the large session timeout, we left this as a SHOULD. Any comments? Thanks. cheers, suresh --- Senthil Sivakumar wrote: > The next revision of TCP Behavior draft is available at: > > http://www.ietf.org/internet-drafts/draft-sivakumar-behave-nat-tcp-req-01.txt > > This revision captures the WG discussions on this topic. > > Please review this and let us know your comments. > > Senthil > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Mon, 11 Apr 2005 09:21:16 -0700 (PDT) From: Cullen Jennings Date: Mon, 11 Apr 2005 09:21:16 -0700 (PDT) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets In-Reply-To: <20050325024136.95515.qmail@web40428.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 3/24/05 6:41 PM, "Pyda Srisuresh" wrote: > --- Cullen Jennings wrote: >> >> Ok, that proposal is concrete and I get it. Thank you. >> >> Now the application developer that is trying to write a client that will >> work through a NAT that does this can not make any assumptions about how the >> NAT has been configured. So I don't see how behave specifying this one way >> or another makes any difference to what applications can work or not. >> > > [suresh] When applications send large chunks of data with no reverence to MTU > size, the NAT devices along the traversal will not block the fragments from > traversing. For example, aplication like NFS can work across a NAT device. > > cheers, > suresh What size packets can the application send before it stops working because the flow has exceeded the buffer allocated by the NAT for that flow? Of course it is impossible to answer this question which is exactly my point. Specifying this type of behavior, while reasonable and good, will not in anyway help design algorithms that reliably work through NATs that have to operate in the real world. Not knowing the size of buffers on a configured NAT simply contributes to the non deterministic behavior of the NAT. I'm not against implementations deciding to do the type of behavior you suggested - I'm just pointing out that applications can not rely on the buffer size be anything greater than zero. Cullen - not as chair From audet@nortel.com Tue, 12 Apr 2005 14:24:22 -0700 (PDT) From: "Francois Audet" Date: Tue, 12 Apr 2005 14:24:22 -0700 (PDT) Subject: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF01E7F8BD@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: FW: I-D ACTION:draft-ietf-behave-nat-udp-01.txt New version of draft-ietf-behave-nat-udp-01 has been posted. It reflects the agreements of IETF 62. > -----Original Message----- > From: i-d-announce-bounces@xxxxxxxx > [mailto:i-d-announce-bounces@xxxxxxxx] On Behalf Of > Internet-Drafts@xxxxxxxx > Sent: Tuesday, April 12, 2005 12:37 > To: i-d-announce@xxxxxxxx > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: I-D ACTION:draft-ietf-behave-nat-udp-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > Behavior Engineering for Hindrance Avoidance Working Group of > the IETF. > > Title : NAT Behavioral Requirements for Unicast UDP > Author(s) : F. Audet, C. Jennings > Filename : draft-ietf-behave-nat-udp-01.txt > Pages : 24 > Date : 2005-4-12 > > This document defines basic terminology for describing different > types of NAT behavior when handling Unicast UDP, and > defines a set of > requirements that would allow many applications, such as multimedia > communications or on-line gaming, to work consistently. Developing > NATs that meet this set of requirements will greatly increase the > likelihood that these applications will function properly. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@xxxxxxxx with the word unsubscribe in > the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-behave-nat-udp-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@xxxxxxxxx > In the body type: > "FILE /internet-drafts/draft-ietf-behave-nat-udp-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > Transfer-mode: ftp.ietf.org From ssenthil@cisco.com Tue, 12 Apr 2005 14:29:19 -0700 (PDT) From: Senthil Sivakumar Date: Tue, 12 Apr 2005 14:29:19 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <6667> Message-ID: <4.3.2.7.2.20050412142743.02f2f158@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I believe there was a test conducted on the behavior of many NAT boxes, does any one have the data of what the timeouts of different boxes were? Also, does anyone know if TCP keepalives are implemented by the vendors and if so what percent of these boxes implement them? thanks Senthil At 08:14 AM 4/10/2005 -0700, Pyda Srisuresh wrote: Folks, The revised behave-tcp draft (i.e., sivakumar-behave-nat-tcp-req draft cited below) is completely reworked in that issues that are not tcp-specific (IP fragmentation, port reservation, Path MTU handling, ICMP error handling etc) are moved to the behave-gen draft. The next rev of ford-behave-gen draft will include these. Below are additional highlights of the behave-tcp draft. 1. A consolidated requirements summary section lists a total of 6 requirements. 2. A new "Hints to implementors" section is added. Text relating to supporting embedded ALGs is moved to be under this section. Do send in your comments and thoughts on the draft, so we can have a discussion. Thanks. Let me start off by soliciting comments on the following specific items. 1. Timeout recommendations: Recommended value for SYN timeout: 30 secs Recommended value for TCP session timeout: 30 mins. Recommended value for close timeout: 2 x MSL or 4 mins. Do we have work group consensus on these values? 2. NAT initiated TCP-keppalives: We made this requirement to be a MAY. We did this because the session timeout recommendation is reasonably large (i.e., 30 mins above) and we donot need to mandate NAT devices to send in keep-alives. Any comments? 3. NAT initiated RST: We made this as a SHOULD requirement. We did this because NAT retains state of an end-to-end TCP session. Upon session timeout, simply loosing the session state without notifying the end nodes would leave the endnodes in zombie state. Considering the large session timeout, we left this as a SHOULD. Any comments? Thanks. cheers, suresh --- Senthil Sivakumar wrote: > The next revision of TCP Behavior draft is available at: > > http://www.ietf.org/internet-drafts/draft-sivakumar-behave-nat-tcp-req-01.txt > > This revision captures the WG discussions on this topic. > > Please review this and let us know your comments. > > Senthil > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From sg266@cornell.edu Tue, 12 Apr 2005 15:32:01 -0700 (PDT) From: Saikat Guha Date: Tue, 12 Apr 2005 15:32:01 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <6667> Message-ID: <1113344997.31649.152.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630133.multipart/signed" --Boundary..27398.1163630133.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-04-12 at 14:29 -0700, Senthil Sivakumar wrote: > I believe there was a test conducted on the behavior of many NAT boxes, > does any > one have the data of what the timeouts of different boxes were? The STUNT tests include TCP timeout tests. The results are online at https://www.guha.cc/saikat/stunt-results.php -- Saikat Attachment: signature.asc --Boundary..27398.1163630133.multipart/signed Content-Type: application/octet-stream; name="pgp00020.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00020.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ1hFdmxuRmx0cWk2OTEvb1JBcjlrQUo5QVVjOUhFOWZMYSsxaWU0MmpL Y08yNFVNZFNBQ1pBZkFWCnIvMmV4d1ZlbGpudlZweWFCM0VRaThzPQo9YTFDaAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630133.multipart/signed-- From jerrysfus@yahoo.com Tue, 12 Apr 2005 16:33:06 -0700 (PDT) From: Jerry Wu Date: Tue, 12 Apr 2005 16:33:06 -0700 (PDT) Subject: [Ietf-behave] Firmware Upgrade for Cisco IP Phone 7960 Message-ID: <20050412233306.75396.qmail@web90107.mail.scd.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Hi, We bought a cisco IP Phone 7960 and try to make it work with sipxpbx, now the firmware versions on this phone is: Application LoadID P003AM30 BootLoadID PC03A300 And the firmware LoadID suppose to be upload to this phone I believe is POS3-06-3-00. Does any body have already download the firmare and upgrade the phone to work with the sipxpbx? If it works, could you email or send me a download link to download the firmware, also include the upgrade instructions? Thanks very much! Jerry From jerrysfus@yahoo.com Tue, 12 Apr 2005 16:33:59 -0700 (PDT) From: Jerry Wu Date: Tue, 12 Apr 2005 16:33:59 -0700 (PDT) Subject: [Ietf-behave] Firmware Upgrade for Cisco IP Phone 7960 Message-ID: <20050412233359.10009.qmail@web90103.mail.scd.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Hi, We bought a cisco IP Phone 7960 and try to make it work with sipxpbx, now the firmware versions on this phone is: Application LoadID P003AM30 BootLoadID PC03A300 And the firmware LoadID suppose to be upload to this phone I believe is POS3-06-3-00. Does any body have already download the firmare and upgrade the phone to work with the sipxpbx? If it works, could you email or send me a download link to download the firmware, also include the upgrade instructions? Thanks very much! John From dwing@cisco.com Wed, 13 Apr 2005 22:04:19 -0700 (PDT) From: "Dan Wing" Date: Wed, 13 Apr 2005 22:04:19 -0700 (PDT) Subject: RE: [Ietf-behave] Firmware Upgrade for Cisco IP Phone 7960 In-Reply-To: <20050412233359.10009.qmail@web90103.mail.scd.yahoo.com> Message-ID: <200504140504.WAA20597@edison.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Jerry, Try asking on cisco-voip@xxxxxxxxxxxxxxx -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jerry Wu > Sent: Tuesday, April 12, 2005 4:34 PM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] Firmware Upgrade for Cisco IP Phone 7960 > > Hi, > > We bought a cisco IP Phone 7960 and try to make it > work with sipxpbx, now the firmware versions on this > phone is: > > Application LoadID > P003AM30 > BootLoadID > PC03A300 > > And the firmware LoadID > suppose to be upload to this phone I believe is > POS3-06-3-00. > > Does any body have already download the firmare and > upgrade the phone to work with the sipxpbx? > > If it works, could you email or send me a download > link to download the firmware, also include the > upgrade instructions? > > Thanks very much! > John > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Sun, 17 Apr 2005 07:55:50 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 17 Apr 2005 07:55:50 -0700 (PDT) Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets Message-ID: <20050417145550.29344.qmail@web40424.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > On 3/24/05 6:41 PM, "Pyda Srisuresh" wrote: > > > --- Cullen Jennings wrote: > >> > >> Ok, that proposal is concrete and I get it. Thank you. > >> > >> Now the application developer that is trying to write a client that will > >> work through a NAT that does this can not make any assumptions about how > the > >> NAT has been configured. So I don't see how behave specifying this one way > >> or another makes any difference to what applications can work or not. > >> > > > > [suresh] When applications send large chunks of data with no reverence to > MTU > > size, the NAT devices along the traversal will not block the fragments from > > traversing. For example, aplication like NFS can work across a NAT device. > > > > cheers, > > suresh > > What size packets can the application send before it stops working because > the flow has exceeded the buffer allocated by the NAT for that flow? Of > course it is impossible to answer this question which is exactly my point. > Specifying this type of behavior, while reasonable and good, will not in > anyway help design algorithms that reliably work through NATs that have to > operate in the real world. Not knowing the size of buffers on a configured > NAT simply contributes to the non deterministic behavior of the NAT. I'm not > against implementations deciding to do the type of behavior you suggested - > I'm just pointing out that applications can not rely on the buffer size be > anything greater than zero. > [suresh] The buffer size is configurable. The default read/write buffer size for nfsv2 is 8192 bytes. NFS/UDP relies on IP fragmentation support in the network, NAT or not. > Cullen - not as chair > cheers, suresh From srisuresh@yahoo.com Sun, 17 Apr 2005 08:59:59 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 17 Apr 2005 08:59:59 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior Message-ID: <20050417155958.43915.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Saikat, This is a lot of work you and your team has done. Lot of interestig data. Thank you for your work. I believe, your results indicate that a overwheleming majority of the devices use the following timeouts in various phases of the TCP session. SYN-SENT: >1min (73%) ESTD: >2hrs (53%), 15min-1hr (31 out of 100) TIMED-WAIT: >1 min (65%) RST: >1 min (58%) However, I noticed that only a small portion of the devices tested (13%) use port binding. Vast majority of the devices tested (85%) use independent binding. By "independent binding", I assume, you meant address binding. If not, please clarify. Thanks. As you now, many of the residentail NATs are NAPT devices. I am a concerned if the results are representative of the NAPT devices profile. Please cinfirm if I am interpretng the results right. It seems the results are generaly encouraging and fit the profile of the requirements outlined in the behave-tcp draft (with the exception of timeout values). Look forward to hearing your thoughts. cheers, suresh --- Saikat Guha wrote: > On Tue, 2005-04-12 at 14:29 -0700, Senthil Sivakumar wrote: > > I believe there was a test conducted on the behavior of many NAT boxes, > > does any > > one have the data of what the timeouts of different boxes were? > > The STUNT tests include TCP timeout tests. The results are online at > https://www.guha.cc/saikat/stunt-results.php > > -- > Saikat > From sg266@cornell.edu Sun, 17 Apr 2005 12:07:34 -0700 (PDT) From: Saikat Guha Date: Sun, 17 Apr 2005 12:07:34 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <20050417155958.43915.qmail@web40427.mail.yahoo.com> Message-ID: <1113764725.8432.56.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630133.multipart/signed" --Boundary..27398.1163630133.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-04-17 at 08:59 -0700, Pyda Srisuresh wrote: > I believe, your results indicate that a overwheleming majority of the devices > use the following timeouts in various phases of the TCP session. The reports included hosts that ran the test without being behind a NAT or were configured in the DMZ for the NAT (all unmatched packets were sent to them). Those showed up as TCP Filtering Type: Open and may have thrown off your numbers. I've changed the default tabulation to hide those for now. > SYN-SENT: >1min (73%) > ESTD: >2hrs (53%), 15min-1hr (31 out of 100) > TIMED-WAIT: >1 min (65%) > RST: >1 min (58%) I get SYN-SENT: >1m 45/72 (62%) ESTD: >2h 26/72 (36%), 15m-2h 31/72 (43% (note 15m-2h and not 1h) TIMED-WAIT: >1m 36/72 (50%) RST: >1m 29/72 (40%) > However, I noticed that only a small portion of the devices tested (13%) use > port binding. Vast majority of the devices tested (85%) use independent > binding. By "independent binding", I assume, you meant address binding. If > not, > please clarify. By independent, I mean NB=I from draft-ietf-behave-nat-udp-01 i.e. the external address and port is determined uniquely by the 2-tuple (source address and port) of the packet initiating the flow. If a host uses LA:LP to connect to RA1:RP1 as is allocated the mapping MA:MP, then when the host uses LA:LP to connect to RA2:RP2, it will be allocated the mapping MA:MP as well. As for the numbers, I get 53/78 (63%) for "Independent" ... unintentional inclusion the non NAT'ed or DMZ'ed hosts artificially inflated the previous estimate. The other classifications in this category "Address", "Port", "Session" and "Address and Port" are explained in http://nutss.gforge.cis.cornell.edu/stunt-client.php > I am a concerned if the results are representative of the NAPT devices > profile. While almost all results are from NAPT devices, they may not be representative of the global NAT deployment. For instance, according to market surveys, NATs from Buffalo Technologies is more common than D- Link and Netgear, however our sample set does not reflect this. -- Saikat Attachment: signature.asc --Boundary..27398.1163630133.multipart/signed Content-Type: application/octet-stream; name="pgp00021.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00021.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ1lyTjFuRmx0cWk2OTEvb1JBaVBMQUo0dWszSjRzbnB2SklYOWxZUkZ3 cHFRb2NsakRnQ2Zhc3hkClk1bU1OVGh1RjBwem52QlJBNm93VldRPQo9RkpLQQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630133.multipart/signed-- From srisuresh@yahoo.com Sun, 17 Apr 2005 23:33:55 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 17 Apr 2005 23:33:55 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior Message-ID: <20050418063354.459.qmail@web40424.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Saikat, My comments inline below. Thanks. cheers, suresh --- Saikat Guha wrote: > On Sun, 2005-04-17 at 08:59 -0700, Pyda Srisuresh wrote: > > I believe, your results indicate that a overwheleming majority of the > devices > > use the following timeouts in various phases of the TCP session. > > The reports included hosts that ran the test without being behind a NAT > or were configured in the DMZ for the NAT (all unmatched packets were > sent to them). Those showed up as TCP Filtering Type: Open and may have > thrown off your numbers. [suresh] I see. I didnt quite know what you meant by open filtering. Now that you mention this, it seems, about 30% of the devices are non-NAT devices, right. > I've changed the default tabulation to hide > those for now. > > > SYN-SENT: >1min (73%) > > ESTD: >2hrs (53%), 15min-1hr (31 out of 100) > > TIMED-WAIT: >1 min (65%) > > RST: >1 min (58%) > > I get > SYN-SENT: >1m 45/72 (62%) > ESTD: >2h 26/72 (36%), 15m-2h 31/72 (43% > (note 15m-2h and not 1h) > TIMED-WAIT: >1m 36/72 (50%) > RST: >1m 29/72 (40%) > [suresh] OK. Thanks for recaliberating. This certainly changes the TCP session timeout value usage. I guess, it is also important to note that a good 21% of the devices use a TCP session timeout of 15mins or less. Basically, selecting a large timeout ties up resources in the NAT devices for a long time. Making the timeout too short is problematic from end-to-end session perspective. The recommendation has to strike a balance between the two. What do you think of the following proposal. SYN timeout (Connecting phase): 60 secs. TCP session timeout (Estab phase): 60 mins. Closing timeout (Closign phase): 4 mins. > > However, I noticed that only a small portion of the devices tested (13%) > use > > port binding. Vast majority of the devices tested (85%) use independent > > binding. By "independent binding", I assume, you meant address binding. If > not, > > please clarify. > > By independent, I mean NB=I from draft-ietf-behave-nat-udp-01 i.e. the > external address and port is determined uniquely by the 2-tuple (source > address and port) of the packet initiating the flow. If a host uses > LA:LP to connect to RA1:RP1 as is allocated the mapping MA:MP, then when > the host uses LA:LP to connect to RA2:RP2, it will be allocated the > mapping MA:MP as well. [suresh] I see. Thanks for clarifyig. The above description is indeed what I consider to be TCP port binding. There are about 20% of the devices that list the TCP binding type as "Address and Port" or "Session". From your description of binding types in http://nutss.gforge.cis.cornell.edu/stunt-client.php, it seems "address and port" and "Session" type are one and the same and they both represent symmetric NAT behavior, right? > As for the numbers, I get 53/78 (63%) for > "Independent" ... unintentional inclusion the non NAT'ed or DMZ'ed hosts > artificially inflated the previous estimate. The other classifications > in this category "Address", "Port", "Session" and "Address and Port" are > explained in http://nutss.gforge.cis.cornell.edu/stunt-client.php > [suresh] It is still heartening to note that 63% of the devices tested already enforce port binding. This is good news. We want to depricate symmetric NAT type of behavior. > > > I am a concerned if the results are representative of the NAPT devices > > profile. > > While almost all results are from NAPT devices, they may not be > representative of the global NAT deployment. For instance, according to > market surveys, NATs from Buffalo Technologies is more common than D- > Link and Netgear, however our sample set does not reflect this. > [suresh] I understand what you mean. It is also important to note that the study of existing devices does not imply that we want to recommend what is already status quo for a majority of the devices. It is just good to understand where the current state of the NAT devices is. We should not hesitate proposing a change, when a change is required. Thanks. > -- > Saikat > cheers, suresh From sg266@cornell.edu Mon, 18 Apr 2005 01:32:18 -0700 (PDT) From: Saikat Guha Date: Mon, 18 Apr 2005 01:32:18 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <20050418063354.459.qmail@web40424.mail.yahoo.com> Message-ID: <1113813123.8432.153.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630133.multipart/signed" --Boundary..27398.1163630133.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-04-17 at 23:33 -0700, Pyda Srisuresh wrote: > Basically, selecting a large timeout ties up resources in the NAT devices for > a > long time. Making the timeout too short is problematic from end-to-end session > perspective. The recommendation has to strike a balance between the two. > > What do you think of the following proposal. > SYN timeout (Connecting phase): 60 secs. > TCP session timeout (Estab phase): 60 mins. > Closing timeout (Closign phase): 4 mins. Regarding SYN timeout, I feel 60s is fine. Although RFC 1122 suggests a 2xMSL of 4min, Linux, BSD and most other stacks use a 2xMSL of 60s. So this gives them enough time to receive the response from the destination, if any. As for session timeout, RFC 1122 reads "[TCP Keep-Alive] interval MUST be configurable and MUST default to no less than two hours." which means that end-hosts that do not exchange any data for a while will, by default, check liveness of a connection by sending a probe every 2 hours. 'ssh -o TCPKeepAlive' does this I believe. So I feel 2h would be a better recommendation unless the NAT aggressively checks liveness. The NAT may send a TCPKeepalive probe after 60 min ... and if no response is received within 2xMSL, then expire the connection. If the NAT chooses not to implement this, then it must not expire the connection before 2h. > [suresh] I see. Thanks for clarifyig. The above description is indeed what I > consider to be TCP port binding. There are about 20% of the devices that list > the TCP binding type as "Address and Port" or "Session". From your > description > of binding types in http://nutss.gforge.cis.cornell.edu/stunt-client.php, it > seems "address and port" and "Session" type are one and the same and they both > represent symmetric NAT behavior, right? No. Assume the local endpoint LA:LP, remote endpoints RA_k:RP_k and the mapped address MA:MP_k (assuming NAPT with only one external IP) Consider the following sequence of connections: (1) LA:LP -> RA_1:RP_1 (2) LA:LP -> RA_1:RP_1 (3) LA:LP -> RA_1:RP_1 (4) LA:LP -> RA_2:RP_2 (5) LA:LP -> RA_2:RP_2 (6) LA:LP -> RA_2:RP_2 For NB="Address and port" the mappings will be (1) MA:MP_1 (2) MA:MP_1 (3) MA:MP_1 (4) MA:MP_2 (5) MA:MP_2 (6) MA:MP_2 For NB="Session" the mappings will be (1) MA:MP_1 (2) MA:MP_2 (3) MA:MP_3 (4) MA:MP_4 (5) MA:MP_5 (6) MA:MP_6 This is something not seen in the UDP case. Essentially, in the session case, a new port is allocated every time a SYN packet is sent out. -- Saikat Attachment: signature.asc --Boundary..27398.1163630133.multipart/signed Content-Type: application/octet-stream; name="pgp00022.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00022.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ1kzQ0RuRmx0cWk2OTEvb1JBdWQ1QUp3TVVoaXpjcHphSittWjBYRlJr R2JCRWZScmNRQ2NDQkR4CnBhckc0eHFiM1piQ3psVGRYZEhTamdFPQo9YnBSZgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630133.multipart/signed-- From srisuresh@yahoo.com Mon, 18 Apr 2005 07:41:51 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 18 Apr 2005 07:41:51 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior Message-ID: <20050418144148.39563.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Sun, 2005-04-17 at 23:33 -0700, Pyda Srisuresh wrote: > > > Basically, selecting a large timeout ties up resources in the NAT devices > for a > > long time. Making the timeout too short is problematic from end-to-end > session > > perspective. The recommendation has to strike a balance between the two. > > > > What do you think of the following proposal. > > SYN timeout (Connecting phase): 60 secs. > > TCP session timeout (Estab phase): 60 mins. > > Closing timeout (Closign phase): 4 mins. > > Regarding SYN timeout, I feel 60s is fine. Although RFC 1122 suggests a > 2xMSL of 4min, Linux, BSD and most other stacks use a 2xMSL of 60s. So > this gives them enough time to receive the response from the > destination, if any. > > As for session timeout, RFC 1122 reads "[TCP Keep-Alive] interval MUST > be configurable and MUST default to no less than two hours." which means > that end-hosts that do not exchange any data for a while will, by > default, check liveness of a connection by sending a probe every 2 > hours. 'ssh -o TCPKeepAlive' does this I believe. So I feel 2h would be > a better recommendation unless the NAT aggressively checks liveness. The > NAT may send a TCPKeepalive probe after 60 min ... and if no response is > received within 2xMSL, then expire the connection. If the NAT chooses > not to implement this, then it must not expire the connection before 2h. > [suresh] Interesting. 2 hrs seem like a lot to recommend for a minimum TCP session timeout. As for the servers out there, do you know if majority of them use 2krs keepalive or less? What do others think? I agree with your second comment about requiring to send keepalives, when the session timeout is less than the recommended value. > > [suresh] I see. Thanks for clarifyig. The above description is indeed what > I > > consider to be TCP port binding. There are about 20% of the devices that > list > > the TCP binding type as "Address and Port" or "Session". From your > description > > of binding types in http://nutss.gforge.cis.cornell.edu/stunt-client.php, > it > > seems "address and port" and "Session" type are one and the same and they > both > > represent symmetric NAT behavior, right? > > No. Assume the local endpoint LA:LP, remote endpoints RA_k:RP_k and the > mapped address MA:MP_k (assuming NAPT with only one external IP) > > Consider the following sequence of connections: > (1) LA:LP -> RA_1:RP_1 > (2) LA:LP -> RA_1:RP_1 > (3) LA:LP -> RA_1:RP_1 > (4) LA:LP -> RA_2:RP_2 > (5) LA:LP -> RA_2:RP_2 > (6) LA:LP -> RA_2:RP_2 > > For NB="Address and port" the mappings will be > (1) MA:MP_1 > (2) MA:MP_1 > (3) MA:MP_1 > (4) MA:MP_2 > (5) MA:MP_2 > (6) MA:MP_2 > > For NB="Session" the mappings will be > (1) MA:MP_1 > (2) MA:MP_2 > (3) MA:MP_3 > (4) MA:MP_4 > (5) MA:MP_5 > (6) MA:MP_6 > > This is something not seen in the UDP case. Essentially, in the session > case, a new port is allocated every time a SYN packet is sent out. > [suresh] OK, I see the difference. I would still argue, they both exhibit symmetric NAT behavior in that they provide different endpoint associattions to the local endpoint for different session tuples. In the first case, it seems the NAT device remembers the endpoint association on a per-session basis (LA:LP->RA_1:RP_1 vs. LA:LP->RA_2:RP_2) and resues the association. Is this true only when the sessions are continuously made with the same tuple (i.e., from LA:LP to RA_1:RP_1 continuously three times, one after the other)? considering that they both are symmetric NAT, Do you know if this behavior has any benefit over the second behavior? Thanks. > -- > Saikat > cheers, suresh From sg266@cornell.edu Mon, 18 Apr 2005 15:51:01 -0700 (PDT) From: Saikat Guha Date: Mon, 18 Apr 2005 15:51:01 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <20050418144148.39563.qmail@web40429.mail.yahoo.com> Message-ID: <1113864656.32032.61.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630133.multipart/signed" --Boundary..27398.1163630133.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-04-18 at 07:41 -0700, Pyda Srisuresh wrote: > [suresh] Interesting. 2 hrs seem like a lot to recommend for a minimum TCP > session timeout. It does seem large, however, it is only for the case when the session is not closed normally (FIN or RST) due to a host crashing. In addition, if the host comes back up, then subsequent packets from the first connections would trigger a RST, further mitigating the resource leakage problem. On a related note, some NATs support a very small number of concurrent connections. The actual numbers are being added to the STUNT page, but from initial estimates it looks like atleast Linksys, Netgear and D-Link NATs have a limit of only 255 open connections! > As for the servers out there, do you know if majority of them > use 2krs keepalive or less? I don't know how often servers keep a session open for 2h. HTTP servers, and many applications implement some sort of application level idle timer and explicitly close the connection after a couple of minutes of inactivity. Other servers such as TELNET, SSH, RSH etc are designed to sustain sessions indefinitely. > [suresh] OK, I see the difference. I would still argue, they both exhibit > symmetric NAT behavior in that they provide different endpoint associattions > to > the local endpoint for different session tuples. True. Deprecating symmetric behavior (or NB != I behavior in draft-ietf- behave-nat-udp terms) would deprecate both "address and port" and "session" equally. > In the first case, it seems > the NAT device remembers the endpoint association on a per-session basis > (LA:LP->RA_1:RP_1 vs. LA:LP->RA_2:RP_2) and resues the association. Is this > true only when the sessions are continuously made with the same tuple (i.e., > from LA:LP to RA_1:RP_1 continuously three times, one after the other)? In my experience, as long as the allocated mapping is not garbage collected, new sessions between the same endpoints use the existing mappings. > considering that they both are symmetric NAT, Do you know if this behavior has > any benefit over the second behavior? I think second one (NB="session") is quite bad since if a host behind such a NAT tries connecting to another NAT'ed host (where the other NAT drops incoming SYN packets), then each SYN packet sent by the host creates a new mapping that hangs around for a minute or two. Depending on the OS, each TCP attempt uses up 3-5 entries in the NAT (corresponding to 3-5 retries); this eats into the 255 entries limit making it easier to DoS the NAT. That brings up another question, if a SYN (or any packet) is filtered, what should the response be? Silently dropping the packet opens the NAT up to IP Spoofing attacks where an adversary in the middle of the network spoofs the NATs IP in a SYN, and replies with a spoofed ACK knowing that the SYNACK was dropped silently by the NAT; thus fooling the victim. Generating RST packets seems to violate the semantics of RST, which in my opinion means the host replying can authoritatively say that there is no application expecting to receive the packet. I propose the NAT should respond with ICMP Destination Unreachable (Code: Host unreachable or Port unreachable) much like a router responds with net unreachables. The response would naturally be subject to ICMP rate limiting to prevent reflection attacks. Second, NATs should process incoming ICMP Host or Port Unreachables the same way they would process a RST or FIN/FINACK. Thoughts? Cheers -- Saikat Attachment: signature.asc --Boundary..27398.1163630133.multipart/signed Content-Type: application/octet-stream; name="pgp00023.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00023.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ1pEblFuRmx0cWk2OTEvb1JBaGVzQUo0NC9paGt6WVFwZVkxRHhSUjhW L3l3WEpqUVdBQ2ZRU294CmdCU2N3R05SUFZLalc5eXFnS1ZWQ0IwPQo9MkoyWQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630133.multipart/signed-- From jerrysfus@yahoo.com Mon, 18 Apr 2005 16:16:59 -0700 (PDT) From: Jerry Wu Date: Mon, 18 Apr 2005 16:16:59 -0700 (PDT) Subject: [Ietf-behave] Help needed on one way audio problems via sipxpbx configuration. Message-ID: <20050418231657.11129.qmail@web90106.mail.scd.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Hello, We setup our sipxpbx server, and try to make a outbound phone calls via Polycom SoundPoint IP 300 phone to our gateway, but only can hear the outbound audio on the callee phone.So we need any help on the configuration on the sipxpbx,DNS,NAT firwalls etc. Thanks, Johne From fluffy@cisco.com Mon, 18 Apr 2005 17:03:49 -0700 (PDT) From: Cullen Jennings Date: Mon, 18 Apr 2005 17:03:49 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <1113813123.8432.153.camel@mazinger.u.cs.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 4/18/05 1:32 AM, "Saikat Guha" wrote: > As for session timeout, RFC 1122 reads "[TCP Keep-Alive] interval MUST > be configurable and MUST default to no less than two hours." which means > that end-hosts that do not exchange any data for a while will, by > default, check liveness of a connection by sending a probe every 2 > hours. I agree with having this greater than two hours. The default for several OS including windows, solaris, and linux is 7200 seconds for TCP keep alives. I think we need to be enough above 7200 seconds that even with race conditions on the keep alive packet and NAT, things wok out ok Cullen (not as chair) From ssenthil@cisco.com Mon, 18 Apr 2005 17:26:33 -0700 (PDT) From: Senthil Sivakumar Date: Mon, 18 Apr 2005 17:26:33 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <20050418144148.39563.qmail@web40429.mail.yahoo.com> Message-ID: <4.3.2.7.2.20050418171107.02f5eff8@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain That brings up another question, if a SYN (or any packet) is filtered, what should the response be? Silently dropping the packet opens the NAT up to IP Spoofing attacks where an adversary in the middle of the network spoofs the NATs IP in a SYN, and replies with a spoofed ACK knowing that the SYNACK was dropped silently by the NAT; thus fooling the victim. Generating RST packets seems to violate the semantics of RST, which in my opinion means the host replying can authoritatively say that there is no application expecting to receive the packet. I propose the NAT should respond with ICMP Destination Unreachable (Code: Host unreachable or Port unreachable) much like a router responds with net unreachables. The response would naturally be subject to ICMP rate limiting to prevent reflection attacks. Second, NATs should process incoming ICMP Host or Port Unreachables the same way they would process a RST or FIN/FINACK. Thoughts? Does either of these messages cause the originating host to behave differently? I think sending a RST or ICMP Unreachable would not prevent a host app from retrying a number of times (it is programmed to retry), right? Of course, I agree that ICMP unreachables are slightly better for the rate limiting reason. Senthil Cheers -- Saikat _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From sg266@cornell.edu Mon, 18 Apr 2005 18:59:59 -0700 (PDT) From: Saikat Guha Date: Mon, 18 Apr 2005 18:59:59 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <20050418144148.39563.qmail@web40429.mail.yahoo.com> Message-ID: <1113875994.32032.105.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630133.multipart/signed" --Boundary..27398.1163630133.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-04-18 at 17:26 -0700, Senthil Sivakumar wrote: > Does either of these messages cause the originating host to behave > differently? > I think sending a RST or ICMP Unreachable would not prevent a host app from > retrying a number of times (it is programmed to retry), right? There are a couple of minor differences. Error values returned from the socket functions is different: ECONNREFUSED for RST vs. EHOSTUNREACH for ICMP host unreachable, which in turn generates different error strings "Connection refused" vs. "No route to host" respectively. According to RFC1122 btw, ICMP host unreachable _must_ be soft, ICMP port unreachable _should_ be hard and RST _must_ be hard. Then again, Linux doesn't retry on some soft errors (host unreach in SYN_SENT) and windows retries on some hard errors (RST in SYN_SENT) ... so retries in the stack is unpredictable as it is. :-p -- Saikat Attachment: signature.asc --Boundary..27398.1163630133.multipart/signed Content-Type: application/octet-stream; name="pgp00024.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00024.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ1pHWWFuRmx0cWk2OTEvb1JBcHFIQUo5WjBpTDErOXIwKzFYdWlMdStJ Q1A4M090NXhnQ2ZmekRMCmQzczFkMlRtY1p5dzMxemZaR1llLzJZPQo9L3h3MwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630133.multipart/signed-- From srisuresh@yahoo.com Wed, 20 Apr 2005 17:51:52 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 20 Apr 2005 17:51:52 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior Message-ID: <20050421005151.90096.qmail@web40424.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Mon, 2005-04-18 at 07:41 -0700, Pyda Srisuresh wrote: > > [suresh] Interesting. 2 hrs seem like a lot to recommend for a minimum TCP > > session timeout. > > It does seem large, however, it is only for the case when the session is > not closed normally (FIN or RST) due to a host crashing. In addition, if > the host comes back up, then subsequent packets from the first > connections would trigger a RST, further mitigating the resource leakage > problem. > [suresh] OK. > On a related note, some NATs support a very small number of concurrent > connections. The actual numbers are being added to the STUNT page, but > from initial estimates it looks like atleast Linksys, Netgear and D-Link > NATs have a limit of only 255 open connections! > [suresh] I am sure, most devices have a limit on the number of open connections. The actual count may vary across vendors. > > As for the servers out there, do you know if majority of them > > use 2krs keepalive or less? > > I don't know how often servers keep a session open for 2h. HTTP servers, > and many applications implement some sort of application level idle > timer and explicitly close the connection after a couple of minutes of > inactivity. Other servers such as TELNET, SSH, RSH etc are designed to > sustain sessions indefinitely. > > > [suresh] OK, I see the difference. I would still argue, they both exhibit > > symmetric NAT behavior in that they provide different endpoint > associattions to > > the local endpoint for different session tuples. > > True. Deprecating symmetric behavior (or NB != I behavior in draft-ietf- > behave-nat-udp terms) would deprecate both "address and port" and > "session" equally. > [suresh] Yup. > > In the first case, it seems > > the NAT device remembers the endpoint association on a per-session basis > > (LA:LP->RA_1:RP_1 vs. LA:LP->RA_2:RP_2) and resues the association. Is this > > true only when the sessions are continuously made with the same tuple > (i.e., > > from LA:LP to RA_1:RP_1 continuously three times, one after the other)? > > In my experience, as long as the allocated mapping is not garbage > collected, new sessions between the same endpoints use the existing > mappings. > [suresh] OK. > > considering that they both are symmetric NAT, Do you know if this behavior > has > > any benefit over the second behavior? > > I think second one (NB="session") is quite bad since if a host behind > such a NAT tries connecting to another NAT'ed host (where the other NAT > drops incoming SYN packets), then each SYN packet sent by the host > creates a new mapping that hangs around for a minute or two. Depending [suresh] Hmm... This doesnt make sense. Why woudl a NAT create a new endpoint association for each SYN packet, when the NAT-session already exists for the first SYN? On the other hand, if the NAT-session already expired when the new SYN packet came, what difference does it make whether it reused the same endpoint association or not. > on the OS, each TCP attempt uses up 3-5 entries in the NAT > (corresponding to 3-5 retries); this eats into the 255 entries limit > making it easier to DoS the NAT. > [suresh] How so? For the same session 5-tuple, I dont see how a NAT will have multiple concurrent NAT-sessions simultaneously. I see no difference in resource consumption between the two cases. > That brings up another question, if a SYN (or any packet) is filtered, > what should the response be? Silently dropping the packet opens the NAT > up to IP Spoofing attacks where an adversary in the middle of the > network spoofs the NATs IP in a SYN, and replies with a spoofed ACK > knowing that the SYNACK was dropped silently by the NAT; thus fooling > the victim. Generating RST packets seems to violate the semantics of > RST, which in my opinion means the host replying can authoritatively say > that there is no application expecting to receive the packet. > > I propose the NAT should respond with ICMP Destination Unreachable > (Code: Host unreachable or Port unreachable) much like a router responds > with net unreachables. The response would naturally be subject to ICMP > rate limiting to prevent reflection attacks. Second, NATs should process > incoming ICMP Host or Port Unreachables the same way they would process > a RST or FIN/FINACK. Thoughts? > [suresh] Let me try and respond to this in a different thread. > Cheers > -- > Saikat > cheers, suresh From srisuresh@yahoo.com Wed, 20 Apr 2005 18:45:22 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 20 Apr 2005 18:45:22 -0700 (PDT) Subject: How should NATs reject TCP packets? (was:: Re: [Ietf-behave] Next rev on TCP Behavior) Message-ID: <20050421014522.24629.qmail@web40428.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Senthil Sivakumar wrote: > > > > > > >That brings up another question, if a SYN (or any packet) is filtered, > >what should the response be? [suresh] I believe, NAT should simply drop the TCP packets that are not permitted. Silent discard of unpermitted/erroneous datagrams will prevent "broadcast storms" and unneeded clutter in the network. I believe, it is a BAD idea to generate RST pakets because that gives the attacker clues when the attacker does port scan on the NAT device. Further, the attacker could keep the NAT device busy generating RSTs. > > Silently dropping the packet opens the NAT > >up to IP Spoofing attacks where an adversary in the middle of the > >network spoofs the NATs IP in a SYN, and replies with a spoofed ACK > >knowing that the SYNACK was dropped silently by the NAT; thus fooling > >the victim. [suresh] Sorry, I donot understand what the problem is. > > Generating RST packets seems to violate the semantics of > >RST, which in my opinion means the host replying can authoritatively say > >that there is no application expecting to receive the packet. > > [suresh] Right. As I said before, I agree, it is not a good idea to send RST. > >I propose the NAT should respond with ICMP Destination Unreachable > >(Code: Host unreachable or Port unreachable) much like a router responds > >with net unreachables. The response would naturally be subject to ICMP > >rate limiting to prevent reflection attacks. Second, NATs should process > >incoming ICMP Host or Port Unreachables the same way they would process > >a RST or FIN/FINACK. Thoughts? > > Does either of these messages cause the originating host to behave > differently? > I think sending a RST or ICMP Unreachable would not prevent a host app from > retrying > a number of times (it is programmed to retry), right? Of course, I agree > that ICMP > unreachables are slightly better for the rate limiting reason. > [suresh] I believe, the NAT device may optionally send ICMP Destination unreachable message for the cases where a certain session tuple is not permitted. However, for diagnostic purposes, the NAT device SHOULD perhaps be required to log the error and record the event in a statistic counter. As fo rthe ICMP code, I would recommend using code 10 (Communicaion with destination host administratively prohibited). It woudl have been nice if we had another code that would indicate "Communication with destination host port administratively prohibited". But, we dont. So, I suggest, we use the same code for host as well as port filtering. The above logic is not specific to TCP alone and is appliable to UDP. So, we shoudl capture this in the behave-gen draft. As you might recall, we talked about capturing ICMP message generation as well as processng concerning PMTU (i.e., for the cases where framentation is needed with DF set) in the behave-gen draft in the Minneapolis meeting. We could extend the coverage to include this as well. > Senthil > > > >Cheers > >-- > >Saikat > > cheers, suresh From srisuresh@yahoo.com Wed, 20 Apr 2005 18:53:03 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 20 Apr 2005 18:53:03 -0700 (PDT) Subject: How should NATs reject TCP packets? (WAS:: Re: [Ietf-behave] Next rev on TCP Behavior) Message-ID: <20050421015303.87390.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Mon, 2005-04-18 at 17:26 -0700, Senthil Sivakumar wrote: > > Does either of these messages cause the originating host to behave > differently? > > I think sending a RST or ICMP Unreachable would not prevent a host app from > > > retrying a number of times (it is programmed to retry), right? > > There are a couple of minor differences. Error values returned from the > socket functions is different: ECONNREFUSED for RST vs. EHOSTUNREACH for > ICMP host unreachable, which in turn generates different error strings > "Connection refused" vs. "No route to host" respectively. > > According to RFC1122 btw, ICMP host unreachable _must_ be soft, ICMP > port unreachable _should_ be hard and RST _must_ be hard. Then again, > Linux doesn't retry on some soft errors (host unreach in SYN_SENT) and > windows retries on some hard errors (RST in SYN_SENT) ... so retries in > the stack is unpredictable as it is. :-p > [suresh] Unfortunately, RFC 1122 doesnt discuss ICMP code 10 upon receipt. I believe, code 10 shold be treated as soft error. What do folks think about using code 10 for NAT/firewall rejects? > -- > Saikat > cheers, suresh From ssenthil@cisco.com Thu, 21 Apr 2005 14:32:08 -0700 (PDT) From: Senthil Sivakumar Date: Thu, 21 Apr 2005 14:32:08 -0700 (PDT) Subject: Re: How should NATs reject TCP packets? (was:: Re: [Ietf-behave] Next rev on TCP Behavior) In-Reply-To: <6667> Message-ID: <4.3.2.7.2.20050421142058.0312d588@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain At 06:45 PM 4/20/2005 -0700, Pyda Srisuresh wrote: --- Senthil Sivakumar wrote: > > > > > > >That brings up another question, if a SYN (or any packet) is filtered, > >what should the response be? [suresh] I believe, NAT should simply drop the TCP packets that are not permitted. Silent discard of unpermitted/erroneous datagrams will prevent "broadcast storms" and unneeded clutter in the network. I believe, it is a BAD idea to generate RST pakets because that gives the attacker clues when the attacker does port scan on the NAT device. Further, the attacker could keep the NAT device busy generating RSTs. I agree that NAT responding with a RST is not a good idea. However, there are cases where the TCP stack in the NAT box will generate RSTs for stray TCP packets. For example in case of a SYN received on an outside interface (coming from out->in) for which a NAT translation does not exist. NAT cannot drop this packet because it is addressed to the interface's address so it simply passes the packet up in the stack. The TCP stack would receive the SYN and probably respond with a RST since there isn't any application listening on the port. Senthil > > Silently dropping the packet opens the NAT > >up to IP Spoofing attacks where an adversary in the middle of the > >network spoofs the NATs IP in a SYN, and replies with a spoofed ACK > >knowing that the SYNACK was dropped silently by the NAT; thus fooling > >the victim. [suresh] Sorry, I donot understand what the problem is. > > Generating RST packets seems to violate the semantics of > >RST, which in my opinion means the host replying can authoritatively say > >that there is no application expecting to receive the packet. > > [suresh] Right. As I said before, I agree, it is not a good idea to send RST. > >I propose the NAT should respond with ICMP Destination Unreachable > >(Code: Host unreachable or Port unreachable) much like a router responds > >with net unreachables. The response would naturally be subject to ICMP > >rate limiting to prevent reflection attacks. Second, NATs should process > >incoming ICMP Host or Port Unreachables the same way they would process > >a RST or FIN/FINACK. Thoughts? > > Does either of these messages cause the originating host to behave > differently? > I think sending a RST or ICMP Unreachable would not prevent a host app from > retrying > a number of times (it is programmed to retry), right? Of course, I agree > that ICMP > unreachables are slightly better for the rate limiting reason. > [suresh] I believe, the NAT device may optionally send ICMP Destination unreachable message for the cases where a certain session tuple is not permitted. However, for diagnostic purposes, the NAT device SHOULD perhaps be required to log the error and record the event in a statistic counter. As fo rthe ICMP code, I would recommend using code 10 (Communicaion with destination host administratively prohibited). It woudl have been nice if we had another code that would indicate "Communication with destination host port administratively prohibited". But, we dont. So, I suggest, we use the same code for host as well as port filtering. The above logic is not specific to TCP alone and is appliable to UDP. So, we shoudl capture this in the behave-gen draft. As you might recall, we talked about capturing ICMP message generation as well as processng concerning PMTU (i.e., for the cases where framentation is needed with DF set) in the behave-gen draft in the Minneapolis meeting. We could extend the coverage to include this as well. > Senthil > > > >Cheers > >-- > >Saikat > > cheers, suresh From rrs@cisco.com Fri, 22 Apr 2005 03:22:56 -0700 (PDT) From: Randall Stewart Date: Fri, 22 Apr 2005 03:22:56 -0700 (PDT) Subject: [Ietf-behave] A new SCTP NAT draft Message-ID: <4268D1E3.309@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Hi all: At the last IETF Michael Tuexen and I had an interesting idea on how to get SCTP through a NAT.. provide full functionality of a NAPT type NAT and still only do NAT.. We finally got the document together and I submitted it today.. For the impatient.. I have also placed it up on sctp.org at: http://www.sctp.org/draft-stewart-behave-sctpnat-00.txt Comments would be much appreciated R -- Randall Stewart ITD 803-345-0369 815-342-5222 From srisuresh@yahoo.com Sun, 24 Apr 2005 09:55:45 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 24 Apr 2005 09:55:45 -0700 (PDT) Subject: Re: How should NATs reject TCP packets? (was:: Re: [Ietf-behave] Next rev on TCP Behavior) In-Reply-To: <4.3.2.7.2.20050421142058.0312d588@mira-sjcd-2.cisco.com> Message-ID: <20050424165544.16341.qmail@web40424.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Senthil, Please see my comment inline below. cheers, suresh --- Senthil Sivakumar wrote: > At 06:45 PM 4/20/2005 -0700, Pyda Srisuresh wrote: > > >--- Senthil Sivakumar wrote: > > > > > > > > > > > > > > >That brings up another question, if a SYN (or any packet) is filtered, > > > >what should the response be? > > > >[suresh] I believe, NAT should simply drop the TCP packets that are not > >permitted. Silent discard of unpermitted/erroneous datagrams will prevent > >"broadcast storms" and unneeded clutter in the network. > > > >I believe, it is a BAD idea to generate RST pakets because that gives the > >attacker clues when the attacker does port scan on the NAT device. > >Further, the > >attacker could keep the NAT device busy generating RSTs. > > I agree that NAT responding with a RST is not a good idea. However, there are > cases where the TCP stack in the NAT box will generate RSTs for stray TCP > packets. For example in case of a SYN received on an outside interface > (coming > from out->in) for which a NAT translation does not exist. NAT cannot drop > this packet > because it is addressed to the interface's address so it simply passes the > packet > up in the stack. The TCP stack would receive the SYN and probably respond > with > a RST since there isn't any application listening on the port. > [suresh] I understand and agree with what you say about ports for which the NAT device is acting as endpoint and no NAT involved. I was refering only to the ports for which the NAT functon is applicable - say, the block of ports that may have been reserved for NAT use (or) the ports that currently have a port binding for outgoign sessions, but inbound session is not permitted. cheers, suresh > Senthil > From kbiswas@cisco.com Sun, 24 Apr 2005 12:13:13 -0700 (PDT) From: Kaushik Biswas Date: Sun, 24 Apr 2005 12:13:13 -0700 (PDT) Subject: Re: How should NATs reject TCP packets? (was:: Re: [Ietf-behave] Next rev on TCP Behavior) In-Reply-To: <4.3.2.7.2.20050421142058.0312d588@mira-sjcd-2.cisco.com> Message-ID: <4.3.2.7.2.20050424115854.02368d30@mira-sjcd-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Hi Suresh, Please see inline for my comments.... At 09:55 AM 4/24/2005 -0700, Pyda Srisuresh wrote: Senthil, Please see my comment inline below. cheers, suresh --- Senthil Sivakumar wrote: > At 06:45 PM 4/20/2005 -0700, Pyda Srisuresh wrote: > > >--- Senthil Sivakumar wrote: > > > > > > > > > > > > > > >That brings up another question, if a SYN (or any packet) is filtered, > > > >what should the response be? > > > >[suresh] I believe, NAT should simply drop the TCP packets that are not > >permitted. Silent discard of unpermitted/erroneous datagrams will prevent > >"broadcast storms" and unneeded clutter in the network. > > > >I believe, it is a BAD idea to generate RST pakets because that gives the > >attacker clues when the attacker does port scan on the NAT device. > >Further, the > >attacker could keep the NAT device busy generating RSTs. > > I agree that NAT responding with a RST is not a good idea. However, there are > cases where the TCP stack in the NAT box will generate RSTs for stray TCP > packets. For example in case of a SYN received on an outside interface > (coming > from out->in) for which a NAT translation does not exist. NAT cannot drop > this packet > because it is addressed to the interface's address so it simply passes the > packet > up in the stack. The TCP stack would receive the SYN and probably respond > with > a RST since there isn't any application listening on the port. > [suresh] I understand and agree with what you say about ports for which the NAT device is acting as endpoint and no NAT involved. I was refering only to the ports for which the NAT functon is applicable - say, the block of ports that may have been reserved for NAT use (or) the ports that currently have a port binding for outgoign sessions, but inbound session is not permitted. [Kaushik] If we are not going to generate RST for such out->in packets destined to the block of ports that may have been reserved by NAT, then there would be an inconsistency in behavior. Since if this port were to be a port which NAT had *not* reserved then it would be going to the local TCP stack of the router and it would anyway generate a RST as there is no associated TCP control-block for this flow. Actually by not sending a RST for this such out->in packets one would be giving the attacker more clue as to which ports are reserved by NAT and which are not. Thanks, Kaushik cheers, suresh > Senthil > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From jiri@iptel.org Mon, 25 Apr 2005 17:12:21 -0700 (PDT) From: Jiri Kuthan Date: Mon, 25 Apr 2005 17:12:21 -0700 (PDT) Subject: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <6.0.3.0.0.20050426011721.055967c0@localhost> MIME-Version: 1.0 Content-Type: text/plain This is a BEHAVE Working Group Last Call for comments on draft-ietf-behave-nat-udp-01. This last call closes Tuesday May 12, 2005. Please post any final comments you have on this draft to this list by that date. -jiri A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-01.txt From sg266@cornell.edu Mon, 25 Apr 2005 19:22:08 -0700 (PDT) From: Saikat Guha Date: Mon, 25 Apr 2005 19:22:08 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <20050421005151.90096.qmail@web40424.mail.yahoo.com> Message-ID: <1114482118.5919.58.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630133.multipart/signed" --Boundary..27398.1163630133.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-04-20 at 17:51 -0700, Pyda Srisuresh wrote: > > I think second one (NB="session") is quite bad since if a host behind > > such a NAT tries connecting to another NAT'ed host (where the other NAT > > drops incoming SYN packets), then each SYN packet sent by the host > > creates a new mapping that hangs around for a minute or two. Depending > > [suresh] Hmm... This doesnt make sense. Why woudl a NAT create a new endpoint > association for each SYN packet, when the NAT-session already exists for the > first SYN? On the other hand, if the NAT-session already expired when the new > SYN packet came, what difference does it make whether it reused the same > endpoint association or not. It's very bewildering actually. The packet trace I observed through a netgear NAT went something like: Host = a = 192.168.1.1 NAT = A = 128.84.154.97 Server= B = 128.84.154.62 Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1052,B:3389)---> dropped Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1053,B:3389)---> dropped Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1054,B:3389)---> delivered Server---(SYNACK,B:3389,A:1054)---> NAT---(SYNACK,B:3389,a:1024)---> delivered Host---(ACK,a:1024,B:3389)---> NAT---(ACK,A:1054,B:3389)---> delivered The SYNs are TCP retransmissions at time 0s, 3s, 9s. It seems like this particular NAT allocates a new packet for _every_ SYN packet it sees; retransmission or not. The server receives one of the SYN packets and responds, and the source port of that SYN at the NAT enters established state while the others get garbage collected shortly afterward. > > on the OS, each TCP attempt uses up 3-5 entries in the NAT > > (corresponding to 3-5 retries); this eats into the 255 entries limit > > making it easier to DoS the NAT. > > > [suresh] How so? For the same session 5-tuple, I dont see how a NAT will have > multiple concurrent NAT-sessions simultaneously. the session tuple could depend on the implementation. Logically it is a 5-tuple (proto, src_ip, src_port, dst_ip, dst_port) ... but the NAT may store it internally as, perhaps, a 8-tuple (..., map_ip, map_port, TCP_STATE). My guess is that in the above case each SYN generates a new 8-tuple. inbound packets are matched based on map_ip/map_port. Outbound packets are matched on tcp status in addition to some combination of source and destination address and ports. Just a hunch. Cheers. -- Saikat (who feels NAT firmware source should be made available for inspection to prevent hairloss) Attachment: signature.asc --Boundary..27398.1163630133.multipart/signed Content-Type: application/octet-stream; name="pgp00025.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00025.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ2JhWEduRmx0cWk2OTEvb1JBcVFYQUo5cERsMW9lK0tJbXBXeW16Yzgr ZUNsanZHZXV3Q2RHYzBBCjY2MFErVXlPOTNkMDlrNzdJWjliWVA4PQo9cTVaRQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630133.multipart/signed-- From sg266@cornell.edu Mon, 25 Apr 2005 19:53:46 -0700 (PDT) From: Saikat Guha Date: Mon, 25 Apr 2005 19:53:46 -0700 (PDT) Subject: Re: How should NATs reject TCP packets? (was:: Re: [Ietf-behave] Next rev on TCP Behavior) In-Reply-To: <20050421014522.24629.qmail@web40428.mail.yahoo.com> Message-ID: <1114483956.5919.68.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630133.multipart/signed" --Boundary..27398.1163630133.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-04-20 at 18:45 -0700, Pyda Srisuresh wrote: > [suresh] I believe, NAT should simply drop the TCP packets that are not > permitted. I am not in favor of this since this forces the other end to wait for a TCP timeout on a failed connect. > I believe, it is a BAD idea to generate RST pakets because that gives the > attacker clues when the attacker does port scan on the NAT device. Further, > the > attacker could keep the NAT device busy generating RSTs. I am not in favor of this either since 1) It forces the other end to abort immediately. 2) I agree that the NAT could be kept busy generating RSTs. > [suresh] I believe, the NAT device may optionally send ICMP Destination > unreachable message [...] I would recommend using code 10 (Communicaion with > destination host administratively prohibited) I vote for this one. 1) ICMP rate limiting prevents the NAT being kept busy. 2) Code 10 could be defined with a SHOULD clause to be either hard or soft giving the endhost the final say on whether to retry or not. One reason why the endhost may want to consider it a soft error is if it is expecting (or trying) to trigger a TCP Simultaneous Open. One reason why the host may want to consider it a hard error is to abort a likely- to-fail connection request as soon as possible. Using ICMP Dest Unreach, Code 10 gives the host flexibility to do either. Cheers. -- Saikat Attachment: signature.asc --Boundary..27398.1163630133.multipart/signed Content-Type: application/octet-stream; name="pgp00026.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00026.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ2JhejBuRmx0cWk2OTEvb1JBck9RQUo0eStIY3JBdUdNRjl1SVErMEZv dEVpVm5wa1hBQ2ZaUzlBCjJCNWNHMm90dmpmSHk2WGlTQ29EU1FBPQo9aS9GbQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630133.multipart/signed-- From srisuresh@yahoo.com Tue, 26 Apr 2005 07:52:22 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 26 Apr 2005 07:52:22 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior Message-ID: <20050426145221.83407.qmail@web40422.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Wed, 2005-04-20 at 17:51 -0700, Pyda Srisuresh wrote: > > > I think second one (NB="session") is quite bad since if a host behind > > > such a NAT tries connecting to another NAT'ed host (where the other NAT > > > drops incoming SYN packets), then each SYN packet sent by the host > > > creates a new mapping that hangs around for a minute or two. Depending > > > > [suresh] Hmm... This doesnt make sense. Why woudl a NAT create a new > endpoint > > association for each SYN packet, when the NAT-session already exists for > the > > first SYN? On the other hand, if the NAT-session already expired when the > new > > SYN packet came, what difference does it make whether it reused the same > > endpoint association or not. > > It's very bewildering actually. The packet trace I observed through a > netgear NAT went something like: > > Host = a = 192.168.1.1 > NAT = A = 128.84.154.97 > Server= B = 128.84.154.62 > > Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1052,B:3389)---> dropped > Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1053,B:3389)---> dropped > Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1054,B:3389)---> delivered > Server---(SYNACK,B:3389,A:1054)---> NAT---(SYNACK,B:3389,a:1024)---> > delivered > Host---(ACK,a:1024,B:3389)---> NAT---(ACK,A:1054,B:3389)---> delivered > > The SYNs are TCP retransmissions at time 0s, 3s, 9s. It seems like this > particular NAT allocates a new packet for _every_ SYN packet it sees; > retransmission or not. The server receives one of the SYN packets and > responds, and the source port of that SYN at the NAT enters established > state while the others get garbage collected shortly afterward. > [suresh] Saikat - Thanks for the detailed description. Do you know for a fact that the NAT device did not free up the first two NAT sessions, by the time it created the third NAT session. I think, it may have and here is what I suspect might have happened. Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1052,B:3389)---> dropped ==> NAT device created NAT session-1 (a:1024->A:1052,B:3389) Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1053,B:3389)---> dropped ==> At this point or before, NAT device freed up NAT session-1. ==> NAT device created NAT session-2 (a:1024->A:1053,B:3389) Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1054,B:3389)---> delivered ==> At this point or before, NAT device freed up NAT session-2. ==> NAT device created NAT session-3 (a:1024->A:1054,B:3389) Server---(SYNACK,B:3389,A:1054)---> NAT---(SYNACK,B:3389,a:1024)---> delivered ==> NAT device matched the packet from Server against NAT session-3. ==> NAT device changed the TCP-state of NAT Session-3 ==> NAT device used NAT Session-3 to translate & forward to Host a. Host---(ACK,a:1024,B:3389)---> NAT---(ACK,A:1054,B:3389)---> delivered ==> NAT device matched the packet from Host-a against NAT session-3.. ==> NAT device changed the TCP-state of NAT Session-3. ==> NAT device used NAT Session-3 to translate & forward to server. > > > > on the OS, each TCP attempt uses up 3-5 entries in the NAT > > > (corresponding to 3-5 retries); this eats into the 255 entries limit > > > making it easier to DoS the NAT. > > > > > [suresh] How so? For the same session 5-tuple, I dont see how a NAT will > have > > multiple concurrent NAT-sessions simultaneously. > > the session tuple could depend on the implementation. Logically it is a > 5-tuple (proto, src_ip, src_port, dst_ip, dst_port) ... but the NAT may > store it internally as, perhaps, a 8-tuple (..., map_ip, map_port, > TCP_STATE). [suresh] Yup, I agree. The NAT Session does need to include all the parameters you list. > My guess is that in the above case each SYN generates a new > 8-tuple. inbound packets are matched based on map_ip/map_port. Outbound > packets are matched on tcp status in addition to some combination of > source and destination address and ports. Just a hunch. [suresh] Hmm.. That is possible. However, if a new xlation endpoint is identified, I see no reason to retain the old NAT Session unless there is some implementation glitch. The prior NAT Session should have been freed, if the NAT device chose to create a new NAT session with a different endpoint to translate to. If the NAT device is indeed holding on to all the previous NAT sessions, it seems like an implementation glitch to me. > > Cheers. > -- > Saikat > (who feels NAT firmware source should be made available for inspection > to prevent hairloss) > cheers, suresh From fluffy@cisco.com Tue, 26 Apr 2005 14:05:01 -0700 (PDT) From: Cullen Jennings Date: Tue, 26 Apr 2005 14:05:01 -0700 (PDT) Subject: [Ietf-behave] STUN attribute values in draft-ietf-behave-rfc3489bis-01 Message-ID: MIME-Version: 1.0 Content-Type: text/plain On page 18 it says If a client receives a response with an attribute whose type is greater than 0x7fff, the attribute MUST be ignored. It seems it should say it it receives an unknown attribute it should ignore it - it should be welcome to use ones it understands.. More importantly, I think we have defined several things a mandatory to understand that probably are not. For example, seems that SERVER should have a code like 0x8022 not 0x0022 I imagine XOR-MAPPED might be optional to understand. Cullen From jdrosen@cisco.com Tue, 26 Apr 2005 23:36:03 -0700 (PDT) From: Jonathan Rosenberg Date: Tue, 26 Apr 2005 23:36:03 -0700 (PDT) Subject: [Ietf-behave] Re: STUN attribute values in draft-ietf-behave-rfc3489bis-01 In-Reply-To: Message-ID: <426F32CE.50106@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Cullen Jennings wrote: On page 18 it says If a client receives a response with an attribute whose type is greater than 0x7fff, the attribute MUST be ignored. It seems it should say it it receives an unknown attribute it should ignore it - it should be welcome to use ones it understands.. Oops. This is a bug. Fixed. More importantly, I think we have defined several things a mandatory to understand that probably are not. For example, seems that SERVER should have a code like 0x8022 not 0x0022 I imagine XOR-MAPPED might be optional to understand. Good points. You are right. In fact, XOR-MAPPED-ADDRESs has to be over 7fff for compatibility with existing stun clients. Same with SERVER. I've changed them to 0x8020 and 0x8022 respectively. XOR-ONLY needs to be under 0x7fff however. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From matthews@nimcatnetworks.com Wed, 27 Apr 2005 05:49:57 -0700 (PDT) From: Philip Matthews Date: Wed, 27 Apr 2005 05:49:57 -0700 (PDT) Subject: [Ietf-behave] Re: STUN attribute values in draft-ietf-behave-rfc3489bis-01 In-Reply-To: Message-ID: <426F89EB.2070504@nimcatnetworks.com> MIME-Version: 1.0 Content-Type: text/plain I was about to make the same comments at Cullen. And I agree with the proposed fixes as well. I have some other comments on the 3489bis draft which I will write up and pass on shortly. - Philip Jonathan Rosenberg wrote: Cullen Jennings wrote: On page 18 it says If a client receives a response with an attribute whose type is greater than 0x7fff, the attribute MUST be ignored. It seems it should say it it receives an unknown attribute it should ignore it - it should be welcome to use ones it understands.. Oops. This is a bug. Fixed. More importantly, I think we have defined several things a mandatory to understand that probably are not. For example, seems that SERVER should have a code like 0x8022 not 0x0022 I imagine XOR-MAPPED might be optional to understand. Good points. You are right. In fact, XOR-MAPPED-ADDRESs has to be over 7fff for compatibility with existing stun clients. Same with SERVER. I've changed them to 0x8020 and 0x8022 respectively. XOR-ONLY needs to be under 0x7fff however. -Jonathan R. -- Philip Matthews Architect Phone: +1 613-832-4343 x224 Nimcat Networks Email: matthews -at- nimcatnetworks -dot- com 1135 Innovation Drive Ottawa, Ontario K2K 3G7 Canada From sg266@cornell.edu Sun, 8 May 2005 22:16:07 -0700 (PDT) From: Saikat Guha Date: Sun, 8 May 2005 22:16:07 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <20050426145221.83407.qmail@web40422.mail.yahoo.com> Message-ID: <1115615763.5219.19.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630133.multipart/signed" --Boundary..27398.1163630133.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Comments inline. Sorry for the delay; it was a DLink NAT (not netgear). On Tue, 2005-04-26 at 07:52 -0700, Pyda Srisuresh wrote: > here is what I suspect might have happened. > > Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1052,B:3389)---> dropped > ==> NAT device created NAT session-1 (a:1024->A:1052,B:3389) > > Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1053,B:3389)---> dropped > ==> At this point or before, NAT device freed up NAT session-1. > ==> NAT device created NAT session-2 (a:1024->A:1053,B:3389) > > Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1054,B:3389)---> delivered > ==> At this point or before, NAT device freed up NAT session-2. > ==> NAT device created NAT session-3 (a:1024->A:1054,B:3389) You are correct. This time I traced the traffic on both sides of the NAT. If a SYN goes unanswered for about 2 seconds, the NAT frees up the session and generates a RST for the internal stack. -- Saikat Attachment: signature.asc --Boundary..27398.1163630133.multipart/signed Content-Type: application/octet-stream; name="pgp00027.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00027.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ2Z2SVRuRmx0cWk2OTEvb1JBbzBtQUo0OTdBOFRlTHU0N044U0IxcUVU bXVPZTU4V1pRQ2VLT2Q1CkZIMkJrSW90NDBMSFJENFdzZFdLWDFjPQo9eFIxZgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630133.multipart/signed-- From srisuresh@yahoo.com Sun, 8 May 2005 23:10:49 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 8 May 2005 23:10:49 -0700 (PDT) Subject: Re: How should NATs reject TCP packets? (was:: Re: [Ietf-behave] Next rev on TCP Behavior) In-Reply-To: <1114483956.5919.68.camel@mazinger.u.cs.cornell.edu> Message-ID: <20050509061049.70363.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Hi Saikat, It seems I missed responding to this. Please see my comments inline below. cheers, suresh --- Saikat Guha wrote: > On Wed, 2005-04-20 at 18:45 -0700, Pyda Srisuresh wrote: > > [suresh] I believe, NAT should simply drop the TCP packets that are not > > permitted. > > I am not in favor of this since this forces the other end to wait for a > TCP timeout on a failed connect. > [suresh] OK. > > I believe, it is a BAD idea to generate RST pakets because that gives the > > attacker clues when the attacker does port scan on the NAT device. Further, > the > > attacker could keep the NAT device busy generating RSTs. > > I am not in favor of this either since 1) It forces the other end to > abort immediately. 2) I agree that the NAT could be kept busy generating > RSTs. > [suresh] OK. we are in agreement for the same reasons. > > [suresh] I believe, the NAT device may optionally send ICMP Destination > > unreachable message [...] I would recommend using code 10 (Communicaion > with > > destination host administratively prohibited) > > I vote for this one. > 1) ICMP rate limiting prevents the NAT being kept busy. > 2) Code 10 could be defined with a SHOULD clause to be either hard or > soft giving the endhost the final say on whether to retry or not. > > One reason why the endhost may want to consider it a soft error is if it > is expecting (or trying) to trigger a TCP Simultaneous Open. One reason > why the host may want to consider it a hard error is to abort a likely- > to-fail connection request as soon as possible. Using ICMP Dest Unreach, > Code 10 gives the host flexibility to do either. > [suresh] Sounds good. > Cheers. > -- > Saikat > cheers, suresh From srisuresh@yahoo.com Sun, 8 May 2005 23:22:54 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 8 May 2005 23:22:54 -0700 (PDT) Subject: Re: [Ietf-behave] Next rev on TCP Behavior In-Reply-To: <1115615763.5219.19.camel@mazinger.u.cs.cornell.edu> Message-ID: <20050509062254.823.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain OK. Sounds like, it doesnt matter how endpoint associations are made with Symmetric NAT behavior. They all are equally unacceptable, right. cheers, suresh --- Saikat Guha wrote: > Comments inline. Sorry for the delay; it was a DLink NAT (not netgear). > > On Tue, 2005-04-26 at 07:52 -0700, Pyda Srisuresh wrote: > > here is what I suspect might have happened. > > > > Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1052,B:3389)---> dropped > > ==> NAT device created NAT session-1 (a:1024->A:1052,B:3389) > > > > Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1053,B:3389)---> dropped > > ==> At this point or before, NAT device freed up NAT session-1. > > ==> NAT device created NAT session-2 (a:1024->A:1053,B:3389) > > > > Host---(SYN,a:1024,B:3389)---> NAT---(SYN,A:1054,B:3389)---> delivered > > ==> At this point or before, NAT device freed up NAT session-2. > > ==> NAT device created NAT session-3 (a:1024->A:1054,B:3389) > > You are correct. This time I traced the traffic on both sides of the > NAT. If a SYN goes unanswered for about 2 seconds, the NAT frees up the > session and generates a RST for the internal stack. > > -- > Saikat > From paul.hoffman@cybersecurity.org Mon, 9 May 2005 10:14:26 -0700 (PDT) From: Paul Hoffman Date: Mon, 9 May 2005 10:14:26 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <6.0.3.0.0.20050426011721.055967c0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 2:10 AM +0200 4/26/05, Jiri Kuthan wrote: This is a BEHAVE Working Group Last Call for comments on draft-ietf-behave-nat-udp-01. This last call closes Tuesday May 12, 2005. Please post any final comments you have on this draft to this list by that date. **Unnecessary specification of UDP** In a few sentences in the document, UDP is mentioned as if it is the specific protocol being discussed, but TCP could be equivalently substituted in its place. These sentences should be made protocol-agnostic if they really are protocol-agnostic, which I think the following are. (Of course, there are still many UDP-specific sections in the document!) 4.1, first sentence, delete "UDP" because the same would be true for "TCP" and possibly other protocols. 4.3, first sentence, remove "UDP" because the timers are very unlikely to be different than TCP timers. 5.1, first sentence, remove "UDP" because the same would be true for "TCP" and possibly other protocols. 7, first sentence, remove "UDP" because the same would be true for "TCP" and possibly other protocols. 9, first sentence, remove "UDP" because the same would be true for "TCP" and possibly other protocols. 11, first two sentences, remove "UDP" because the same would be true for "TCP" and possibly other protocols. **Editorial** 1, fourth paragraph, remove "the" and change "off" to "of": "...control off middle boxes..." 1, last paragraph, RTP and other UDP-based protocols are said to run on top of UDP, so change "below" to "above". 4.2.3, first paragraph, "glare" should be "glaring". 5.1, second bullet, replace "...packets to Y..." with "packets to Y:any ..." to make it parallel with the other usage in the section. 7, last paragraph, after "methods" add "or protocols that try to be NAT-aware" to make it more general. 9, section title should be "ICMP Destination Unreachable Behavior" because that is the only type of ICMP behavior being discussed in the section. 10, section title should be "Fragmentation of Outgoing Packets" to emphasize that the entire section is about packets flowing in one direction. 10.1, end of first paragraph, add ", or other reasons" because there are many reasons why the MTU is set higher on the NAT. 10.1, third and fourth paragraph, "should" needs to be capitalized. 10.2, end of first paragraph, add "as specified in" before "RFC 1812". 11, first sentence, change "first or last" to "in any fragment" because there may be more than two fragments for the packet. 13, last paragraph, add "if done incorrectly" after "...a DoS opportunity" because many stacks correctly buffer fragments in a manner that doesn't make them susceptible. --Paul Hoffman, Director --Cybersecurity Association From audet@nortel.com Mon, 9 May 2005 11:02:55 -0700 (PDT) From: "Francois Audet" Date: Mon, 9 May 2005 11:02:55 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF0228CEC5@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Hi Paul, Thank you for your careful reading of the document. I agree with all your comments and will make the changes accordingly unless there is opposition on the list. Cheers. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Paul Hoffman > Sent: Monday, May 09, 2005 10:11 > To: Jiri Kuthan; Ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] WG last call: > draft-ietf-behave-nat-udp-01.txt > > > At 2:10 AM +0200 4/26/05, Jiri Kuthan wrote: > >This is a BEHAVE Working Group Last Call for comments > >on draft-ietf-behave-nat-udp-01. This last call closes > >Tuesday May 12, 2005. Please post any final comments you > >have on this draft to this list by that date. > > **Unnecessary specification of UDP** > > In a few sentences in the document, UDP is mentioned as if it is the > specific protocol being discussed, but TCP could be equivalently > substituted in its place. These sentences should be made > protocol-agnostic if they really are protocol-agnostic, which I think > the following are. (Of course, there are still many UDP-specific > sections in the document!) > > 4.1, first sentence, delete "UDP" because the same would be true for > "TCP" and possibly other protocols. > > 4.3, first sentence, remove "UDP" because the timers are very > unlikely to be different than TCP timers. > > 5.1, first sentence, remove "UDP" because the same would be true for > "TCP" and possibly other protocols. > > 7, first sentence, remove "UDP" because the same would be true for > "TCP" and possibly other protocols. > > 9, first sentence, remove "UDP" because the same would be true for > "TCP" and possibly other protocols. > > 11, first two sentences, remove "UDP" because the same would be true > for "TCP" and possibly other protocols. > > > **Editorial** > > 1, fourth paragraph, remove "the" and change "off" to "of": > "...control off middle boxes..." > > 1, last paragraph, RTP and other UDP-based protocols are said to run > on top of UDP, so change "below" to "above". > > 4.2.3, first paragraph, "glare" should be "glaring". > > 5.1, second bullet, replace "...packets to Y..." with "packets to > Y:any ..." to make it parallel with the other usage in the section. > > 7, last paragraph, after "methods" add "or protocols that try to be > NAT-aware" to make it more general. > > 9, section title should be "ICMP Destination Unreachable Behavior" > because that is the only type of ICMP behavior being discussed in the > section. > > 10, section title should be "Fragmentation of Outgoing Packets" to > emphasize that the entire section is about packets flowing in one > direction. > > 10.1, end of first paragraph, add ", or other reasons" because there > are many reasons why the MTU is set higher on the NAT. > > 10.1, third and fourth paragraph, "should" needs to be capitalized. > > 10.2, end of first paragraph, add "as specified in" before "RFC 1812". > > 11, first sentence, change "first or last" to "in any fragment" > because there may be more than two fragments for the packet. > > 13, last paragraph, add "if done incorrectly" after "...a DoS > opportunity" because many stacks correctly buffer fragments in a > manner that doesn't make them susceptible. > > > --Paul Hoffman, Director > --Cybersecurity Association > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From ssenthil@cisco.com Mon, 9 May 2005 11:13:39 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Mon, 9 May 2005 11:13:39 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB23247D@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt A lot of text in this document is generic to both TCP and UDP but the applicability states "This document only covers the UDP Unicast aspects of NAT traversaland does not cover TCP, IPSEC, or other protocols. Since thedocument is for UDP only, packet inspection below the UDP layer(including RTP) is also out-of-scope." We felt this while writing the TCP behavior draft where we had to refer to the UDP draft for generic issues. The common requirements should be addressed in a seperate document, that will make both the TCP and UDP requirements concise and should not be interleaved in this UDP requirements draft. Senthil From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Francois AudetSent: Monday, May 09, 2005 11:02 AMTo: 'Paul Hoffman'; 'Jiri Kuthan'; 'Ietf-behave@xxxxxxxxxxxxxxxxxxx'Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Hi Paul, Thank you for your careful reading of the document. I agree with all your comments and will make the changes accordingly unless there is opposition on the list. Cheers. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Paul Hoffman > Sent: Monday, May 09, 2005 10:11 > To: Jiri Kuthan; Ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] WG last call: > draft-ietf-behave-nat-udp-01.txt > > > At 2:10 AM +0200 4/26/05, Jiri Kuthan wrote: > >This is a BEHAVE Working Group Last Call for comments > >on draft-ietf-behave-nat-udp-01. This last call closes > >Tuesday May 12, 2005. Please post any final comments you > >have on this draft to this list by that date. > > **Unnecessary specification of UDP** > > In a few sentences in the document, UDP is mentioned as if it is the > specific protocol being discussed, but TCP could be equivalently > substituted in its place. These sentences should be made > protocol-agnostic if they really are protocol-agnostic, which I think > the following are. (Of course, there are still many UDP-specific > sections in the document!) > > 4.1, first sentence, delete "UDP" because the same would be true for > "TCP" and possibly other protocols. > > 4.3, first sentence, remove "UDP" because the timers are very > unlikely to be different than TCP timers. > > 5.1, first sentence, remove "UDP" because the same would be true for > "TCP" and possibly other protocols. > > 7, first sentence, remove "UDP" because the same would be true for > "TCP" and possibly other protocols. > > 9, first sentence, remove "UDP" because the same would be true for > "TCP" and possibly other protocols. > > 11, first two sentences, remove "UDP" because the same would be true > for "TCP" and possibly other protocols. > > > **Editorial** > > 1, fourth paragraph, remove "the" and change "off" to "of": > "...control off middle boxes..." > > 1, last paragraph, RTP and other UDP-based protocols are said to run > on top of UDP, so change "below" to "above". > > 4.2.3, first paragraph, "glare" should be "glaring". > > 5.1, second bullet, replace "...packets to Y..." with "packets to > Y:any ..." to make it parallel with the other usage in the section. > > 7, last paragraph, after "methods" add "or protocols that try to be > NAT-aware" to make it more general. > > 9, section title should be "ICMP Destination Unreachable Behavior" > because that is the only type of ICMP behavior being discussed in the > section. > > 10, section title should be "Fragmentation of Outgoing Packets" to > emphasize that the entire section is about packets flowing in one > direction. > > 10.1, end of first paragraph, add ", or other reasons" because there > are many reasons why the MTU is set higher on the NAT. > > 10.1, third and fourth paragraph, "should" needs to be capitalized. > > 10.2, end of first paragraph, add "as specified in" before "RFC 1812". > > 11, first sentence, change "first or last" to "in any fragment" > because there may be more than two fragments for the packet. > > 13, last paragraph, add "if done incorrectly" after "...a DoS > opportunity" because many stacks correctly buffer fragments in a > manner that doesn't make them susceptible. > > > --Paul Hoffman, Director > --Cybersecurity Association > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From paul.hoffman@cybersecurity.org Mon, 9 May 2005 11:32:00 -0700 (PDT) From: Paul Hoffman Date: Mon, 9 May 2005 11:32:00 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB23247D@xmb-sjc-236.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 11:13 AM -0700 5/9/05, Senthil Sivakumar \(ssenthil\) wrote: A lot of text in this document is generic to both TCP and UDP but the applicability states "This document only covers the UDP Unicast aspects of NAT traversal and does not cover TCP, IPSEC, or other protocols. There is no mismatch there. In the areas I pointed out, where it says "UDP" it actually covers any IP-based protocol. Thus, it is better to keep those parts generic. Since the document is for UDP only, packet inspection below the UDP layer (including RTP) is also out-of-scope." There is no mismatch there either. I don't think that the current UDP requirements draft talks about UDP packet inspection except to say "don't do that". We felt this while writing the TCP behavior draft where we had to refer to the UDP draft for generic issues. Right. The common requirements should be addressed in a seperate document, that will make both the TCP and UDP requirements concise and should not be interleaved in this UDP requirements draft. That's one option. Another is to make the two drafts parallel, pointing out where they differ due to specific differences between UDP and TCP. --Paul Hoffman, Director --Cybersecurity Association From audet@nortel.com Mon, 9 May 2005 11:57:35 -0700 (PDT) From: "Francois Audet" Date: Mon, 9 May 2005 11:57:35 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF0228CFCD@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt > At 11:13 AM -0700 5/9/05, Senthil Sivakumar \(ssenthil\) wrote: > >A lot of text in this document is generic to both TCP and UDP but > >the applicability states > > > >"This document only covers the UDP Unicast aspects of NAT > >traversal and does not cover TCP, IPSEC, or other protocols. > > There is no mismatch there. In the areas I pointed out, where it says > "UDP" it actually covers any IP-based protocol. Thus, it is better to > keep those parts generic. > > > Since the document is for UDP only, packet inspection below the > >UDP layer (including RTP) is also out-of-scope." > > There is no mismatch there either. I don't think that the current UDP > requirements draft talks about UDP packet inspection except to say > "don't do that". > > >We felt this while writing the TCP behavior draft where we had to > >refer to the UDP draft for generic issues. > > Right. > > > The common requirements should be addressed in a seperate > >document, that will make both the TCP and UDP requirements concise > >and should not be interleaved in this UDP requirements draft. > > That's one option. Another is to make the two drafts parallel, > pointing out where they differ due to specific differences between > UDP and TCP. Agree. That decision (to have two parrallel drafts) was already made. From ssenthil@cisco.com Mon, 9 May 2005 12:04:41 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Mon, 9 May 2005 12:04:41 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB232494@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Comments inline with [Senthil] -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Paul Hoffman Sent: Monday, May 09, 2005 11:32 AM To: Ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt At 11:13 AM -0700 5/9/05, Senthil Sivakumar \(ssenthil\) wrote: >A lot of text in this document is generic to both TCP and UDP but the >applicability states > >"This document only covers the UDP Unicast aspects of NAT traversal and >does not cover TCP, IPSEC, or other protocols. There is no mismatch there. In the areas I pointed out, where it says "UDP" it actually covers any IP-based protocol. Thus, it is better to keep those parts generic. [Senthil] To me that is confusing. The text explicitly says no other protocol is covered but it discusses generic aspects of any IP based protocol? > Since the document is for UDP only, packet inspection below the UDP >layer (including RTP) is also out-of-scope." There is no mismatch there either. I don't think that the current UDP requirements draft talks about UDP packet inspection except to say "don't do that". >We felt this while writing the TCP behavior draft where we had to refer >to the UDP draft for generic issues. Right. > The common requirements should be addressed in a seperate document, >that will make both the TCP and UDP requirements concise and should not >be interleaved in this UDP requirements draft. That's one option. Another is to make the two drafts parallel, pointing out where they differ due to specific differences between UDP and TCP. [Senthil] Discussing the specific differences of each of the specific protocol is what these two drafts are all about. That is not the problem, the problem is where should the commonlaties reside, in UDP draft, in TCP draft, in both or in a separate draft. I think it should reside in a separate draft. Senthil --Paul Hoffman, Director --Cybersecurity Association _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From paul.hoffman@cybersecurity.org Mon, 9 May 2005 14:52:19 -0700 (PDT) From: Paul Hoffman Date: Mon, 9 May 2005 14:52:19 -0700 (PDT) Subject: [Ietf-behave] Issues with draft-ietf-behave-rfc3489bis-01 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Greetings again. In looking over the STUNbis draft, two issues popped up. In section 8.1, it says: OPEN ISSUE: Experience has shown that the usage of a dynamic port for P2 has been problematic. This is because firewall administrators have opened up port 3478 to permit STUN, but disallowed the dynamic port used by the server. This causes the diagnostic techniques to fail. This can be fixed through allocation of a second port number from IANA. Does that belong in this specification or in the diagnostic specification? I think it has to go here. Agree, it should go here, particularly because there doesn't appear to be a diagnostic spec (yet). Later in 8.1, it says: If the RESPONSE-ADDRESS attribute was absent from the Binding Request, the destination address and port of the Binding Response MUST be the same as the source address and port of the Binding Request. Otherwise, the destination address and port of the Binding Response MUST be the value of the IP address and port in the RESPONSE-ADDRESS attribute. This means that a compliant STUN server MUST support sending STUN responses to someone who didn't ask for them; that's pretty bad from a DoS standpoint. The server should be allowed to ignore requests that have a RESPONSE-ADDRESS that differs from the source address of the Binding Request. Also, this really should be covered in the Security Considerations section. --Paul Hoffman, Director --Cybersecurity Association From srisuresh@yahoo.com Mon, 9 May 2005 19:22:33 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 9 May 2005 19:22:33 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0228CFCD@zrc2hxm0.corp.nortel.com> Message-ID: <20050510022230.44731.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain <... stuff deleted> > > > The common requirements should be addressed in a seperate > > >document, that will make both the TCP and UDP requirements concise > > >and should not be interleaved in this UDP requirements draft. > > > > That's one option. Another is to make the two drafts parallel, > > pointing out where they differ due to specific differences between > > UDP and TCP. > > Agree. That decision (to have two parrallel drafts) was already made [suresh] When was this decision made? This was neither reviewed nor decided upon on the list. On the contrary, we talked explicitly about moving the transport independent stuff to the behave-gen draft in the Minneapolis meeting. The sivakumar-behave-nat-tcp-02 draft had excised all the transport independent generic stuff and kept just the transport specific stuff in the draft. In several of the subsequent e-mail threads where we discussed fragmentations, ICMP errors and other generic stuff, we talked about moving the generic stuff to the behave-gen draft. SO, it is a total surprise for me to hear that a decision was made to have parallel drafts do their own thing with generic stuff in parallel. That could be a disater for the implementers trying to make sense of the BCPs. I sent an e-mail to the list with comments on the previous rev of the behave-udp draft on 03/13/05. My comments from that e-mail still stand for the new rev of the draft. The comments esentially centered around using common terminology and refering transport independent stuff in behave-gen draft. I did not receive any responses from the authors to those comments. I believe, this is a serious and important decision for the working group, not to be taken lightly. I would humbly suggest the working group to consider having a single draft that covers transport independent behave requirements. The newer rev of behave-gen draft (draft-ford-behave-behave-gen-01.txt) covers all the generic stuff that has been discussed on the list and should be available on the IETF archives anytime soon (It was submitted on 05/08). cheers, suresh From fluffy@cisco.com Tue, 10 May 2005 17:28:56 -0700 (PDT) From: Cullen Jennings Date: Tue, 10 May 2005 17:28:56 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <20050510022230.44731.qmail@web40426.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 5/9/05 7:22 PM, "Pyda Srisuresh" wrote: > <... stuff deleted> >>>> The common requirements should be addressed in a seperate >>>> document, that will make both the TCP and UDP requirements concise >>>> and should not be interleaved in this UDP requirements draft. >>> >>> That's one option. Another is to make the two drafts parallel, >>> pointing out where they differ due to specific differences between >>> UDP and TCP. >> >> Agree. That decision (to have two parrallel drafts) was already made > > [suresh] When was this decision made? This was neither reviewed nor decided > upon on the list. This was discussed on the list before the BOF. It was discussed in the BOF. It was discussed by ADs and reviewed by IAB and IESG in forming charter. It has been pointed out to you in email from me. It is shown in the milestone section of the Charter page. If there is anything I can do to make it clear I'm glad to do it. If you would like to have another phone call around the reasoning that went into that decision, I am glad to set up a conference call for you and anyone else that cares to join. I'm not sure what else to do. Cullen with my chair hat on. From baford@mit.edu Wed, 11 May 2005 07:01:52 -0700 (PDT) From: Bryan Ford Date: Wed, 11 May 2005 07:01:52 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: <200505111001.47540.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain I likewise do not remember any such decision being made, or even discussed on the list. If you're referring to some decision made "somewhere up high in the chain of command" at the very formation of this WG, as you seem to suggest, then that decision was presumably made before any actual text was on the table and before any of the technical issues had been explored in depth. I do remember seeing a bit of discussion long ago of whether to have two documents (TCP and UDP) or just one big combined document, but _nobody_ here is suggesting just one big document at this point. The issue here, now, is whether to split the (very considerable) common portions of the TCP and UDP docs out into a common, transport-neutral doc. The issue is not one document versus two, but two documents versus three. At the formation of the WG, it probably wasn't obvious that there would be a lot of material common to TCP and UDP, because that material hadn't been written yet. Now that it's been written, it's become very clear that there is a great deal of common technical requirements, and it would be a structural and readability disaster to duplicate that material across the documents or litter them with ad hoc, ambiguous cross-references. Given this, it seems highly appropriate to revisit the original decisions on document organization that were made at the formation of the WG. Cheers, Bryan On Tuesday 10 May 2005 20:28, Cullen Jennings wrote: > On 5/9/05 7:22 PM, "Pyda Srisuresh" wrote: > > <... stuff deleted> > > > >>>> The common requirements should be addressed in a seperate > >>>> document, that will make both the TCP and UDP requirements concise > >>>> and should not be interleaved in this UDP requirements draft. > >>> > >>> That's one option. Another is to make the two drafts parallel, > >>> pointing out where they differ due to specific differences between > >>> UDP and TCP. > >> > >> Agree. That decision (to have two parrallel drafts) was already made > > > > [suresh] When was this decision made? This was neither reviewed nor > > decided upon on the list. > > This was discussed on the list before the BOF. It was discussed in the BOF. > It was discussed by ADs and reviewed by IAB and IESG in forming charter. It > has been pointed out to you in email from me. It is shown in the milestone > section of the Charter page. > > If there is anything I can do to make it clear I'm glad to do it. If you > would like to have another phone call around the reasoning that went into > that decision, I am glad to set up a conference call for you and anyone > else that cares to join. > > I'm not sure what else to do. > > Cullen with my chair hat on. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From baford@mit.edu Wed, 11 May 2005 08:06:33 -0700 (PDT) From: Bryan Ford Date: Wed, 11 May 2005 08:06:33 -0700 (PDT) Subject: Re: How should NATs reject TCP packets? (was:: Re: [Ietf-behave] Next rev on TCP Behavior) In-Reply-To: <20050509061049.70363.qmail@web40427.mail.yahoo.com> Message-ID: <200505111106.27974.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Joining this discussion a bit late... On Monday 09 May 2005 02:10, Pyda Srisuresh wrote: > --- Saikat Guha wrote: > > On Wed, 2005-04-20 at 18:45 -0700, Pyda Srisuresh wrote: > > > [suresh] I believe, the NAT device may optionally send ICMP Destination > > > unreachable message [...] I would recommend using code 10 (Communicaion > > with > > > destination host administratively prohibited) > > > > I vote for this one. > > 1) ICMP rate limiting prevents the NAT being kept busy. > > 2) Code 10 could be defined with a SHOULD clause to be either hard or > > soft giving the endhost the final say on whether to retry or not. > > > > One reason why the endhost may want to consider it a soft error is if it > > is expecting (or trying) to trigger a TCP Simultaneous Open. One reason > > why the host may want to consider it a hard error is to abort a likely- > > to-fail connection request as soon as possible. Using ICMP Dest Unreach, > > Code 10 gives the host flexibility to do either. > > [suresh] Sounds good. I am potentially OK with this recommendation providing that it ONLY applies to NAT ports that do NOT have an active binding. For NAT ports that DO have an active binding, however, I don't think it NATs should be allowed to respond actively with any "hard error" (whether ICMP or TCP RST), because doing so could make TCP hole punching unreliable and timing-sensitive. The standard scenario: 1. Clients A and B open TCP connections to rendezvous server S. 2. A asks S to help establish a connection to B. 3. S gives A and B each other's public and private endpoints. 4. A happens to get S's message before B does, so it does a TCP open to B. 5. B's NAT rejects A's attempt with an ICMP error (or RST or whatever). 6. A's NAT sees the error response come back and closes its TCP hole to B. 7. Client B finally gets S's message and attempts to connect to A. 8. B's NAT now opens a hole, but A's NAT has closed its hole, so A's NAT rejects B's connection attempt with an ICMP error (or RST or whatever). 9. B's NAT now sees the error and closes its hole. 10. A retries, and if it gets unlucky with the timing the cycle repeats... Senthil's earlier suggestion of using "host unreachable", on the grounds that RFC1122 specifies that it _must_ be treated as soft, would be acceptable if it it was actually consistently implemented that way - but he also mentioned that Linux for one doesn't treat it as soft for TCP SYNs (which is precisely what we're worried about for hole punching purposes). Suresh's suggestion of using code 10, "communication administratively prohibited", worries me even more because not only is it not formally specified at all whether it should be treated as a hard or soft error, but it seems very likely to me to be commonly interpreted as a hard error most of the time. Think about it: if communication with some host is administratively prohibited, then by conventional wisdom it would mean that the _system administrator_ set something up to prohibit that communication, which means that prohibition isn't going to go away until the system administrator "administratively" takes it away. An "administrative prohibition" isn't likely to go away soon on its own - hence it's a hard error, not a soft error. If there was a suitable ICMP response that we knew would always reliably be interpreted as a soft error, then I would go along with that. But as the situation stands, I think that a NAT MUST just silently drop any prohibited incoming packets directed at a bound port. Prohibition of packets directed at bound NAT ports is by nature a temporary prohibition, not an "administrative prohibition" - it's a temporary prohibition that lasts only until the internal client punches a hole by sending traffic to the appropriate external endpoint. Such a prohibition MUST elicit either a soft error from the NAT or no response at all. Since there seems to be no reliably soft response, the only option seems to be no response at all. For non-bound NAT ports, I'm OK with any behavior - silently dropping packets, sending ICMP errors, or even sending back RSTs as a "real" host would, providing that any ICMP errors or RSTs sent back are suitably rate-controlled. Of course, sending back RSTs or ICMP errors for unbound ports but not for bound ports could be interpreted as a security weakness since it enables a port-scanning attacker to find out which NAT ports are bound. Thus, in situations where this information leakage is deemed unacceptable, I think the only acceptable behavior is for the NAT not to respond at all on any of its ports. "A black hole leaks no information." It's unfortunate that that means that prohibited connection attempts from external hosts will have to time out rather than receiving an immediate notification - but then, if all external hosts making "unsolicited" connection attempts are assumed to be attackers by default, then again from a security perspective, it seems best to make them wait and not hand out any information unnecessarily. Also, for what it's worth, I think that this is an issue that applies to UDP just as much as to TCP, with the minor difference that "UDP RST" responses aren't an option because they don't exist. :) Cheers, Bryan From audet@nortel.com Wed, 11 May 2005 10:37:39 -0700 (PDT) From: "Francois Audet" Date: Wed, 11 May 2005 10:37:39 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF023AE974@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Bryan, The first version of the draft Cullen and I presented had both UDP and TCP covered. The group decided in the meeting that it should be split in two. The intent was to not have progress stalled, because there is a sense of urgency for this problem. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Bryan Ford > Sent: Wednesday, May 11, 2005 07:02 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] WG last call: > draft-ietf-behave-nat-udp-01.txt > > > I likewise do not remember any such decision being made, or > even discussed on > the list. If you're referring to some decision made > "somewhere up high in > the chain of command" at the very formation of this WG, as > you seem to > suggest, then that decision was presumably made before any > actual text was on > the table and before any of the technical issues had been > explored in depth. > > I do remember seeing a bit of discussion long ago of whether > to have two > documents (TCP and UDP) or just one big combined document, > but _nobody_ here > is suggesting just one big document at this point. The issue > here, now, is > whether to split the (very considerable) common portions of > the TCP and UDP > docs out into a common, transport-neutral doc. The issue is > not one document > versus two, but two documents versus three. > > At the formation of the WG, it probably wasn't obvious that > there would be a > lot of material common to TCP and UDP, because that material > hadn't been > written yet. Now that it's been written, it's become very > clear that there > is a great deal of common technical requirements, and it would be a > structural and readability disaster to duplicate that > material across the > documents or litter them with ad hoc, ambiguous > cross-references. Given > this, it seems highly appropriate to revisit the original > decisions on > document organization that were made at the formation of the WG. > > Cheers, > Bryan > > On Tuesday 10 May 2005 20:28, Cullen Jennings wrote: > > On 5/9/05 7:22 PM, "Pyda Srisuresh" wrote: > > > <... stuff deleted> > > > > > >>>> The common requirements should be addressed in a seperate > > >>>> document, that will make both the TCP and UDP requirements > > >>>> concise and should not be interleaved in this UDP requirements > > >>>> draft. > > >>> > > >>> That's one option. Another is to make the two drafts parallel, > > >>> pointing out where they differ due to specific > differences between > > >>> UDP and TCP. > > >> > > >> Agree. That decision (to have two parrallel drafts) was already > > >> made > > > > > > [suresh] When was this decision made? This was neither > reviewed nor > > > decided upon on the list. > > > > This was discussed on the list before the BOF. It was > discussed in the > > BOF. It was discussed by ADs and reviewed by IAB and IESG > in forming > > charter. It has been pointed out to you in email from me. > It is shown > > in the milestone section of the Charter page. > > > > If there is anything I can do to make it clear I'm glad to > do it. If > > you would like to have another phone call around the reasoning that > > went into that decision, I am glad to set up a conference > call for you > > and anyone else that cares to join. > > > > I'm not sure what else to do. > > > > Cullen with my chair hat on. > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From baford@mit.edu Wed, 11 May 2005 11:15:56 -0700 (PDT) From: Bryan Ford Date: Wed, 11 May 2005 11:15:56 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF023AE974@zrc2hxm0.corp.nortel.com> Message-ID: <200505111415.53892.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 11 May 2005 13:37, Francois Audet wrote: > Bryan, > > The first version of the draft Cullen and I presented had both UDP and TCP > covered. > > The group decided in the meeting that it should be split in two. The intent > was to not have progress stalled, because there is a sense of urgency for > this > problem. As I already pointed out, I don't have any argument with splitting UDP and TCP - that was done long ago and was certainly the right decision. The issue now is whether to take the common technical portions of both of these two documents and split them out into a third transport-independent document, the need for which only became apparent later, after a lot more work had been done on both the TCP and UDP drafts and major technical redundancies started appearing. That's the issue that's on the table now - nobody is suggesting to merge the TCP and UDP drafts back into one. Bryan > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Bryan Ford > > Sent: Wednesday, May 11, 2005 07:02 > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Ietf-behave] WG last call: > > draft-ietf-behave-nat-udp-01.txt > > > > > > I likewise do not remember any such decision being made, or > > even discussed on > > the list. If you're referring to some decision made > > "somewhere up high in > > the chain of command" at the very formation of this WG, as > > you seem to > > suggest, then that decision was presumably made before any > > actual text was on > > the table and before any of the technical issues had been > > explored in depth. > > > > I do remember seeing a bit of discussion long ago of whether > > to have two > > documents (TCP and UDP) or just one big combined document, > > but _nobody_ here > > is suggesting just one big document at this point. The issue > > here, now, is > > whether to split the (very considerable) common portions of > > the TCP and UDP > > docs out into a common, transport-neutral doc. The issue is > > not one document > > versus two, but two documents versus three. > > > > At the formation of the WG, it probably wasn't obvious that > > there would be a > > lot of material common to TCP and UDP, because that material > > hadn't been > > written yet. Now that it's been written, it's become very > > clear that there > > is a great deal of common technical requirements, and it would be a > > structural and readability disaster to duplicate that > > material across the > > documents or litter them with ad hoc, ambiguous > > cross-references. Given > > this, it seems highly appropriate to revisit the original > > decisions on > > document organization that were made at the formation of the WG. > > > > Cheers, > > Bryan > > > > On Tuesday 10 May 2005 20:28, Cullen Jennings wrote: > > > On 5/9/05 7:22 PM, "Pyda Srisuresh" wrote: > > > > <... stuff deleted> > > > > > > > >>>> The common requirements should be addressed in a seperate > > > >>>> document, that will make both the TCP and UDP requirements > > > >>>> concise and should not be interleaved in this UDP requirements > > > >>>> draft. > > > >>> > > > >>> That's one option. Another is to make the two drafts parallel, > > > >>> pointing out where they differ due to specific > > > > differences between > > > > > >>> UDP and TCP. > > > >> > > > >> Agree. That decision (to have two parrallel drafts) was already > > > >> made > > > > > > > > [suresh] When was this decision made? This was neither > > > > reviewed nor > > > > > > decided upon on the list. > > > > > > This was discussed on the list before the BOF. It was > > > > discussed in the > > > > > BOF. It was discussed by ADs and reviewed by IAB and IESG > > > > in forming > > > > > charter. It has been pointed out to you in email from me. > > > > It is shown > > > > > in the milestone section of the Charter page. > > > > > > If there is anything I can do to make it clear I'm glad to > > > > do it. If > > > > > you would like to have another phone call around the reasoning that > > > went into that decision, I am glad to set up a conference > > > > call for you > > > > > and anyone else that cares to join. > > > > > > I'm not sure what else to do. > > > > > > Cullen with my chair hat on. > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Thu, 12 May 2005 07:10:40 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 12 May 2005 07:10:40 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <20050512141037.83348.qmail@web40424.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Right, I fully agree with Bryan's comments below There was no such decision made in the BOF/WG meetings or on the list or in private e-mails with Cullen, as far as I can recall. Bryan & I had several e-mail exchanges with Francois & Cullen, authors of the behave-udp draft. Bryan and I talked about moving out non-UDP-specific stuff into a generic recommendation draft durign the e-mail discussions and we did a draft on it. Subsequent to that, I even requested the WG chairs to slot in the behave-gen draft for the WG meeting in Minneapolis. Had I known a decisin was made to duplicate all the common material in TCP & UDP drafts or cross reference them in some ad hoc way, I would, no doubt, have raised this on the list (as I am doing now). Here is a request to Jon Peterson, our AD: As Bryan says below, I suggest we step back a bit and revise the WG milestones. At the formation of the WG, while milestones are being created, it probably wasn't obvious that there would be a lot of material common to TCP and UDP. Now, it is. I believe, we need to include the behave-gen draft as one of the early on milestones. Further, I believe, this is an opportune time to identify all the drafts that should be adapted as WG drafts and do an overhaul of the milestones. Thanks. regards, suresh --- Bryan Ford wrote: > I likewise do not remember any such decision being made, or even discussed on > > the list. If you're referring to some decision made "somewhere up high in > the chain of command" at the very formation of this WG, as you seem to > suggest, then that decision was presumably made before any actual text was on > > the table and before any of the technical issues had been explored in depth. > > I do remember seeing a bit of discussion long ago of whether to have two > documents (TCP and UDP) or just one big combined document, but _nobody_ here > is suggesting just one big document at this point. The issue here, now, is > whether to split the (very considerable) common portions of the TCP and UDP > docs out into a common, transport-neutral doc. The issue is not one document > > versus two, but two documents versus three. > > At the formation of the WG, it probably wasn't obvious that there would be a > lot of material common to TCP and UDP, because that material hadn't been > written yet. Now that it's been written, it's become very clear that there > is a great deal of common technical requirements, and it would be a > structural and readability disaster to duplicate that material across the > documents or litter them with ad hoc, ambiguous cross-references. Given > this, it seems highly appropriate to revisit the original decisions on > document organization that were made at the formation of the WG. > > Cheers, > Bryan > > On Tuesday 10 May 2005 20:28, Cullen Jennings wrote: > > On 5/9/05 7:22 PM, "Pyda Srisuresh" wrote: > > > <... stuff deleted> > > > > > >>>> The common requirements should be addressed in a seperate > > >>>> document, that will make both the TCP and UDP requirements concise > > >>>> and should not be interleaved in this UDP requirements draft. > > >>> > > >>> That's one option. Another is to make the two drafts parallel, > > >>> pointing out where they differ due to specific differences between > > >>> UDP and TCP. > > >> > > >> Agree. That decision (to have two parrallel drafts) was already made > > > > > > [suresh] When was this decision made? This was neither reviewed nor > > > decided upon on the list. > > > > This was discussed on the list before the BOF. It was discussed in the BOF. > > It was discussed by ADs and reviewed by IAB and IESG in forming charter. It > > has been pointed out to you in email from me. It is shown in the milestone > > section of the Charter page. > > > > If there is anything I can do to make it clear I'm glad to do it. If you > > would like to have another phone call around the reasoning that went into > > that decision, I am glad to set up a conference call for you and anyone > > else that cares to join. > > > > I'm not sure what else to do. > > > > Cullen with my chair hat on. > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From audet@nortel.com Thu, 12 May 2005 09:34:13 -0700 (PDT) From: "Francois Audet" Date: Thu, 12 May 2005 09:34:13 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF023AF679@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt This is the charter: Goals and Milestones: 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 Seems pretty clear to me. The decision to split the document into smaller more manageable chunks was made in IETF 62. I will also point out that we are actually ON SCHEDULE for the UDP document. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pyda Srisuresh > Sent: Thursday, May 12, 2005 07:11 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] WG last call: > draft-ietf-behave-nat-udp-01.txt > > > Right, I fully agree with Bryan's comments below > > There was no such decision made in the BOF/WG meetings or on > the list or in private e-mails with Cullen, as far as I can > recall. Bryan & I had several e-mail exchanges with Francois > & Cullen, authors of the behave-udp draft. Bryan and I talked > about moving out non-UDP-specific stuff into a generic > recommendation draft durign the e-mail discussions and we did > a draft on it. Subsequent to that, I even requested the WG > chairs to slot in the behave-gen draft for the WG meeting in > Minneapolis. Had I known a decisin was made to duplicate all > the common material in TCP & UDP drafts or cross reference > them in some ad hoc way, I would, no doubt, have raised this > on the list (as I am doing now). > > Here is a request to Jon Peterson, our AD: > > As Bryan says below, I suggest we step back a bit and revise > the WG milestones. At the formation of the WG, while > milestones are being created, it probably wasn't obvious that > there would be a lot of material common to TCP and UDP. > Now, it is. I believe, we need to include the behave-gen > draft as one of the early on milestones. Further, I believe, > this is an opportune time to identify all the drafts that > should be adapted as WG drafts and do an overhaul of the > milestones. Thanks. > > regards, > suresh > > --- Bryan Ford wrote: > > I likewise do not remember any such decision being made, or even > > discussed on > > > > the list. If you're referring to some decision made "somewhere up > > high in > > the chain of command" at the very formation of this WG, as > you seem to > > suggest, then that decision was presumably made before any > actual text was on > > > > the table and before any of the technical issues had been > explored in > > depth. > > > > I do remember seeing a bit of discussion long ago of > whether to have > > two > > documents (TCP and UDP) or just one big combined document, > but _nobody_ here > > is suggesting just one big document at this point. The > issue here, now, is > > whether to split the (very considerable) common portions of > the TCP and UDP > > docs out into a common, transport-neutral doc. The issue > is not one document > > > > versus two, but two documents versus three. > > > > At the formation of the WG, it probably wasn't obvious that there > > would be a > > lot of material common to TCP and UDP, because that > material hadn't been > > written yet. Now that it's been written, it's become very > clear that there > > is a great deal of common technical requirements, and it would be a > > structural and readability disaster to duplicate that > material across the > > documents or litter them with ad hoc, ambiguous > cross-references. Given > > this, it seems highly appropriate to revisit the original > decisions on > > document organization that were made at the formation of the WG. > > > > Cheers, > > Bryan > > > > On Tuesday 10 May 2005 20:28, Cullen Jennings wrote: > > > On 5/9/05 7:22 PM, "Pyda Srisuresh" wrote: > > > > <... stuff deleted> > > > > > > > >>>> The common requirements should be addressed in a seperate > > > >>>> document, that will make both the TCP and UDP requirements > > > >>>> concise and should not be interleaved in this UDP > requirements > > > >>>> draft. > > > >>> > > > >>> That's one option. Another is to make the two drafts > parallel, > > > >>> pointing out where they differ due to specific differences > > > >>> between UDP and TCP. > > > >> > > > >> Agree. That decision (to have two parrallel drafts) > was already > > > >> made > > > > > > > > [suresh] When was this decision made? This was neither reviewed > > > > nor decided upon on the list. > > > > > > This was discussed on the list before the BOF. It was > discussed in > > > the BOF. It was discussed by ADs and reviewed by IAB and IESG in > > > forming charter. It has been pointed out to you in email > from me. It > > > is shown in the milestone section of the Charter page. > > > > > > If there is anything I can do to make it clear I'm glad > to do it. If > > > you would like to have another phone call around the > reasoning that > > > went into that decision, I am glad to set up a conference > call for > > > you and anyone else that cares to join. > > > > > > I'm not sure what else to do. > > > > > > Cullen with my chair hat on. > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From baford@mit.edu Thu, 12 May 2005 11:27:23 -0700 (PDT) From: Bryan Ford Date: Thu, 12 May 2005 11:27:23 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <6.0.3.0.0.20050426011721.055967c0@localhost> Message-ID: <200505121427.18238.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Monday 25 April 2005 20:10, Jiri Kuthan wrote: > This is a BEHAVE Working Group Last Call for comments > on draft-ietf-behave-nat-udp-01. This last call closes > Tuesday May 12, 2005. Please post any final comments you > have on this draft to this list by that date. I think it is premature to have a last call on the UDP draft at this time. In addition to the major issue of document organization already under discussion, there are a substantial number of technical and writing issues with the current UDP draft's content itself. (Some of these issues I already discussed privately with the authors of the UDP draft.) First a brief summary of each, then a more thorough discussion below: *1. The draft's use of the term "session" is unclear in various places, because it doesn't distinguish between sessions as identified by (src IP, src port, dst IP, dst port) on one side of the NAT or the other, or between sessions within a single IP address domain and "logical sessions" that flow across the NAT and hence cross IP address domains. *2. The draft uses the terms "mapping" and "binding" in confusing ways that are inconsistent with their historical meanings, and doesn't sufficiently clarify its use of these terms in the "3. Terminology" section. In particular, the draft uses the term "mapping" loosely in various places, sometimes to mean "binding", sometimes apparently to mean other things, but never properly defines either of these terms as they are used here. *3. The new terminology introduced in section 4.1 and 5.1, with the goal of replacing the historically troublesome "Cone/Symmetric" terminology, is hopelessly cumbersome. If we absolutely must, must, MUST invent new terms (instead of just clarifying the old ones, which I still think would be a better approach), then at least the new terms shouldn't take a whole line to write out! As is, they'll never get used in practice because they're just way too long; most people will in practice just keep using the cone/symmetric terms (imprecisely and confusingly) because they're easy to say and remember. *4. The second "address and port mapping behavior" in section 4.1, "External NAT mapping is endpoint address dependent", is unnecessary: no NAT that I've ever heard of implements this behavior, because it just doesn't make sense at the implementation level. This behavior is also subsumed by the third behavior ("External NAT mapping is endpoint address and port dependent"), and both the second and third behaviors are going to be disallowed in the requirements section at the end anyway. *5. The vague notion of "session" used informally in the draft at present is insufficient to make the text in "6. Hairpinning Behavior" precise or even comprehensible. It is especially important that hairpin translation be defined clearly and precisely here because as far as I know this will be the first "official" IETF document that even mentions it. *6. Section 8, "Deterministic Properties", is currently very opaque and confusing as written, and it is not clear exactly it is trying to say. It probably should be combined into earlier sections. *7. It's very annoying and confusing that you have to read all the way through the document before you ever see even a hint of the actual requirements for NAT behavior that the document is trying to specify: e.g., that "Consistent Endpoint Translation is GOOD" and "Inconsistent Endpoint Translation is BAD". *8. I disagree with REQ-7, which recommends "External filtering is endpoint address dependent" behavior, because endpoint-dependent filtering interferes with applications, and because it amounts to a recommendation to deploy firewall functionality. This WG is about making NATs support applications better and more deterministically, not about suggesting firewall practices. *9. In the discussion of fragmented datagrams, it is not clear whether NATs must support datagram sizes up to the maximum of 64K, or whether it is acceptable for a NAT to have a smaller maximum datagram size - e.g., a little over 8K, the size needed by NFS traffic. Now, the longer discussion of the above issues, along with proposed fixes (including specific replacement text) for at least some of them: --- *1. The draft's use of the term "session" is unclear in various places, because it doesn't distinguish between sessions as identified by (src IP, src port, dst IP, dst port) on one side of the NAT or the other, or between sessions within a single IP address domain and "logical sessions" that flow across the NAT and hence cross IP address domains. Further, the vague notion of "session" used informally in the draft at present is insufficient to make the text in "6. Hairpinning Behavior" precise or even comprehensible. To clarify this, we can start by replacing the following paragraph in "3. Terminology": < This document uses the term "session" as defined in RFC 2663: < "TCP/UDP sessions are uniquely identified by the tuple of (source IP < address, source TCP/UDP ports, target IP address, target TCP/UDP < Port)." ...with the following expanded text, including new subsection numbers: --- 3.1. Sessions This document uses the term "session", as defined in RFC 2663, to refer to a logical flow of traffic between two endpoints within a single IP addressing realm: "TCP/UDP sessions are uniquely identified by the tuple of (source IP address, source TCP/UDP ports, target IP address, target TCP/UDP Port)." The logical direction of a session is the direction in which the session was initiated, not the direction in which particular packets flow along the session. For example, a session initiated by a host on the private network behind a NAT is permanently considered to be an "outgoing session", even though subsequent packets flow in both directions in that session. 3.2. NAT Sessions When a logical flow of traffic crosses a NAT, the session tuple that identifies that logical flow on one side of the NAT is different from the corresponding session tuple that identifies the same logical flow on the other side of the NAT, due to the translation of one or more IP addresses and port numbers. Although ordinary nodes in the IP address realms on either side of the NAT are only aware of one session tuple or the other, the NAT itself must of course be aware of the session tuples for both IP address realms corresponding to this logical flow. This document uses the term "NAT session" to refer to a logical communication session from the NAT's viewpoint. A NAT session is conceptually defined by a tuple of the following form: (origin session, source side, target session, target side) The "origin session" and "target session" components are session tuples as described in section 3.1 above, and "source side" and "target side" are simply the tags "Internal" or "External" describing which "side" of the NAT, and thus which IP address realm, the session belongs to. (A NAT implementation might internally use a physical interface name to represent this "side" tag, for example.) 3.3. Types of NAT Sessions There are three types of NAT sessions of particular relevance to Traditional NAT, which is the only basic variety of NAT within the scope of this document. An "outgoing NAT session" is a NAT session having the form (origin session, Internal, target session, External), and represents a logical communication flow that was originated by a node on the internal ("private") IP address realm and is directed toward a node on the external ("public") IP address realm. In practice outgoing sessions are the most common, because they usually represent client/server communication sessions from a "client" host on the private network directed to a well-known "server" host on the public network, only the latter of which has a global IP address. In an outgoing session, the destination IP address and destination port number is usually unchanged between the origin session and the target session: the NAT only translates the source IP address and, in the case of NAPT, the source port. An "incoming NAT session" is a NAT session having the form (origin session, External, target session, Internal), and represents a logical communication flow that was initiated by a node on the external IP address realm and is targetted at a node on the internal network behind the NAT. Due to the filtering behavior to be described in detail later, incoming sessions are usually only permitted by the NAT on certain specific ports, and only by the explicit configuration of the administrator: a NAT usually rejects incoming sessions by default. Incoming NAT sessions are usually only allowed under specific conditions defined by the administrator, NAT behavior for incoming NAT sessions is largely outside the scope of this document. Finally, a "hairpin NAT session" is a NAT session having the form (origin session, Internal, target session, Internal), and represents a logical communication session whose endpoints are both on the internal network but which nevertheless flows "through" the NAT and requires address translation. Hairpin NAT sessions and hairpin translation, to be described in detail later, arise out of the necessity of supporting reliable application communication across multiple Traditional NATs arranged in increasingly common multi-level hierarchical configurations. In a hairpin session, both source and destination IP addresses and port numbers usually require translation. --- *2. The draft uses the terms "mapping" and "binding" in confusing ways that are inconsistent with their historical meanings, and doesn't sufficiently clarify its use of these terms in the "3. Terminology" section. In particular, the draft uses the term "mapping" loosely in various places, sometimes to mean "binding", sometimes apparently to mean other things, but never properly defines either of these terms as they are used here. To fix this, for starters, take the last two paragraphs in section "3. Terminology": < This document uses the term "address and port mapping" as the < translation between an external address and port and an internal < address and port. Note that this is not the same as an "address < binding" as defined in RFC 2663. < < RFC 3489 [7] defines a terminology for different NAT variations. In < particular, it uses the terms "Full Cone", "Restricted Cone", "Port < Restricted Cone" and "Symmetric" to refer to different variations of < NATs applicable to UDP only. This specification refers to specific < individual NAT behaviors instead of using the Cone/Symmetric < terminology. The relationship between the Cone/Symmetric terminology < and the individual behaviors defined in this specification is < described. ...and expand them a little, again with appropriate subsections. Here is my suggested replacement text: --- 3.4. Address/Port Binding This document adopts the term "address binding" as defined in RFC 3022 for Basic NAT, and uses the term "port binding" as defined in RFC 4008. A NAT device may implement both Address and Port Bindings. An address binding is a persistent association that a Basic NAT maintains between a particular IP address on its internal address realm, and an IP address on the external realm, which the NAT assigns as the internal node's temporary "public identity" for the purpose of communicating across the NAT. A "Port binding" similarly represents a persistent association between an internal (IP address, TCP/UDP port) endpoint and a corresponding external (IP address, TCP/UDP port) endpoint. A Traditional NAT generally establishes a port binding while setting up the first outgoing NAT session originating from a particular internal (IP address, TCP/UDP port) endpoint. Once the binding has been established, the NAT re-uses the same mapping from internal to external endpoint as defined by the port binding, whenever it subsequently establishes a new ougoing NAT session originating from the same internal endpoint (but possibly targetted at a different external endpoint). Not all existing NATs use address or port bindings to determine their IP address and port mapping behavior, however. 3.5. NAT Variations RFC 3489 [7] defines a terminology for several different NAT variations. In particular, it uses the terms "Full Cone", "Restricted Cone", "Port Restricted Cone" and "Symmetric" to refer to different variations of NATs applicable to UDP only. These categories have proven insufficient to represent the full range of existing NAT behaviors, however, so this specification refers to specific NAT behaviors instead of using the Cone/Symmetric terminology. The specific relationship between the Cone/Symmetric terminology and the individual behaviors defined in this specification is fully described later. --- More changes to clarify the use of the terms "mapping" and "binding" will appear below in my suggested changes to later sections in the document. --- *3. The new terminology introduced in section 4.1 and 5.1, with the goal of replacing the historically troublesome "Cone/Symmetric" terminology, is hopelessly cumbersome. If we absolutely must, must, MUST invent new terms (instead of just clarifying the old ones, which I still think would be a better approach), then at least the new terms shouldn't take a whole line to write out! As is, they'll never get used in practice because they're just way too long; most people will in practice just keep using the cone/symmetric terms (imprecisely and confusingly) because they're easy to remember. *4. The second "address and port mapping behavior" in section 4.1, "External NAT mapping is endpoint address dependent", is completely unnecessary: no NAT that I've ever heard of implements this behavior because it just doesn't make sense at the implementation level, this behavior is subsumed by the third behavior ("External NAT mapping is endpoint address and port dependent"), and both the second and third behaviors are going to be disallowed in the requirements section at the end anyway. For issue (*3) above, consider: to say that a NAT is a "Full Cone NAT" in the new terminology, you have to write: "The NAT's address and port mapping behavior is 'External NAT mapping is endpoint independent', and the NAT's filtering behavior is 'External filtering is endpoint independent'". What took 3 words to say in the old terminology takes 25 words now! I've started to see some acronyms appearing on the list that apparently refer to these behaviors (e.g., "NB=I, EF=I"), but these only cause further confusion because the shorter acronyms are non-obvious and aren't even mentioned in the draft! Clarifying the historically troublesome terminology is a worthwhile goal, but the new terminology, as currently proposed, has no chance of getting widely adopted in practice simply because it's way too cumbersome to say, write, or explain. Here is my proposal: * Instead of saying that "a NAT's address and port mapping behavior is 'External NAT mapping is endpoint independent'" (14 words), just say that the NAT has "Consistent Endpoint Translation" (3 words). In other words, when the NAT translates the private source endpoint of a new session crossing a NAT into a corresponding public port, it ALWAYS translates that private source endpoint to the same public source endpoint - i.e., "consistently". * Similarly, instead of saying that "a NAT's address and port mapping behavior is 'External NAT mapping is endpoint address and port dependent'", just say that the NAT has "Inconsistent Endpoint Translation". A NAT has Inconsistent Endpoint Translation if it EVER translates source endpoints inconsistently under ANY conditions. That is, a NAT that "usually" behaves like a Cone NAT but "occasionally" switches to symmetric behavior for certain translations, because of contention for a particular NAT port for example, will still have "Inconsistent Endpoint Translation". * Drop the "External NAT mapping is endpoint address dependent" behavior entirely, because it is logically subsumed by "Inconsistent Endpoint Translation", no NAT I know of implements this particular intermediate behavior, and it is just another variation of deprecated behavior that we're going to disallow in the requirements section anyway. * Instead of saying that a NAT's filtering behavior is "External filtering is endpoint independent", just say that the NAT has "Endpoint-Independent Filtering". * Similarly, Instead of "External filtering is endpoint address dependent", just say the NAT has "Address-Specific Filtering" * Finally, instead of "External filtering is endpoint address and port dependent", just say the NAT has "Endpoint-Specific Filtering". Note that I suggest saying "Endpoint-Specific Filtering" here rather than "Endpoint-Dependent Filtering" because the latter sounds like it would subsume "Address-Dependent Filtering". A filtering behavior that "depends on" the external address indeed also by logical extension "depends on" the external endpoint, even if it doesn't really depend on the port part of the endpoint. Saying that the filtering is "Endpoint-Specific", in contrast, I think makes it more clear that the filtering is really specific to _both_ the address and port number components of the endpoint, without actually having to say "endpoint address and port specific" or something clumsy like that. Now we can use the proposed terminology to clarify the historical Cone/Symmetric terminology very easily and concisely: Symmetric NAT := Inconsistent Endpoint Translation. Cone Nat := Consistent Endpoint Translation. Full Cone Nat := Consistent Endpoint Translation with Endpoint-Independent Filtering. [Address-]Restricted Cone Nat := Consistent Endpoint Translation with Address-Specific Filtering Port-Restricted Cone Nat := Consistent Endpoint Translation with Endpoint-Specific Filtering With the above proposal in mind, here is my suggested rewrite for section 4.1, which both fixes the terminology and also helps address the earlier issues *1 and *2 above: --- 4.1 Address and Port Mapping When an internal endpoint initiates a new UDP session targetted at an endpoint on the external network, the NAT establishes a new outgoing NAT session so that subsequent response packets from the external endpoint can be received by the NAT, translated, and forwarded back to the original internal endpoint. To form this new outgoing NAT session, the NAT uses the source and destination endpoints from the original packet that initiated the session, in order to define the internal "origin session" component of the NAT session. The NAT must then compute a corresponding "target session" component in order to define the corresponding UDP session as it will appear on the external network. For Traditional NAT, the destination address and port number is not translated in outgoing NAT sessions, so the NAT merely needs to assign an external source IP address and UDP port to form the new NAT session. If the NAT receives a packet from the internal network with a given (internal source IP, internal source port, external target IP, external target port) session tuple, for example, the NAT must "map" the internal source endpoint to a corresponding external source endpoint that is valid in the external IP address realm, in order to form the new outgoing NAT session. We refer to the way the NAT maps an internal source endpoint to the corresponding external source endpoint, while establishing a new outgoing NAT session, as the NAT's address and port mapping behavior. For many applications, it is important to distinguish the behavior of the NAT when applications establish multiple simultaneous outgoing NAT sessions from a single internal source endpoint to distinct external target endpoints. For example, suppose a node X on the internal network has already initiated an outgoing NAT session from internal source endpoint X:x (address:port), to a particular external destination endpoint Y1:y1. The NAT has mapped the internal source endpoint, X:x, to an external source endpoint X1':x1' in the external IP address realm, to form the full NAT session tuple. Now suppose node X initiates a new session from the same internal source endpoint, X:x, to a new external destination endpoint Y2:y2, and in response the NAT maps the internal source endpoint X:x to an external source endpoint X2':x2' to form the NAT session tuple to translate this new session. The relationship between X1':x1' and X2':x2' for various combinations of the relationship between Y1:y1 and Y2:y2 is critical for describing the NAT behavior. This arrangement is illustrated in the following diagram: The following address and port mapping behavior are defined: Consistent Endpoint Translation: When the NAT establishes the first outgoing NAT session from an internal IP address and port X:x to any external target endpoint, choosing some corresponding external source IP address and port X1':x1' in the process, the NAT also establishes a persistent port binding between the internal endpoint X:x and X1':x1' in the process, and uses that port binding to determine the external source endpoint for any subsequent outgoing NAT sessions that originate from the same internal source endpoint X:x. Specifically, X1':x1' equals X2':x2' for all values of Y2:y2. In terms of the NAT terminology in RFC 3489, this mapping behavior constitutes "Cone NAT", where the sub-type (Full Cone versus Restricted versus Port-Restructed Cone) is based on the filtering behavior to be discussed later. As a consequence of establishing a port binding from X:x to X1':x1' in response to the first outgoing session originating from X:x, the NAT also effectively "allocates" the external source endpoint X1':x1' exclusively to the use of this port binding, so that no other session originating from a different internal source endpoint may be translated so as to use the same external source endpoint X1':x1', while this port binding is active. This "exclusive port allocation" behavior is crucial for a NAT to have consistent endpoint translation, because otherwise the NAT could "paint itself into a corner" and make it impossible to translate future sessions involving the original source endpoint X:x correctly. For example, suppose the NAT has established a NAT session that translates the internal session (X:x,Y1:y1) to an external session (X1':x1',Y1:y1). Suppose further that it has incorrectly established a second NAT session translating an unrelated internal session (X2:x2,Y2:y2) to the external session (X1':x1',Y2:y2), re-using the external source endpoint X1':x1' between these two unrelated sessions. If node X now initiates a new outgoing session from X:x to Y2:y2, then to preserve the Consistent Endpoint Translation property the NAT would have to translate the new internal session (X:x,Y2:y2) to the external session tuple (X1':x1',Y2:y2) - but this external session tuple is the same as the external session tuple the NAT has already assigned to the prior unrelated session originating from X2:x2, and the two sessions would hence be indistinguishable on the external network. In effect, therefore, a NAT MUST exclusively allocate an external source port to a single internal source port for the duration of the corresponding port binding, in order to have Consistent Endpoint Translation. Inconsistent Endpoint Translation: When setting up a new outgoing NAT session from an internal source endpoint X:x to an external target endpoint Y2:y2, the NAT may map the internal source endpoint X:x to any external source endpoint X2':x2' of its choosing, regardless of how it has previously mapped any existing sessions originating from the same internal source endpoint X:x. Specifically, X1':x1' equals X2':x2' only if Y2:y2 equals Y1:y1. Some existing NATs usually but do not always translate source endpoints consistently under all operating conditions; such NATs are still classified as having Inconsistent Endpoint Translation. From an RFC 3489 NAT perspective, but not necessarily a filtering perspective, this behavior constitutes "Symmetric NAT". It is important to note that ... --- ...and the rest of section 4.1 and section 4.2 look basically fine to me. Section 4.3 and 4.4, however, currently use the term "mapping" to refer to "NAT sessions" in some cases and to refer to "port bindings" in other cases; this needs to be clarified. My proposal is to reverse the order of the two sections and differentiate explicitly between "session timers" and "binding timers" while referring to both generally as the NAT's "inactivity timers": --- 4.3 Inactivity Timer Scope: Because the UDP protocol does not provide a standard way to determine exactly when a UDP session crossing the NAT is no longer in use, NATs must implement inactivity timers so they can eventually eliminate NAT sesssions and port bindings that appear to be idle. Different NAT implementations vary widely, however, not only in the values of these timeouts but also in their scope and how they are refreshed. Some NATs associate inactivity timers with individual NAT sessions. Such a NAT is said to have an inactivity timer scope of "per-session". In this case, we define the NAT's per-session inactivity timeout to be the amount of time the NAT will keep a particular NAT session active without packets traversing the NAT on that specific session. Other NATs associate inactivity timers instead with address or port bindings. Such a NAT is said to have an inactivity timer scope of "per-binding". In this case, we define the NAT's per-binding timeout to be the amount of time the NAT will keep a particular binding active, along with all of the NAT sessions associated with that binding, without the NAT observing packets on any of the sessions associated with that binding. For example, suppose an internal node X has established two NAT sessions from the same internal source endpoint X:x to distinct external target endpoints Y1:y1 and Y2:y2, and the NAT has established a port binding from the internal endpoint X:x to an external source endpoint X':x' for these two sessions, as described earlier. The NAT's binding timeout ensures that the port binding from internal endpoint X:x to external endpoint X':x' remains active, along with both of the existing NAT sessions using this binding (the one between X:x and Y1:y1 and the other between X:x and Y2:y2), for as long as the NAT observes traffic on either of these sessions. 4.3 Inactivity Timer Refresh Direction UDP inactivity timeout implementations also vary based on the way the inactivity timer is refreshed to keep NAT sessions or bindings alive. Some NATs keep a session or binding active (i.e., refresh the timer value) whenever a packet passes from the internal side of the NAT to the external side of the NAT, using that session or binding. This is referred to as having a NAT Outbound refresh behavior of "True". Some NATs keep a session or binding active when a packet passes from the external side of the NAT to the internal side of the NAT. This is referred to as having a NAT Inbound Refresh Behavior of "True". Some NATs keep a session or binding active when a packet traverses the NAT in either direction on that session or binding, in which case both properties are "True". --- *5. The vague notion of "session" used informally in the draft at present is insufficient to make the text in "6. Hairpinning Behavior" precise or even comprehensible. It is especially important that hairpin translation be defined clearly and precisely here because as far as I know this will be the first "official" IETF document that even mentions it. I haven't yet written specific text to fix the problem in this section, but suitable text can be found in section 2.6 of draft-ford-behave-gen-01.txt. Of course, as per the ongoing document organization debate, I think most of this text should stay in BEHAVE-GEN and that the UDP draft should just refer to that - but if that doesn't happen, then a decent definition and explanation of hairpin translation needs to be included in behave-udp. --- *6. Section 8, "Deterministic Properties", is currently very opaque and confusing as written, and it is not clear exactly it is trying to say. This section is apparently talking mostly about the address and port mapping behaviors way before in section 4.1, and to a lesser degree the filtering behavior in 5.1, but in that case why not just discuss these nondeterminism issues earlier in the appropriate sections rather than spreading them throughout the document? I think that my proposed replacement text for 4.1 already provides a good start for that, by explicitly saying that any NAT that EVER translates its endpoints inconsistently under ANY conditions is to be considered to have Inconsistent Endpoint Translation behavior, and by discussing the "port allocation" issue in-line. The same could be done for endpoint filtering behavior, if that's actually important. At any rate, it seems very unnecessary to introduce yet another new "behavior" described as "nondeterministic NAT behavior", with its own top-level section in the document, just in order to complain that some NATs seem to get very close to Consistent Endpoint Translation without quite getting there. Just make sure it's clear in the text that a NAT really, really has to go "all the way" and get it right, and that "Mostly/Usually Consistent Endpoint Translation Under Favorable Network Conditions" is still "Inconsistent Endpoint Translation" and hence disallowed. --- *7. It's very annoying and confusing that you have to read all the way through the document before you ever see even a hint of the actual requirements for NAT behavior that the document is trying to specify: e.g., that "Consistent Endpoint Translation is GOOD" and "Inconsistent Endpoint Translation is BAD". I like having a summary of the requirements all in one place, but those requirements also need to be stated in-line with the text that describes what they mean. Just duplicating the text of the REQ-## paragraphs verbatim in the appropriate places is sufficient. Including the requirements in-line would also enable the "Requirement Discussion" paragraphs in section 12.1 to be moved upward to their natural locations, where the respective issues are actually introduced and discussed in the first place. As it is, we have long discussion with no requirements, then short requirements, then short discussion of requirements - very awkward and confusing. --- *8. I disagree with REQ-7, which recommends "External filtering is endpoint address dependent" behavior, because endpoint-dependent filtering interferes with applications, and because it amounts to a recommendation to deploy firewall functionality. This WG is about making NATs support applications better and more deterministically, not about suggesting firewall practices. (I don't even remember hearing any discussion about this recommendation on the list so far, or what the rationale was for the current recommendation.) Once a NAT has implemented Consistent Endpoint Translation (i.e., "Cone NAT"), as we require, the filtering policy the NAT implements on top of this is purely a tradeoff between perceived security benefits and interference with applications. Endpoint-Independent Filtering brings a strong benefit to applications, whereas the security argument for Address- or Endpoint-Specific Filtering is actually rather weak, as discussed below. * Application considerations: Endpoint-Independent Filtering ("Full Cone NAT") is fundamentally more application-friendly than Address-Specific or Endpoint-Specific Filtering ("[Port-]Restricted Cone NAT"), because the former allows the application to have a public "rendezvous point" (albeit a temporary one assigned by the NAT) at which it can be contacted proactively by arbitrary external hosts, whereas the more restrictive filtering behaviors do not. An application behind a NAT with restrictive filtering behavior is forced always to depend on other public "rendezvous server" hosts in order to be able to accept P2P-style connections of any kind initiated from other endpoints. An application residing behind a Full Cone NAT, in contrast, can actually _be_ a public rendezvous server, and even help set up P2P-style connections among other less fortunate hosts, once it has discovered what its NAT-assigned public IP address and port number are. * Security considerations: Restrictive filtering ostensibly has the benefit of protecting applications on internal hosts from traffic it is not expecting, i.e., from traffic from previously unknown external hosts or endpoints. This behavior can only possibly benefit the application if the application only ever initiates outgoing sessions from its internal port, and is obviously a curse if the application ever wants to accept incoming sessions from external hosts. The NAT has no way of knowing which is the case. But suppose the application is one that only initiates outgoing connections (i.e., a "traditional client/server app"), and thus might "potentially" benefit from a NAT's restrictive filtering behavior. Consider TCP and UDP separately: ** TCP: When a client/server app makes an outgoing TCP connection, it typically does a "connect()" call to the host OS's sockets API without bothering to bind() the socket, and the OS's TCP stack allocates a local TCP port exclusively for the use of that connection. Any TCP packets the host OS subsequently received on that port from endpoints other than the one it connect()ed to will be summarily rejected with TCP RSTs by the host OS, and the application never even sees any hint that they ever arrived. Even if the application does a bind() before its connect() in order to use a specific source port (e.g., a <1024 "privileged" port), it still almost always obtains exclusive use of that port. An application indeed has to work really bloody hard to set things up so that it can accept incoming TCP connections on the same port it is using for an outgoing connection, using SO_REUSEADDR and multiple sockets. No traditional client/server application is going to go to all this effort just in order to create a security hole. :) In other words, for TCP, restrictive filtering in practice provides absolutely zero protection from the _application_: the only entity that the restrictive filtering even affects is the host OS's protocol stack. Restrictive filtering might for example benefit a host OS with a TCP stack that is so broken that it fails to check the source IP address and port number on incoming TCP packets at all, but if the host OS is _that_ broken then it undoubtably has many other problems that the NAT can't possibly guard against. ** UDP: When a client/server UDP app uses a UDP port for communication with just one remote host, for convenience it typically does a connect() to the appropriate remote UDP endpoint, so that it can just send messages with send() or write() without having to specify a destination address for each datagram, and so that it can receive messages with read() or recv() without having to check the source address and port number in each message received. In this case, the host OS effectively provides the external endpoint filtering functionality as for TCP, and any restrictive filtering implemented by the NAT again provides no security benefit at all to the application. A UDP application that uses a single UDP port for communication with multiple remote hosts, in contrast, must generally check the source IP addresses and port numbers in the datagrams it receives just in order to distinguish between the multiple communication sessions it is involved in, and hence it will inherently provide its own external endpoint filtering. It's conceivable that some abysmally buggy UDP applications might benefit from the NAT's external filtering - e.g., a UDP application that only talks to one external endpoint but doesn't use connect() and doesn't check the source endpoint on incoming datagrams - but an application that is so seriously broken probably has many other security vulnerabilities that can be exploited despite the NAT's external filtering behavior, e.g., by finding out or guessing the public server the application is talking to (which is easy in many cases such as commercial games or services where there are only a few well-known servers) and sending packets with spoofed source IP address and UDP port numbers. Besides, many, perhaps the majority, of UDP applications use UDP _because_ they need P2P-style communication, and so external filtering by the NAT provides no practical security benefit and only causes interference with the application. In summary, restrictive filtering in the NAT interferes with applications substantially and provides very little or no real security benefit in practice, considering the way communication works using standard sockets APIs. As such, especially considering the purpose of this WG is to increase the predictability and compatibility of NATs with applications and not to specify standards for firewall functionality, it seems highly inappropriate for this WG's documents to recommend firewall functionality that interferes with applications while providing dubious security benefits. On the contrary, I think this WG should recommend (although not necessarily mandate) that NATs provide Endpoint-Independent Filtering by default. NAT vendors or system administrators that are particularly paranoid about security and perceive the security benefits to be worth the interference it causes with applications can still enable more restrictive filtering policies, but that's a firewall deployment issue, not a NAT functionality issue. We need to steer clear from recommending firewall functionality. With that, I propose the following text for REQ-7: REQ-7: NATs MUST implement Endpoint-Independent Filtering in their default configuration. NATs SHOULD be configurable to support Address-Specific Filtering or Endpoint-Specific Filtering at the option of the system administrator. --- *9. In the discussion of fragmented datagrams, it is not clear whether NATs must support datagram sizes up to the maximum of 64K, or whether it is acceptable for a NAT to have a smaller maximum datagram size - e.g., a little over 8K, the size needed by NFS traffic. Unless there are serious screams from NAT implementors here, I would say that NATs MUST support full-size (up to 64K) fragmented datagrams. [End of overly long blurb] From baford@mit.edu Thu, 12 May 2005 12:20:49 -0700 (PDT) From: Bryan Ford Date: Thu, 12 May 2005 12:20:49 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF023AF679@zrc2hxm0.corp.nortel.com> Message-ID: <200505121520.44154.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 12 May 2005 12:34, Francois Audet wrote: > This is the charter: > [...] > Seems pretty clear to me. > > The decision to split the document into smaller more manageable chunks was > made in IETF 62. Copy-and-pasting the original milestone list from the BEHAVE group home page and repeatedly pointing back to well-known early WG decisions that nobody is disputing does absolutely nothing to address the issues actually being discussed. Nobody is disputing the original decision "to split the document into smaller more manageable chunks"; we are proposing to take this decision further and split the common parts of the UDP and TCP documents into a separate "more manageable chunk". Nobody is contesting what the original milestones _were_; we are talking about what they _should be_ now that substantial work has been done and the interrelationships between the documents to be produced has become clearer. > I will also point out that we are actually ON SCHEDULE for the UDP > document. What's the huge hurry? Is the publication of the UDP draft so urgent that it can't wait another month or two in order to avoid serious inconsistencies and duplication of content between it and the other forthcoming documents this WG produces? The world has waited for many years already for the IETF to produce documents on NAT; is this task now suddenly so urgent that the world can't even wait a couple more months in order to ensure that the NAT documents the IETF produces are actually solid, well-organized, and consistent with each other? Besides, the proposed BEHAVE-GEN draft is already written and has been under evaluation and discussion for some time already too. There's no reason to assume that linking BEHAVE-UDP with BEHAVE-GEN will cause all that much delay: BEHAVE-GEN, after all, mostly just contains stuff that's in BEHAVE-UDP but is needed for BEHAVE-TCP too. If you have objections to specific content in BEHAVE-GEN, then let's fix it and get both drafts published as quickly as possible. Cheers, Bryan > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Pyda Srisuresh > > Sent: Thursday, May 12, 2005 07:11 > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Ietf-behave] WG last call: > > draft-ietf-behave-nat-udp-01.txt > > > > > > Right, I fully agree with Bryan's comments below > > > > There was no such decision made in the BOF/WG meetings or on > > the list or in private e-mails with Cullen, as far as I can > > recall. Bryan & I had several e-mail exchanges with Francois > > & Cullen, authors of the behave-udp draft. Bryan and I talked > > about moving out non-UDP-specific stuff into a generic > > recommendation draft durign the e-mail discussions and we did > > a draft on it. Subsequent to that, I even requested the WG > > chairs to slot in the behave-gen draft for the WG meeting in > > Minneapolis. Had I known a decisin was made to duplicate all > > the common material in TCP & UDP drafts or cross reference > > them in some ad hoc way, I would, no doubt, have raised this > > on the list (as I am doing now). > > > > Here is a request to Jon Peterson, our AD: > > > > As Bryan says below, I suggest we step back a bit and revise > > the WG milestones. At the formation of the WG, while > > milestones are being created, it probably wasn't obvious that > > there would be a lot of material common to TCP and UDP. > > Now, it is. I believe, we need to include the behave-gen > > draft as one of the early on milestones. Further, I believe, > > this is an opportune time to identify all the drafts that > > should be adapted as WG drafts and do an overhaul of the > > milestones. Thanks. > > > > regards, > > suresh > > > > --- Bryan Ford wrote: > > > I likewise do not remember any such decision being made, or even > > > discussed on > > > > > > the list. If you're referring to some decision made "somewhere up > > > high in > > > the chain of command" at the very formation of this WG, as > > > > you seem to > > > > > suggest, then that decision was presumably made before any > > > > actual text was on > > > > > the table and before any of the technical issues had been > > > > explored in > > > > > depth. > > > > > > I do remember seeing a bit of discussion long ago of > > > > whether to have > > > > > two > > > documents (TCP and UDP) or just one big combined document, > > > > but _nobody_ here > > > > > is suggesting just one big document at this point. The > > > > issue here, now, is > > > > > whether to split the (very considerable) common portions of > > > > the TCP and UDP > > > > > docs out into a common, transport-neutral doc. The issue > > > > is not one document > > > > > versus two, but two documents versus three. > > > > > > At the formation of the WG, it probably wasn't obvious that there > > > would be a > > > lot of material common to TCP and UDP, because that > > > > material hadn't been > > > > > written yet. Now that it's been written, it's become very > > > > clear that there > > > > > is a great deal of common technical requirements, and it would be a > > > structural and readability disaster to duplicate that > > > > material across the > > > > > documents or litter them with ad hoc, ambiguous > > > > cross-references. Given > > > > > this, it seems highly appropriate to revisit the original > > > > decisions on > > > > > document organization that were made at the formation of the WG. > > > > > > Cheers, > > > Bryan > > > > > > On Tuesday 10 May 2005 20:28, Cullen Jennings wrote: > > > > On 5/9/05 7:22 PM, "Pyda Srisuresh" wrote: > > > > > <... stuff deleted> > > > > > > > > > >>>> The common requirements should be addressed in a seperate > > > > >>>> document, that will make both the TCP and UDP requirements > > > > >>>> concise and should not be interleaved in this UDP > > > > requirements > > > > > > >>>> draft. > > > > >>> > > > > >>> That's one option. Another is to make the two drafts > > > > parallel, > > > > > > >>> pointing out where they differ due to specific differences > > > > >>> between UDP and TCP. > > > > >> > > > > >> Agree. That decision (to have two parrallel drafts) > > > > was already > > > > > > >> made > > > > > > > > > > [suresh] When was this decision made? This was neither reviewed > > > > > nor decided upon on the list. > > > > > > > > This was discussed on the list before the BOF. It was > > > > discussed in > > > > > > the BOF. It was discussed by ADs and reviewed by IAB and IESG in > > > > forming charter. It has been pointed out to you in email > > > > from me. It > > > > > > is shown in the milestone section of the Charter page. > > > > > > > > If there is anything I can do to make it clear I'm glad > > > > to do it. If > > > > > > you would like to have another phone call around the > > > > reasoning that > > > > > > went into that decision, I am glad to set up a conference > > > > call for > > > > > > you and anyone else that cares to join. > > > > > > > > I'm not sure what else to do. > > > > > > > > Cullen with my chair hat on. > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Thu, 12 May 2005 12:38:15 -0700 (PDT) From: "Francois Audet" Date: Thu, 12 May 2005 12:38:15 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF02421D1E@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt I have strong objections to reverse the decision to go ahead with separate documents. > -----Original Message----- > From: Bryan Ford [mailto:baford@xxxxxxx] > Sent: Thursday, May 12, 2005 12:21 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Cc: Audet, Francois [SC100:9T51:EXCH]; 'Pyda Srisuresh' > Subject: Re: [Ietf-behave] WG last call: > draft-ietf-behave-nat-udp-01.txt > > > On Thursday 12 May 2005 12:34, Francois Audet wrote: > > This is the charter: > > [...] > > Seems pretty clear to me. > > > > The decision to split the document into smaller more > manageable chunks > > was made in IETF 62. > > Copy-and-pasting the original milestone list from the BEHAVE > group home page > and repeatedly pointing back to well-known early WG decisions > that nobody is > disputing does absolutely nothing to address the issues > actually being > discussed. Nobody is disputing the original decision "to > split the document > into smaller more manageable chunks"; we are proposing to > take this decision > further and split the common parts of the UDP and TCP > documents into a > separate "more manageable chunk". Nobody is contesting what > the original > milestones _were_; we are talking about what they _should be_ > now that > substantial work has been done and the interrelationships between the > documents to be produced has become clearer. > > > I will also point out that we are actually ON SCHEDULE for the UDP > > document. > > What's the huge hurry? Is the publication of the UDP draft > so urgent that it > can't wait another month or two in order to avoid serious > inconsistencies and > duplication of content between it and the other forthcoming > documents this WG > produces? The world has waited for many years already for > the IETF to > produce documents on NAT; is this task now suddenly so urgent > that the world > can't even wait a couple more months in order to ensure that the NAT > documents the IETF produces are actually solid, well-organized, and > consistent with each other? > > Besides, the proposed BEHAVE-GEN draft is already written and > has been under > evaluation and discussion for some time already too. There's > no reason to > assume that linking BEHAVE-UDP with BEHAVE-GEN will cause all > that much > delay: BEHAVE-GEN, after all, mostly just contains stuff > that's in BEHAVE-UDP > but is needed for BEHAVE-TCP too. If you have objections to > specific content > in BEHAVE-GEN, then let's fix it and get both drafts > published as quickly as > possible. > > Cheers, > Bryan > > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > Behalf Of Pyda > > > Srisuresh > > > Sent: Thursday, May 12, 2005 07:11 > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: Re: [Ietf-behave] WG last call: > > > draft-ietf-behave-nat-udp-01.txt > > > > > > > > > Right, I fully agree with Bryan's comments below > > > > > > There was no such decision made in the BOF/WG meetings or on the > > > list or in private e-mails with Cullen, as far as I can recall. > > > Bryan & I had several e-mail exchanges with Francois & Cullen, > > > authors of the behave-udp draft. Bryan and I talked about > moving out > > > non-UDP-specific stuff into a generic recommendation draft durign > > > the e-mail discussions and we did a draft on it. > Subsequent to that, > > > I even requested the WG chairs to slot in the behave-gen > draft for > > > the WG meeting in Minneapolis. Had I known a decisin was made to > > > duplicate all the common material in TCP & UDP drafts or cross > > > reference them in some ad hoc way, I would, no doubt, have raised > > > this on the list (as I am doing now). > > > > > > Here is a request to Jon Peterson, our AD: > > > > > > As Bryan says below, I suggest we step back a bit and > revise the WG > > > milestones. At the formation of the WG, while milestones > are being > > > created, it probably wasn't obvious that there would be a lot of > > > material common to TCP and UDP. Now, it is. I believe, we need to > > > include the behave-gen draft as one of the early on milestones. > > > Further, I believe, this is an opportune time to identify all the > > > drafts that should be adapted as WG drafts and do an > overhaul of the > > > milestones. Thanks. > > > > > > regards, > > > suresh > > > > > > --- Bryan Ford wrote: > > > > I likewise do not remember any such decision being > made, or even > > > > discussed on > > > > > > > > the list. If you're referring to some decision made > "somewhere up > > > > high in the chain of command" at the very formation of > this WG, as > > > > > > you seem to > > > > > > > suggest, then that decision was presumably made before any > > > > > > actual text was on > > > > > > > the table and before any of the technical issues had been > > > > > > explored in > > > > > > > depth. > > > > > > > > I do remember seeing a bit of discussion long ago of > > > > > > whether to have > > > > > > > two > > > > documents (TCP and UDP) or just one big combined document, > > > > > > but _nobody_ here > > > > > > > is suggesting just one big document at this point. The > > > > > > issue here, now, is > > > > > > > whether to split the (very considerable) common portions of > > > > > > the TCP and UDP > > > > > > > docs out into a common, transport-neutral doc. The issue > > > > > > is not one document > > > > > > > versus two, but two documents versus three. > > > > > > > > At the formation of the WG, it probably wasn't obvious > that there > > > > would be a lot of material common to TCP and UDP, because that > > > > > > material hadn't been > > > > > > > written yet. Now that it's been written, it's become very > > > > > > clear that there > > > > > > > is a great deal of common technical requirements, and > it would be > > > > a structural and readability disaster to duplicate that > > > > > > material across the > > > > > > > documents or litter them with ad hoc, ambiguous > > > > > > cross-references. Given > > > > > > > this, it seems highly appropriate to revisit the original > > > > > > decisions on > > > > > > > document organization that were made at the formation of the WG. > > > > > > > > Cheers, > > > > Bryan > > > > > > > > On Tuesday 10 May 2005 20:28, Cullen Jennings wrote: > > > > > On 5/9/05 7:22 PM, "Pyda Srisuresh" > wrote: > > > > > > <... stuff deleted> > > > > > > > > > > > >>>> The common requirements should be addressed in > a seperate > > > > > >>>> document, that will make both the TCP and UDP > requirements > > > > > >>>> concise and should not be interleaved in this UDP > > > > > > requirements > > > > > > > > >>>> draft. > > > > > >>> > > > > > >>> That's one option. Another is to make the two drafts > > > > > > parallel, > > > > > > > > >>> pointing out where they differ due to specific > differences > > > > > >>> between UDP and TCP. > > > > > >> > > > > > >> Agree. That decision (to have two parrallel drafts) > > > > > > was already > > > > > > > > >> made > > > > > > > > > > > > [suresh] When was this decision made? This was neither > > > > > > reviewed nor decided upon on the list. > > > > > > > > > > This was discussed on the list before the BOF. It was > > > > > > discussed in > > > > > > > > the BOF. It was discussed by ADs and reviewed by IAB > and IESG in > > > > > forming charter. It has been pointed out to you in email > > > > > > from me. It > > > > > > > > is shown in the milestone section of the Charter page. > > > > > > > > > > If there is anything I can do to make it clear I'm glad > > > > > > to do it. If > > > > > > > > you would like to have another phone call around the > > > > > > reasoning that > > > > > > > > went into that decision, I am glad to set up a conference > > > > > > call for > > > > > > > > you and anyone else that cares to join. > > > > > > > > > > I'm not sure what else to do. > > > > > > > > > > Cullen with my chair hat on. > > > > > > > > > > _______________________________________________ > > > > > Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From baford@mit.edu Thu, 12 May 2005 13:05:52 -0700 (PDT) From: Bryan Ford Date: Thu, 12 May 2005 13:05:52 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02421D1E@zrc2hxm0.corp.nortel.com> Message-ID: <200505121605.50210.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 12 May 2005 15:37, Francois Audet wrote: > I have strong objections to reverse the decision to go > ahead with separate documents. Are you even LISTENING??? Nobody is proposing to reverse the decision to separate the TCP and UDP documents. Nobody is proposing to "reverse" any earlier decision at all. We're basically just proposing to generalize the existing Nov 05 "ICMP" milestone into a "transport-independent behavior" milestone, and bring it forward in the schedule to go alongside the UDP draft. For example, here's one way we might do it: -May 05 Produce a BCP that defines unicast UDP behavioral requirements +Jun 05 Produce a BCP that defines unicast UDP behavioral requirements +Jun 05 Produce a BCP that defines transport protocol-independent behavioral requirements 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 Note that I'm not proposing any change to the TCP milestone, and in particular am not proposing that the TCP and UDP documents be linked. So far you have offered no argument whatsoever as to why a minor change of the above form to the WG milestones, accompanied with a simple but much-needed document reorganization, would be a bad idea. I and others on the list have offered plenty of reasons why it would be a good idea: organizational coherence, consistency, minimizing redundancy. All you seem to offer is the statement that you have "strong objections." Do you actually have ANY rational objections at all, other than sheer conservatism, or perhaps a blind passion to get your pet document published as quickly as possible regardless of the needs of the situation? Doggedly thumping on the original WG charter as if it were the Ten Commandments, and refusing to contemplate even the slightest change in the interest of producing good specifications, is not a viable way to produce good specifications or to benefit the Internet community. Bryan > > -----Original Message----- > > From: Bryan Ford [mailto:baford@xxxxxxx] > > Sent: Thursday, May 12, 2005 12:21 > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Cc: Audet, Francois [SC100:9T51:EXCH]; 'Pyda Srisuresh' > > Subject: Re: [Ietf-behave] WG last call: > > draft-ietf-behave-nat-udp-01.txt > > > > On Thursday 12 May 2005 12:34, Francois Audet wrote: > > > This is the charter: > > > [...] > > > Seems pretty clear to me. > > > > > > The decision to split the document into smaller more > > > > manageable chunks > > > > > was made in IETF 62. > > > > Copy-and-pasting the original milestone list from the BEHAVE > > group home page > > and repeatedly pointing back to well-known early WG decisions > > that nobody is > > disputing does absolutely nothing to address the issues > > actually being > > discussed. Nobody is disputing the original decision "to > > split the document > > into smaller more manageable chunks"; we are proposing to > > take this decision > > further and split the common parts of the UDP and TCP > > documents into a > > separate "more manageable chunk". Nobody is contesting what > > the original > > milestones _were_; we are talking about what they _should be_ > > now that > > substantial work has been done and the interrelationships between the > > documents to be produced has become clearer. > > > > > I will also point out that we are actually ON SCHEDULE for the UDP > > > document. > > > > What's the huge hurry? Is the publication of the UDP draft > > so urgent that it > > can't wait another month or two in order to avoid serious > > inconsistencies and > > duplication of content between it and the other forthcoming > > documents this WG > > produces? The world has waited for many years already for > > the IETF to > > produce documents on NAT; is this task now suddenly so urgent > > that the world > > can't even wait a couple more months in order to ensure that the NAT > > documents the IETF produces are actually solid, well-organized, and > > consistent with each other? > > > > Besides, the proposed BEHAVE-GEN draft is already written and > > has been under > > evaluation and discussion for some time already too. There's > > no reason to > > assume that linking BEHAVE-UDP with BEHAVE-GEN will cause all > > that much > > delay: BEHAVE-GEN, after all, mostly just contains stuff > > that's in BEHAVE-UDP > > but is needed for BEHAVE-TCP too. If you have objections to > > specific content > > in BEHAVE-GEN, then let's fix it and get both drafts > > published as quickly as > > possible. > > > > Cheers, > > Bryan > > > > > > -----Original Message----- > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > > > > Behalf Of Pyda > > > > > > Srisuresh > > > > Sent: Thursday, May 12, 2005 07:11 > > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Subject: Re: [Ietf-behave] WG last call: > > > > draft-ietf-behave-nat-udp-01.txt > > > > > > > > > > > > Right, I fully agree with Bryan's comments below > > > > > > > > There was no such decision made in the BOF/WG meetings or on the > > > > list or in private e-mails with Cullen, as far as I can recall. > > > > Bryan & I had several e-mail exchanges with Francois & Cullen, > > > > authors of the behave-udp draft. Bryan and I talked about > > > > moving out > > > > > > non-UDP-specific stuff into a generic recommendation draft durign > > > > the e-mail discussions and we did a draft on it. > > > > Subsequent to that, > > > > > > I even requested the WG chairs to slot in the behave-gen > > > > draft for > > > > > > the WG meeting in Minneapolis. Had I known a decisin was made to > > > > duplicate all the common material in TCP & UDP drafts or cross > > > > reference them in some ad hoc way, I would, no doubt, have raised > > > > this on the list (as I am doing now). > > > > > > > > Here is a request to Jon Peterson, our AD: > > > > > > > > As Bryan says below, I suggest we step back a bit and > > > > revise the WG > > > > > > milestones. At the formation of the WG, while milestones > > > > are being > > > > > > created, it probably wasn't obvious that there would be a lot of > > > > material common to TCP and UDP. Now, it is. I believe, we need to > > > > include the behave-gen draft as one of the early on milestones. > > > > Further, I believe, this is an opportune time to identify all the > > > > drafts that should be adapted as WG drafts and do an > > > > overhaul of the > > > > > > milestones. Thanks. > > > > > > > > regards, > > > > suresh > > > > > > > > --- Bryan Ford wrote: > > > > > I likewise do not remember any such decision being > > > > made, or even > > > > > > > discussed on > > > > > > > > > > the list. If you're referring to some decision made > > > > "somewhere up > > > > > > > high in the chain of command" at the very formation of > > > > this WG, as > > > > > > you seem to > > > > > > > > > suggest, then that decision was presumably made before any > > > > > > > > actual text was on > > > > > > > > > the table and before any of the technical issues had been > > > > > > > > explored in > > > > > > > > > depth. > > > > > > > > > > I do remember seeing a bit of discussion long ago of > > > > > > > > whether to have > > > > > > > > > two > > > > > documents (TCP and UDP) or just one big combined document, > > > > > > > > but _nobody_ here > > > > > > > > > is suggesting just one big document at this point. The > > > > > > > > issue here, now, is > > > > > > > > > whether to split the (very considerable) common portions of > > > > > > > > the TCP and UDP > > > > > > > > > docs out into a common, transport-neutral doc. The issue > > > > > > > > is not one document > > > > > > > > > versus two, but two documents versus three. > > > > > > > > > > At the formation of the WG, it probably wasn't obvious > > > > that there > > > > > > > would be a lot of material common to TCP and UDP, because that > > > > > > > > material hadn't been > > > > > > > > > written yet. Now that it's been written, it's become very > > > > > > > > clear that there > > > > > > > > > is a great deal of common technical requirements, and > > > > it would be > > > > > > > a structural and readability disaster to duplicate that > > > > > > > > material across the > > > > > > > > > documents or litter them with ad hoc, ambiguous > > > > > > > > cross-references. Given > > > > > > > > > this, it seems highly appropriate to revisit the original > > > > > > > > decisions on > > > > > > > > > document organization that were made at the formation of the WG. > > > > > > > > > > Cheers, > > > > > Bryan > > > > > > > > > > On Tuesday 10 May 2005 20:28, Cullen Jennings wrote: > > > > > > On 5/9/05 7:22 PM, "Pyda Srisuresh" > > > > wrote: > > > > > > > <... stuff deleted> > > > > > > > > > > > > > >>>> The common requirements should be addressed in > > > > a seperate > > > > > > > > >>>> document, that will make both the TCP and UDP > > > > requirements > > > > > > > > >>>> concise and should not be interleaved in this UDP > > > > > > > > requirements > > > > > > > > > > >>>> draft. > > > > > > >>> > > > > > > >>> That's one option. Another is to make the two drafts > > > > > > > > parallel, > > > > > > > > > > >>> pointing out where they differ due to specific > > > > differences > > > > > > > > >>> between UDP and TCP. > > > > > > >> > > > > > > >> Agree. That decision (to have two parrallel drafts) > > > > > > > > was already > > > > > > > > > > >> made > > > > > > > > > > > > > > [suresh] When was this decision made? This was neither > > > > > > > reviewed nor decided upon on the list. > > > > > > > > > > > > This was discussed on the list before the BOF. It was > > > > > > > > discussed in > > > > > > > > > > the BOF. It was discussed by ADs and reviewed by IAB > > > > and IESG in > > > > > > > > forming charter. It has been pointed out to you in email > > > > > > > > from me. It > > > > > > > > > > is shown in the milestone section of the Charter page. > > > > > > > > > > > > If there is anything I can do to make it clear I'm glad > > > > > > > > to do it. If > > > > > > > > > > you would like to have another phone call around the > > > > > > > > reasoning that > > > > > > > > > > went into that decision, I am glad to set up a conference > > > > > > > > call for > > > > > > > > > > you and anyone else that cares to join. > > > > > > > > > > > > I'm not sure what else to do. > > > > > > > > > > > > Cullen with my chair hat on. > > > > > > > > > > > > _______________________________________________ > > > > > > Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Fri, 13 May 2005 16:31:57 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 13 May 2005 16:31:57 -0700 (PDT) Subject: Re: How should NATs reject TCP packets? (was:: Re: [Ietf-behave] Next rev on TCP Behavior) In-Reply-To: <200505111106.27974.baford@mit.edu> Message-ID: <20050513233157.59919.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Bryan, Please see my comments inline below. cheers, suresh --- Bryan Ford wrote: > Joining this discussion a bit late... > > On Monday 09 May 2005 02:10, Pyda Srisuresh wrote: > > --- Saikat Guha wrote: > > > On Wed, 2005-04-20 at 18:45 -0700, Pyda Srisuresh wrote: > > > > [suresh] I believe, the NAT device may optionally send ICMP Destination > > > > unreachable message [...] I would recommend using code 10 (Communicaion > > > with > > > > destination host administratively prohibited) > > > > > > I vote for this one. > > > 1) ICMP rate limiting prevents the NAT being kept busy. > > > 2) Code 10 could be defined with a SHOULD clause to be either hard or > > > soft giving the endhost the final say on whether to retry or not. > > > > > > One reason why the endhost may want to consider it a soft error is if it > > > is expecting (or trying) to trigger a TCP Simultaneous Open. One reason > > > why the host may want to consider it a hard error is to abort a likely- > > > to-fail connection request as soon as possible. Using ICMP Dest Unreach, > > > Code 10 gives the host flexibility to do either. > > > > [suresh] Sounds good. > > I am potentially OK with this recommendation providing that it ONLY applies > to > NAT ports that do NOT have an active binding. [suresh] I believe, there are principally four kinds of scenarios that could cause the NAT to reject incoming IP packets. a) The packet is not the first packet of a session and the packet does not match any existing NAT Sessions. b) The packet is the first packet of a session; NAT could permit the session to go through. However, the NAT device ran out of resources such as memory or NAT address pool or port pool etc. c) The packet is the first packet of a session; But, the direction of the first packet is not permitted by NAT, per the NAT address map; And, there is no existing BINDing on the NAT device exists for the same dest addres/port. d) The packet is the first packet of a session. The direction of the first packet is not permitted by NAT, even though a BINDing exists for the same dest address/port that permits sessions in the opposite direction. I believe, we all agree we simply want to drop packets in case (a) above. As for the remaining 3 cases (b), (c) & (d) - I dont think, there is a good reason to make a distinction to respond differently in each of these cases. I would suggest using the same approach for all three cases. > For NAT ports that DO have an > active binding, however, I don't think it NATs should be allowed to respond > actively with any "hard error" (whether ICMP or TCP RST), because doing so > could make TCP hole punching unreliable and timing-sensitive. The standard > scenario: > > 1. Clients A and B open TCP connections to rendezvous server S. > 2. A asks S to help establish a connection to B. > 3. S gives A and B each other's public and private endpoints. > 4. A happens to get S's message before B does, so it does a TCP open to B. > 5. B's NAT rejects A's attempt with an ICMP error (or RST or whatever). > 6. A's NAT sees the error response come back and closes its TCP hole to B. > 7. Client B finally gets S's message and attempts to connect to A. > 8. B's NAT now opens a hole, but A's NAT has closed its hole, so A's NAT > rejects B's connection attempt with an ICMP error (or RST or whatever). > 9. B's NAT now sees the error and closes its hole. > 10. A retries, and if it gets unlucky with the timing the cycle repeats... > [suresh] After step 6 above - I am not sure that A's NAT would simply close the associated NAT Session. I.e., When you see an ICMP Destination unreachable message, forward the packet usign the matching NAT Session, but immediately close the NAT Session right after that? I dont believe that would be the right thing to do. I believe, the NAT Session should stay alive even after seeing the ICMP error message, perhaps with a reduced timeout. I would be curious to find out what the empirical results are on this. If the NAT device were to simply delete the NAT Session upon seeign a ICMP Dest unreachable message, this could be the source of a serious attack on the NAT device operation. Same thing after step 9 as well. > Senthil's earlier suggestion of using "host unreachable", on the grounds that > > RFC1122 specifies that it _must_ be treated as soft, would be acceptable if > it it was actually consistently implemented that way - but he also mentioned > that Linux for one doesn't treat it as soft for TCP SYNs (which is precisely > what we're worried about for hole punching purposes). > > Suresh's suggestion of using code 10, "communication administratively > prohibited", worries me even more because not only is it not formally > specified at all whether it should be treated as a hard or soft error, but it > > seems very likely to me to be commonly interpreted as a hard error most of > the time. Think about it: if communication with some host is > administratively prohibited, then by conventional wisdom it would mean that > the _system administrator_ set something up to prohibit that communication, > which means that prohibition isn't going to go away until the system > administrator "administratively" takes it away. An "administrative > prohibition" isn't likely to go away soon on its own - hence it's a hard > error, not a soft error. > > If there was a suitable ICMP response that we knew would always reliably be > interpreted as a soft error, then I would go along with that. But as the > situation stands, I think that a NAT MUST just silently drop any prohibited > incoming packets directed at a bound port. Prohibition of packets directed > at bound NAT ports is by nature a temporary prohibition, not an > "administrative prohibition" - it's a temporary prohibition that lasts only > until the internal client punches a hole by sending traffic to the > appropriate external endpoint. Such a prohibition MUST elicit either a soft > error from the NAT or no response at all. Since there seems to be no > reliably soft response, the only option seems to be no response at all. > [suresh] Well, I wasnt thinking peer-to-peer when I suggested the ICMP Dest. Unreachable. But, as you say, I agree, ICMP dest unreacable can be problematic for peer-to-peer hosts, because we want the hosts to retry. Sounds like, the right thing to do for a NAT is to simply drop the unallowed pkts. I dont see any ICMP code that woudl be soft and makes sense. However, it seems, the NAT device should keep metrics of the various types of pkt drops for diagnostic purposes. > For non-bound NAT ports, I'm OK with any behavior - silently dropping > packets, > sending ICMP errors, or even sending back RSTs as a "real" host would, > providing that any ICMP errors or RSTs sent back are suitably > rate-controlled. [suresh] Please see my note earlier. I believe, the same logic shoudl apply even here. I woudlnt treat this different from the case where a binding was pre-existing. > Of course, sending back RSTs or ICMP errors for unbound > ports but not for bound ports could be interpreted as a security weakness > since it enables a port-scanning attacker to find out which NAT ports are > bound. Thus, in situations where this information leakage is deemed > unacceptable, I think the only acceptable behavior is for the NAT not to > respond at all on any of its ports. "A black hole leaks no information." > It's unfortunate that that means that prohibited connection attempts from > external hosts will have to time out rather than receiving an immediate > notification - but then, if all external hosts making "unsolicited" > connection attempts are assumed to be attackers by default, then again from a > > security perspective, it seems best to make them wait and not hand out any > information unnecessarily. > [suresh] Yup. > Also, for what it's worth, I think that this is an issue that applies to UDP > just as much as to TCP, with the minor difference that "UDP RST" responses > aren't an option because they don't exist. :) > [suresh] Agreed. > Cheers, > Bryan > cheers, suresh From huitema@windows.microsoft.com Sat, 14 May 2005 00:24:07 -0700 (PDT) From: "Christian Huitema" Date: Sat, 14 May 2005 00:24:07 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain > > I have strong objections to reverse the decision to go > > ahead with separate documents. > > Are you even LISTENING??? Nobody is proposing to reverse the decision to > separate the TCP and UDP documents. Nobody is proposing to "reverse" any > earlier decision at all. We're basically just proposing to generalize the > existing Nov 05 "ICMP" milestone into a "transport-independent behavior" > milestone, and bring it forward in the schedule to go alongside the UDP > draft. I have a strong opposition against delaying the publication of an UDP specific document by trying to build up an artificial "common requirement" document. There is no consensus that such a document can even be done, as many NAT implement separate protocols using wholly separate algorithms. There is also no requirement of any such document in the charter. If some actually want to issue a common document, they should do so after we have published the other documents, as a summary. I support immediate progress of the UDP document. -- Christian Huitema From srisuresh@yahoo.com Sun, 15 May 2005 07:26:28 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 15 May 2005 07:26:28 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <20050515142627.28581.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Christian Huitema wrote: > > > I have strong objections to reverse the decision to go > > > ahead with separate documents. > > > > Are you even LISTENING??? Nobody is proposing to reverse the decision > to > > separate the TCP and UDP documents. Nobody is proposing to "reverse" > any > > earlier decision at all. We're basically just proposing to generalize > the > > existing Nov 05 "ICMP" milestone into a "transport-independent > behavior" > > milestone, and bring it forward in the schedule to go alongside the > UDP > > draft. > > I have a strong opposition against delaying the publication of an UDP > specific document by trying to build up an artificial "common > requirement" document. There is no consensus that such a document can > even be done, as many NAT implement separate protocols using wholly > separate algorithms. [suresh] "Common requirements" is not artificial. Such a document draft-ford-behave-gen-01.txt already exists. As for consensus on adapting this as a WG draft, I would certainly like to see a poll taken on the list sooner than later. As for your comment about NATs implementing seperate protocols using separate agortihms - No one is disputing the need for seperate drafts for TCP vs UDP. However, your comment misses the point that NAT implementations have a big piece of common stuff and some variations on top of that for TCP vs UDP processing. > There is also no requirement of any such document > in the charter. [suresh] The charter states- "This working group proposes to generate requirements documents and best current practices to enable NATs to function in as deterministic a fashion as possible". > If some actually want to issue a common document, they > should do so after we have published the other documents, as a summary. > > I support immediate progress of the UDP document. > [suresh] UDP document is not going to be used in isolation by NAT implementers. behave-gen, behave-udp and behave-tcp are going to be used together. I see little point in rushing the UDP draft in isolation. It would make no sense to release the behave drafts without coordination or structure and duplicate common material, worse, have conflicting comments across the drafts. > -- Christian Huitema cheers, suresh From marc@let.de Sun, 15 May 2005 08:14:35 -0700 (PDT) From: Marc Manthey Date: Sun, 15 May 2005 08:14:35 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <20050515142627.28581.qmail@web40426.mail.yahoo.com> Message-ID: <703AAC3D-46FC-4CD5-AF32-DE4B5CB707E6@let.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630133.multipart/signed" --Boundary..27398.1163630133.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On May 15, 2005, at 4:26 PM, Pyda Srisuresh wrote: --- Christian Huitema wrote: I have strong objections to reverse the decision to go ahead with separate documents. sorry isnt this what microsoft mostly do ?. cheers codewarrior@xxxxxxxxxx -- " In a world without walls or fences, who needs Windows and Gates ? " Les Enfants Terribles - www.let.de - www.cuseeme.de cuseeme:// 207.44.156.3 CID 0 Max send.25 Max. Recieve.80 Attachment: smime.p7s --Boundary..27398.1163630133.multipart/signed Content-Type: application/octet-stream; name="p7s00001.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7s00001.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHHzCCA0kw ggKyoAMCAQICDgpqAAEAAntSGyw2RRVxMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQ MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50 ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIu ZGUwHhcNMDUwNTA5MTQzMjQ4WhcNMDYwNTA5MTQzMjQ4WjBAMQswCQYDVQQGEwJERTEVMBMGA1UE AxMMTWFyYyBNYW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAvwCjxxISYuhol4fmTuqlvYN3JOLxcceKV3T8OzmBqQVkbKvmkqh+d5ue O+Dz4ZD9sYKbvbAcQmfLqra94of91kM20oPlAalNcSNe8HUEDEVb4GHdqPVwmaVK9jJ5BUPDMheq W5TR5X/ATEfQU7oCZSI/7+h9Ww3anbUXIZeCCOMCAwEAAaOByDCBxTAMBgNVHRMBAf8EAjAAMA4G A1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9n dWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0cHM6Ly93d3cu dHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzBBNkEwMDAxMDAwMjdCNTIxQjJD MzY0NTE1NzE/MA0GCSqGSIb3DQEBBAUAA4GBAE94N6LMW8iv8HvV9RC77acqqCw4JyLYB6pcgTK9 bpEYxkdggTJRUnCMzz8TOOzVvfA2mzEmwoKDnMYUFugAxdLbFPuxsw4aJ9vMZPdppz28nBDdx1jt lmoJvm3fogTLCGfhWyrd68/tqneYNf540iiXPkp9bwVs8qvQFyEUa8Y8MIIDzjCCAzegAwIBAgIP AJn2AAAAAtbxQYHMGpdhMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMH SGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNl Y3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwHhcNMDUw MjA0MTY0ODQ3WhcNMDYwMjA0MTY0ODQ3WjBAMQswCQYDVQQGEwJERTEVMBMGA1UEAxMMTWFyYyBN YW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANL2cTdJD0oNKje7z4466yUIRX8DJbmjCZBMLtnmHiEqMrpK2rQps8Gcmp3ueB+d o7lGwU7YH3m676a5XhyvcaYwmu1C2gLfBiOzbijbZLP95vP0Aowf9HyuO6iTS42el73q+6MKCY8h O1px1R1blj9cxFeGfFXiG8Oz2QOi7sfJHB+Vp9WVU8ZI1I8NibF/wAN8HzZSdbKkEArGarBCYZ8J Em9C7UZpxc3fx61PePP/z5j4GeQVt+iI5FzBMlg0T7W5X16D0yQuLQb2ajeYJhstFC0KrbO+v9eV WnOsXzOYo+PkPH4O6tOKyX14GFITKYWTwyU6It03XrO/lAvn80kCAwEAAaOByDCBxTAMBgNVHRMB Af8EAjAAMA4GA1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNl bnRlci5kZS9ndWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0 cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzk5RjYwMDAwMDAw MkQ2RjE0MTgxQ0MxQTk3NjE/MA0GCSqGSIb3DQEBBAUAA4GBAF3ZoITTnsH5RDnrDWReZJPv9WUF yGPjjKIUHQlGeEg+JY4T5b8SrHJGkyxyoc2dj3E5G7iJ173mz5IK42YizLRNCcw3gZcSJQl8SqiL L7VN/xdOZfbZKFhDStraQXghJ9tvoD5CNzFKblW71W0iv2f1R7GPwR+lKB9S5ZejZj+CMYIDoTCC A50CAQEwgc8wgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1i dXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3Jr cyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkB FhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIOCmoAAQACe1IbLDZFFXEwCQYFKw4DAhoFAKCC AicwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNTE1MTUxNDM5 WjAjBgkqhkiG9w0BCQQxFgQUoYR4fdLWxQqWMWmjYGLXR0r4SHkwgeEGCSsGAQQBgjcQBDGB0zCB 0DCBvDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4 BgNVBAoTMVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgx IjAgBgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRp ZmljYXRlQHRydXN0Y2VudGVyLmRlAg8AmfYAAAAC1vFBgcwal2EwgeMGCyqGSIb3DQEJEAILMYHT oIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6 MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21i SDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2Vy dGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTANBgkqhkiG9w0BAQEFAASB gB1tN/bQo0ilr4JS7yV95nVx9vxf4gQUOa8hJi+JqXz1zTk/qq61C0XbXrb9g/XO1AvxfWGJ0+77 qYP5DMyqtGALcJZGYUQC2xLHXA/Ece0xwBb2qAnopJVUI9FErm3fJVyNbf4EpUJeSuMmsd4qD6yA SFA/p7jan2J8G0WJ4nNvAAAAAAAA --Boundary..27398.1163630133.multipart/signed-- From huitema@windows.microsoft.com Sun, 15 May 2005 09:14:57 -0700 (PDT) From: "Christian Huitema" Date: Sun, 15 May 2005 09:14:57 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain On May 15, 2005 8:15 AM, at Marc Manthey wrote: > On May 15, 2005, at 4:26 PM, Pyda Srisuresh wrote: > > > > > --- Christian Huitema wrote: > > > >>>> I have strong objections to reverse the decision to go > >>>> ahead with separate documents. The phrase you quote was written by Francois Audet, not me. It was quoted in Suresh's message, to which I responded. -- Christian Huitema From paul.hoffman@cybersecurity.org Mon, 16 May 2005 08:58:49 -0700 (PDT) From: Paul Hoffman Date: Mon, 16 May 2005 08:58:49 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <6.0.3.0.0.20050426011721.055967c0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain First, a *big* thanks to Bryan for reading this carefully and proposing new text. My responses here are as a non-implementer, but someone who will soon be doing NAT testing. It would be good to hear responses from NAT implementers. At 2:27 PM -0400 5/12/05, Bryan Ford wrote: *1. The draft's use of the term "session" is unclear in various places, because it doesn't distinguish between sessions as identified by (src IP, src port, dst IP, dst port) on one side of the NAT or the other, or between sessions within a single IP address domain and "logical sessions" that flow across the NAT and hence cross IP address domains. Further, the vague notion of "session" used informally in the draft at present is insufficient to make the text in "6. Hairpinning Behavior" precise or even comprehensible. The current "session" definition made sense to me, but that doesn't mean that my understanding was correct. Your additional definitions also made sense, and were certainly more precise than the ones in the draft. However, I can't judge if they are worth using until I see where the three types of sessions you define are to be used in the document. That is, the current use of "session" seemed fine, but if we are going to add your types of sessions, we need to also say for each use of the term, which kind of session it is. I would tend to keep the current simpler definition unless implementers say that they are confused. *2. The draft uses the terms "mapping" and "binding" in confusing ways that are inconsistent with their historical meanings, and doesn't sufficiently clarify its use of these terms in the "3. Terminology" section. In particular, the draft uses the term "mapping" loosely in various places, sometimes to mean "binding", sometimes apparently to mean other things, but never properly defines either of these terms as they are used here. Again, I didn't see the problem. And, when I read the earlier NAT documents and your suggestion for revised definitions, I found those earlier definitions and categorizations more confusing, not less. There is always a problem when protocol designers come up with terminology that doesn't match what the marketing folks use: developers get stuck in the middle. In this case, I think the new terminology that Franois and Cullen use is much closer to what typical developers will understand. In informal discussions with some firewall developers over the past few months, they often wail about the incomprehensibility of the NAT RFCs. More than once I have been asked "can you explain what the heck symmetric means here?". I went through and looked at each use of the term "mapping" in the current draft, and don't find any inconsistency or confusion. Of course, I could be missing some detail that is important to implementers (not to protocol designers); having specific examples of where that term fails them would be useful. As for "binding", it is only used in the body of the document in exactly one place. In section 9, first paragraph, the term "binding" should be changed to "mapping". This one mistake is not a good enough reason to bring back the term. *3. The new terminology introduced in section 4.1 and 5.1, with the goal of replacing the historically troublesome "Cone/Symmetric" terminology, is hopelessly cumbersome. Disagree; see above. If we absolutely must, must, MUST invent new terms (instead of just clarifying the old ones, which I still think would be a better approach), then at least the new terms shouldn't take a whole line to write out! As is, they'll never get used in practice because they're just way too long; most people will in practice just keep using the cone/symmetric terms (imprecisely and confusingly) because they're easy to remember. This assumes that people in practice use "cone" and "symmetric", and use them correctly. Although I'm new in the field of NAT testing, I'm not new to firewalls, and I rarely see these terms used in the marketing literature, even the technical marketing literature. None of the developers I have spoken with (much less marketing people) said they find them "easy to remember"; some have said "I'm glad BEHAVE will clarify the terminology mess". *4. The second "address and port mapping behavior" in section 4.1, "External NAT mapping is endpoint address dependent", is completely unnecessary: no NAT that I've ever heard of implements this behavior because it just doesn't make sense at the implementation level, this behavior is subsumed by the third behavior ("External NAT mapping is endpoint address and port dependent"), and both the second and third behaviors are going to be disallowed in the requirements section at the end anyway. This sounds like a good reason to combine the two and note the fact that the combined description is not covered in the document. * Instead of saying that "a NAT's address and port mapping behavior is 'External NAT mapping is endpoint independent'" (14 words), just say that the NAT has "Consistent Endpoint Translation" (3 words). In other words, when the NAT translates the private source endpoint of a new session crossing a NAT into a corresponding public port, it ALWAYS translates that private source endpoint to the same public source endpoint - i.e., "consistently". * Similarly, instead of saying that "a NAT's address and port mapping behavior is 'External NAT mapping is endpoint address and port dependent'", just say that the NAT has "Inconsistent Endpoint Translation". A NAT has Inconsistent Endpoint Translation if it EVER translates source endpoints inconsistently under ANY conditions. That is, a NAT that "usually" behaves like a Cone NAT but "occasionally" switches to symmetric behavior for certain translations, because of contention for a particular NAT port for example, will still have "Inconsistent Endpoint Translation". * Drop the "External NAT mapping is endpoint address dependent" behavior entirely, because it is logically subsumed by "Inconsistent Endpoint Translation", no NAT I know of implements this particular intermediate behavior, and it is just another variation of deprecated behavior that we're going to disallow in the requirements section anyway. * Instead of saying that a NAT's filtering behavior is "External filtering is endpoint independent", just say that the NAT has "Endpoint-Independent Filtering". * Similarly, Instead of "External filtering is endpoint address dependent", just say the NAT has "Address-Specific Filtering" * Finally, instead of "External filtering is endpoint address and port dependent", just say the NAT has "Endpoint-Specific Filtering". All of these sound fine to me. Note that I suggest saying "Endpoint-Specific Filtering" here rather than "Endpoint-Dependent Filtering" because the latter sounds like it would subsume "Address-Dependent Filtering". A filtering behavior that "depends on" the external address indeed also by logical extension "depends on" the external endpoint, even if it doesn't really depend on the port part of the endpoint. Saying that the filtering is "Endpoint-Specific", in contrast, I think makes it more clear that the filtering is really specific to _both_ the address and port number components of the endpoint, without actually having to say "endpoint address and port specific" or something clumsy like that. Now we can use the proposed terminology to clarify the historical Cone/Symmetric terminology very easily and concisely: Symmetric NAT := Inconsistent Endpoint Translation. Cone Nat := Consistent Endpoint Translation. Full Cone Nat := Consistent Endpoint Translation with Endpoint-Independent Filtering. [Address-]Restricted Cone Nat := Consistent Endpoint Translation with Address-Specific Filtering Port-Restricted Cone Nat := Consistent Endpoint Translation with Endpoint-Specific Filtering With the above proposal in mind, here is my suggested rewrite for section 4.1, which both fixes the terminology and also helps address the earlier issues *1 and *2 above: --- 4.1 Address and Port Mapping When an internal endpoint initiates a new UDP session targetted at an endpoint on the external network, the NAT establishes a new outgoing NAT session so that subsequent response packets from the external endpoint can be received by the NAT, translated, and forwarded back to the original internal endpoint. To form this new outgoing NAT session, the NAT uses the source and destination endpoints from the original packet that initiated the session, in order to define the internal "origin session" component of the NAT session. The NAT must then compute a corresponding "target session" component in order to define the corresponding UDP session as it will appear on the external network. For Traditional NAT, the destination address and port number is not translated in outgoing NAT sessions, so the NAT merely needs to assign an external source IP address and UDP port to form the new NAT session. If the NAT receives a packet from the internal network with a given (internal source IP, internal source port, external target IP, external target port) session tuple, for example, the NAT must "map" the internal source endpoint to a corresponding external source endpoint that is valid in the external IP address realm, in order to form the new outgoing NAT session. We refer to the way the NAT maps an internal source endpoint to the corresponding external source endpoint, while establishing a new outgoing NAT session, as the NAT's address and port mapping behavior. For many applications, it is important to distinguish the behavior of the NAT when applications establish multiple simultaneous outgoing NAT sessions from a single internal source endpoint to distinct external target endpoints. For example, suppose a node X on the internal network has already initiated an outgoing NAT session from internal source endpoint X:x (address:port), to a particular external destination endpoint Y1:y1. The NAT has mapped the internal source endpoint, X:x, to an external source endpoint X1':x1' in the external IP address realm, to form the full NAT session tuple. Now suppose node X initiates a new session from the same internal source endpoint, X:x, to a new external destination endpoint Y2:y2, and in response the NAT maps the internal source endpoint X:x to an external source endpoint X2':x2' to form the NAT session tuple to translate this new session. The relationship between X1':x1' and X2':x2' for various combinations of the relationship between Y1:y1 and Y2:y2 is critical for describing the NAT behavior. This arrangement is illustrated in the following diagram: The following address and port mapping behavior are defined: Consistent Endpoint Translation: When the NAT establishes the first outgoing NAT session from an internal IP address and port X:x to any external target endpoint, choosing some corresponding external source IP address and port X1':x1' in the process, the NAT also establishes a persistent port binding between the internal endpoint X:x and X1':x1' in the process, and uses that port binding to determine the external source endpoint for any subsequent outgoing NAT sessions that originate from the same internal source endpoint X:x. Specifically, X1':x1' equals X2':x2' for all values of Y2:y2. In terms of the NAT terminology in RFC 3489, this mapping behavior constitutes "Cone NAT", where the sub-type (Full Cone versus Restricted versus Port-Restructed Cone) is based on the filtering behavior to be discussed later. As a consequence of establishing a port binding from X:x to X1':x1' in response to the first outgoing session originating from X:x, the NAT also effectively "allocates" the external source endpoint X1':x1' exclusively to the use of this port binding, so that no other session originating from a different internal source endpoint may be translated so as to use the same external source endpoint X1':x1', while this port binding is active. This "exclusive port allocation" behavior is crucial for a NAT to have consistent endpoint translation, because otherwise the NAT could "paint itself into a corner" and make it impossible to translate future sessions involving the original source endpoint X:x correctly. For example, suppose the NAT has established a NAT session that translates the internal session (X:x,Y1:y1) to an external session (X1':x1',Y1:y1). Suppose further that it has incorrectly established a second NAT session translating an unrelated internal session (X2:x2,Y2:y2) to the external session (X1':x1',Y2:y2), re-using the external source endpoint X1':x1' between these two unrelated sessions. If node X now initiates a new outgoing session from X:x to Y2:y2, then to preserve the Consistent Endpoint Translation property the NAT would have to translate the new internal session (X:x,Y2:y2) to the external session tuple (X1':x1',Y2:y2) - but this external session tuple is the same as the external session tuple the NAT has already assigned to the prior unrelated session originating from X2:x2, and the two sessions would hence be indistinguishable on the external network. In effect, therefore, a NAT MUST exclusively allocate an external source port to a single internal source port for the duration of the corresponding port binding, in order to have Consistent Endpoint Translation. Inconsistent Endpoint Translation: When setting up a new outgoing NAT session from an internal source endpoint X:x to an external target endpoint Y2:y2, the NAT may map the internal source endpoint X:x to any external source endpoint X2':x2' of its choosing, regardless of how it has previously mapped any existing sessions originating from the same internal source endpoint X:x. Specifically, X1':x1' equals X2':x2' only if Y2:y2 equals Y1:y1. Some existing NATs usually but do not always translate source endpoints consistently under all operating conditions; such NATs are still classified as having Inconsistent Endpoint Translation. From an RFC 3489 NAT perspective, but not necessarily a filtering perspective, this behavior constitutes "Symmetric NAT". It is important to note that ... --- ...and the rest of section 4.1 and section 4.2 look basically fine to me. This generally looks OK, but I am leery of bringing up the RFC 3489 terminology. It isn't useful to *NAT developers*, it is only useful to protocol designers who liked the old terms. It doesn't help reach our goal of benefiting NAT developers. It also doesn't hurt that much, it just adds statements that make the section longer than needed. Also, please remove "UDP" in the very first sentence; it is true regardless of whether it is UDP or TCP. Section 4.3 and 4.4, however, currently use the term "mapping" to refer to "NAT sessions" in some cases and to refer to "port bindings" in other cases; this needs to be clarified. Again, I don't see a problem with the current wording. My proposal is to reverse the order of the two sections and differentiate explicitly between "session timers" and "binding timers" while referring to both generally as the NAT's "inactivity timers": --- 4.3 Inactivity Timer Scope: Because the UDP protocol does not provide a standard way to determine exactly when a UDP session crossing the NAT is no longer in use, NATs must implement inactivity timers so they can eventually eliminate NAT sesssions and port bindings that appear to be idle. Different NAT implementations vary widely, however, not only in the values of these timeouts but also in their scope and how they are refreshed. Some NATs associate inactivity timers with individual NAT sessions. Such a NAT is said to have an inactivity timer scope of "per-session". In this case, we define the NAT's per-session inactivity timeout to be the amount of time the NAT will keep a particular NAT session active without packets traversing the NAT on that specific session. Other NATs associate inactivity timers instead with address or port bindings. Such a NAT is said to have an inactivity timer scope of "per-binding". In this case, we define the NAT's per-binding timeout to be the amount of time the NAT will keep a particular binding active, along with all of the NAT sessions associated with that binding, without the NAT observing packets on any of the sessions associated with that binding. For example, suppose an internal node X has established two NAT sessions from the same internal source endpoint X:x to distinct external target endpoints Y1:y1 and Y2:y2, and the NAT has established a port binding from the internal endpoint X:x to an external source endpoint X':x' for these two sessions, as described earlier. The NAT's binding timeout ensures that the port binding from internal endpoint X:x to external endpoint X':x' remains active, along with both of the existing NAT sessions using this binding (the one between X:x and Y1:y1 and the other between X:x and Y2:y2), for as long as the NAT observes traffic on either of these sessions. Do others find these three long paragraphs clearer than the draft's two sentences? I don't see how this helps NAT developers, but I could be missing some important facet of the detail. 4.3 Inactivity Timer Refresh Direction UDP inactivity timeout implementations also vary based on the way the inactivity timer is refreshed to keep NAT sessions or bindings alive. Some NATs keep a session or binding active (i.e., refresh the timer value) whenever a packet passes from the internal side of the NAT to the external side of the NAT, using that session or binding. This is referred to as having a NAT Outbound refresh behavior of "True". Some NATs keep a session or binding active when a packet passes from the external side of the NAT to the internal side of the NAT. This is referred to as having a NAT Inbound Refresh Behavior of "True". Some NATs keep a session or binding active when a packet traverses the NAT in either direction on that session or binding, in which case both properties are "True". This seems quite close to the current document, and is probably OK. *5. The vague notion of "session" used informally in the draft at present is insufficient to make the text in "6. Hairpinning Behavior" precise or even comprehensible. Section 6 doesn't use the term "session" at all. Having said that, I admit I had to read the section in the draft a few times to figure out what is going on. It is especially important that hairpin translation be defined clearly and precisely here because as far as I know this will be the first "official" IETF document that even mentions it. Agree. *6. Section 8, "Deterministic Properties", is currently very opaque and confusing as written, and it is not clear exactly it is trying to say. Agree. This section is apparently talking mostly about the address and port mapping behaviors way before in section 4.1, and to a lesser degree the filtering behavior in 5.1, but in that case why not just discuss these nondeterminism issues earlier in the appropriate sections rather than spreading them throughout the document? I think that my proposed replacement text for 4.1 already provides a good start for that, by explicitly saying that any NAT that EVER translates its endpoints inconsistently under ANY conditions is to be considered to have Inconsistent Endpoint Translation behavior, and by discussing the "port allocation" issue in-line. The same could be done for endpoint filtering behavior, if that's actually important. Agree. At any rate, it seems very unnecessary to introduce yet another new "behavior" described as "nondeterministic NAT behavior", with its own top-level section in the document, just in order to complain that some NATs seem to get very close to Consistent Endpoint Translation without quite getting there. Just make sure it's clear in the text that a NAT really, really has to go "all the way" and get it right, and that "Mostly/Usually Consistent Endpoint Translation Under Favorable Network Conditions" is still "Inconsistent Endpoint Translation" and hence disallowed. Agree. If we need an "inconsistency is bad" section, make it a non-normative appendix. But I think Bryan's folding in of the ideas in Section 4 is better. *7. It's very annoying and confusing that you have to read all the way through the document before you ever see even a hint of the actual requirements for NAT behavior that the document is trying to specify: e.g., that "Consistent Endpoint Translation is GOOD" and "Inconsistent Endpoint Translation is BAD". I like having a summary of the requirements all in one place, but those requirements also need to be stated in-line with the text that describes what they mean. Just duplicating the text of the REQ-## paragraphs verbatim in the appropriate places is sufficient. Agree. Maybe have an appendix that copies all the requirements, but possibly not even that. Including the requirements in-line would also enable the "Requirement Discussion" paragraphs in section 12.1 to be moved upward to their natural locations, where the respective issues are actually introduced and discussed in the first place. As it is, we have long discussion with no requirements, then short requirements, then short discussion of requirements - very awkward and confusing. Agree. *8. I disagree with REQ-7, which recommends "External filtering is endpoint address dependent" behavior, because endpoint-dependent filtering interferes with applications, and because it amounts to a recommendation to deploy firewall functionality. This WG is about making NATs support applications better and more deterministically, not about suggesting firewall practices. (I don't even remember hearing any discussion about this recommendation on the list so far, or what the rationale was for the current recommendation.) Once a NAT has implemented Consistent Endpoint Translation (i.e., "Cone NAT"), as we require, the filtering policy the NAT implements on top of this is purely a tradeoff between perceived security benefits and interference with applications. Endpoint-Independent Filtering brings a strong benefit to applications, whereas the security argument for Address- or Endpoint-Specific Filtering is actually rather weak, as discussed below. Agree. It is fine to talk about the security considerations of not allowing additional traffic in, but having this as a SHOULD is overkill. With that, I propose the following text for REQ-7: REQ-7: NATs MUST implement Endpoint-Independent Filtering in their default configuration. NATs SHOULD be configurable to support Address-Specific Filtering or Endpoint-Specific Filtering at the option of the system administrator. Agree, as long as we add some of your text (that I elided) to the Security Considerations section to help the few implementers who actually read it to decide what to do. *9. In the discussion of fragmented datagrams, it is not clear whether NATs must support datagram sizes up to the maximum of 64K, or whether it is acceptable for a NAT to have a smaller maximum datagram size - e.g., a little over 8K, the size needed by NFS traffic. Unless there are serious screams from NAT implementors here, I would say that NATs MUST support full-size (up to 64K) fragmented datagrams. We should follow the MUSTs and SHOULDs for whatever the current standards are. I failed to find that in my search; hopefully someone on the list can help? Again, thanks for doing a thorough review, even if I didn't agree with all of it. It would be grand if others on the list (particularly NAT developers!) would chime in right about now... --Paul Hoffman, Director --Cybersecurity Association --www.cybersecurity.org From audet@nortel.com Mon, 16 May 2005 19:35:01 -0700 (PDT) From: "Francois Audet" Date: Mon, 16 May 2005 19:35:01 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF02503D3E@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Bryan, Here are some responses to your comments. --------------- "Annoying" placement of the Requirements: - You've expressed the wish that we include the requirements as they occur in the document instead of having to wait for them in section 12 (copying them verbatim would be OK). I agree that it would make it easier for the reader to follow "where we are going" with this document. Section 12 would just be the consolidated summary of the requirements. I agree with this editorial recommendation. I will make the change however only if there is a consensus that it would be beneficial (but I support it). - You would prefer to have section 12.1 merged into 12. There are plus and minuses to this approach, and I'm reluctant to change it now. The rationale for the current model is that it emphasises the Requirements in a "check-list" type section. If there is a consensus that merging the justification and the requirements into one section is better, I will do it. Otherwise, I'll leave it as is. Use of term "session", "Mapping" and "Binding" - In the document, the term "session" is from the point of view of the endpoints. This is why we talk about going "through" the NAT. This is why we don't talk of a session being in a "specific realm". There is one session, and it goes through the NAT. The NAT maps addresses and ports. If it is implemented as 2 sessions in the NAT, as it is likely, that is OK, but it is unecessary to explain in the document. - We use the "mapping" terminology instead of your double-play of "binding" and "NAT session". We find this "mapping" to much more less complicated to explain than refering to "bindings" for certain types of NATs with NAT sessions, and then to NAT that don't have "NAT sessions" but instead rely on inactivity timers. - Furthermore, it is not clear to us at all that all NATs have been built using the same model as you describe. It seems like they is tremendous variability in the logical model that people have been using, creating lots of incompatible NATs. - Rather than simplifying the document and making it easier to understand, your proposal seem to make it much more complicated. - Note that I don't necessarily disagree with the terminology that you are using. It is just that it seems to be more complicated, and implies a certain implementation of the NAT. My fear is that it would be a source of confusion for many NAT implementors who tend to have their own idiosyncracies on their implementation. Symmetric and Cone NAT terminology: - RFC 4008 introduced a new definition of "Symmetric NAT" that is different from the one originally defined in RFC 3489. We spent almost the entirety of the Minnesota meeting on this, without progress, or agreement of what the definition of Symmetric NAT was. In fact, the version of the draft in Minnesota attempted to explain the Cone/Symmetric terminology in the context of this draft in great details (in a way similar that you are proposing now). We then decided NOT to do this because people found it pointless and nobody agreed on what Symmetric actually meant. Address and port mapping terminology: - The term "consistent mapping" is ambiguous, unlike "Endpoint independent mapping" which is not. Some of us believe that an "Address and port dependent mapping" is consistent if it always behaves like this. In my mind, the term "consistent" refers more to the type of behavior that we are describing in section 8 on "Deterministic Behavior" - The claim that the "Address dependent" behavior paragraph is superflous is unfounded as we have found NATs that behaved like this. In fact, we have found NATs that did much worst than that. - That being said, I am sympathetic to the idea of making the names of the behaviors shorter, while keeping them explicit. For example, I would agree with: - Endpoint independent mapping <--- Good - Address specific mapping <--- Bad - Address/port specific mapping <--- Bad If I get a consensus from the group that this terminology is better, I can make this editorial change. - Your extra material describing those three behaviors seem more complicated than the original, and the attempt to describe them in terms of "symmetric" versus "Cone" NAT is something we removed at the last meeting in Minnesota. Mapping refresh: - I don't mind switching the order for sections 4.3 and 4.4. Again, I will need a consensus from the group that it is beneficial. - I believe the "mapping" refresh concept is easier to understand and more general than introducing inactivity timers and NAT sessions. Deterministic properties: - Non-deterministic NATs is the single biggest and most annoying problem we have seen with NATs. Cullen described some of them in his NAT testing result document. You are absolutely right that if you followed every rule in the behave draft, you would then not have a non-deterministic behavior. It is not because you haven't seen those nasty non-deterministic behaviors that they don't exist: they do, and on massively deployed NATs. We talked about this a million times already on the list and in the meetings. - We do feel that non-determinism is so entrenched in NATs (because implementors try to introduce "one-off fixes" to NATs), that it makes NATs a huge problem. The consequence is that you test a NAT, it looks well-behaved, but under some other call scenario (like having multiple IP phones behind the same NAT) it suddently starts to fail. - Many people have expressed the view that this section is very important. If you have some suggestion on how to make it better, please let us know. External filtering behavior: - I don't have a problem with the editorial change to the terminology, along the lines of: - Endpoint independent filtering - Address specific filtering - Address and port specific filtering Again, I will only do it if there is a consensus that it is befeficial. - You don't like REQ-7 which states that the filtering behavior shall be "Address specific", and propose mandating endpoint-independent by default, and allowing for a configuration for the other two behaviors. I don't have any strong views on which mechanism should be used. We have had a LOT of people saying that "Address and port dependent" would break a lot of applications (which you don't like anyways). We also had lots of comments on avoiding "non-determinism" (which your current proposal has). We never had much views expressed to us on "Endpoint-independent" versus "Address dependent" (most people seem to say they are OK with either). I kind of agree with your long explanation on why you prefer Address-independent. - Therefore, I would have no problem with REQ-7 to be changed to: It is RECOMMENDED that a NAT have an Endpoint independent filtering behavior. Again, I would like to hear some consensus from the group before we do so. My personal recommendation is that this change would be BETTER than the previous text. Fragmentation issue - I'd like feedback from others (like Dan Wing) on this particular item. Finally, I'd like some consise and precise suggestions where we could gage the interest in the group. A gigantic proposal to overhaul the whole document is not particularly constructive. Franois From paul.hoffman@cybersecurity.org Mon, 16 May 2005 20:42:30 -0700 (PDT) From: Paul Hoffman Date: Mon, 16 May 2005 20:42:30 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02503D3E@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 10:34 PM -0400 5/16/05, Francois Audet wrote: - You would prefer to have section 12.1 merged into 12. There are plus and minuses to this approach, and I'm reluctant to change it now. The rationale for the current model is that it emphasises the Requirements in a "check-list" type section. If there is a consensus that merging the justification and the requirements into one section is better, I will do it. Otherwise, I'll leave it as is. I read Bryan's request as merging the rationales *into the body of the document*, along with the requirements. That sounds good to me. --Paul Hoffman, Director --Cybersecurity Association --www.cybersecurity.org From audet@nortel.com Tue, 17 May 2005 07:03:47 -0700 (PDT) From: "Francois Audet" Date: Tue, 17 May 2005 07:03:47 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF02503F12@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Yeah, you are right. Let's wait for more feedback. > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@xxxxxxxxxxxxxxxxx] > Sent: Monday, May 16, 2005 20:42 > To: Audet, Francois [SC100:9T51:EXCH]; 'Bryan Ford'; > 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: RE: [Ietf-behave] WG last call: > draft-ietf-behave-nat-udp-01.txt > > > At 10:34 PM -0400 5/16/05, Francois Audet wrote: > >- You would prefer to have section 12.1 merged into 12. > There are plus and > > minuses to this approach, and I'm reluctant to change it > now. The rationale > > for the current model is that it emphasises the Requirements in a > >"check-list" > > type section. If there is a consensus that merging the > justification and > > the requirements into one section is better, I will do > it. Otherwise, I'll > > leave it as is. > > I read Bryan's request as merging the rationales *into the body of > the document*, along with the requirements. That sounds good to me. > > --Paul Hoffman, Director > --Cybersecurity Association > --www.cybersecurity.org > > From fluffy@cisco.com Tue, 17 May 2005 07:35:54 -0700 (PDT) From: Cullen Jennings Date: Tue, 17 May 2005 07:35:54 -0700 (PDT) Subject: Re: How should NATs reject TCP packets? (was:: Re: [Ietf-behave] Next rev on TCP Behavior) In-Reply-To: <20050513233157.59919.qmail@web40426.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I suspect that many devices (that are also firewalls) will choose to silently discard so we probably can't disallow that behavior even if it is not the preferred approach. I would like to remind folks that this was discussed in the last WG meeting. Some notes on the topic were > "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." Anyways, I guess I do wonder if we really need to specify this or not. If you want STUNT to work and you want to do it on fairly normal OS without replacing the TCP stacks, what behavior do you need to assume here and how much can you still leave open? I note that a router would just drop the packet if it felt like it thought that may not be the right analogy. I suspect that while making an new ICMP code may have been the right thing to do long ago, I'm not sure it is that practical to today because of the large deployment issues in getting OS to change to understand it. Cullen On 5/13/05 4:31 PM, "Pyda Srisuresh" wrote: > Bryan, > > Please see my comments inline below. > > cheers, > suresh > --- Bryan Ford wrote: > >> Joining this discussion a bit late... >> >> On Monday 09 May 2005 02:10, Pyda Srisuresh wrote: >>> --- Saikat Guha wrote: >>>> On Wed, 2005-04-20 at 18:45 -0700, Pyda Srisuresh wrote: >>>>> [suresh] I believe, the NAT device may optionally send ICMP Destination >>>>> unreachable message [...] I would recommend using code 10 (Communicaion >>>> with >>>>> destination host administratively prohibited) >>>> >>>> I vote for this one. >>>> 1) ICMP rate limiting prevents the NAT being kept busy. >>>> 2) Code 10 could be defined with a SHOULD clause to be either hard or >>>> soft giving the endhost the final say on whether to retry or not. >>>> >>>> One reason why the endhost may want to consider it a soft error is if it >>>> is expecting (or trying) to trigger a TCP Simultaneous Open. One reason >>>> why the host may want to consider it a hard error is to abort a likely- >>>> to-fail connection request as soon as possible. Using ICMP Dest Unreach, >>>> Code 10 gives the host flexibility to do either. >>> >>> [suresh] Sounds good. >> >> I am potentially OK with this recommendation providing that it ONLY applies >> to >> NAT ports that do NOT have an active binding. > > [suresh] I believe, there are principally four kinds of scenarios that could > cause the NAT to reject incoming IP packets. > > a) The packet is not the first packet of a session and the packet does not > match any existing NAT Sessions. > > b) The packet is the first packet of a session; NAT could permit the session > to > go through. However, the NAT device ran out of resources such as memory or NAT > address pool or port pool etc. > > c) The packet is the first packet of a session; But, the direction of the > first > packet is not permitted by NAT, per the NAT address map; And, there is no > existing BINDing on the NAT device exists for the same dest addres/port. > > d) The packet is the first packet of a session. The direction of the first > packet is not permitted by NAT, even though a BINDing exists for the same dest > address/port that permits sessions in the opposite direction. > > I believe, we all agree we simply want to drop packets in case (a) above. As > for the remaining 3 cases (b), (c) & (d) - I dont think, there is a good > reason > to make a distinction to respond differently in each of these cases. I would > suggest using the same approach for all three cases. > >> For NAT ports that DO have an >> active binding, however, I don't think it NATs should be allowed to respond >> actively with any "hard error" (whether ICMP or TCP RST), because doing so >> could make TCP hole punching unreliable and timing-sensitive. The standard >> scenario: >> >> 1. Clients A and B open TCP connections to rendezvous server S. >> 2. A asks S to help establish a connection to B. >> 3. S gives A and B each other's public and private endpoints. >> 4. A happens to get S's message before B does, so it does a TCP open to B. >> 5. B's NAT rejects A's attempt with an ICMP error (or RST or whatever). >> 6. A's NAT sees the error response come back and closes its TCP hole to B. >> 7. Client B finally gets S's message and attempts to connect to A. >> 8. B's NAT now opens a hole, but A's NAT has closed its hole, so A's NAT >> rejects B's connection attempt with an ICMP error (or RST or whatever). >> 9. B's NAT now sees the error and closes its hole. >> 10. A retries, and if it gets unlucky with the timing the cycle repeats... >> > [suresh] After step 6 above - I am not sure that A's NAT would simply close > the > associated NAT Session. I.e., When you see an ICMP Destination unreachable > message, forward the packet usign the matching NAT Session, but immediately > close the NAT Session right after that? I dont believe that would be the right > thing to do. I believe, the NAT Session should stay alive even after seeing > the > ICMP error message, perhaps with a reduced timeout. I would be curious to find > out what the empirical results are on this. > > If the NAT device were to simply delete the NAT Session upon seeign a ICMP > Dest > unreachable message, this could be the source of a serious attack on the NAT > device operation. > > Same thing after step 9 as well. > >> Senthil's earlier suggestion of using "host unreachable", on the grounds that >> >> RFC1122 specifies that it _must_ be treated as soft, would be acceptable if >> it it was actually consistently implemented that way - but he also mentioned >> that Linux for one doesn't treat it as soft for TCP SYNs (which is precisely >> what we're worried about for hole punching purposes). >> >> Suresh's suggestion of using code 10, "communication administratively >> prohibited", worries me even more because not only is it not formally >> specified at all whether it should be treated as a hard or soft error, but it >> >> seems very likely to me to be commonly interpreted as a hard error most of >> the time. Think about it: if communication with some host is >> administratively prohibited, then by conventional wisdom it would mean that >> the _system administrator_ set something up to prohibit that communication, >> which means that prohibition isn't going to go away until the system >> administrator "administratively" takes it away. An "administrative >> prohibition" isn't likely to go away soon on its own - hence it's a hard >> error, not a soft error. >> >> If there was a suitable ICMP response that we knew would always reliably be >> interpreted as a soft error, then I would go along with that. But as the >> situation stands, I think that a NAT MUST just silently drop any prohibited >> incoming packets directed at a bound port. Prohibition of packets directed >> at bound NAT ports is by nature a temporary prohibition, not an >> "administrative prohibition" - it's a temporary prohibition that lasts only >> until the internal client punches a hole by sending traffic to the >> appropriate external endpoint. Such a prohibition MUST elicit either a soft >> error from the NAT or no response at all. Since there seems to be no >> reliably soft response, the only option seems to be no response at all. >> > [suresh] Well, I wasnt thinking peer-to-peer when I suggested the ICMP Dest. > Unreachable. But, as you say, I agree, ICMP dest unreacable can be problematic > for peer-to-peer hosts, because we want the hosts to retry. Sounds like, the > right thing to do for a NAT is to simply drop the unallowed pkts. I dont see > any ICMP code that woudl be soft and makes sense. However, it seems, the NAT > device should keep metrics of the various types of pkt drops for diagnostic > purposes. > >> For non-bound NAT ports, I'm OK with any behavior - silently dropping >> packets, >> sending ICMP errors, or even sending back RSTs as a "real" host would, >> providing that any ICMP errors or RSTs sent back are suitably >> rate-controlled. > > [suresh] Please see my note earlier. I believe, the same logic shoudl apply > even here. I woudlnt treat this different from the case where a binding was > pre-existing. > >> Of course, sending back RSTs or ICMP errors for unbound >> ports but not for bound ports could be interpreted as a security weakness >> since it enables a port-scanning attacker to find out which NAT ports are >> bound. Thus, in situations where this information leakage is deemed >> unacceptable, I think the only acceptable behavior is for the NAT not to >> respond at all on any of its ports. "A black hole leaks no information." >> It's unfortunate that that means that prohibited connection attempts from >> external hosts will have to time out rather than receiving an immediate >> notification - but then, if all external hosts making "unsolicited" >> connection attempts are assumed to be attackers by default, then again from a >> >> security perspective, it seems best to make them wait and not hand out any >> information unnecessarily. >> > > [suresh] Yup. > >> Also, for what it's worth, I think that this is an issue that applies to UDP >> just as much as to TCP, with the minor difference that "UDP RST" responses >> aren't an option because they don't exist. :) >> > [suresh] Agreed. > >> Cheers, >> Bryan >> > > cheers, > suresh > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Tue, 17 May 2005 09:42:02 -0700 (PDT) From: Cullen Jennings Date: Tue, 17 May 2005 09:42:02 -0700 (PDT) Subject: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt In-Reply-To: <200505121427.18238.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Thank you for the many comments - I wanted to start a separate thread on your comment about this requirement and about the MTU stuff because theses seem to be the only ones were you were suggesting a change to the recommended behavior and most the others seem like a document change to how we describe the desired behavior. We are really only discussing if we recommend that the filtering is restrictive or not here. Somewhere you pointed out this is falling into the firewall area and may not even be relevant for BEHAVE to specify and I think I agree with you on that. At one point we had that but got strong feedback form implementers, please recommend (but don't mandate) something as they want to know what to do. We certainly want Full Cone NAT to be behave compliant. However, what you are proposing is making it such that a NAT with only Restricted filtering would *not* be behave compliant. I strongly disagree with this proposal. I understand your security argument below however I think it is wrong. A large portion of application that use UDP do not do connected UDP. Furthermore, the outside firewall that does this type of behavior is protecting the resources on the internal network from being consumed forwarding bogus packets even if the eventual end application will correctly discard them. We can not define behave such that a behave compliant NAT could not also be a fairly normally configured firewall. However, which of us is right or wrong about the security implications here turns out to probably be totally irrelevant. I phoned my colleagues at Linksys this morning and asked if they would do this. When they stopped laughing at me they told me no way. If they did this, netgear and dlink would claim their NATs were more secure than linksys NATs and they would get toasted in the market. They are not going to do full cone. I imagine your own testing shows the number of full cone NATs in the market is a) fairly small and b) becoming more rare. My testing indicates this. Furthermore, this topic was significantly discussed in the past, we have had consensus on it for the last two WG meetings. I'm not keen on reopening it with no new information. That said I would not care deeply if we said that the implementers could choose to do restrictive filtering or not, pointed out it was a Firewall issues, and did not recommend on way over the other. Cullen On 5/12/05 2:27 PM, "Bryan Ford" wrote: > *8. I disagree with REQ-7, which recommends "External filtering is endpoint > address dependent" behavior, because endpoint-dependent filtering interferes > with applications, and because it amounts to a recommendation to deploy > firewall functionality. This WG is about making NATs support applications > better and more deterministically, not about suggesting firewall practices. > (I don't even remember hearing any discussion about this recommendation on > the list so far, or what the rationale was for the current recommendation.) > > Once a NAT has implemented Consistent Endpoint Translation (i.e., "Cone NAT"), > as we require, the filtering policy the NAT implements on top of this is > purely a tradeoff between perceived security benefits and interference with > applications. Endpoint-Independent Filtering brings a strong benefit to > applications, whereas the security argument for Address- or Endpoint-Specific > Filtering is actually rather weak, as discussed below. > > * Application considerations: Endpoint-Independent Filtering ("Full Cone > NAT") is fundamentally more application-friendly than Address-Specific or > Endpoint-Specific Filtering ("[Port-]Restricted Cone NAT"), because the > former allows the application to have a public "rendezvous point" (albeit a > temporary one assigned by the NAT) at which it can be contacted proactively > by arbitrary external hosts, whereas the more restrictive filtering behaviors > do not. An application behind a NAT with restrictive filtering behavior is > forced always to depend on other public "rendezvous server" hosts in order to > be able to accept P2P-style connections of any kind initiated from other > endpoints. An application residing behind a Full Cone NAT, in contrast, can > actually _be_ a public rendezvous server, and even help set up P2P-style > connections among other less fortunate hosts, once it has discovered what its > NAT-assigned public IP address and port number are. > > * Security considerations: Restrictive filtering ostensibly has the benefit > of protecting applications on internal hosts from traffic it is not > expecting, i.e., from traffic from previously unknown external hosts or > endpoints. This behavior can only possibly benefit the application if the > application only ever initiates outgoing sessions from its internal port, and > is obviously a curse if the application ever wants to accept incoming > sessions from external hosts. The NAT has no way of knowing which is the > case. But suppose the application is one that only initiates outgoing > connections (i.e., a "traditional client/server app"), and thus might > "potentially" benefit from a NAT's restrictive filtering behavior. Consider > TCP and UDP separately: > > ** TCP: When a client/server app makes an outgoing TCP connection, it > typically does a "connect()" call to the host OS's sockets API without > bothering to bind() the socket, and the OS's TCP stack allocates a local TCP > port exclusively for the use of that connection. Any TCP packets the host OS > subsequently received on that port from endpoints other than the one it > connect()ed to will be summarily rejected with TCP RSTs by the host OS, and > the application never even sees any hint that they ever arrived. Even if the > application does a bind() before its connect() in order to use a specific > source port (e.g., a <1024 "privileged" port), it still almost always obtains > exclusive use of that port. An application indeed has to work really bloody > hard to set things up so that it can accept incoming TCP connections on the > same port it is using for an outgoing connection, using SO_REUSEADDR and > multiple sockets. No traditional client/server application is going to go to > all this effort just in order to create a security hole. :) In other words, > for TCP, restrictive filtering in practice provides absolutely zero > protection from the _application_: the only entity that the restrictive > filtering even affects is the host OS's protocol stack. Restrictive > filtering might for example benefit a host OS with a TCP stack that is so > broken that it fails to check the source IP address and port number on > incoming TCP packets at all, but if the host OS is _that_ broken then it > undoubtably has many other problems that the NAT can't possibly guard > against. > > ** UDP: When a client/server UDP app uses a UDP port for communication with > just one remote host, for convenience it typically does a connect() to the > appropriate remote UDP endpoint, so that it can just send messages with > send() or write() without having to specify a destination address for each > datagram, and so that it can receive messages with read() or recv() without > having to check the source address and port number in each message received. > In this case, the host OS effectively provides the external endpoint > filtering functionality as for TCP, and any restrictive filtering implemented > by the NAT again provides no security benefit at all to the application. A > UDP application that uses a single UDP port for communication with multiple > remote hosts, in contrast, must generally check the source IP addresses and > port numbers in the datagrams it receives just in order to distinguish > between the multiple communication sessions it is involved in, and hence it > will inherently provide its own external endpoint filtering. It's > conceivable that some abysmally buggy UDP applications might benefit from the > NAT's external filtering - e.g., a UDP application that only talks to one > external endpoint but doesn't use connect() and doesn't check the source > endpoint on incoming datagrams - but an application that is so seriously > broken probably has many other security vulnerabilities that can be exploited > despite the NAT's external filtering behavior, e.g., by finding out or > guessing the public server the application is talking to (which is easy in > many cases such as commercial games or services where there are only a few > well-known servers) and sending packets with spoofed source IP address and > UDP port numbers. Besides, many, perhaps the majority, of UDP applications > use UDP _because_ they need P2P-style communication, and so external > filtering by the NAT provides no practical security benefit and only causes > interference with the application. > > In summary, restrictive filtering in the NAT interferes with applications > substantially and provides very little or no real security benefit in > practice, considering the way communication works using standard sockets > APIs. As such, especially considering the purpose of this WG is to increase > the predictability and compatibility of NATs with applications and not to > specify standards for firewall functionality, it seems highly inappropriate > for this WG's documents to recommend firewall functionality that interferes > with applications while providing dubious security benefits. On the > contrary, I think this WG should recommend (although not necessarily mandate) > that NATs provide Endpoint-Independent Filtering by default. NAT vendors or > system administrators that are particularly paranoid about security and > perceive the security benefits to be worth the interference it causes with > applications can still enable more restrictive filtering policies, but that's > a firewall deployment issue, not a NAT functionality issue. We need to steer > clear from recommending firewall functionality. > > With that, I propose the following text for REQ-7: > > REQ-7: NATs MUST implement Endpoint-Independent > Filtering in their default configuration. > NATs SHOULD be configurable to support > Address-Specific Filtering or Endpoint-Specific Filtering > at the option of the system administrator. From huitema@windows.microsoft.com Tue, 17 May 2005 09:59:49 -0700 (PDT) From: "Christian Huitema" Date: Tue, 17 May 2005 09:59:49 -0700 (PDT) Subject: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain > However, which of us is right or wrong about the security implications > here > turns out to probably be totally irrelevant. I phoned my colleagues at > Linksys this morning and asked if they would do this. When they stopped > laughing at me they told me no way. If they did this, netgear and dlink > would claim their NATs were more secure than linksys NATs and they would > get > toasted in the market. They are not going to do full cone. I imagine your > own testing shows the number of full cone NATs in the market is a) fairly > small and b) becoming more rare. My testing indicates this. On the other hand, the same folks would have a problem if, say, X-Box games did not work through their products but worked well through the competition's offers. So, obviously, there has to be a compromise. The emerging consensus seems to be along the line of "address restricted cone". It enables replies to an UDP port from addresses to which a packet has already been sent, and it also enables multi-party sessions. It accounts for the fact that replies sometimes come from a different UDP. It blocks traffic sent by random sources, and thus offer a reasonable degree of protection. -- Christian Huitema From fluffy@cisco.com Tue, 17 May 2005 10:32:31 -0700 (PDT) From: Cullen Jennings Date: Tue, 17 May 2005 10:32:31 -0700 (PDT) Subject: [Ietf-behave] MTU in last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <200505121427.18238.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain The way the text is written right now, the NAT only needs to support storing a packet as large as the larger of the two MTUs. We can't mandate any particular minimum MTU size that has to be supported. Lots of Ethernet chip sets used in NATs has hardware limits on the MTU size. I would not be surprised to see some devices that can only do around 1500. On 5/12/05 2:27 PM, "Bryan Ford" wrote: > *9. In the discussion of fragmented datagrams, it is not clear whether NATs > must support datagram sizes up to the maximum of 64K, or whether it is > acceptable for a NAT to have a smaller maximum datagram size - e.g., a little > over 8K, the size needed by NFS traffic. > > Unless there are serious screams from NAT implementors here, I would say that > NATs MUST support full-size (up to 64K) fragmented datagrams. From fluffy@cisco.com Tue, 17 May 2005 10:35:57 -0700 (PDT) From: Cullen Jennings Date: Tue, 17 May 2005 10:35:57 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02503F12@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt I don't care deeply, this has been discussed before, I don't see it as really a big deal one way or the other - I will point out that part of the reason it si this way is that residential NAT vendors told us to make a short simple list that they could copy into their requirements document and refer back to RFC for details. This is trying to make that easy for them. On 5/17/05 7:03 AM, "Francois Audet" wrote: Yeah, you are right. Let's wait for more feedback. > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@xxxxxxxxxxxxxxxxx] > Sent: Monday, May 16, 2005 20:42 > To: Audet, Francois [SC100:9T51:EXCH]; 'Bryan Ford'; > 'ietf-behave@xxxxxxxxxxxxxxxxxxx' > Subject: RE: [Ietf-behave] WG last call: > draft-ietf-behave-nat-udp-01.txt > > > At 10:34 PM -0400 5/16/05, Francois Audet wrote: > >- You would prefer to have section 12.1 merged into 12. > There are plus and > > minuses to this approach, and I'm reluctant to change it > now. The rationale > > for the current model is that it emphasises the Requirements in a > >"check-list" > > type section. If there is a consensus that merging the > justification and > > the requirements into one section is better, I will do > it. Otherwise, I'll > > leave it as is. > > I read Bryan's request as merging the rationales *into the body of > the document*, along with the requirements. That sounds good to me. > > --Paul Hoffman, Director > --Cybersecurity Association > --www.cybersecurity.org > > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Tue, 17 May 2005 11:46:36 -0700 (PDT) From: Cullen Jennings Date: Tue, 17 May 2005 11:46:36 -0700 (PDT) Subject: [Ietf-behave] Terminology (again) - was WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <200505121427.18238.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Several of your points have to do with changing terminology. Let me try to address those in this email. On 5/12/05 2:27 PM, "Bryan Ford" wrote: > On Monday 25 April 2005 20:10, Jiri Kuthan wrote: >> This is a BEHAVE Working Group Last Call for comments >> on draft-ietf-behave-nat-udp-01. This last call closes >> Tuesday May 12, 2005. Please post any final comments you >> have on this draft to this list by that date. > > I think it is premature to have a last call on the UDP draft at this time. In > addition to the major issue of document organization already under > discussion, there are a substantial number of technical and writing issues > with the current UDP draft's content itself. (Some of these issues I already > discussed privately with the authors of the UDP draft.) First a brief > summary of each, then a more thorough discussion below: > > *1. The draft's use of the term "session" is unclear in various places, > because it doesn't distinguish between sessions as identified by (src IP, src > port, dst IP, dst port) on one side of the NAT or the other, or between > sessions within a single IP address domain and "logical sessions" that flow > across the NAT and hence cross IP address domains. I don't think the draft need to differentiate between incoming and outgoing sessions. It does differentiate between incoming and outgoing traffic for timer refresh. > > *2. The draft uses the terms "mapping" and "binding" in confusing ways that > are inconsistent with their historical meanings, and doesn't sufficiently > clarify its use of these terms in the "3. Terminology" section. In > particular, the draft uses the term "mapping" loosely in various places, > sometimes to mean "binding", sometimes apparently to mean other things, but > never properly defines either of these terms as they are used here. > "binding" is not used other than a type in section 9 which we will fix. I think mapping is clearly defined without mandating a specific implementation. > *3. The new terminology introduced in section 4.1 and 5.1, with the goal of > replacing the historically troublesome "Cone/Symmetric" terminology, is > hopelessly cumbersome. If we absolutely must, must, MUST invent new terms > (instead of just clarifying the old ones, which I still think would be a > better approach), then at least the new terms shouldn't take a whole line to > write out! As is, they'll never get used in practice because they're just > way too long; most people will in practice just keep using the cone/symmetric > terms (imprecisely and confusingly) because they're easy to say and remember. > I agree they should be short enough to use. Some people seem to be using "Address Independent Mapping" and "Address Depended Filtering" which don't seem too bad. Every time we have tried to change names, their was some group of folks that did not like the new names. I do like some of your names. > *4. The second "address and port mapping behavior" in section 4.1, "External > NAT mapping is endpoint address dependent", is unnecessary: no NAT that I've > ever heard of implements this behavior, because it just doesn't make sense at > the implementation level. uh - I might be misunderstanding you here. I think are saying that though "External NAT mapping is endpoint address and port dependent" and "External NAT mapping is endpoint independent" both exist, no one would every implement "External NAT mapping is endpoint address dependent". If this is what you mean, there is more than one NAT that does this. It is considered a feature by people that want to conceal the fact that traffic going to server A and to server B are both from the same client behind the NAT. > This behavior is also subsumed by the third > behavior ("External NAT mapping is endpoint address and port dependent"), and > both the second and third behaviors are going to be disallowed in the > requirements section at the end anyway. agreed > > *5. The vague notion of "session" used informally in the draft at present is > insufficient to make the text in "6. Hairpinning Behavior" precise or even > comprehensible. It is especially important that hairpin translation be > defined clearly and precisely here because as far as I know this will be the > first "official" IETF document that even mentions it. Is there some specific you can think of where we are underspecified in this section and implementers will do different things that cause applications not to work? > > *6. Section 8, "Deterministic Properties", is currently very opaque and > confusing as written, and it is not clear exactly it is trying to say. It > probably should be combined into earlier sections. The other section do precisely nail all the non deterministic behaviors we can think of. This one tries to capture one we can not think of. The proposed text seemed to only cover the ones we could think of which are already covered by other portions of the document. > > *7. It's very annoying and confusing that you have to read all the way through > the document before you ever see even a hint of the actual requirements for > NAT behavior that the document is trying to specify: e.g., that "Consistent > Endpoint Translation is GOOD" and "Inconsistent Endpoint Translation is BAD". agree but think this is better than the alternatives. Cullen From fluffy@cisco.com Tue, 17 May 2005 11:50:07 -0700 (PDT) From: Cullen Jennings Date: Tue, 17 May 2005 11:50:07 -0700 (PDT) Subject: Re: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 5/17/05 9:59 AM, "Christian Huitema" wrote: >> However, which of us is right or wrong about the security implications >> here >> turns out to probably be totally irrelevant. I phoned my colleagues at >> Linksys this morning and asked if they would do this. When they > stopped >> laughing at me they told me no way. If they did this, netgear and > dlink >> would claim their NATs were more secure than linksys NATs and they > would >> get >> toasted in the market. They are not going to do full cone. I imagine > your >> own testing shows the number of full cone NATs in the market is a) > fairly >> small and b) becoming more rare. My testing indicates this. > > On the other hand, the same folks would have a problem if, say, X-Box > games did not work through their products but worked well through the > competition's offers. So, obviously, there has to be a compromise. > > The emerging consensus seems to be along the line of "address restricted > cone". It enables replies to an UDP port from addresses to which a > packet has already been sent, and it also enables multi-party sessions. > It accounts for the fact that replies sometimes come from a different > UDP. It blocks traffic sent by random sources, and thus offer a > reasonable degree of protection. > > -- Christian Huitema Yes, I'm in 100% agreement with you. From fluffy@cisco.com Tue, 17 May 2005 11:50:46 -0700 (PDT) From: Cullen Jennings Date: Tue, 17 May 2005 11:50:46 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02503D3E@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt On 5/16/05 7:34 PM, "Francois Audet" wrote: - You've expressed the wish that we include the requirements as they occur in the document instead of having to wait for them in section 12 (copying them verbatim would be OK). I agree that it would make it easier for the reader to follow "where we are going" with this document. Section 12 would just be the consolidated summary of the requirements. I agree with this editorial recommendation. I will make the change however only if there is a consensus that it would be beneficial (but I support it). I think it is a bad idea to specify things two place and repeat text - we will end up with contradictions. Cullen From audet@nortel.com Tue, 17 May 2005 14:08:30 -0700 (PDT) From: "Francois Audet" Date: Tue, 17 May 2005 14:08:30 -0700 (PDT) Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF02562041@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message Right: we got the same feedback. They wanted a "checklist" type section.
-----Original Message-----From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] Sent: Tuesday, May 17, 2005 10:36To: Audet, Francois [SC100:9T51:EXCH]; 'Paul Hoffman'; 'Bryan Ford'; BehaveSubject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txtI don't care deeply, this has been discussed before, I don't see it as really a big deal one way or the other - I will point out that part of the reason it si this way is that residential NAT vendors told us to make a short simple list that they could copy into their requirements document and refer back to RFC for details. This is trying to make that easy for them. From audet@nortel.com Tue, 17 May 2005 14:10:28 -0700 (PDT) From: "Francois Audet" Date: Tue, 17 May 2005 14:10:28 -0700 (PDT) Subject: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF0256204D@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt Guys, The current draft actually does RECOMMEND "Address restricted cone". I'm hearing support from both of you for the current RECOMMENDATION. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Christian Huitema > Sent: Tuesday, May 17, 2005 10:00 > To: Cullen Jennings; Bryan Ford; Behave; audet@xxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt > > > > However, which of us is right or wrong about the security > implications > > here turns out to probably be totally irrelevant. I phoned my > > colleagues at Linksys this morning and asked if they would do this. > > When they > stopped > > laughing at me they told me no way. If they did this, netgear and > dlink > > would claim their NATs were more secure than linksys NATs and they > would > > get > > toasted in the market. They are not going to do full cone. I imagine > your > > own testing shows the number of full cone NATs in the market is a) > fairly > > small and b) becoming more rare. My testing indicates this. > > On the other hand, the same folks would have a problem if, > say, X-Box games did not work through their products but > worked well through the competition's offers. So, obviously, > there has to be a compromise. > > The emerging consensus seems to be along the line of "address > restricted cone". It enables replies to an UDP port from > addresses to which a packet has already been sent, and it > also enables multi-party sessions. It accounts for the fact > that replies sometimes come from a different UDP. It blocks > traffic sent by random sources, and thus offer a reasonable > degree of protection. > > -- Christian Huitema _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortel.com Tue, 17 May 2005 14:14:47 -0700 (PDT) From: "Francois Audet" Date: Tue, 17 May 2005 14:14:47 -0700 (PDT) Subject: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF02562070@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt To reiterate both Christian's and Cullen's points, lots of applications (like SIP phones) also behave like an address restricted cone NAT (from a filtering point of view) in that they don't use connected sockets, but still check for the IP address of the far end to match what it expects. For the same reasons Christian highlights. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Christian Huitema > Sent: Tuesday, May 17, 2005 10:00 > To: Cullen Jennings; Bryan Ford; Behave; audet@xxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt > > > > However, which of us is right or wrong about the security > implications > > here turns out to probably be totally irrelevant. I phoned my > > colleagues at Linksys this morning and asked if they would do this. > > When they > stopped > > laughing at me they told me no way. If they did this, netgear and > dlink > > would claim their NATs were more secure than linksys NATs and they > would > > get > > toasted in the market. They are not going to do full cone. I imagine > your > > own testing shows the number of full cone NATs in the market is a) > fairly > > small and b) becoming more rare. My testing indicates this. > > On the other hand, the same folks would have a problem if, > say, X-Box games did not work through their products but > worked well through the competition's offers. So, obviously, > there has to be a compromise. > > The emerging consensus seems to be along the line of "address > restricted cone". It enables replies to an UDP port from > addresses to which a packet has already been sent, and it > also enables multi-party sessions. It accounts for the fact > that replies sometimes come from a different UDP. It blocks > traffic sent by random sources, and thus offer a reasonable > degree of protection. > > -- Christian Huitema _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From sg266@cornell.edu Tue, 17 May 2005 15:03:45 -0700 (PDT) From: Saikat Guha Date: Tue, 17 May 2005 15:03:45 -0700 (PDT) Subject: [Ietf-behave] TCP through NATs (was Re: How should NATs reject TCP packets?) In-Reply-To: Message-ID: <1116367416.22848.54.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630133.multipart/signed" --Boundary..27398.1163630133.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-05-17 at 07:35 -0700, Cullen Jennings wrote: > If you want STUNT to work and you want to do it on fairly normal OS without > replacing the TCP stacks, what behavior do you need to assume here and how > much can you still leave open? We studied TCP through existing NATs; the results are under submission: http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf In response to Cullen's question, when it comes to packet filtering, it would be nice to assume: 1. TCP simultaneous open (or even just SYN-in after a SYN-out) works 2. One of: a) NATs don't generate either RSTs or ICMP Unreachables in response to unsolicited SYNs. or b) NATs don't release the mapping if a) is violated i.e. if they receive a RST/ICMP in response to a SYN Attachment: signature.asc --Boundary..27398.1163630133.multipart/signed Content-Type: application/octet-stream; name="pgp00028.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00028.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ2ltbzRuRmx0cWk2OTEvb1JBaVlIQUo5OG1VSG5xWEpxbnEvNTVmSVRD UzRiMWdDNVJRQ2ZjRG5OClpDMk45b1BRcmFVOGVMTlNIaCt6YlQ0PQo9bzdjSgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630133.multipart/signed-- From sg266@cornell.edu Tue, 17 May 2005 15:15:39 -0700 (PDT) From: Saikat Guha Date: Tue, 17 May 2005 15:15:39 -0700 (PDT) Subject: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: <1116368136.22848.60.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630133.multipart/signed" --Boundary..27398.1163630133.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-05-17 at 09:59 -0700, Christian Huitema wrote: > The emerging consensus seems to be along the line of "address restricted > cone". It enables replies to an UDP port from addresses to which a > packet has already been sent, and it also enables multi-party sessions. Just curious -- does this hold for TCP as well? Existing NATs are predominantly "restricted" (both address and port) for TCP though we did notice some "address restricted" ones. -- Saikat Attachment: signature.asc --Boundary..27398.1163630133.multipart/signed Content-Type: application/octet-stream; name="pgp00029.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00029.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ2ltMEluRmx0cWk2OTEvb1JBZ3V4QUpzSDdFZkd1NFFHc3hUcnVkWHAv Ujc0MnUwQzhnQ2ZUNTJVClJncU5XekhFekpUM08wdng2WjdtTnRzPQo9dFh4cQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630133.multipart/signed-- From huitema@windows.microsoft.com Tue, 17 May 2005 20:45:16 -0700 (PDT) From: "Christian Huitema" Date: Tue, 17 May 2005 20:45:16 -0700 (PDT) Subject: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain Saikat Guha wrote: > On Tue, 2005-05-17 at 09:59 -0700, Christian Huitema wrote: > > The emerging consensus seems to be along the line of "address restricted > > cone". It enables replies to an UDP port from addresses to which a > > packet has already been sent, and it also enables multi-party sessions. > > Just curious -- does this hold for TCP as well? Existing NATs are > predominantly "restricted" (both address and port) for TCP though we did > notice some "address restricted" ones. I personally do not expect peer-to-peer TCP to work through NAT. I cannot convince myself that any of the proposed TCP solutions is practical. In any case, I consider establishing TCP connections a different problem than allowing UDP associations. -- Christian Huitema From huitema@windows.microsoft.com Tue, 17 May 2005 21:26:41 -0700 (PDT) From: "Christian Huitema" Date: Tue, 17 May 2005 21:26:41 -0700 (PDT) Subject: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain > Saikat Guha wrote: > > On Tue, 2005-05-17 at 09:59 -0700, Christian Huitema wrote: > > > The emerging consensus seems to be along the line of "address > restricted > > > cone". It enables replies to an UDP port from addresses to which a > > > packet has already been sent, and it also enables multi-party > sessions. > > > > Just curious -- does this hold for TCP as well? Existing NATs are > > predominantly "restricted" (both address and port) for TCP though we > did > > notice some "address restricted" ones. > > I personally do not expect peer-to-peer TCP to work through NAT. I > cannot convince myself that any of the proposed TCP solutions is > practical. In any case, I consider establishing TCP connections a > different problem than allowing UDP associations. Well, I wrote this before reading the paper that Saikat and Paul published. Their experiment shows that a combination of simultaneous TCP openings and port prediction may very often succeed establishing peer-to-peer TCP connections through NAT, which is quite interesting. Still, this is a different problem than allowing UDP associations... -- Christian Huitema From baford@mit.edu Wed, 18 May 2005 05:38:17 -0700 (PDT) From: Bryan Ford Date: Wed, 18 May 2005 05:38:17 -0700 (PDT) Subject: Re: How should NATs reject TCP packets? (was:: Re: [Ietf-behave] Next rev on TCP Behavior) In-Reply-To: <20050513233157.59919.qmail@web40426.mail.yahoo.com> Message-ID: <200505180838.13220.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Inline... On Friday 13 May 2005 19:31, Pyda Srisuresh wrote: > [suresh] I believe, there are principally four kinds of scenarios that > could cause the NAT to reject incoming IP packets. > > a) The packet is not the first packet of a session and the packet does not > match any existing NAT Sessions. > > b) The packet is the first packet of a session; NAT could permit the > session to go through. However, the NAT device ran out of resources such as > memory or NAT address pool or port pool etc. > > c) The packet is the first packet of a session; But, the direction of the > first packet is not permitted by NAT, per the NAT address map; And, there > is no existing BINDing on the NAT device exists for the same dest > addres/port. > > d) The packet is the first packet of a session. The direction of the first > packet is not permitted by NAT, even though a BINDing exists for the same > dest address/port that permits sessions in the opposite direction. > > I believe, we all agree we simply want to drop packets in case (a) above. > As for the remaining 3 cases (b), (c) & (d) - I dont think, there is a good > reason to make a distinction to respond differently in each of these cases. > I would suggest using the same approach for all three cases. I agree - I would prefer that they all be the same. But case (d) is the problem - for that case it's really important for hole punching that the NAT's response either be a reliably "soft" error response of some kind, or no error at all - and since there seems to be no reliable "soft" error response, that means no error at all. Since case (d) demands a soft response, if we want consistency across the board, it seems we need a soft response is in order across the board for all cases of the NAT rejecting IP packets. > > For NAT ports that DO have > > an active binding, however, I don't think it NATs should be allowed to > > respond actively with any "hard error" (whether ICMP or TCP RST), because > > doing so could make TCP hole punching unreliable and timing-sensitive. > > The standard scenario: > > > > 1. Clients A and B open TCP connections to rendezvous server S. > > 2. A asks S to help establish a connection to B. > > 3. S gives A and B each other's public and private endpoints. > > 4. A happens to get S's message before B does, so it does a TCP open to > > B. 5. B's NAT rejects A's attempt with an ICMP error (or RST or > > whatever). 6. A's NAT sees the error response come back and closes its > > TCP hole to B. 7. Client B finally gets S's message and attempts to > > connect to A. 8. B's NAT now opens a hole, but A's NAT has closed its > > hole, so A's NAT rejects B's connection attempt with an ICMP error (or > > RST or whatever). 9. B's NAT now sees the error and closes its hole. > > 10. A retries, and if it gets unlucky with the timing the cycle > > repeats... > > [suresh] After step 6 above - I am not sure that A's NAT would simply close > the associated NAT Session. I.e., When you see an ICMP Destination > unreachable message, forward the packet usign the matching NAT Session, but > immediately close the NAT Session right after that? I dont believe that > would be the right thing to do. I believe, the NAT Session should stay > alive even after seeing the ICMP error message, perhaps with a reduced > timeout. I would be curious to find out what the empirical results are on > this. The very nice draft paper Saikat Guha just pointed to on the list has some useful results regarding this issue: http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf Specifically, according to the table on page 8, up to 28% of NATs appear to "close the hole" immediately upon receiving an ICMP or RST, depending on the exact sequence involved. Which is fortunately already a minority of NATs that will hopefully continue to get smaller in the future, but not insignificant. > If the NAT device were to simply delete the NAT Session upon seeign a ICMP > Dest unreachable message, this could be the source of a serious attack on > the NAT device operation. Good point - another reason such NATs should be considered broken. But they do exist. I believe the current TCP BEHAVE draft already outlaws this behavior, which is good. So I suppose the upshot is that if a NAT rejects incoming sessions with ICMP errors, that won't necessarily cause a serious problem as long as the other "facing" NAT is BEHAVE-compliant in its "hole closing" behavior, and as long as the end-host application retries outgoing hole punching attempts that fail due to those ICMP errors. I think I would still prefer recommending no active response to unsolicited traffic, but I could live with something like this for example: NATs MUST NOT reject incoming TCP SYNs with a RST. NATs SHOULD simply drop incoming SYNs for disallowed sessions. NATs MAY alternatively respond with an ICMP error. In the latter case, the ICMP error MUST use a "soft error" response code (e.g., "destination unreachable"), and ICMP responses MUST be rate-limited. I could live with the "SHOULD" being weakened to a "MAY", but I'd prefer that it be a "SHOULD". > Same thing after step 9 as well. > > > Senthil's earlier suggestion of using "host unreachable", on the grounds > > that > > > > RFC1122 specifies that it _must_ be treated as soft, would be acceptable > > if it it was actually consistently implemented that way - but he also > > mentioned that Linux for one doesn't treat it as soft for TCP SYNs (which > > is precisely what we're worried about for hole punching purposes). > > > > Suresh's suggestion of using code 10, "communication administratively > > prohibited", worries me even more because not only is it not formally > > specified at all whether it should be treated as a hard or soft error, > > but it > > > > seems very likely to me to be commonly interpreted as a hard error most > > of the time. Think about it: if communication with some host is > > administratively prohibited, then by conventional wisdom it would mean > > that the _system administrator_ set something up to prohibit that > > communication, which means that prohibition isn't going to go away until > > the system administrator "administratively" takes it away. An > > "administrative prohibition" isn't likely to go away soon on its own - > > hence it's a hard error, not a soft error. > > > > If there was a suitable ICMP response that we knew would always reliably > > be interpreted as a soft error, then I would go along with that. But as > > the situation stands, I think that a NAT MUST just silently drop any > > prohibited incoming packets directed at a bound port. Prohibition of > > packets directed at bound NAT ports is by nature a temporary prohibition, > > not an > > "administrative prohibition" - it's a temporary prohibition that lasts > > only until the internal client punches a hole by sending traffic to the > > appropriate external endpoint. Such a prohibition MUST elicit either a > > soft error from the NAT or no response at all. Since there seems to be > > no reliably soft response, the only option seems to be no response at > > all. > > [suresh] Well, I wasnt thinking peer-to-peer when I suggested the ICMP > Dest. Unreachable. But, as you say, I agree, ICMP dest unreacable can be > problematic for peer-to-peer hosts, because we want the hosts to retry. > Sounds like, the right thing to do for a NAT is to simply drop the > unallowed pkts. I dont see any ICMP code that woudl be soft and makes > sense. However, it seems, the NAT device should keep metrics of the > various types of pkt drops for diagnostic purposes. Agreed. > > For non-bound NAT ports, I'm OK with any behavior - silently dropping > > packets, > > sending ICMP errors, or even sending back RSTs as a "real" host would, > > providing that any ICMP errors or RSTs sent back are suitably > > rate-controlled. > > [suresh] Please see my note earlier. I believe, the same logic shoudl > apply even here. I woudlnt treat this different from the case where a > binding was pre-existing. Agreed. Bryan From baford@mit.edu Wed, 18 May 2005 07:12:35 -0700 (PDT) From: Bryan Ford Date: Wed, 18 May 2005 07:12:35 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <6.0.3.0.0.20050426011721.055967c0@localhost> Message-ID: <200505181012.31573.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Hi Paul, thanks for your feedback on my comments - nice that we agree on many of them. On Monday 16 May 2005 11:58, Paul Hoffman wrote: > First, a *big* thanks to Bryan for reading this carefully and > proposing new text. My responses here are as a non-implementer, but > someone who will soon be doing NAT testing. It would be good to hear > responses from NAT implementers. > > At 2:27 PM -0400 5/12/05, Bryan Ford wrote: > >*1. The draft's use of the term "session" is unclear in various places, > >because it doesn't distinguish between sessions as identified by (src IP, > > src port, dst IP, dst port) on one side of the NAT or the other, or > > between sessions within a single IP address domain and "logical sessions" > > that flow across the NAT and hence cross IP address domains. Further, > > the vague notion of "session" used informally in the draft at present is > > insufficient to make the text in "6. Hairpinning Behavior" precise or > > even comprehensible. > > The current "session" definition made sense to me, but that doesn't > mean that my understanding was correct. Your additional definitions > also made sense, and were certainly more precise than the ones in the > draft. However, I can't judge if they are worth using until I see > where the three types of sessions you define are to be used in the > document. That is, the current use of "session" seemed fine, but if > we are going to add your types of sessions, we need to also say for > each use of the term, which kind of session it is. I would tend to > keep the current simpler definition unless implementers say that they > are confused. The standard basic definition of "session" as a 4-tuple (src IP, src port, dst IP, dst port), only makes sense _within_ a particular IP address space. In the pre-NAT world this definition was fine, but NATs bridge multiple IP address spaces, and the basic definition of "session" provides no way to talk or reason about how a logical session _crosses_ a NAT: i.e., how the session 4-tuple on one side of a NAT relates to the session 4-tuple on the other. That's why the term "NAT Session" is needed in this context. Note that RFC 4008 already introduced the term "NAT Session" and uses it in a fashion consistent with what I proposed. My proposed text refines it just slightly further so as to be able to account for hairpin translation sessions. Without being able to talk precisely about how a logical session flows through a NAT in this way, for example, the description of "Hairpinning Behavior" in Section 6 is ad hoc and imprecise and is going to seem pretty opaque to anyone who isn't already familiar with the concept of hairpin translation. > >*2. The draft uses the terms "mapping" and "binding" in confusing ways > > that are inconsistent with their historical meanings, and doesn't > > sufficiently clarify its use of these terms in the "3. Terminology" > > section. In particular, the draft uses the term "mapping" loosely in > > various places, sometimes to mean "binding", sometimes apparently to mean > > other things, but never properly defines either of these terms as they > > are used here. > > I went through and looked at each use of the term "mapping" in the > current draft, and don't find any inconsistency or confusion. Of > course, I could be missing some detail that is important to > implementers (not to protocol designers); having specific examples of > where that term fails them would be useful. The problem with the term "mapping" is that its definition is very vague from the start and is used inconsistently. For starters, consider the definition: This document uses the term "address and port mapping" as the translation between an external address and port and an internal address and port. Note that this is not the same as an "address binding" as defined in RFC 2663. This actually only defines "address and port mapping", leaving the reader to wonder whether the subsequent use of plain term "mapping" refers to this definition or to some more generic concept. Defining a "mapping" as "the translation between an X and a Y" is not very helpful because it hasn't been stated what "a translation" is either - the definition sounds very circular to me. The final sentence saying that "a mapping is not the same as a binding" is similarly unhelpful; saying what something is not does not really help to identify what it is. At least we do know what a "binding" is. I suggest the following alternative text, which I believe remains consistent with the spirit of the existing definition: This document uses the term "mapping" to refer to the association between the internal source endpoint and external source endpoint in an outgoing NAT session, which determines how the NAT translates packets flowing over the NAT session. Two outgoing NAT sessions with matching internal source endpoints and matching external source endpoints are said to use "the same mapping", irrespective of the internal or external destination endpoints involved in defining the respective NAT sessions. Section 4.1 then uses the term "mapping" to refer to a property of outgoing NAT Sessions: specifically, to the relationship between the NAT Session's internal source endpoint and external source endpoint. But it never really makes clear that it is specifically the source endpoint that it is talking about, let alone giving any clue as to whether "mapping" _always_ refers to source endpoints or not. I think the above proposed definition text would make that clearer. Section 4.2.3 then apparently starts using the term "mapping" to refer to a NAT Session itself rather than to a specific property of a NAT Session. For example: "Sequential port assignment assumes that the application will open a mapping for RTP first and then open a mapping for RTCP." What does it mean to "open a mapping"? If a "mapping" is just a "translation between an external address and port and an internal address and port", then this makes no sense because a translation between internal and external source endpoints can only be uniquely identified in general via a complete session 4-tuple: applications "open" sessions, not mappings. I suggest using the terms "session" or "NAT session" instead as appropriate here. Similarly, 4.3 and 4.4 seem to use the term "mapping" to mean "NAT session". Section 5.1 then apparently goes back to using the term "mapping" to refer to the relationship between internal and external source endpoints of a NAT session. Finally, section 6 uses the term "active mapping", which is never defined, to refer to a "port binding" (as specified in RFC 4008) rather than to either of the above uses. > As for "binding", it is only used in the body of the document in > exactly one place. In section 9, first paragraph, the term "binding" > should be changed to "mapping". This one mistake is not a good enough > reason to bring back the term. The term "binding" may currently only be used here, but various parts of the document would be made much clearer with judicious use of this perfectly good term which has extensive historical precedent and a concrete definition in RFC 4008. Particularly in section 4.1 and 5.1, and of course in substitute for the vague term "active mapping" in section 6. > >*4. The second "address and port mapping behavior" in section 4.1, > > "External NAT mapping is endpoint address dependent", is completely > > unnecessary: no NAT that I've ever heard of implements this behavior > > because it just doesn't make sense at the implementation level, this > > behavior is subsumed by the third behavior ("External NAT mapping is > > endpoint address and port dependent"), and both the second and third > > behaviors are going to be disallowed in the requirements section at the > > end anyway. > > This sounds like a good reason to combine the two and note the fact > that the combined description is not covered in the document. Agreed. > >* Instead of saying that "a NAT's address and port mapping behavior is > >'External NAT mapping is endpoint independent'" (14 words), just say that > > the NAT has "Consistent Endpoint Translation" (3 words). In other words, > > when the NAT translates the private source endpoint of a new session > > crossing a NAT into a corresponding public port, it ALWAYS translates > > that private source endpoint to the same public source endpoint - i.e., > > "consistently". > > > >* Similarly, instead of saying that "a NAT's address and port mapping > > behavior is 'External NAT mapping is endpoint address and port > > dependent'", just say that the NAT has "Inconsistent Endpoint > > Translation". A NAT has Inconsistent Endpoint Translation if it EVER > > translates source endpoints inconsistently under ANY conditions. That > > is, a NAT that "usually" behaves like a Cone NAT but "occasionally" > > switches to symmetric behavior for certain translations, because of > > contention for a particular NAT port for example, will still have > > "Inconsistent Endpoint Translation". > > > >* Drop the "External NAT mapping is endpoint address dependent" behavior > >entirely, because it is logically subsumed by "Inconsistent Endpoint > >Translation", no NAT I know of implements this particular intermediate > >behavior, and it is just another variation of deprecated behavior that > > we're going to disallow in the requirements section anyway. > > > >* Instead of saying that a NAT's filtering behavior is "External filtering > > is endpoint independent", just say that the NAT has "Endpoint-Independent > > Filtering". > > > >* Similarly, Instead of "External filtering is endpoint address > > dependent", just say the NAT has "Address-Specific Filtering" > > > >* Finally, instead of "External filtering is endpoint address and port > >dependent", just say the NAT has "Endpoint-Specific Filtering". > > All of these sound fine to me. Excellent. > >Note that I suggest saying "Endpoint-Specific Filtering" here rather than > >"Endpoint-Dependent Filtering" because the latter sounds like it would > >subsume "Address-Dependent Filtering". A filtering behavior that "depends > >on" the external address indeed also by logical extension "depends on" the > >external endpoint, even if it doesn't really depend on the port part of > > the endpoint. Saying that the filtering is "Endpoint-Specific", in > > contrast, I think makes it more clear that the filtering is really > > specific to _both_ the address and port number components of the > > endpoint, without actually having to say "endpoint address and port > > specific" or something clumsy like that. > > > >Now we can use the proposed terminology to clarify the historical > >Cone/Symmetric terminology very easily and concisely: > > > >Symmetric NAT := Inconsistent Endpoint Translation. > >Cone Nat := Consistent Endpoint Translation. > >Full Cone Nat := Consistent Endpoint Translation with Endpoint-Independent > >Filtering. > >[Address-]Restricted Cone Nat := Consistent Endpoint Translation with > >Address-Specific Filtering > >Port-Restricted Cone Nat := Consistent Endpoint Translation with > >Endpoint-Specific Filtering > > > >With the above proposal in mind, here is my suggested rewrite for section > > 4.1, which both fixes the terminology and also helps address the earlier > > issues *1 and *2 above: > > > >--- > > > >4.1 Address and Port Mapping > > > > When an internal endpoint initiates a new UDP session targetted at an > > endpoint on the external network, the NAT establishes a new outgoing > > NAT session so that subsequent response packets from the external > > endpoint can be received by the NAT, translated, and forwarded back > > to the original internal endpoint. To form this new outgoing NAT > > session, the NAT uses the source and destination endpoints from the > > original packet that initiated the session, in order to define the > > internal "origin session" component of the NAT session. The NAT > > must then compute a corresponding "target session" component in order > > to define the corresponding UDP session as it will appear on the > > external network. > > > > For Traditional NAT, the destination address and port number is > > not translated in outgoing NAT sessions, so the NAT merely needs to > > assign an external source IP address and UDP port to form the new > > NAT session. If the NAT receives a packet from the internal network > > with a given (internal source IP, internal source port, external > > target IP, external target port) session tuple, for example, the NAT > > must "map" the internal source endpoint to a corresponding external > > source endpoint that is valid in the external IP address realm, > > in order to form the new outgoing NAT session. We refer to the way > > the NAT maps an internal source endpoint to the corresponding external > > source endpoint, while establishing a new outgoing NAT session, > > as the NAT's address and port mapping behavior. > > > > For many applications, it is important to distinguish the behavior > > of the NAT when applications establish multiple simultaneous outgoing > > NAT sessions from a single internal source endpoint to distinct > > external target endpoints. For example, suppose a node X on the > > internal network has already initiated an outgoing NAT session from > > internal source endpoint X:x (address:port), to a particular > > external destination endpoint Y1:y1. The NAT has mapped the internal > > source endpoint, X:x, to an external source endpoint X1':x1' in the > > external IP address realm, to form the full NAT session tuple. > > Now suppose node X initiates a new session from the same internal > > source endpoint, X:x, to a new external destination endpoint Y2:y2, > > and in response the NAT maps the internal source endpoint X:x > > to an external source endpoint X2':x2' to form the NAT session > > tuple to translate this new session. The relationship between > > X1':x1' and X2':x2' for various combinations of the relationship > > between Y1:y1 and Y2:y2 is critical for describing the NAT behavior. > > This arrangement is illustrated in the following diagram: > > > > > > > > The following address and port mapping behavior are defined: > > > > Consistent Endpoint Translation: > > When the NAT establishes the first outgoing NAT session > > from an internal IP address and port X:x to any external > > target endpoint, choosing some corresponding external source > > IP address and port X1':x1' in the process, the NAT also > > establishes a persistent port binding between the internal > > endpoint X:x and X1':x1' in the process, and uses that > > port binding to determine the external source endpoint for > > any subsequent outgoing NAT sessions that originate from > > the same internal source endpoint X:x. Specifically, > > X1':x1' equals X2':x2' for all values of Y2:y2. In terms > > of the NAT terminology in RFC 3489, this mapping behavior > > constitutes "Cone NAT", where the sub-type (Full Cone > > versus Restricted versus Port-Restructed Cone) is > > based on the filtering behavior to be discussed later. > > > > As a consequence of establishing a port binding from X:x to > > X1':x1' in response to the first outgoing session originating > > from X:x, the NAT also effectively "allocates" the external > > source endpoint X1':x1' exclusively to the use of this port > > binding, so that no other session originating from a different > > internal source endpoint may be translated so as to use the > > same external source endpoint X1':x1', while this port binding > > is active. This "exclusive port allocation" behavior is > > crucial for a NAT to have consistent endpoint translation, > > because otherwise the NAT could "paint > > itself into a corner" and make it impossible to translate > > future sessions involving the original source endpoint X:x > > correctly. For example, suppose the NAT has established > > a NAT session that translates the internal session (X:x,Y1:y1) > > to an external session (X1':x1',Y1:y1). Suppose further > > that it has incorrectly established a second NAT session > > translating an unrelated internal session (X2:x2,Y2:y2) to > > the external session (X1':x1',Y2:y2), re-using the external > > source endpoint X1':x1' between these two unrelated sessions. > > If node X now initiates a new outgoing session from X:x to > > Y2:y2, then to preserve the Consistent Endpoint > > Translation property the NAT would > > have to translate the new internal session (X:x,Y2:y2) > > to the external session tuple (X1':x1',Y2:y2) - but this > > external session tuple is the same as the external session > > tuple the NAT has already assigned to the prior unrelated > > session originating from X2:x2, and the two sessions would > > hence be indistinguishable on the external network. In > > effect, therefore, a NAT MUST exclusively allocate an > > external source port to a single internal source port > > for the duration of the corresponding port binding, > > in order to have Consistent Endpoint Translation. > > > > Inconsistent Endpoint Translation: > > When setting up a new outgoing NAT session from an internal > > source endpoint X:x to an external target endpoint Y2:y2, > > the NAT may map the internal source endpoint X:x to any > > external source endpoint X2':x2' of its choosing, regardless > > of how it has previously mapped any existing sessions > > originating from the same internal source endpoint X:x. > > Specifically, X1':x1' equals X2':x2' only if Y2:y2 equals > > Y1:y1. Some existing NATs usually but do not always > > translate source endpoints consistently under all > > operating conditions; such NATs are still classified as > > having Inconsistent Endpoint Translation. > > From an RFC 3489 NAT perspective, but not necessarily > > a filtering perspective, this behavior constitutes > > "Symmetric NAT". > > > > It is important to note that ... > > > >--- > > > >...and the rest of section 4.1 and section 4.2 look basically fine to me. > > This generally looks OK, but I am leery of bringing up the RFC 3489 > terminology. It isn't useful to *NAT developers*, it is only useful > to protocol designers who liked the old terms. It doesn't help reach > our goal of benefiting NAT developers. It also doesn't hurt that > much, it just adds statements that make the section longer than > needed. I think it's very important to make sure there's a concrete, well-defined relationship between the new terminology and the old, even if that relationship is only useful to some people and not all. Otherwise this will be the beginning of neverending questions about what that relationship is from people who are familiar with one set of terms but not the other. > Also, please remove "UDP" in the very first sentence; it is true > regardless of whether it is UDP or TCP. But this is the BEHAVE-UDP draft! As I've already pointed out extensively, this content really belongs in a separate transport-independent document, but as long as it's in a document that's expressly focused on UDP only, the content should make no pretensions to being more general than UDP. >[various noncontentious points elided...] > > >*8. I disagree with REQ-7, which recommends "External filtering is > > endpoint address dependent" behavior, because endpoint-dependent > > filtering interferes with applications, and because it amounts to a > > recommendation to deploy firewall functionality. This WG is about making > > NATs support applications better and more deterministically, not about > > suggesting firewall practices. (I don't even remember hearing any > > discussion about this recommendation on the list so far, or what the > > rationale was for the current recommendation.) > > > >Once a NAT has implemented Consistent Endpoint Translation (i.e., "Cone > > NAT"), as we require, the filtering policy the NAT implements on top of > > this is purely a tradeoff between perceived security benefits and > > interference with applications. Endpoint-Independent Filtering brings a > > strong benefit to applications, whereas the security argument for > > Address- or Endpoint-Specific Filtering is actually rather weak, as > > discussed below. > > Agree. It is fine to talk about the security considerations of not > allowing additional traffic in, but having this as a SHOULD is > overkill. > > >With that, I propose the following text for REQ-7: > > > > REQ-7: NATs MUST implement Endpoint-Independent > > Filtering in their default configuration. > > NATs SHOULD be configurable to support > > Address-Specific Filtering or Endpoint-Specific Filtering > > at the option of the system administrator. > > Agree, as long as we add some of your text (that I elided) to the > Security Considerations section to help the few implementers who > actually read it to decide what to do. Yes, I think having such text in the Security Considerations section would be a good idea, and I'll volunteer to rework the text specifically for that purpose. > >*9. In the discussion of fragmented datagrams, it is not clear whether > > NATs must support datagram sizes up to the maximum of 64K, or whether it > > is acceptable for a NAT to have a smaller maximum datagram size - e.g., a > > little over 8K, the size needed by NFS traffic. > > > >Unless there are serious screams from NAT implementors here, I would say > > that NATs MUST support full-size (up to 64K) fragmented datagrams. > > We should follow the MUSTs and SHOULDs for whatever the current > standards are. I failed to find that in my search; hopefully someone > on the list can help? I don't know of any either, other than section 3.3.2 of RFC 1122 which specifies an EMTU_R, "the largest datagram size that can be reassembled", of at least 576 bytes - an unrealistically low lower bound for current networks. It obviously needs to be above 8K on account of NFS traffic; I don't know of any specific reason offhand why it shouldn't be 64K. Cheers, Bryan From baford@mit.edu Wed, 18 May 2005 08:04:06 -0700 (PDT) From: Bryan Ford Date: Wed, 18 May 2005 08:04:06 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02503D3E@zrc2hxm0.corp.nortel.com> Message-ID: <200505181103.59522.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Monday 16 May 2005 22:34, Francois Audet wrote: > Bryan, > > Here are some responses to your comments. > > --------------- > > "Annoying" placement of the Requirements: > > - You would prefer to have section 12.1 merged into 12. No, that's not what I want - I want section 12.1 merged into sections 4-11, in the main body of the text. > There are plus and > minuses to this approach, and I'm reluctant to change it now. The > rationale > for the current model is that it emphasises the Requirements in a > "check-list" > type section. If there is a consensus that merging the justification and > the requirements into one section is better, I will do it. Otherwise, > I'll > leave it as is. I completely agree with having a short checklist-style Requirements section, and I don't think it should be unnecessarily bloated with discussion or justification. The discussion and justification text belongs in the main body of the text, sections 4-11, which introduces the behavioral properties being discussed in the first place. > Use of term "session", "Mapping" and "Binding" > > - In the document, the term "session" is from the point of view of the > endpoints. This is why we talk about going "through" the NAT. This is > why we don't talk of a session being in a "specific realm". There is > one session, and it goes through the NAT. The NAT maps addresses and > ports. If it is implemented as 2 sessions in the NAT, as it is likely, > that is OK, but it is unecessary to explain in the document. It's fine and appropriate to use the term "session" from the viewpoint of one of the endpoints or the other, each of which lives in a specific IP address realm - but since a "session" (4-tuple) is only well-defined within a specific IP realm, that term alone is insufficient to describe precisely _how_ a logical session "flows through" a NAT, or even what the logical notion of "session" actually means to a NAT. > - We use the "mapping" terminology instead of your double-play of "binding" > and "NAT session". We find this "mapping" to much more less complicated > to explain than refering to "bindings" for certain types of NATs with NAT > sessions, and then to NAT that don't have "NAT sessions" but instead rely > on inactivity timers. Disagree, for the reasons I went into in my reply to Paul Hoffman's response. > - Furthermore, it is not clear to us at all that all NATs have been built > using > the same model as you describe. It seems like they is tremendous > variability > in the logical model that people have been using, creating lots of > incompatible NATs. Yes, and by refusing to _provide_ a well-defined "logical model" for NATs, you are inviting this tremendous variability to continue and to produce still more incompatible NATs! > Address and port mapping terminology: > > - The term "consistent mapping" is ambiguous, unlike "Endpoint independent > mapping" which is not. But "Endpoint independent mapping" is still ambiguous and in my mind far more confusing, because it gives no indication of _what_ is independent of _which_ endpoint. It seems to be trying to be a "self-explanatory" term, but failing miserably. We could make the terminology truly self-explanatory by expanding it even further, but that would make it even more cumbersome. The whole purpose of such terminology is to provide a short, convenient way of talking about things, and short, convenient terms can rarely be fully self-explanatory; otherwise they are not "terms" but "explanations". > Some of us believe that an "Address and port > dependent mapping" is consistent if it always behaves like this. In my > mind, > the term "consistent" refers more to the type of behavior that we are > describing in section 8 on "Deterministic Behavior" What a term means depends on how we define it. I proposed a term that is short and simple and can easily be defined clearly, regardless of whether everyone might agree on what the word "consistent" may seem to suggest. > - The claim that the "Address dependent" behavior paragraph is superflous > is unfounded as we have found NATs that behaved like this. In fact, we > have found NATs that did much worst than that. Who cares? That behavior is logically subsumed in the "address and port dependent" behavior, each is equally bad and explicitly outlawed in the document, as are the non-deterministic behaviors discussed in section 8. It is not the purpose of this document to categorize individually every possible type of bad NAT behavior that has ever been observed anywhere - if we did that, we would also have to describe and characterize the behaviors of all those other NATs "that did much worst than that" as well, and that's completely unreasonable. The purpose of this document is to define what _GOOD_ NAT behavior is. > Mapping refresh: > > - I don't mind switching the order for sections 4.3 and 4.4. Again, I will > need a consensus from the group that it is beneficial. > > - I believe the "mapping" refresh concept is easier to understand and more > general than introducing inactivity timers and NAT sessions. But what exactly is a "mapping"? See my prior comments to Paul Hoffman. > Deterministic properties: > > - Non-deterministic NATs is the single biggest and most annoying problem > we have seen with NATs. Cullen described some of them in his NAT testing > result document. You are absolutely right that if you followed every > rule in the behave draft, you would then not have a non-deterministic > behavior. It is not because you haven't seen those nasty > non-deterministic behaviors that they don't exist: they do, and on > massively deployed NATs. We > talked about this a million times already on the list and in the > meetings. > > > - We do feel that non-determinism is so entrenched in NATs (because > implementors > try to introduce "one-off fixes" to NATs), that it makes NATs a huge > problem. > The consequence is that you test a NAT, it looks well-behaved, but under > some > other call scenario (like having multiple IP phones behind the same NAT) > it > suddently starts to fail. > > - Many people have expressed the view that this section is very important. > If > you have some suggestion on how to make it better, please let us know. I agree that what this section says is probably useful to have _somewhere_, to emphasize the point of determinism - but most of its content belongs in section 4 where mapping behavior is discussed, and the specific requirement REQ-10 is completely redundant. A NAT that follows REQ-1, REQ-3, etc., automatically also follows REQ-10. A NAT that ever violates REQ-10 (by having "nondeterministic" mapping or filtering behavior in the way that you describe) also inherently violates REQ-1 or REQ-3 (by not ALWAYS mapping or filtering traffic according to the specified rules). I think that the best thing to do might be to add an "Implementation Considerations" subsection to (perhaps) section 4 or 4.1, which would contain this determinism discussion, as well as some of the text I proposed earlier regarding exclusive port allocation. I'll work on some updated text for this purpose. > - You don't like REQ-7 which states that the filtering behavior shall be > "Address specific", and propose mandating endpoint-independent by > default, and allowing for a configuration for the other two behaviors. I > don't have any strong views on which mechanism should be used. We have had > a LOT of people saying that "Address and port dependent" would break a lot > of applications (which you don't like anyways). We also had lots of > comments on avoiding "non-determinism" (which your current proposal has). What "non-determinism" does my proposal has that yours doesn't? In fact, as I see it, mine has LESS determinism than yours: Original: REQ-7 It is RECOMMENDED that a NAT have an "External filtering is endpoint address dependent" behavior. Proposed: REQ-7: NATs MUST implement Endpoint-Independent Filtering in their default configuration. NATs SHOULD be configurable to support Address-Specific Filtering or Endpoint-Specific Filtering at the option of the system administrator. The original REQ-7 is only a soft requirement, so the NAT gets to decide what to do. My proposed REQ-7 is a _hard_ requirement on _default_ behavior, which means that an "out of the box" NAT will _always_ consistently exhibit deterministic endpoint-independent filtering behavior unless the administrator reconfigures the NAT to do otherwise. Hence less non-determinism in practice (especially given that most home NAT users don't even know how to reconfigure their NATs). > - Therefore, I would have no problem with REQ-7 to be changed to: > It is RECOMMENDED that a NAT have an Endpoint independent filtering > behavior. > Again, I would like to hear some consensus from the group before we do > so. My personal recommendation is that this change would be BETTER than > the previous text. I could potentially live with a weaker recommendation such as this, but would much prefer a recommendation that ensures that NATs will behave more consistently and deterministically at least in their "out of the box" configuration, and let the user/administrator decide whether they want to make the NAT behave differently. Cheers, Bryan From baford@mit.edu Wed, 18 May 2005 08:10:36 -0700 (PDT) From: Bryan Ford Date: Wed, 18 May 2005 08:10:36 -0700 (PDT) Subject: Re: How should NATs reject TCP packets? (was:: Re: [Ietf-behave] Next rev on TCP Behavior) In-Reply-To: Message-ID: <200505181110.32549.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 17 May 2005 10:35, Cullen Jennings wrote: > I suspect that many devices (that are also firewalls) will choose to > silently discard so we probably can't disallow that behavior even if it is > not the preferred approach. Agreed. > I would like to remind folks that this was > discussed in the last WG meeting. Some notes on the topic were > > > "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." > > Anyways, I guess I do wonder if we really need to specify this or not. If > you want STUNT to work and you want to do it on fairly normal OS without > replacing the TCP stacks, what behavior do you need to assume here and how > much can you still leave open? I note that a router would just drop the > packet if it felt like it thought that may not be the right analogy. I think this is precisely the right analogy. Probably the reason "soft errors" aren't very prevalent or supported reliably in ICMP or other Internet protocols is because of the strong historical precedent that "soft errors" of all kinds are generally treated in the same way: just drop the packet. > I suspect that while making an new ICMP code may have been the right thing > to do long ago, I'm not sure it is that practical to today because of the > large deployment issues in getting OS to change to understand it. Agreed. > Cullen Bryan From baford@mit.edu Wed, 18 May 2005 08:44:16 -0700 (PDT) From: Bryan Ford Date: Wed, 18 May 2005 08:44:16 -0700 (PDT) Subject: [Ietf-behave] Re: Terminology (again) - was WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: <200505181143.56580.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 17 May 2005 14:46, Cullen Jennings wrote: > Several of your points have to do with changing terminology. Let me try to > address those in this email. > > On 5/12/05 2:27 PM, "Bryan Ford" wrote: > > On Monday 25 April 2005 20:10, Jiri Kuthan wrote: > >> This is a BEHAVE Working Group Last Call for comments > >> on draft-ietf-behave-nat-udp-01. This last call closes > >> Tuesday May 12, 2005. Please post any final comments you > >> have on this draft to this list by that date. > > > > I think it is premature to have a last call on the UDP draft at this > > time. In addition to the major issue of document organization already > > under discussion, there are a substantial number of technical and writing > > issues with the current UDP draft's content itself. (Some of these > > issues I already discussed privately with the authors of the UDP draft.) > > First a brief summary of each, then a more thorough discussion below: > > > > *1. The draft's use of the term "session" is unclear in various places, > > because it doesn't distinguish between sessions as identified by (src IP, > > src port, dst IP, dst port) on one side of the NAT or the other, or > > between sessions within a single IP address domain and "logical sessions" > > that flow across the NAT and hence cross IP address domains. > > I don't think the draft need to differentiate between incoming and outgoing > sessions. It does differentiate between incoming and outgoing traffic for > timer refresh. Perhaps the difference between incoming and outgoing sessions is not terribly important, but the difference between incoming/outgoing and hairpin sessions is. I would potentially be amenable to merging incoming and outgoing sessions into a single term - e.g., "NAT-crossing" or "NAT-traversing sessions" or something like that, if you can suggest a good way to define them that preserves the precision and the ability to talk about hairpin sessions as well. > > *2. The draft uses the terms "mapping" and "binding" in confusing ways > > that are inconsistent with their historical meanings, and doesn't > > sufficiently clarify its use of these terms in the "3. Terminology" > > section. In particular, the draft uses the term "mapping" loosely in > > various places, sometimes to mean "binding", sometimes apparently to mean > > other things, but never properly defines either of these terms as they > > are used here. > > "binding" is not used other than a type in section 9 which we will fix. I > think mapping is clearly defined without mandating a specific > implementation. See my prior comments to Paul Hoffman. > > *3. The new terminology introduced in section 4.1 and 5.1, with the goal > > of replacing the historically troublesome "Cone/Symmetric" terminology, > > is hopelessly cumbersome. If we absolutely must, must, MUST invent new > > terms (instead of just clarifying the old ones, which I still think would > > be a better approach), then at least the new terms shouldn't take a whole > > line to write out! As is, they'll never get used in practice because > > they're just way too long; most people will in practice just keep using > > the cone/symmetric terms (imprecisely and confusingly) because they're > > easy to say and remember. > > I agree they should be short enough to use. Some people seem to be using > "Address Independent Mapping" and "Address Depended Filtering" which don't > seem too bad. Every time we have tried to change names, their was some > group of folks that did not like the new names. I do like some of your > names. Thanks. > > *4. The second "address and port mapping behavior" in section 4.1, > > "External NAT mapping is endpoint address dependent", is unnecessary: no > > NAT that I've ever heard of implements this behavior, because it just > > doesn't make sense at the implementation level. > > uh - I might be misunderstanding you here. I think are saying that though > "External NAT mapping is endpoint address and port dependent" and "External > NAT mapping is endpoint independent" both exist, no one would every > implement "External NAT mapping is endpoint address dependent". If this is > what you mean, there is more than one NAT that does this. It is considered > a feature by people that want to conceal the fact that traffic going to > server A and to server B are both from the same client behind the NAT. OK, I'll take your word for it that such NATs exist. But they are still just "bad NATs" according to the requirements of the document, and so there is no point in differentiating them from other kinds of "bad NATs" in terms of this obscure behavioral subtlety. There exist many more different types of "bad NATs" in the wild than we will ever hope to or want to characterize individually in this document; what is important is that we describe clearly how a "good NAT" behaves. > > This behavior is also subsumed by the third > > behavior ("External NAT mapping is endpoint address and port dependent"), > > and both the second and third behaviors are going to be disallowed in the > > requirements section at the end anyway. > > agreed > > > *5. The vague notion of "session" used informally in the draft at present > > is insufficient to make the text in "6. Hairpinning Behavior" precise or > > even comprehensible. It is especially important that hairpin translation > > be defined clearly and precisely here because as far as I know this will > > be the first "official" IETF document that even mentions it. > > Is there some specific you can think of where we are underspecified in this > section and implementers will do different things that cause applications > not to work? No, my concern is more with whether the section is comprehensible at all to someone who hasn't already thought through the issues very thoroughly. I've already received questions on "what hairpin translation actually is and how it might be implemented" from NAT implementors who had seen this document; if the document was clear those questions would not have arisen. I believe the proposed notion of "hairpin NAT session" is essential to providing NAT implementors with a logical model to understand how and why hairpin translation works. > > *6. Section 8, "Deterministic Properties", is currently very opaque and > > confusing as written, and it is not clear exactly it is trying to say. > > It probably should be combined into earlier sections. > > The other section do precisely nail all the non deterministic behaviors we > can think of. This one tries to capture one we can not think of. The > proposed text seemed to only cover the ones we could think of which are > already covered by other portions of the document. OK, but if the purpose of section 8 is "to capture [the non deterministic behaviors] we can not think of", then why is almost all of the actual text in this section a discussion about the specific nondeterministic we _have_ thought of - specifically, nondeterministic mapping or filtering behaviors? Trying to outlaw "nondeterministic behavior in general" from a NAT is going to be like nailing jell-o to a wall. For example, all NATs have resource limits of various kinds: when the NAT runs out of room in its session table, it has to change its behavior somehow, e.g., by rejecting new sessions. This is clearly "nondeterministic behavior" in that it depends on "particular conditions" that applications cannot possibly predict, but there's no way we can reasonably outlaw such forms of nondeterministic behavior. If this section is truly intended to be specific to the NAT's mapping and filtering behavior, which is how it reads, then the discussion on nondeterminism should be in sections 4.1 and 5.1. > > *7. It's very annoying and confusing that you have to read all the way > > through the document before you ever see even a hint of the actual > > requirements for NAT behavior that the document is trying to specify: > > e.g., that "Consistent Endpoint Translation is GOOD" and "Inconsistent > > Endpoint Translation is BAD". > > agree but think this is better than the alternatives. What is wrong with the alternative I proposed? Namely, you see the specific requirements as you read through the body of the text, and you also get a concise checklist-style summary of them all at the end. (This is the convention that BEHAVE-GEN and BEHAVE-TCP already use. Seems like the best of both worlds to me, at not much cost in space or effort. Cheers, Bryan From baford@mit.edu Wed, 18 May 2005 08:46:40 -0700 (PDT) From: Bryan Ford Date: Wed, 18 May 2005 08:46:40 -0700 (PDT) Subject: Re: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: <200505181146.38708.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 17 May 2005 14:50, Cullen Jennings wrote: > On 5/16/05 7:34 PM, "Francois Audet" wrote: > > - You've expressed the wish that we include the requirements as they > > occur in the document instead of having to wait for them in section > > 12 (copying them verbatim would be OK). I agree that it would make it > > easier for the reader to follow "where we are going" with this document. > > Section 12 would just be the consolidated summary of the requirements. I > > agree with this editorial recommendation. I will make the change however > > only if there is a consensus that it would be beneficial (but I support > > it). > > I think it is a bad idea to specify things two place and repeat text - we > will end up with contradictions. We're talking about very short snippets of text, which are extremely easy to cut-and-paste into the (exactly) two appropriate spots whenever one of the requirements changes. And before the publication of the final document it will be trivial for anyone to take a quick pass through and make sure the requirements text in the body is identical to the requirements text in the end. In fact a quick perl script could probably do it quite easily. :) Cheeers, Bryan From baford@mit.edu Wed, 18 May 2005 08:54:41 -0700 (PDT) From: Bryan Ford Date: Wed, 18 May 2005 08:54:41 -0700 (PDT) Subject: [Ietf-behave] Re: MTU in last call: draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: <200505181154.31567.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 17 May 2005 13:32, Cullen Jennings wrote: > The way the text is written right now, the NAT only needs to support > storing a packet as large as the larger of the two MTUs. We can't mandate > any particular minimum MTU size that has to be supported. Lots of Ethernet > chip sets used in NATs has hardware limits on the MTU size. I would not be > surprised to see some devices that can only do around 1500. This isn't about MTU size - it's about the _total_ size of a fully-reassembled UDP datagram that the NAT can reliably forward. Clearly UDP datagrams of totalling 8K or larger are commonly used, and NATs need to support forwarding the (<1500-byte) fragments of those datagrams properly. Since there is no reason I can think of that would make it inherently harder or consume substantially more resources for a NAT to be able to forward a 64KB UDP datagram (broken into 40+ fragments) than to forward an 8KB datagram (broken into 6+ fragments), my suggestion is to require NATs to support forwarding of any fragmented UDP packets up to the 64KB maximum reassembled datagram size in IPv4. But I may be missing something. (I seem to recall IPv6 added support for reassembled datagrams with 32-bit sizes, but can't remember, and that's probably not of much concern to us at the moment.) Cheers, Bryan > On 5/12/05 2:27 PM, "Bryan Ford" wrote: > > *9. In the discussion of fragmented datagrams, it is not clear whether > > NATs must support datagram sizes up to the maximum of 64K, or whether it > > is acceptable for a NAT to have a smaller maximum datagram size - e.g., a > > little over 8K, the size needed by NFS traffic. > > > > Unless there are serious screams from NAT implementors here, I would say > > that NATs MUST support full-size (up to 64K) fragmented datagrams. From fluffy@cisco.com Wed, 18 May 2005 09:37:26 -0700 (PDT) From: Cullen Jennings Date: Wed, 18 May 2005 09:37:26 -0700 (PDT) Subject: Re: [Ietf-behave] TCP through NATs (was Re: How should NATs reject TCP packets?) In-Reply-To: <1116367416.22848.54.camel@mazinger.u.cs.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 5/17/05 3:03 PM, "Saikat Guha" wrote: > On Tue, 2005-05-17 at 07:35 -0700, Cullen Jennings wrote: >> If you want STUNT to work and you want to do it on fairly normal OS without >> replacing the TCP stacks, what behavior do you need to assume here and how >> much can you still leave open? > > We studied TCP through existing NATs; the results are under submission: > http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf > > In response to Cullen's question, when it comes to packet filtering, it > would be nice to assume: > 1. TCP simultaneous open (or even just SYN-in after a SYN-out) works > 2. One of: > a) NATs don't generate either RSTs or ICMP Unreachables in > response to unsolicited SYNs. > or > b) NATs don't release the mapping if a) is violated i.e. if they > receive a RST/ICMP in response to a SYN Yes, I had come to more or less the same conclusion. I note that from the notes of the last WG meeting we had concluded on 1 and 2a. Some notes are: ? 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". also ? 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. So unless people have some new information of why we would not want to do the stuff above, this might be a somewhat already decided issue. I think that we had come to the conclusion that we would allow an inbound SYN and if there was no where to send it we would silently discard it. We had also come to the conclusion we were not going to extensively talk about RST handling because we did not need to and it was a firewall issue. Cullen From baford@mit.edu Wed, 18 May 2005 09:49:43 -0700 (PDT) From: Bryan Ford Date: Wed, 18 May 2005 09:49:43 -0700 (PDT) Subject: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: <200505181249.41878.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 17 May 2005 12:41, Cullen Jennings wrote: > We are really only discussing if we recommend that the filtering is > restrictive or not here. Somewhere you pointed out this is falling into the > firewall area and may not even be relevant for BEHAVE to specify and I > think I agree with you on that. At one point we had that but got strong > feedback form implementers, please recommend (but don't mandate) something > as they want to know what to do. We certainly want Full Cone NAT to be > behave compliant. However, what you are proposing is making it such that a > NAT with only Restricted filtering would *not* be behave compliant. Not true - please refer again to my specific proposal: REQ-7: NATs MUST implement Endpoint-Independent Filtering in their default configuration. NATs SHOULD be configurable to support Address-Specific Filtering or Endpoint-Specific Filtering at the option of the system administrator. Notice *"in their default configuration"*. Under this proposal, a NAT that does Restricted filtering is still BEHAVE compliant *if* the administrator configures it as such. My proposal in fact specifically recommends that NAT vendors implement Restricted filtering as a configuration option, and since most NATs already support it we can assume that it will be a pretty standard security option. But the operative word here is *option*. A NAT in its "out of the box" configuration shouldn't impose firewall functionality that severely interferes with the capabilities of applications, as restricted filtering does. > I strongly disagree with this proposal. > > I understand your security argument below however I think it is wrong. A > large portion of application that use UDP do not do connected UDP. That's because a "large portion of application[s] that use UDP" use a single UDP port to talk to multiple external endpoints, usually because they want to engage in peer-to-peer-style communication in some form with other peer hosts. And it is precisely this "large portion" of UDP applications that needs endpoint-independent filtering the most. > Furthermore, the outside firewall that does this type of behavior is > protecting the resources on the internal network from being consumed > forwarding bogus packets even if the eventual end application will > correctly discard them. We can not define behave such that a behave > compliant NAT could not also be a fairly normally configured firewall. First of all, even with endpoint-independent filtering, a NAT will in practice filter out the vast majority of bogus traffic that reaches it - the only bogus traffic it will let through is bogus traffic that happens to hit the specific external port number that corresponds to an active port binding, and that is not likely to happen too often because these port numbers are assigned more-or-less randomly by the NAT and only in the high, non-well-known port number space. The incremental benefit of restrictive filtering on random bogus traffic is going to be very small. An attacker might deliberately send bogus to a bound NAT port known to be in use, but if the attacker can find out which NAT port the application is using, then the attacker probably also knows (or can easily find out or guess) the address and port number of the remote host that the application is talking to and just spoof that source IP address and port number in its attack packets, getting around Restricted filtering as well. In fact the remote host's endpoint is in practice likely to be much easier for the attacker to find out or guess than the application's public NAT port, because of the overwhelming prevalence of well-known servers and ports on the Internet. So the practical benefit that Restricted filtering provides even against directed attacks is still minimal. Finally, the goal of "protecting the resources on the internal network from being consumed forwarding bogus packets" is really only a consideration on large corporate or ISP networks with substantial internal traffic load, and if this minimization of resource use is a concern then the network administrator can certainly be expected to know how to configure the company's NAT to enable Restricted filtering. As I pointed out above, under my proposal a NAT can use Restricted filtering and still be BEHAVE-compliant as long as it is the administrator (not the NAT vendor) that enables this firewall behavior. For home NATs, in contrast, minimizing resource load on the internal network due to bogus traffic is completely a non-issue because the home network (Ethernet or 802.11 or whatever) is typically so much faster than the Internet uplink anyway. In this case it's much more important that NATs consistently support applications well, which my proposal ensures by requiring that the NAT's "out of the box" configuration is Endpoint-independent Filtering. Joe Clueless who buys a home NAT router probably doesn't have any idea what NAT actually is, but he wants his applications to work. > However, which of us is right or wrong about the security implications here > turns out to probably be totally irrelevant. I phoned my colleagues at > Linksys this morning and asked if they would do this. When they stopped > laughing at me they told me no way. If they did this, netgear and dlink > would claim their NATs were more secure than linksys NATs and they would > get toasted in the market. They are not going to do full cone. I imagine > your own testing shows the number of full cone NATs in the market is a) > fairly small and b) becoming more rare. My testing indicates this. How did you ask the question? Any marketing person worth his monthly paycheck will be able to figure out that a NAT following my proposed recommendations can be presented as: * JUST AS SECURE as everyone else's NAT because it implements all the same security features (including Restricted filtering, as a configurable option). * MORE APPLICATION-FRIENDLY than the next guy's NAT because it allows applications to have a first-class "Internet presence", and the other guy's (non-configurable Restricted Cone NAT) doesn't. With this approach I'm sure any NAT that wasn't BEHAVE-compliant would quickly get toasted in the market. Besides, is it our job to bow to every existing NAT market tendency, good or bad, or is to set a standard for how NATs _should_ (and reasonably can) behave in order to work well with applications? Cheers, Bryan From yutaka_takeda@playstation.sony.com Thu, 19 May 2005 21:08:11 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Thu, 19 May 2005 21:08:11 -0700 (PDT) Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: <428D62A8.60709@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain I agree with Bryan's opinion with following three reasons: 1) NAT should do just what it is supposed to do. If the port overloading is not required, then the "external filtering" is no longer a NAT's job. "It sounds more secure.." as more of a sales talk just does not sound right to be a basis of a decision made by IETF. Filtering behavior should have something to do with users' security policy, which is exactly what Bryan is suggesting. 2) Endpoint independent maintains full UDP functionality. Endpoint address dependent filter compromises natted node's ability to receive packet from anyone. This seems to be a huge loss for the Internet community, for the sake of halfway security measures. Probably this is likely a thing that people who only has VoIP in mind do not care about. 3) Avoid ICE to be an requirement for traversing NAT As a programmer, the simplest solution is preferable. ICE is way far from 'simple'. Endpoint dependent filter behavior requires ICE connectivity check process or equivalent (UDP hole punching by knowing the other end's transport address). Just for a reminder for us... So, I strongly support: > REQ-7: NATs MUST implement Endpoint-Independent > Filtering in their default configuration. > NATs SHOULD be configurable to support > Address-Specific Filtering or Endpoint-Specific Filtering > at the option of the system administrator. - Yutaka Bryan Ford wrote: On Tuesday 17 May 2005 12:41, Cullen Jennings wrote: We are really only discussing if we recommend that the filtering is restrictive or not here. Somewhere you pointed out this is falling into the firewall area and may not even be relevant for BEHAVE to specify and I think I agree with you on that. At one point we had that but got strong feedback form implementers, please recommend (but don't mandate) something as they want to know what to do. We certainly want Full Cone NAT to be behave compliant. However, what you are proposing is making it such that a NAT with only Restricted filtering would *not* be behave compliant. Not true - please refer again to my specific proposal: REQ-7: NATs MUST implement Endpoint-Independent Filtering in their default configuration. NATs SHOULD be configurable to support Address-Specific Filtering or Endpoint-Specific Filtering at the option of the system administrator. Notice *"in their default configuration"*. Under this proposal, a NAT that does Restricted filtering is still BEHAVE compliant *if* the administrator configures it as such. My proposal in fact specifically recommends that NAT vendors implement Restricted filtering as a configuration option, and since most NATs already support it we can assume that it will be a pretty standard security option. But the operative word here is *option*. A NAT in its "out of the box" configuration shouldn't impose firewall functionality that severely interferes with the capabilities of applications, as restricted filtering does. I strongly disagree with this proposal. I understand your security argument below however I think it is wrong. A large portion of application that use UDP do not do connected UDP. That's because a "large portion of application[s] that use UDP" use a single UDP port to talk to multiple external endpoints, usually because they want to engage in peer-to-peer-style communication in some form with other peer hosts. And it is precisely this "large portion" of UDP applications that needs endpoint-independent filtering the most. Furthermore, the outside firewall that does this type of behavior is protecting the resources on the internal network from being consumed forwarding bogus packets even if the eventual end application will correctly discard them. We can not define behave such that a behave compliant NAT could not also be a fairly normally configured firewall. First of all, even with endpoint-independent filtering, a NAT will in practice filter out the vast majority of bogus traffic that reaches it - the only bogus traffic it will let through is bogus traffic that happens to hit the specific external port number that corresponds to an active port binding, and that is not likely to happen too often because these port numbers are assigned more-or-less randomly by the NAT and only in the high, non-well-known port number space. The incremental benefit of restrictive filtering on random bogus traffic is going to be very small. An attacker might deliberately send bogus to a bound NAT port known to be in use, but if the attacker can find out which NAT port the application is using, then the attacker probably also knows (or can easily find out or guess) the address and port number of the remote host that the application is talking to and just spoof that source IP address and port number in its attack packets, getting around Restricted filtering as well. In fact the remote host's endpoint is in practice likely to be much easier for the attacker to find out or guess than the application's public NAT port, because of the overwhelming prevalence of well-known servers and ports on the Internet. So the practical benefit that Restricted filtering provides even against directed attacks is still minimal. Finally, the goal of "protecting the resources on the internal network from being consumed forwarding bogus packets" is really only a consideration on large corporate or ISP networks with substantial internal traffic load, and if this minimization of resource use is a concern then the network administrator can certainly be expected to know how to configure the company's NAT to enable Restricted filtering. As I pointed out above, under my proposal a NAT can use Restricted filtering and still be BEHAVE-compliant as long as it is the administrator (not the NAT vendor) that enables this firewall behavior. For home NATs, in contrast, minimizing resource load on the internal network due to bogus traffic is completely a non-issue because the home network (Ethernet or 802.11 or whatever) is typically so much faster than the Internet uplink anyway. In this case it's much more important that NATs consistently support applications well, which my proposal ensures by requiring that the NAT's "out of the box" configuration is Endpoint-independent Filtering. Joe Clueless who buys a home NAT router probably doesn't have any idea what NAT actually is, but he wants his applications to work. However, which of us is right or wrong about the security implications here turns out to probably be totally irrelevant. I phoned my colleagues at Linksys this morning and asked if they would do this. When they stopped laughing at me they told me no way. If they did this, netgear and dlink would claim their NATs were more secure than linksys NATs and they would get toasted in the market. They are not going to do full cone. I imagine your own testing shows the number of full cone NATs in the market is a) fairly small and b) becoming more rare. My testing indicates this. How did you ask the question? Any marketing person worth his monthly paycheck will be able to figure out that a NAT following my proposed recommendations can be presented as: * JUST AS SECURE as everyone else's NAT because it implements all the same security features (including Restricted filtering, as a configurable option). * MORE APPLICATION-FRIENDLY than the next guy's NAT because it allows applications to have a first-class "Internet presence", and the other guy's (non-configurable Restricted Cone NAT) doesn't. With this approach I'm sure any NAT that wasn't BEHAVE-compliant would quickly get toasted in the market. Besides, is it our job to bow to every existing NAT market tendency, good or bad, or is to set a standard for how NATs _should_ (and reasonably can) behave in order to work well with applications? Cheers, Bryan _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Thu, 19 May 2005 22:05:05 -0700 (PDT) From: "Francois Audet" Date: Thu, 19 May 2005 22:05:05 -0700 (PDT) Subject: RE: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF026102A0@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt Hi Yutaka, Thanks for your input. I'm not sure I understand why you think you need to do ICE with Address dependent (or Address and port dependent as a matter of fact). In both cases, you don't but in both cases, you need to send some outgoing packets before you can start receiving any. With Endpoint Independent you have to have sent packets outside of the NAT from the source port to anywhere to start receiving from anywhere. With Address dependent, you have to have sent packets outside of the NAT to the IP address that is sending you packet to the source. With Address and port dependent, you have to have sent packets outside of the NAT to the IP address and port that is sending you packets to the source. None of these options requires ICE: just sending some probes, without even waiting for responses. In all cases you need to send a probe. The difference is do you have to send it to 1 IP address, or to all IP address (and possibly port) you want to communicate with. Does the application you have in mind requires receiving packets from "unknown" places? I assume the application then has to have it's own way of securing itself based on some other criteria than the source of the packets? Anyways, some clarification would be appreciated. Thanks. > -----Original Message----- > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] > Sent: Thursday, May 19, 2005 21:08 > To: Bryan Ford > Cc: Cullen Jennings; Behave; audet@xxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt > > > > I agree with Bryan's opinion with following three reasons: > > 1) NAT should do just what it is supposed to do. If the > port overloading is not required, then the "external > filtering" is no longer a NAT's job. > "It sounds more secure.." as more of a sales talk > just does not sound right to be a basis of a decision > made by IETF. Filtering behavior should have something > to do with users' security policy, which is exactly what > Bryan is suggesting. > > 2) Endpoint independent maintains full UDP functionality. > Endpoint address dependent filter compromises natted node's > ability to receive packet from anyone. This seems to be a > huge loss for the Internet community, for the sake of halfway > security measures. Probably this is likely a thing that > people who only has VoIP in mind do not care about. > > 3) Avoid ICE to be an requirement for traversing NAT > As a programmer, the simplest solution is preferable. > ICE is way far from 'simple'. Endpoint dependent filter > behavior requires ICE connectivity check process or > equivalent (UDP hole punching by knowing the other end's > transport address). Just for a reminder for us... > > So, I strongly support: > > > REQ-7: NATs MUST implement Endpoint-Independent > > Filtering in their default configuration. > > NATs SHOULD be configurable to support > > Address-Specific Filtering or Endpoint-Specific > Filtering > > at the option of the system administrator. > > - Yutaka > > From yutaka_takeda@playstation.sony.com Fri, 20 May 2005 11:40:16 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Fri, 20 May 2005 11:40:16 -0700 (PDT) Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF026102A0@zrc2hxm0.corp.nortel.com> Message-ID: <428E2F0D.4010404@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain What I meant by saying "ICE or equivalent" is a system that operates: 1) Initiator grabs external transport address on the NAT on every event of session initiation. 2) Inform the other end of the address via a proxy server. 3) The other end (Acceptor) grabs its external transport address on the Acceptor's NAT. 4) Inform the initiator of the external address. 5) Preform UDP hole punching from both ends to the transport addresses obtained. (This is done by connectivity check in ICE.) and this operation is required to every node including ability to use the proxy server. Imagine, if a node behind an Endpoint Independent NAT wishes to receive packets from anywhere (like a server), the node simply sends a binding request to STUN server to grab an external port on the NAT, and the port is available ahead of time for anyone without the above operation. > Does the application you have in mind requires receiving packets > from "unknown" places? Yes, hopefully with a simple way. Currently UPnP is the only way that allows this. > I assume the application then has to have > it's own way of securing itself based on some other criteria than > the source of the packets? Yes, as well as the application used to have a global address needed to do, and as an UDP/IPv6 application that likely does not require a NAT. - Yutaka Francois Audet wrote: Hi Yutaka, Thanks for your input. I'm not sure I understand why you think you need to do ICE with Address dependent (or Address and port dependent as a matter of fact). In both cases, you don't but in both cases, you need to send some outgoing packets before you can start receiving any. With Endpoint Independent you have to have sent packets outside of the NAT from the source port to anywhere to start receiving from anywhere. With Address dependent, you have to have sent packets outside of the NAT to the IP address that is sending you packet to the source. With Address and port dependent, you have to have sent packets outside of the NAT to the IP address and port that is sending you packets to the source. None of these options requires ICE: just sending some probes, without even waiting for responses. In all cases you need to send a probe. The difference is do you have to send it to 1 IP address, or to all IP address (and possibly port) you want to communicate with. Does the application you have in mind requires receiving packets from "unknown" places? I assume the application then has to have it's own way of securing itself based on some other criteria than the source of the packets? Anyways, some clarification would be appreciated. Thanks. > -----Original Message----- > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] > Sent: Thursday, May 19, 2005 21:08 > To: Bryan Ford > Cc: Cullen Jennings; Behave; audet@xxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt > > > > I agree with Bryan's opinion with following three reasons: > > 1) NAT should do just what it is supposed to do. If the > port overloading is not required, then the "external > filtering" is no longer a NAT's job. > "It sounds more secure.." as more of a sales talk > just does not sound right to be a basis of a decision > made by IETF. Filtering behavior should have something > to do with users' security policy, which is exactly what > Bryan is suggesting. > > 2) Endpoint independent maintains full UDP functionality. > Endpoint address dependent filter compromises natted node's > ability to receive packet from anyone. This seems to be a > huge loss for the Internet community, for the sake of halfway > security measures. Probably this is likely a thing that > people who only has VoIP in mind do not care about. > > 3) Avoid ICE to be an requirement for traversing NAT > As a programmer, the simplest solution is preferable. > ICE is way far from 'simple'. Endpoint dependent filter > behavior requires ICE connectivity check process or > equivalent (UDP hole punching by knowing the other end's > transport address). Just for a reminder for us... > > So, I strongly support: > > > REQ-7: NATs MUST implement Endpoint-Independent > > Filtering in their default configuration. > > NATs SHOULD be configurable to support > > Address-Specific Filtering or Endpoint-Specific > Filtering > > at the option of the system administrator. > > - Yutaka > > From fluffy@cisco.com Fri, 20 May 2005 13:07:37 -0700 (PDT) From: Cullen Jennings Date: Fri, 20 May 2005 13:07:37 -0700 (PDT) Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt In-Reply-To: <428D62A8.60709@playstation.sony.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I don't see how Brian's proposal helps application developers. Let say that a NAT has been configured to do address dependant filtering, the application still supposed to work. We are trying to make a system where applications can work with any behave compliant NAT. That means the application needs to assume the "worst case". Unless we change Req-7 to say that a NAT MUST NOT filter based on the the address or port, we don't make life any easier for the application developer. On 5/19/05 9:08 PM, "yutaka_takeda@xxxxxxxxxxxxxxxxxxxx" wrote: > > I agree with Bryan's opinion with following three reasons: > > 1) NAT should do just what it is supposed to do. If the > port overloading is not required, then the "external > filtering" is no longer a NAT's job. > "It sounds more secure.." as more of a sales talk > just does not sound right to be a basis of a decision > made by IETF. Filtering behavior should have something > to do with users' security policy, which is exactly what > Bryan is suggesting. > > 2) Endpoint independent maintains full UDP functionality. > Endpoint address dependent filter compromises natted > node's ability to receive packet from anyone. This seems > to be a huge loss for the Internet community, for the sake > of halfway security measures. Probably this is likely a > thing that people who only has VoIP in mind do not care > about. > > 3) Avoid ICE to be an requirement for traversing NAT > As a programmer, the simplest solution is preferable. > ICE is way far from 'simple'. Endpoint dependent filter > behavior requires ICE connectivity check process or > equivalent (UDP hole punching by knowing the other end's > transport address). Just for a reminder for us... > > So, I strongly support: > >> REQ-7: NATs MUST implement Endpoint-Independent >> Filtering in their default configuration. >> NATs SHOULD be configurable to support >> Address-Specific Filtering or Endpoint-Specific Filtering >> at the option of the system administrator. > > - Yutaka > > > > Bryan Ford wrote: >> On Tuesday 17 May 2005 12:41, Cullen Jennings wrote: >> >>> We are really only discussing if we recommend that the filtering is >>> restrictive or not here. Somewhere you pointed out this is falling into the >>> firewall area and may not even be relevant for BEHAVE to specify and I >>> think I agree with you on that. At one point we had that but got strong >>> feedback form implementers, please recommend (but don't mandate) something >>> as they want to know what to do. We certainly want Full Cone NAT to be >>> behave compliant. However, what you are proposing is making it such that a >>> NAT with only Restricted filtering would *not* be behave compliant. >> >> >> Not true - please refer again to my specific proposal: >> >> REQ-7: NATs MUST implement Endpoint-Independent >> Filtering in their default configuration. >> NATs SHOULD be configurable to support >> Address-Specific Filtering or Endpoint-Specific Filtering >> at the option of the system administrator. >> >> Notice *"in their default configuration"*. Under this proposal, a NAT that >> does Restricted filtering is still BEHAVE compliant *if* the administrator >> configures it as such. My proposal in fact specifically recommends that NAT >> vendors implement Restricted filtering as a configuration option, and since >> most NATs already support it we can assume that it will be a pretty standard >> security option. But the operative word here is *option*. A NAT in its "out >> of the box" configuration shouldn't impose firewall functionality that >> severely interferes with the capabilities of applications, as restricted >> filtering does. >> >> >>> I strongly disagree with this proposal. >>> >>> I understand your security argument below however I think it is wrong. A >>> large portion of application that use UDP do not do connected UDP. >> >> >> That's because a "large portion of application[s] that use UDP" use a single >> UDP port to talk to multiple external endpoints, usually because they want to >> engage in peer-to-peer-style communication in some form with other peer >> hosts. And it is precisely this "large portion" of UDP applications that >> needs endpoint-independent filtering the most. >> >> >>> Furthermore, the outside firewall that does this type of behavior is >>> protecting the resources on the internal network from being consumed >>> forwarding bogus packets even if the eventual end application will >>> correctly discard them. We can not define behave such that a behave >>> compliant NAT could not also be a fairly normally configured firewall. >> >> >> First of all, even with endpoint-independent filtering, a NAT will in >> practice >> filter out the vast majority of bogus traffic that reaches it - the only >> bogus traffic it will let through is bogus traffic that happens to hit the >> specific external port number that corresponds to an active port binding, and >> that is not likely to happen too often because these port numbers are >> assigned more-or-less randomly by the NAT and only in the high, >> non-well-known port number space. The incremental benefit of restrictive >> filtering on random bogus traffic is going to be very small. >> >> An attacker might deliberately send bogus to a bound NAT port known to be in >> use, but if the attacker can find out which NAT port the application is >> using, then the attacker probably also knows (or can easily find out or >> guess) the address and port number of the remote host that the application is >> talking to and just spoof that source IP address and port number in its >> attack packets, getting around Restricted filtering as well. In fact the >> remote host's endpoint is in practice likely to be much easier for the >> attacker to find out or guess than the application's public NAT port, because >> of the overwhelming prevalence of well-known servers and ports on the >> Internet. So the practical benefit that Restricted filtering provides even >> against directed attacks is still minimal. >> >> Finally, the goal of "protecting the resources on the internal network from >> being consumed forwarding bogus packets" is really only a consideration on >> large corporate or ISP networks with substantial internal traffic load, and >> if this minimization of resource use is a concern then the network >> administrator can certainly be expected to know how to configure the >> company's NAT to enable Restricted filtering. As I pointed out above, under >> my proposal a NAT can use Restricted filtering and still be BEHAVE-compliant >> as long as it is the administrator (not the NAT vendor) that enables this >> firewall behavior. >> >> For home NATs, in contrast, minimizing resource load on the internal network >> due to bogus traffic is completely a non-issue because the home network >> (Ethernet or 802.11 or whatever) is typically so much faster than the >> Internet uplink anyway. In this case it's much more important that NATs >> consistently support applications well, which my proposal ensures by >> requiring that the NAT's "out of the box" configuration is >> Endpoint-independent Filtering. Joe Clueless who buys a home NAT router >> probably doesn't have any idea what NAT actually is, but he wants his >> applications to work. >> >> >>> However, which of us is right or wrong about the security implications here >>> turns out to probably be totally irrelevant. I phoned my colleagues at >>> Linksys this morning and asked if they would do this. When they stopped >>> laughing at me they told me no way. If they did this, netgear and dlink >>> would claim their NATs were more secure than linksys NATs and they would >>> get toasted in the market. They are not going to do full cone. I imagine >>> your own testing shows the number of full cone NATs in the market is a) >>> fairly small and b) becoming more rare. My testing indicates this. >> >> >> How did you ask the question? Any marketing person worth his monthly >> paycheck >> will be able to figure out that a NAT following my proposed recommendations >> can be presented as: >> >> * JUST AS SECURE as everyone else's NAT because it implements all the same >> security features (including Restricted filtering, as a configurable option). >> * MORE APPLICATION-FRIENDLY than the next guy's NAT because it allows >> applications to have a first-class "Internet presence", and the other guy's >> (non-configurable Restricted Cone NAT) doesn't. >> >> With this approach I'm sure any NAT that wasn't BEHAVE-compliant would >> quickly >> get toasted in the market. >> >> Besides, is it our job to bow to every existing NAT market tendency, good or >> bad, or is to set a standard for how NATs _should_ (and reasonably can) >> behave in order to work well with applications? >> >> Cheers, >> Bryan >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> >> >> From audet@nortel.com Fri, 20 May 2005 13:50:02 -0700 (PDT) From: "Francois Audet" Date: Fri, 20 May 2005 13:50:02 -0700 (PDT) Subject: RE: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF02610D10@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt Exactly. For 7 to make life easier for implementros, it would have to say A NAT MUST have an "External filtering is endpoint independent". > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Friday, May 20, 2005 13:08 > To: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx; Bryan Ford > Cc: Behave; audet@xxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt > > > > I don't see how Brian's proposal helps application > developers. Let say that a NAT has been configured to do > address dependant filtering, the application still supposed > to work. We are trying to make a system where applications > can work with any behave compliant NAT. That means the > application needs to assume the "worst case". Unless we > change Req-7 to say that a NAT MUST NOT filter based on the > the address or port, we don't make life any easier for the > application developer. > > On 5/19/05 9:08 PM, "yutaka_takeda@xxxxxxxxxxxxxxxxxxxx" > wrote: > > > > > I agree with Bryan's opinion with following three reasons: > > > > 1) NAT should do just what it is supposed to do. If the > > port overloading is not required, then the "external > filtering" is no > > longer a NAT's job. "It sounds more secure.." as more of a > sales talk > > just does not sound right to be a basis of a decision > > made by IETF. Filtering behavior should have something > > to do with users' security policy, which is exactly what > > Bryan is suggesting. > > > > 2) Endpoint independent maintains full UDP functionality. Endpoint > > address dependent filter compromises natted node's ability > to receive > > packet from anyone. This seems to be a huge loss for the Internet > > community, for the sake of halfway security measures. > Probably this is > > likely a thing that people who only has VoIP in mind do not care > > about. > > > > 3) Avoid ICE to be an requirement for traversing NAT > > As a programmer, the simplest solution is preferable. > > ICE is way far from 'simple'. Endpoint dependent filter behavior > > requires ICE connectivity check process or equivalent (UDP hole > > punching by knowing the other end's transport address). Just for a > > reminder for us... > > > > So, I strongly support: > > > >> REQ-7: NATs MUST implement Endpoint-Independent > >> Filtering in their default configuration. > >> NATs SHOULD be configurable to support > >> Address-Specific Filtering or Endpoint-Specific > Filtering > >> at the option of the system administrator. > > > > - Yutaka > > > > > > > > Bryan Ford wrote: > >> On Tuesday 17 May 2005 12:41, Cullen Jennings wrote: > >> > >>> We are really only discussing if we recommend that the > filtering is > >>> restrictive or not here. Somewhere you pointed out this > is falling > >>> into the firewall area and may not even be relevant for BEHAVE to > >>> specify and I think I agree with you on that. At one point we had > >>> that but got strong feedback form implementers, please recommend > >>> (but don't mandate) something as they want to know what to do. We > >>> certainly want Full Cone NAT to be behave compliant. > However, what > >>> you are proposing is making it such that a NAT with only > Restricted > >>> filtering would *not* be behave compliant. > >> > >> > >> Not true - please refer again to my specific proposal: > >> > >> REQ-7: NATs MUST implement Endpoint-Independent > >> Filtering in their default configuration. > >> NATs SHOULD be configurable to support > >> Address-Specific Filtering or Endpoint-Specific > Filtering > >> at the option of the system administrator. > >> > >> Notice *"in their default configuration"*. Under this proposal, a > >> NAT that does Restricted filtering is still BEHAVE > compliant *if* the > >> administrator configures it as such. My proposal in fact > >> specifically recommends that NAT vendors implement Restricted > >> filtering as a configuration option, and since most NATs already > >> support it we can assume that it will be a pretty standard > security > >> option. But the operative word here is *option*. A NAT > in its "out > >> of the box" configuration shouldn't impose firewall functionality > >> that severely interferes with the capabilities of applications, as > >> restricted filtering does. > >> > >> > >>> I strongly disagree with this proposal. > >>> > >>> I understand your security argument below however I think it is > >>> wrong. A large portion of application that use UDP do not do > >>> connected UDP. > >> > >> > >> That's because a "large portion of application[s] that use > UDP" use a > >> single UDP port to talk to multiple external endpoints, usually > >> because they want to engage in peer-to-peer-style communication in > >> some form with other peer hosts. And it is precisely this "large > >> portion" of UDP applications that needs endpoint-independent > >> filtering the most. > >> > >> > >>> Furthermore, the outside firewall that does this type of > behavior is > >>> protecting the resources on the internal network from > being consumed > >>> forwarding bogus packets even if the eventual end > application will > >>> correctly discard them. We can not define behave such > that a behave > >>> compliant NAT could not also be a fairly normally configured > >>> firewall. > >> > >> > >> First of all, even with endpoint-independent filtering, a > NAT will in > >> practice filter out the vast majority of bogus traffic > that reaches > >> it - the only bogus traffic it will let through is bogus > traffic that > >> happens to hit the specific external port number that > corresponds to > >> an active port binding, and that is not likely to happen too often > >> because these port numbers are assigned more-or-less > randomly by the > >> NAT and only in the high, non-well-known port number space. The > >> incremental benefit of restrictive filtering on random > bogus traffic > >> is going to be very small. > >> > >> An attacker might deliberately send bogus to a bound NAT > port known > >> to be in use, but if the attacker can find out which NAT port the > >> application is using, then the attacker probably also > knows (or can > >> easily find out or > >> guess) the address and port number of the remote host that > the application is > >> talking to and just spoof that source IP address and port > number in its > >> attack packets, getting around Restricted filtering as > well. In fact the > >> remote host's endpoint is in practice likely to be much > easier for the > >> attacker to find out or guess than the application's > public NAT port, because > >> of the overwhelming prevalence of well-known servers and > ports on the > >> Internet. So the practical benefit that Restricted > filtering provides even > >> against directed attacks is still minimal. > >> > >> Finally, the goal of "protecting the resources on the internal > >> network from being consumed forwarding bogus packets" is > really only > >> a consideration on large corporate or ISP networks with > substantial > >> internal traffic load, and if this minimization of > resource use is a > >> concern then the network administrator can certainly be > expected to > >> know how to configure the company's NAT to enable Restricted > >> filtering. As I pointed out above, under my proposal a > NAT can use > >> Restricted filtering and still be BEHAVE-compliant as long > as it is > >> the administrator (not the NAT vendor) that enables this firewall > >> behavior. > >> > >> For home NATs, in contrast, minimizing resource load on > the internal > >> network due to bogus traffic is completely a non-issue because the > >> home network (Ethernet or 802.11 or whatever) is typically so much > >> faster than the Internet uplink anyway. In this case it's > much more > >> important that NATs consistently support applications > well, which my > >> proposal ensures by requiring that the NAT's "out of the box" > >> configuration is Endpoint-independent Filtering. Joe Clueless who > >> buys a home NAT router probably doesn't have any idea what NAT > >> actually is, but he wants his applications to work. > >> > >> > >>> However, which of us is right or wrong about the security > >>> implications here turns out to probably be totally irrelevant. I > >>> phoned my colleagues at Linksys this morning and asked if > they would > >>> do this. When they stopped laughing at me they told me no way. If > >>> they did this, netgear and dlink would claim their NATs were more > >>> secure than linksys NATs and they would get toasted in > the market. > >>> They are not going to do full cone. I imagine your own > testing shows > >>> the number of full cone NATs in the market is a) fairly > small and b) > >>> becoming more rare. My testing indicates this. > >> > >> > >> How did you ask the question? Any marketing person worth > his monthly > >> paycheck will be able to figure out that a NAT following > my proposed > >> recommendations can be presented as: > >> > >> * JUST AS SECURE as everyone else's NAT because it > implements all the > >> same security features (including Restricted filtering, as a > >> configurable option). > >> * MORE APPLICATION-FRIENDLY than the next guy's NAT > because it allows > >> applications to have a first-class "Internet presence", > and the other guy's > >> (non-configurable Restricted Cone NAT) doesn't. > >> > >> With this approach I'm sure any NAT that wasn't BEHAVE-compliant > >> would quickly get toasted in the market. > >> > >> Besides, is it our job to bow to every existing NAT market > tendency, > >> good or bad, or is to set a standard for how NATs _should_ (and > >> reasonably can) behave in order to work well with applications? > >> > >> Cheers, > >> Bryan > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > >> > >> > > From baford@mit.edu Fri, 20 May 2005 13:55:27 -0700 (PDT) From: Bryan Ford Date: Fri, 20 May 2005 13:55:27 -0700 (PDT) Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: <200505201655.22722.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Friday 20 May 2005 16:07, Cullen Jennings wrote: > I don't see how Brian's proposal helps application developers. Let say that > a NAT has been configured to do address dependant filtering, the > application still supposed to work. We are trying to make a system where > applications can work with any behave compliant NAT. That means the > application needs to assume the "worst case". Unless we change Req-7 to say > that a NAT MUST NOT filter based on the the address or port, we don't make > life any easier for the application developer. Not true - many applications can easily handle _some_ nodes having restrictive filtering behavior but would be seriously impacted for the worse if _most_ nodes had restrictive filtering behavior. In particular, many P2P application protocols, including "the latest craze" Skype I believe, employ a concept of "supernode" versus "ordinary node". Through automatic self-selection or by some election process with their peers, particularly stable, long-lived, or accessible ordinary nodes can be "promoted" to supernode status (usually invisibly to the user). Once promoted, supernodes take on the additional responsibilities of keeping a number of other "ordinary nodes" connected, such as by aggregating search index data, or... (drum droll :) ) by helping ordinary nodes to establish P2P connections to each other. In the design of many P2P protocols it is very natural for supernodes to provide such a "rendezvous server" function to help ordinary nodes perform hole punching. However, to perform this rendezvous server function the supernode must itself have an IP address and UDP port number at which it can be reached directly by any node across the network - i.e., if it is NATted, the NAT must have Full Cone (Endpoint-independent filtering) behavior. In such a protocol, a node behind a Restricted Cone NAT typically cannot become a supernode. As an ever-larger percentage of hosts on the Internet become NATted, if those NATs have restricted filtering, then the total number of hosts that are eligible to become supernodes rapidly diminishes. If this working group establishes restricted filtering as "The Offical Standard" (tm) for NAT behavior, then that may well be the death knell for all supernode-based application protocols. As the number of "supernode-eligible" participants on the Internet falls and drops below some percentage of the total participants due to Restricted Cone NAT, the few supernodes that exist will be increasingly overloaded and the protocol eventually breaks down. If, on the other hand, this working group recommends Full Cone NAT as the standard, "application-friendly" behavior, while leaving the option open for the more paranoid users and administrators to configure their NATs for restricted filtering, we can be pretty sure that a high enough percentage of users will leave their NATs in Full Cone mode that supernode-based protocols will continue to function reliably. Cheers, Bryan > On 5/19/05 9:08 PM, "yutaka_takeda@xxxxxxxxxxxxxxxxxxxx" > > wrote: > > I agree with Bryan's opinion with following three reasons: > > > > 1) NAT should do just what it is supposed to do. If the > > port overloading is not required, then the "external > > filtering" is no longer a NAT's job. > > "It sounds more secure.." as more of a sales talk > > just does not sound right to be a basis of a decision > > made by IETF. Filtering behavior should have something > > to do with users' security policy, which is exactly what > > Bryan is suggesting. > > > > 2) Endpoint independent maintains full UDP functionality. > > Endpoint address dependent filter compromises natted > > node's ability to receive packet from anyone. This seems > > to be a huge loss for the Internet community, for the sake > > of halfway security measures. Probably this is likely a > > thing that people who only has VoIP in mind do not care > > about. > > > > 3) Avoid ICE to be an requirement for traversing NAT > > As a programmer, the simplest solution is preferable. > > ICE is way far from 'simple'. Endpoint dependent filter > > behavior requires ICE connectivity check process or > > equivalent (UDP hole punching by knowing the other end's > > transport address). Just for a reminder for us... > > > > So, I strongly support: > >> REQ-7: NATs MUST implement Endpoint-Independent > >> Filtering in their default configuration. > >> NATs SHOULD be configurable to support > >> Address-Specific Filtering or Endpoint-Specific Filtering > >> at the option of the system administrator. > > > > - Yutaka > > > > Bryan Ford wrote: > >> On Tuesday 17 May 2005 12:41, Cullen Jennings wrote: > >>> We are really only discussing if we recommend that the filtering is > >>> restrictive or not here. Somewhere you pointed out this is falling into > >>> the firewall area and may not even be relevant for BEHAVE to specify > >>> and I think I agree with you on that. At one point we had that but got > >>> strong feedback form implementers, please recommend (but don't mandate) > >>> something as they want to know what to do. We certainly want Full Cone > >>> NAT to be behave compliant. However, what you are proposing is making > >>> it such that a NAT with only Restricted filtering would *not* be behave > >>> compliant. > >> > >> Not true - please refer again to my specific proposal: > >> > >> REQ-7: NATs MUST implement Endpoint-Independent > >> Filtering in their default configuration. > >> NATs SHOULD be configurable to support > >> Address-Specific Filtering or Endpoint-Specific Filtering > >> at the option of the system administrator. > >> > >> Notice *"in their default configuration"*. Under this proposal, a NAT > >> that does Restricted filtering is still BEHAVE compliant *if* the > >> administrator configures it as such. My proposal in fact specifically > >> recommends that NAT vendors implement Restricted filtering as a > >> configuration option, and since most NATs already support it we can > >> assume that it will be a pretty standard security option. But the > >> operative word here is *option*. A NAT in its "out of the box" > >> configuration shouldn't impose firewall functionality that severely > >> interferes with the capabilities of applications, as restricted > >> filtering does. > >> > >>> I strongly disagree with this proposal. > >>> > >>> I understand your security argument below however I think it is wrong. > >>> A large portion of application that use UDP do not do connected UDP. > >> > >> That's because a "large portion of application[s] that use UDP" use a > >> single UDP port to talk to multiple external endpoints, usually because > >> they want to engage in peer-to-peer-style communication in some form > >> with other peer hosts. And it is precisely this "large portion" of UDP > >> applications that needs endpoint-independent filtering the most. > >> > >>> Furthermore, the outside firewall that does this type of behavior is > >>> protecting the resources on the internal network from being consumed > >>> forwarding bogus packets even if the eventual end application will > >>> correctly discard them. We can not define behave such that a behave > >>> compliant NAT could not also be a fairly normally configured firewall. > >> > >> First of all, even with endpoint-independent filtering, a NAT will in > >> practice > >> filter out the vast majority of bogus traffic that reaches it - the only > >> bogus traffic it will let through is bogus traffic that happens to hit > >> the specific external port number that corresponds to an active port > >> binding, and that is not likely to happen too often because these port > >> numbers are assigned more-or-less randomly by the NAT and only in the > >> high, non-well-known port number space. The incremental benefit of > >> restrictive filtering on random bogus traffic is going to be very small. > >> > >> An attacker might deliberately send bogus to a bound NAT port known to > >> be in use, but if the attacker can find out which NAT port the > >> application is using, then the attacker probably also knows (or can > >> easily find out or guess) the address and port number of the remote host > >> that the application is talking to and just spoof that source IP address > >> and port number in its attack packets, getting around Restricted > >> filtering as well. In fact the remote host's endpoint is in practice > >> likely to be much easier for the attacker to find out or guess than the > >> application's public NAT port, because of the overwhelming prevalence of > >> well-known servers and ports on the Internet. So the practical benefit > >> that Restricted filtering provides even against directed attacks is > >> still minimal. > >> > >> Finally, the goal of "protecting the resources on the internal network > >> from being consumed forwarding bogus packets" is really only a > >> consideration on large corporate or ISP networks with substantial > >> internal traffic load, and if this minimization of resource use is a > >> concern then the network administrator can certainly be expected to know > >> how to configure the company's NAT to enable Restricted filtering. As I > >> pointed out above, under my proposal a NAT can use Restricted filtering > >> and still be BEHAVE-compliant as long as it is the administrator (not > >> the NAT vendor) that enables this firewall behavior. > >> > >> For home NATs, in contrast, minimizing resource load on the internal > >> network due to bogus traffic is completely a non-issue because the home > >> network (Ethernet or 802.11 or whatever) is typically so much faster > >> than the Internet uplink anyway. In this case it's much more important > >> that NATs consistently support applications well, which my proposal > >> ensures by requiring that the NAT's "out of the box" configuration is > >> Endpoint-independent Filtering. Joe Clueless who buys a home NAT router > >> probably doesn't have any idea what NAT actually is, but he wants his > >> applications to work. > >> > >>> However, which of us is right or wrong about the security implications > >>> here turns out to probably be totally irrelevant. I phoned my > >>> colleagues at Linksys this morning and asked if they would do this. > >>> When they stopped laughing at me they told me no way. If they did this, > >>> netgear and dlink would claim their NATs were more secure than linksys > >>> NATs and they would get toasted in the market. They are not going to do > >>> full cone. I imagine your own testing shows the number of full cone > >>> NATs in the market is a) fairly small and b) becoming more rare. My > >>> testing indicates this. > >> > >> How did you ask the question? Any marketing person worth his monthly > >> paycheck > >> will be able to figure out that a NAT following my proposed > >> recommendations can be presented as: > >> > >> * JUST AS SECURE as everyone else's NAT because it implements all the > >> same security features (including Restricted filtering, as a > >> configurable option). * MORE APPLICATION-FRIENDLY than the next guy's > >> NAT because it allows applications to have a first-class "Internet > >> presence", and the other guy's (non-configurable Restricted Cone NAT) > >> doesn't. > >> > >> With this approach I'm sure any NAT that wasn't BEHAVE-compliant would > >> quickly > >> get toasted in the market. > >> > >> Besides, is it our job to bow to every existing NAT market tendency, > >> good or bad, or is to set a standard for how NATs _should_ (and > >> reasonably can) behave in order to work well with applications? > >> > >> Cheers, > >> Bryan > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Fri, 20 May 2005 13:58:54 -0700 (PDT) From: "Francois Audet" Date: Fri, 20 May 2005 13:58:54 -0700 (PDT) Subject: RE: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF02610D2D@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt Right. To me, this is only going to work if it is Endpoint independent. > -----Original Message----- > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] > Sent: Friday, May 20, 2005 11:40 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Bryan Ford'; 'Cullen Jennings'; 'Behave' > Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt > > > > What I meant by saying "ICE or equivalent" is a system that > operates: > > 1) Initiator grabs external transport address on the NAT on > every event of session initiation. > 2) Inform the other end of the address via a proxy server. > 3) The other end (Acceptor) grabs its external transport > address on the Acceptor's NAT. > 4) Inform the initiator of the external address. > 5) Preform UDP hole punching from both ends to the transport > addresses obtained. (This is done by connectivity check > in ICE.) > > and this operation is required to every node including > ability to use the proxy server. > > Imagine, if a node behind an Endpoint Independent NAT > wishes to receive packets from anywhere (like a server), > the node simply sends a binding request to STUN server > to grab an external port on the NAT, and the port is > available ahead of time for anyone without the above > operation. > > > Does the application you have in mind requires receiving > packets > from "unknown" places? > > Yes, hopefully with a simple way. Currently UPnP is the > only way that allows this. > > > I assume the application then has to have > > it's own way of securing itself based on some other > criteria than > the source of the packets? > > Yes, as well as the application used to have a global > address needed to do, and as an UDP/IPv6 application > that likely does not require a NAT. > > > - Yutaka > > > > Francois Audet wrote: > > Hi Yutaka, > > > > Thanks for your input. > > > > I'm not sure I understand why you think you need to do ICE with > > Address dependent (or Address and port dependent as a > matter of fact). > > In both cases, you don't but in both cases, you need to send some > > outgoing packets before you can start receiving any. > > > > With Endpoint Independent you have to have sent packets > outside of the > > NAT from the source port to anywhere to start receiving > from anywhere. > > > > With Address dependent, you have to have sent packets > outside of the > > NAT to the IP address that is sending you packet to the source. > > > > With Address and port dependent, you have to have sent > packets outside > > of the NAT to the IP address and port that is sending you > packets to > > the source. > > > > None of these options requires ICE: just sending some > probes, without > > even waiting for responses. > > > > In all cases you need to send a probe. The difference is do > you have > > to send it to 1 IP address, or to all IP address (and possibly > > port) you want to communicate with. > > > > Does the application you have in mind requires receiving > packets from > > "unknown" places? I assume the application then has to have > it's own > > way of securing itself based on some other criteria than > the source of > > the packets? > > > > Anyways, some clarification would be appreciated. > > > > Thanks. > > > > > -----Original Message----- > > > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > > > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] > > > Sent: Thursday, May 19, 2005 21:08 > > > To: Bryan Ford > > > Cc: Cullen Jennings; Behave; audet@xxxxxxxxxxxxxxxxxx > > > Subject: Re: [Ietf-behave] Re: Req-7 > > draft-ietf-behave-nat-udp-01.txt > > > > > > > > I agree with Bryan's opinion with following three reasons: > > > > > > 1) NAT should do just what it is supposed to do. If the > > > port overloading is not required, then the "external > > > filtering" is no longer a NAT's job. > > > "It sounds more secure.." as more of a sales talk > > > just does not sound right to be a basis of a decision > > > made by IETF. Filtering behavior should have something > > > to do with users' security policy, which is exactly what > > > Bryan is suggesting. > > > > > > 2) Endpoint independent maintains full UDP functionality. > > > Endpoint address dependent filter compromises natted node's > > > ability to receive packet from anyone. This seems to be a > > > huge loss for the Internet community, for the sake of halfway > > > security measures. Probably this is likely a thing that > > > people who only has VoIP in mind do not care about. > > > > > > 3) Avoid ICE to be an requirement for traversing NAT > > > As a programmer, the simplest solution is preferable. > > > ICE is way far from 'simple'. Endpoint dependent filter > > > behavior requires ICE connectivity check process or > > > equivalent (UDP hole punching by knowing the other end's > > > transport address). Just for a reminder for us... > > > > > > So, I strongly support: > > > > > > > REQ-7: NATs MUST implement Endpoint-Independent > > > > Filtering in their default configuration. > > > > NATs SHOULD be configurable to support > > > > Address-Specific Filtering or Endpoint-Specific > > > Filtering > > > > at the option of the system administrator. > > > > > > - Yutaka > > > > > > > > > > From yutaka_takeda@playstation.sony.com Fri, 20 May 2005 14:26:18 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Fri, 20 May 2005 14:26:18 -0700 (PDT) Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: <428E55F5.1040509@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain Cullen Jennings wrote: > Let say that a NAT has been configured to do > address dependant filtering, the application > still supposed to work. Say, there is a router to be behave compliant but it has a built-in firewall which is configured by an admin to only allow inbound packets from a specified subnet. This is the "worst case" in reality. What you have pointed out does not look different from the firewall issue to me. This argument stems from the fact that the current proposal addresses the inbound packet filtering as inherent matter of NAT, which I think wrong and it should be a firewall matter. - Yutaka Cullen Jennings wrote: I don't see how Brian's proposal helps application developers. Let say that a NAT has been configured to do address dependant filtering, the application still supposed to work. We are trying to make a system where applications can work with any behave compliant NAT. That means the application needs to assume the "worst case". Unless we change Req-7 to say that a NAT MUST NOT filter based on the the address or port, we don't make life any easier for the application developer. On 5/19/05 9:08 PM, "yutaka_takeda@xxxxxxxxxxxxxxxxxxxx" wrote: I agree with Bryan's opinion with following three reasons: 1) NAT should do just what it is supposed to do. If the port overloading is not required, then the "external filtering" is no longer a NAT's job. "It sounds more secure.." as more of a sales talk just does not sound right to be a basis of a decision made by IETF. Filtering behavior should have something to do with users' security policy, which is exactly what Bryan is suggesting. 2) Endpoint independent maintains full UDP functionality. Endpoint address dependent filter compromises natted node's ability to receive packet from anyone. This seems to be a huge loss for the Internet community, for the sake of halfway security measures. Probably this is likely a thing that people who only has VoIP in mind do not care about. 3) Avoid ICE to be an requirement for traversing NAT As a programmer, the simplest solution is preferable. ICE is way far from 'simple'. Endpoint dependent filter behavior requires ICE connectivity check process or equivalent (UDP hole punching by knowing the other end's transport address). Just for a reminder for us... So, I strongly support: REQ-7: NATs MUST implement Endpoint-Independent Filtering in their default configuration. NATs SHOULD be configurable to support Address-Specific Filtering or Endpoint-Specific Filtering at the option of the system administrator. - Yutaka Bryan Ford wrote: On Tuesday 17 May 2005 12:41, Cullen Jennings wrote: We are really only discussing if we recommend that the filtering is restrictive or not here. Somewhere you pointed out this is falling into the firewall area and may not even be relevant for BEHAVE to specify and I think I agree with you on that. At one point we had that but got strong feedback form implementers, please recommend (but don't mandate) something as they want to know what to do. We certainly want Full Cone NAT to be behave compliant. However, what you are proposing is making it such that a NAT with only Restricted filtering would *not* be behave compliant. Not true - please refer again to my specific proposal: REQ-7: NATs MUST implement Endpoint-Independent Filtering in their default configuration. NATs SHOULD be configurable to support Address-Specific Filtering or Endpoint-Specific Filtering at the option of the system administrator. Notice *"in their default configuration"*. Under this proposal, a NAT that does Restricted filtering is still BEHAVE compliant *if* the administrator configures it as such. My proposal in fact specifically recommends that NAT vendors implement Restricted filtering as a configuration option, and since most NATs already support it we can assume that it will be a pretty standard security option. But the operative word here is *option*. A NAT in its "out of the box" configuration shouldn't impose firewall functionality that severely interferes with the capabilities of applications, as restricted filtering does. I strongly disagree with this proposal. I understand your security argument below however I think it is wrong. A large portion of application that use UDP do not do connected UDP. That's because a "large portion of application[s] that use UDP" use a single UDP port to talk to multiple external endpoints, usually because they want to engage in peer-to-peer-style communication in some form with other peer hosts. And it is precisely this "large portion" of UDP applications that needs endpoint-independent filtering the most. Furthermore, the outside firewall that does this type of behavior is protecting the resources on the internal network from being consumed forwarding bogus packets even if the eventual end application will correctly discard them. We can not define behave such that a behave compliant NAT could not also be a fairly normally configured firewall. First of all, even with endpoint-independent filtering, a NAT will in practice filter out the vast majority of bogus traffic that reaches it - the only bogus traffic it will let through is bogus traffic that happens to hit the specific external port number that corresponds to an active port binding, and that is not likely to happen too often because these port numbers are assigned more-or-less randomly by the NAT and only in the high, non-well-known port number space. The incremental benefit of restrictive filtering on random bogus traffic is going to be very small. An attacker might deliberately send bogus to a bound NAT port known to be in use, but if the attacker can find out which NAT port the application is using, then the attacker probably also knows (or can easily find out or guess) the address and port number of the remote host that the application is talking to and just spoof that source IP address and port number in its attack packets, getting around Restricted filtering as well. In fact the remote host's endpoint is in practice likely to be much easier for the attacker to find out or guess than the application's public NAT port, because of the overwhelming prevalence of well-known servers and ports on the Internet. So the practical benefit that Restricted filtering provides even against directed attacks is still minimal. Finally, the goal of "protecting the resources on the internal network from being consumed forwarding bogus packets" is really only a consideration on large corporate or ISP networks with substantial internal traffic load, and if this minimization of resource use is a concern then the network administrator can certainly be expected to know how to configure the company's NAT to enable Restricted filtering. As I pointed out above, under my proposal a NAT can use Restricted filtering and still be BEHAVE-compliant as long as it is the administrator (not the NAT vendor) that enables this firewall behavior. For home NATs, in contrast, minimizing resource load on the internal network due to bogus traffic is completely a non-issue because the home network (Ethernet or 802.11 or whatever) is typically so much faster than the Internet uplink anyway. In this case it's much more important that NATs consistently support applications well, which my proposal ensures by requiring that the NAT's "out of the box" configuration is Endpoint-independent Filtering. Joe Clueless who buys a home NAT router probably doesn't have any idea what NAT actually is, but he wants his applications to work. However, which of us is right or wrong about the security implications here turns out to probably be totally irrelevant. I phoned my colleagues at Linksys this morning and asked if they would do this. When they stopped laughing at me they told me no way. If they did this, netgear and dlink would claim their NATs were more secure than linksys NATs and they would get toasted in the market. They are not going to do full cone. I imagine your own testing shows the number of full cone NATs in the market is a) fairly small and b) becoming more rare. My testing indicates this. How did you ask the question? Any marketing person worth his monthly paycheck will be able to figure out that a NAT following my proposed recommendations can be presented as: * JUST AS SECURE as everyone else's NAT because it implements all the same security features (including Restricted filtering, as a configurable option). * MORE APPLICATION-FRIENDLY than the next guy's NAT because it allows applications to have a first-class "Internet presence", and the other guy's (non-configurable Restricted Cone NAT) doesn't. With this approach I'm sure any NAT that wasn't BEHAVE-compliant would quickly get toasted in the market. Besides, is it our job to bow to every existing NAT market tendency, good or bad, or is to set a standard for how NATs _should_ (and reasonably can) behave in order to work well with applications? Cheers, Bryan _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From yutaka_takeda@playstation.sony.com Fri, 20 May 2005 14:38:01 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Fri, 20 May 2005 14:38:01 -0700 (PDT) Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: <428E58B3.3010505@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain Exactly! Bryan Ford wrote: On Friday 20 May 2005 16:07, Cullen Jennings wrote: I don't see how Brian's proposal helps application developers. Let say that a NAT has been configured to do address dependant filtering, the application still supposed to work. We are trying to make a system where applications can work with any behave compliant NAT. That means the application needs to assume the "worst case". Unless we change Req-7 to say that a NAT MUST NOT filter based on the the address or port, we don't make life any easier for the application developer. Not true - many applications can easily handle _some_ nodes having restrictive filtering behavior but would be seriously impacted for the worse if _most_ nodes had restrictive filtering behavior. In particular, many P2P application protocols, including "the latest craze" Skype I believe, employ a concept of "supernode" versus "ordinary node". Through automatic self-selection or by some election process with their peers, particularly stable, long-lived, or accessible ordinary nodes can be "promoted" to supernode status (usually invisibly to the user). Once promoted, supernodes take on the additional responsibilities of keeping a number of other "ordinary nodes" connected, such as by aggregating search index data, or... (drum droll :) ) by helping ordinary nodes to establish P2P connections to each other. In the design of many P2P protocols it is very natural for supernodes to provide such a "rendezvous server" function to help ordinary nodes perform hole punching. However, to perform this rendezvous server function the supernode must itself have an IP address and UDP port number at which it can be reached directly by any node across the network - i.e., if it is NATted, the NAT must have Full Cone (Endpoint-independent filtering) behavior. In such a protocol, a node behind a Restricted Cone NAT typically cannot become a supernode. As an ever-larger percentage of hosts on the Internet become NATted, if those NATs have restricted filtering, then the total number of hosts that are eligible to become supernodes rapidly diminishes. If this working group establishes restricted filtering as "The Offical Standard" (tm) for NAT behavior, then that may well be the death knell for all supernode-based application protocols. As the number of "supernode-eligible" participants on the Internet falls and drops below some percentage of the total participants due to Restricted Cone NAT, the few supernodes that exist will be increasingly overloaded and the protocol eventually breaks down. If, on the other hand, this working group recommends Full Cone NAT as the standard, "application-friendly" behavior, while leaving the option open for the more paranoid users and administrators to configure their NATs for restricted filtering, we can be pretty sure that a high enough percentage of users will leave their NATs in Full Cone mode that supernode-based protocols will continue to function reliably. Cheers, Bryan On 5/19/05 9:08 PM, "yutaka_takeda@xxxxxxxxxxxxxxxxxxxx" wrote: I agree with Bryan's opinion with following three reasons: 1) NAT should do just what it is supposed to do. If the port overloading is not required, then the "external filtering" is no longer a NAT's job. "It sounds more secure.." as more of a sales talk just does not sound right to be a basis of a decision made by IETF. Filtering behavior should have something to do with users' security policy, which is exactly what Bryan is suggesting. 2) Endpoint independent maintains full UDP functionality. Endpoint address dependent filter compromises natted node's ability to receive packet from anyone. This seems to be a huge loss for the Internet community, for the sake of halfway security measures. Probably this is likely a thing that people who only has VoIP in mind do not care about. 3) Avoid ICE to be an requirement for traversing NAT As a programmer, the simplest solution is preferable. ICE is way far from 'simple'. Endpoint dependent filter behavior requires ICE connectivity check process or equivalent (UDP hole punching by knowing the other end's transport address). Just for a reminder for us... So, I strongly support: REQ-7: NATs MUST implement Endpoint-Independent Filtering in their default configuration. NATs SHOULD be configurable to support Address-Specific Filtering or Endpoint-Specific Filtering at the option of the system administrator. - Yutaka Bryan Ford wrote: On Tuesday 17 May 2005 12:41, Cullen Jennings wrote: We are really only discussing if we recommend that the filtering is restrictive or not here. Somewhere you pointed out this is falling into the firewall area and may not even be relevant for BEHAVE to specify and I think I agree with you on that. At one point we had that but got strong feedback form implementers, please recommend (but don't mandate) something as they want to know what to do. We certainly want Full Cone NAT to be behave compliant. However, what you are proposing is making it such that a NAT with only Restricted filtering would *not* be behave compliant. Not true - please refer again to my specific proposal: REQ-7: NATs MUST implement Endpoint-Independent Filtering in their default configuration. NATs SHOULD be configurable to support Address-Specific Filtering or Endpoint-Specific Filtering at the option of the system administrator. Notice *"in their default configuration"*. Under this proposal, a NAT that does Restricted filtering is still BEHAVE compliant *if* the administrator configures it as such. My proposal in fact specifically recommends that NAT vendors implement Restricted filtering as a configuration option, and since most NATs already support it we can assume that it will be a pretty standard security option. But the operative word here is *option*. A NAT in its "out of the box" configuration shouldn't impose firewall functionality that severely interferes with the capabilities of applications, as restricted filtering does. I strongly disagree with this proposal. I understand your security argument below however I think it is wrong. A large portion of application that use UDP do not do connected UDP. That's because a "large portion of application[s] that use UDP" use a single UDP port to talk to multiple external endpoints, usually because they want to engage in peer-to-peer-style communication in some form with other peer hosts. And it is precisely this "large portion" of UDP applications that needs endpoint-independent filtering the most. Furthermore, the outside firewall that does this type of behavior is protecting the resources on the internal network from being consumed forwarding bogus packets even if the eventual end application will correctly discard them. We can not define behave such that a behave compliant NAT could not also be a fairly normally configured firewall. First of all, even with endpoint-independent filtering, a NAT will in practice filter out the vast majority of bogus traffic that reaches it - the only bogus traffic it will let through is bogus traffic that happens to hit the specific external port number that corresponds to an active port binding, and that is not likely to happen too often because these port numbers are assigned more-or-less randomly by the NAT and only in the high, non-well-known port number space. The incremental benefit of restrictive filtering on random bogus traffic is going to be very small. An attacker might deliberately send bogus to a bound NAT port known to be in use, but if the attacker can find out which NAT port the application is using, then the attacker probably also knows (or can easily find out or guess) the address and port number of the remote host that the application is talking to and just spoof that source IP address and port number in its attack packets, getting around Restricted filtering as well. In fact the remote host's endpoint is in practice likely to be much easier for the attacker to find out or guess than the application's public NAT port, because of the overwhelming prevalence of well-known servers and ports on the Internet. So the practical benefit that Restricted filtering provides even against directed attacks is still minimal. Finally, the goal of "protecting the resources on the internal network from being consumed forwarding bogus packets" is really only a consideration on large corporate or ISP networks with substantial internal traffic load, and if this minimization of resource use is a concern then the network administrator can certainly be expected to know how to configure the company's NAT to enable Restricted filtering. As I pointed out above, under my proposal a NAT can use Restricted filtering and still be BEHAVE-compliant as long as it is the administrator (not the NAT vendor) that enables this firewall behavior. For home NATs, in contrast, minimizing resource load on the internal network due to bogus traffic is completely a non-issue because the home network (Ethernet or 802.11 or whatever) is typically so much faster than the Internet uplink anyway. In this case it's much more important that NATs consistently support applications well, which my proposal ensures by requiring that the NAT's "out of the box" configuration is Endpoint-independent Filtering. Joe Clueless who buys a home NAT router probably doesn't have any idea what NAT actually is, but he wants his applications to work. However, which of us is right or wrong about the security implications here turns out to probably be totally irrelevant. I phoned my colleagues at Linksys this morning and asked if they would do this. When they stopped laughing at me they told me no way. If they did this, netgear and dlink would claim their NATs were more secure than linksys NATs and they would get toasted in the market. They are not going to do full cone. I imagine your own testing shows the number of full cone NATs in the market is a) fairly small and b) becoming more rare. My testing indicates this. How did you ask the question? Any marketing person worth his monthly paycheck will be able to figure out that a NAT following my proposed recommendations can be presented as: * JUST AS SECURE as everyone else's NAT because it implements all the same security features (including Restricted filtering, as a configurable option). * MORE APPLICATION-FRIENDLY than the next guy's NAT because it allows applications to have a first-class "Internet presence", and the other guy's (non-configurable Restricted Cone NAT) doesn't. With this approach I'm sure any NAT that wasn't BEHAVE-compliant would quickly get toasted in the market. Besides, is it our job to bow to every existing NAT market tendency, good or bad, or is to set a standard for how NATs _should_ (and reasonably can) behave in order to work well with applications? Cheers, Bryan _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From huitema@windows.microsoft.com Fri, 20 May 2005 16:35:11 -0700 (PDT) From: "Christian Huitema" Date: Fri, 20 May 2005 16:35:11 -0700 (PDT) Subject: RE: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A lot of this discussion assumes that "address independent filtering" makes the design of applications much simpler. Well, that is not really my experience. Even with address independent filtering, sending a packet to the specified address and port often fails. For example, it fails when two clients are behind the same NAT that does not support hair-pinning, e.g. when two clients are on different local networks, but behind the same ISP NAT. It also fails when there are multiple exit NAT for a local network, and the peer is not reached through the same NAT as the STUN server. So, in practice, even with "address independent filtering", applications have to include a verification step to make sure that the communication actually works. Another fly in the ointment is, there is almost no way for an application to ascertain that it is actually behind an "address independent filtering" NAT. I do not personally like "address independent filtering". I don't believe that the exposure is unduly large. It does make P2P application more reliable, i.e. they tend to work more often. But it does not make the applications simpler. -- Christian Huitema From jon.peterson@neustar.biz Fri, 20 May 2005 16:35:41 -0700 (PDT) From: "Peterson, Jon" Date: Fri, 20 May 2005 16:35:41 -0700 (PDT) Subject: [Ietf-behave] on the behave charter Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59701502ED3@stntexch03.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain In response to some of the discussion on this list related to introducing a new charter milestone for a general transport-independent framework and requirements draft which would be independent of the transport-specific milestones currently on the charter, I have a few comments. As some comments to the list have pointed out, there are requirements in the UDP draft which are not specific to UDP. Those requirements should no doubt be identified as such (I believe the authors of the UDP draft have agreed to this), and preferably split into a subsection specifically designated for such requirements. I think it is important for the UDP work to complete expeditiously. I furthermore believe that these general requirements are necessary to understanding how to engineer UDP NAT behavior. I foresee no great difficulty in having other drafts, like the TCP draft, reference this section of the UDP document, provided that its content is sound. Are there any advocates of a separate transport-independent draft who believe that this approach is unworkable? Jon Peterson NeuStar, Inc. From jon.peterson@neustar.biz Fri, 20 May 2005 16:47:30 -0700 (PDT) From: "Peterson, Jon" Date: Fri, 20 May 2005 16:47:30 -0700 (PDT) Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59701502ED4@stntexch03.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain In light of the recent Last Call discussions about behave-nat-udp, I wanted to make a few comments. Regarding REQ-7, it seems pretty clear to me that there is no immediate consensus to endorse endpoint-dependent or endpoint-independent filtering. Consequently, in the interest of time I'd like to make the modest proposal that REQ-7 endorse neither, but instead state that both these modes (and address-specific filtering) should be supported. Is there some advantage to privileging one over the other? I see no great need to specify the maximum datagram length that NATs must process. I find the conceptual model of behave-nat-udp, which focuses on functions NATs might perform rather than classifications of NATs as particular taxonomic entities (Basic, Full Cone, etc), to be very attractive. That much said, I do agree with several commentators that the resulting functional descriptions lead to some very wordy terminologies. There seems to be some emerging agreement on shorter terms, and I think that would be most welcome to readers. Regarding the terms used in behave-nat-udp versus ford-behave-gen, I see no immediate problems with the terms used in behave-nat-udp. The distinction between a "map", a "binding" and a "NAT session" in ford-behave-gen makes me a little dizzy, to be honest. I do not find the definition of "mapping" in behave-nat-udp to be problematic. I don't find the use of the term "session" to refer to a transport-layer connection between two endpoints to be problematic. Terminology can be endlessly debated, but it is not clear to me that we will gain much leverage on our problem space by spending a few more cycles refining these terms. In Section 4.1, I think it reasonable to define behaviors such as "External NAT mapping is endpoint address dependent" just in order to disallow them in the requirements section. I think it is worth being specific about things that we don't want implementers to do. Given the conceptual model of behave-nat-udp, I think the distinction between "deterministic" and "non-deterministic" NATs in Section 8 is valuable. In fact, I think this non-determinism is one of the primary grounds to move away from a taxonomic model of NATs and into the functional model espoused by behave-nat-udp. I didn't find Section 8 to be particularly obscure when I read it, though no doubt the text could be made more focused. Jon Peterson NeuStar, Inc. From baford@mit.edu Sat, 21 May 2005 08:03:05 -0700 (PDT) From: Bryan Ford Date: Sat, 21 May 2005 08:03:05 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD59701502ED4@stntexch03.cis.neustar.com> Message-ID: <200505211103.03664.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Friday 20 May 2005 19:47, Peterson, Jon wrote: > In light of the recent Last Call discussions about behave-nat-udp, I wanted > to make a few comments. > > Regarding REQ-7, it seems pretty clear to me that there is no immediate > consensus to endorse endpoint-dependent or endpoint-independent filtering. > Consequently, in the interest of time I'd like to make the modest proposal > that REQ-7 endorse neither, but instead state that both these modes (and > address-specific filtering) should be supported. Is there some advantage to > privileging one over the other? Yes - unfortunately the "status quo" is currently [Port-]Restricted Cone NAT, and if we endorse this status quo by not recommending anything, the trend is likely to make many supernode-based peer-to-peer application protocols unworkable in the future as the percentage of nodes with a first-class network presence diminishes. As a minor change to your suggested compromise, how about adding a "weak endorsement" of Endpoint-Independent Filtering, as follows: REQ-7: NATs SHOULD support Endpoint-Independent Filtering, Address-Specific Filtering, and Endpoint-Specific Filtering, as options configurable by the user. Endpoint-Independent Filtering SHOULD be the default. This is a weaker endorsement of Endpoint-Independent filtering than I'd like, but I can live with it. And I also propose adding text to the Security Considerations section (as Paul Hoffman suggested earlier I believe) explaining the security versus application-friendliness tradeoffs. > I see no great need to specify the maximum datagram length that NATs must > process. That issue wasn't a major concern for me; I just wanted to make sure we weren't leaving something important out. If no one else thinks it's important, I'm happy to drop it. > In Section 4.1, I think it reasonable to define behaviors such as "External > NAT mapping is endpoint address dependent" just in order to disallow them > in the requirements section. I think it is worth being specific about > things that we don't want implementers to do. I guess I'm OK with that, as long as the two disallowed behaviors are actually stated as such in-line in the section in which the three behaviors are specified. In other words, I'll drop this concern as long as copies of the requirements specifications are included in-line throughout the document and not just at the end, as I suggested elsewhere. As it is, the document (and especially this section) reads as if it's saying, "here are three perfectly reasonable behaviors", and makes it very difficult for the reader to figure out exactly which behaviors are actually endorsed. > Given the conceptual model of behave-nat-udp, I think the distinction > between "deterministic" and "non-deterministic" NATs in Section 8 is > valuable. In fact, I think this non-determinism is one of the primary > grounds to move away from a taxonomic model of NATs and into the functional > model espoused by behave-nat-udp. I didn't find Section 8 to be > particularly obscure when I read it, though no doubt the text could be made > more focused. As I've said before, I'm fine with having a specific discussion of determinism like this, and I think it's a good thing - but since the only aspects of determinism this section actually talks about is mapping and filtering behavior, I think this discussion of determinism needs to be merged into the appropriate sections on those topics, specifically 4.1 and 5.1. Thanks, Bryan From baford@mit.edu Sat, 21 May 2005 08:46:58 -0700 (PDT) From: Bryan Ford Date: Sat, 21 May 2005 08:46:58 -0700 (PDT) Subject: Re: [Ietf-behave] on the behave charter In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD59701502ED3@stntexch03.cis.neustar.com> Message-ID: <200505211146.54866.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Friday 20 May 2005 19:35, Peterson, Jon wrote: > In response to some of the discussion on this list related to introducing a > new charter milestone for a general transport-independent framework and > requirements draft which would be independent of the transport-specific > milestones currently on the charter, I have a few comments. > > As some comments to the list have pointed out, there are requirements in > the UDP draft which are not specific to UDP. Those requirements should no > doubt be identified as such (I believe the authors of the UDP draft have > agreed to this), and preferably split into a subsection specifically > designated for such requirements. In the interest of getting the UDP document published quickly, I would be amenable to this compromise strategy, under the condition that the new transport-independent subsection you propose incorporates some of the important text from the behave-gen draft (draft-ford-behave-gen-01.txt) that provide important general information or address issues currently missing from the UDP draft. Specifically: * Section 2 of behave-gen, which provides the logical model of NAT operation essential to making the actual behavioral requirements clear and precise for NAT implementors. I could live with compressing or eliminating section 2.4 on the legacy RFC3489 terminology since I know there are strong objections to even mentioning those terms, but I think the rest of the section is essential. * Section 3.3 in behave-gen provides a more complete discussion of receive fragmentation behavior than the current section 11 of the UDP draft, and should be included or merged. Also, the specific requirements regarding fragmentation support needs to be updated as per the recent fragmentation discussion on the list: i.e., the NAT MUST support receiving fragmented packets. * Section 3.4 in behave-gen, on outbound fragmentation issues. * Section 3.6, on DHCP-configured NATs and conflicting private IP address spaces. * Section 3.8, on ICMP error handling, provides a more complete and transport-independent discussion of this issue than the current section 9 of behave-udp, and thus should be incorporated. * Section 3.10, on ALG support recommendations. * Section 3.11, on denial-of-service protection. * Section 4, "Hints to Implementors": I think it would be useful to include at least some of this section, although it is only for information and doesn't contain any normative requirements. > I think it is important for the UDP work to complete expeditiously. I > furthermore believe that these general requirements are necessary to > understanding how to engineer UDP NAT behavior. I foresee no great > difficulty in having other drafts, like the TCP draft, reference this > section of the UDP document, provided that its content is sound. I agree, again provided that its content is sound, and provided that the transport-independent portions of the UDP draft are clearly marked as such in a separate section or sections for that purpose, so that there will be no ambiguity on which parts also apply to other transports. Cheers, Bryan From baford@mit.edu Sat, 21 May 2005 08:58:53 -0700 (PDT) From: Bryan Ford Date: Sat, 21 May 2005 08:58:53 -0700 (PDT) Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt In-Reply-To: Message-ID: <200505211158.50830.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Friday 20 May 2005 19:35, Christian Huitema wrote: > A lot of this discussion assumes that "address independent filtering" > makes the design of applications much simpler. Well, that is not really > my experience. The goal of making applications simplier was never one of my reasons for recommending endpoint-independent filtering: indeed, as you point out, given that there's no way we're going to make restricted filtering go away even if we want to, many applications will still have to be able to deal with being located behind a restricted filter. The issue at hand is not one of application simplicity, but one of basic connectivity: endpoint-independent filtering gives the NATted application a first-class public presence on the Internet, while restricted filtering forces the application to rely on public rendezvous servers for all of its peer-to-peer connectivity needs. As I pointed out in prior messages, common peer-to-peer application protocols can work around some (even many) nodes not having a first-class public presence, but would break down if very few nodes do. > I do not personally like "address independent filtering". I don't > believe that the exposure is unduly large. Did you get something reversed here? The first sentence seems to be against endpoint-independent filtering, while the second seems to be for it. > It does make P2P application > more reliable, i.e. they tend to work more often. But it does not make > the applications simpler. Exactly. My argument in favor of endpoint-independent filtering is one of application reliability, robustness, and general connectivity, not one of implementation simplicity. Cheers, Bryan From srisuresh@yahoo.com Sun, 22 May 2005 12:47:36 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 22 May 2005 12:47:36 -0700 (PDT) Subject: Re: [Ietf-behave] on the behave charter Message-ID: <20050522194736.46729.qmail@web40424.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- "Peterson, Jon" wrote: > > In response to some of the discussion on this list related to introducing a > new charter milestone for a general transport-independent framework and > requirements draft which would be independent of the transport-specific > milestones currently on the charter, I have a few comments. > [suresh] First off, thank you, Jon, for taking notice and responding with comments. I appreciate that. > As some comments to the list have pointed out, there are requirements in the > UDP draft which are not specific to UDP. Those requirements should no doubt > be identified as such (I believe the authors of the UDP draft have agreed to > this), and preferably split into a subsection specifically designated for > such requirements. > > I think it is important for the UDP work to complete expeditiously. I [suresh] UDP document does not get used in isolation by NAT implementers. TCP work is equally or arguably more important (More apps use TCP than UDP). I donot see the particular need for rushing the UDP draft (other than the artificial one, by virtue of it being lised first in the WG milestones). NAT implementers do not care for UDP RFC to be the first. More basic stuff such as the logical mode of NAT operation, Distinction between Bindings and NAT Sessions, DHCP Configured NATs, Hairpinning, fragmentation handling, ICMP handling and generic hints to implementers are much more important from a basic requirements understanding perspective. UDP specific aditional requirements are relatively minor. As an FYI, more than 50% of the requirements in the current UDP draft are not UDP specific. > furthermore believe that these general requirements are necessary to > understanding how to engineer UDP NAT behavior. [suresh] Yes. I agree. > I foresee no great difficulty > in having other drafts, like the TCP draft, reference this section of the UDP > document, provided that its content is sound. > [suresh] UDP draft curently has 13 requirements listed. More than 50% of the requiements are not UDP specific. Behave-gen draft is focussed on generic requirements, including common terminology and hints to implementers and has 11 generic requirements. Given a choice between the TCP draft refering the UDP draft vs a generic draft for refering generic sections, which do you believe is cleaner? My choice would be to have a seperate draft for generic requirements. That sounds more straight forward, I believe, from a end-user (i.e., NAT implementer) perspective. > Are there any advocates of a separate transport-independent draft who believe > that this approach is unworkable? > [suresh] The approach you suggest is doable. But, that is more work because large portions of the behave-gen draft are to be merged into the UDP draft to have a solid generic section. Instead, why not simply excise generic stuff from the UDP draft and review the UDP and generic drafts independently, but at the same time. > Jon Peterson > NeuStar, Inc. Thanks. regards, suresh From srisuresh@yahoo.com Sun, 22 May 2005 12:56:10 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 22 May 2005 12:56:10 -0700 (PDT) Subject: Re: [Ietf-behave] on the behave charter Message-ID: <20050522195609.31488.qmail@web40428.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain If there MUST be just one draft. I agree with what Bryan says below. Large portions of behave-gen should be merged with the behave-udp draft. cheers, suresh --- Bryan Ford wrote: > On Friday 20 May 2005 19:35, Peterson, Jon wrote: > > In response to some of the discussion on this list related to introducing a > > new charter milestone for a general transport-independent framework and > > requirements draft which would be independent of the transport-specific > > milestones currently on the charter, I have a few comments. > > > > As some comments to the list have pointed out, there are requirements in > > the UDP draft which are not specific to UDP. Those requirements should no > > doubt be identified as such (I believe the authors of the UDP draft have > > agreed to this), and preferably split into a subsection specifically > > designated for such requirements. > > In the interest of getting the UDP document published quickly, I would be > amenable to this compromise strategy, under the condition that the new > transport-independent subsection you propose incorporates some of the > important text from the behave-gen draft (draft-ford-behave-gen-01.txt) that > provide important general information or address issues currently missing > from the UDP draft. Specifically: > > * Section 2 of behave-gen, which provides the logical model of NAT operation > essential to making the actual behavioral requirements clear and precise for > NAT implementors. I could live with compressing or eliminating section 2.4 > on the legacy RFC3489 terminology since I know there are strong objections to > > even mentioning those terms, but I think the rest of the section is > essential. > > * Section 3.3 in behave-gen provides a more complete discussion of receive > fragmentation behavior than the current section 11 of the UDP draft, and > should be included or merged. Also, the specific requirements regarding > fragmentation support needs to be updated as per the recent fragmentation > discussion on the list: i.e., the NAT MUST support receiving fragmented > packets. > > * Section 3.4 in behave-gen, on outbound fragmentation issues. > > * Section 3.6, on DHCP-configured NATs and conflicting private IP address > spaces. > > * Section 3.8, on ICMP error handling, provides a more complete and > transport-independent discussion of this issue than the current section 9 of > behave-udp, and thus should be incorporated. > > * Section 3.10, on ALG support recommendations. > > * Section 3.11, on denial-of-service protection. > > * Section 4, "Hints to Implementors": I think it would be useful to include > at > least some of this section, although it is only for information and doesn't > contain any normative requirements. > > > I think it is important for the UDP work to complete expeditiously. I > > furthermore believe that these general requirements are necessary to > > understanding how to engineer UDP NAT behavior. I foresee no great > > difficulty in having other drafts, like the TCP draft, reference this > > section of the UDP document, provided that its content is sound. > > I agree, again provided that its content is sound, and provided that the > transport-independent portions of the UDP draft are clearly marked as such in > > a separate section or sections for that purpose, so that there will be no > ambiguity on which parts also apply to other transports. > > Cheers, > Bryan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Sun, 22 May 2005 15:54:50 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 22 May 2005 15:54:50 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Message-ID: <20050522225450.67232.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain My comments inline below. regards, suresh --- "Peterson, Jon" wrote: > > In light of the recent Last Call discussions about behave-nat-udp, I wanted > to make a few comments. > > Regarding REQ-7, it seems pretty clear to me that there is no immediate > consensus to endorse endpoint-dependent or endpoint-independent filtering. > Consequently, in the interest of time I'd like to make the modest proposal > that REQ-7 endorse neither, but instead state that both these modes (and > address-specific filtering) should be supported. Is there some advantage to > privileging one over the other? [suresh] I have not read all the comments on the thread. However, I do agree, a NAT that supports either the Address-restricted Cone NAT or the Full-Cone NAT type behavior should be considered behave compliant. As for making Full Cone NAT behavior as the only requirement - There is queasiness from the vendors as this will be perceived as security threat. Address Restricted Cone NAT sould be the minimal bar. Per Refer RFC 1122, section 4.1.3.5 - UDP apps are required to respond using the same Src/dest address pair, but no restrictions to make the source port same as the destination port in the received request. For example, in TFTP protocol (ref: RFC 1350), the initiating client sends a TFTP request with UDP SrcPort set to XX and DestPort set to 69. The TFTP servr responds back with SrcPort set to YY and DestPort set to XX. As you will note, the TFTP would not work with a Port Restricted Cone NAT, but will work with an Address restricted Cone NAT. So, it makes sense to recommend that NATs support Address Restricted Cone NAT type behavior rather than Port Restricted Cone NAT behavior. > > I see no great need to specify the maximum datagram length that NATs must > process. > [suresh] I assume, you are saying this is in the context of IP fragment support. Say, you mandate that a NAT device must support IP fragment processing, yet the fragments do not go through because the NAT device restricts assembled IP packet size to be 1500 bytes. It is no help to the apps to learn this by trial and error. So, I think, it would make sense to require the NATs to suport a minimal threshold (say, 8710 bytes), so most common apps using IP fragament (such as NFSv2/v3) woudl work through them. > I find the conceptual model of behave-nat-udp, which focuses on functions > NATs might perform rather than classifications of NATs as particular > taxonomic entities (Basic, Full Cone, etc), to be very attractive. That much > said, I do agree with several commentators that the resulting functional > descriptions lead to some very wordy terminologies. There seems to be some > emerging agreement on shorter terms, and I think that would be most welcome > to readers. > > Regarding the terms used in behave-nat-udp versus ford-behave-gen, I see no > immediate problems with the terms used in behave-nat-udp. The distinction > between a "map", a "binding" and a "NAT session" in ford-behave-gen makes me > a little dizzy, to be honest. I do not find the definition of "mapping" in > behave-nat-udp to be problematic. I don't find the use of the term "session" > to refer to a transport-layer connection between two endpoints to be > problematic. Terminology can be endlessly debated, but it is not clear to me > that we will gain much leverage on our problem space by spending a few more > cycles refining these terms. [suresh] I am not suggesting redefining existign terms or coining new terms. But, I am suggestng reuse of terms that are already defined in previous RFCs. I am specifically refering to terms defined on NAT RFCs, not the Cone NAT terminology in RFC 3489. I believe, it is important to use the term "Binding" as was originally defined in RFC 3022 & 4008 and not use it interchangeably with mapping. After all, "Binding" is a key NAT concept. A big drive of the behave drafts is to require NAT implementers to support "Address/Port Bindings". Symmetric NATs donot support Bindings and hence Symmteric NAT type behavior ought to be deprecated. It makes no sense to dilute the meaning of this term or not use this well defined term. RFC 4008 associates specific meaning to "mapping" and "NAT Session". Using the previously defined terms consistently makes the text technically cohesive. > > In Section 4.1, I think it reasonable to define behaviors such as "External > NAT mapping is endpoint address dependent" just in order to disallow them in > the requirements section. I think it is worth being specific about things > that we don't want implementers to do. > [suresh] I am fine with this. > Given the conceptual model of behave-nat-udp, I think the distinction between > "deterministic" and "non-deterministic" NATs in Section 8 is valuable. In > fact, I think this non-determinism is one of the primary grounds to move away > from a taxonomic model of NATs and into the functional model espoused by > behave-nat-udp. I didn't find Section 8 to be particularly obscure when I > read it, though no doubt the text could be made more focused. > [suresh] While I have no problem with functional model, I find it problematic to see the taxonomy being fully jettisioned or an entirely new jargon being developed to go about describing the same stuff. As I said earlier, I am not refering to the RFC 3489 terms. I believe, ford-midcm-p2p is the draft that first proposed that attempting to do port preservation should not be required. Bryan and I were co-authors of the draft. I am certainly not opposed to mentioning this in the draft. I am fine with that. But, the text in the document is far from clear to me. Some of the text seems to be describing the buggy behavior of some NAT devices, not necessarily the intended behavior. I donot see a need to describe bugs. Products have bugs. But, we dont necessarily document bugs in RFCs. > Jon Peterson > NeuStar, Inc. > regards, suresh From fluffy@cisco.com Mon, 23 May 2005 10:22:42 -0700 (PDT) From: Cullen Jennings Date: Mon, 23 May 2005 10:22:42 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD59701502ED4@stntexch03.cis.neustar.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 5/20/05 4:47 PM, "Peterson, Jon" wrote: > Regarding REQ-7, it seems pretty clear to me that there is no immediate > consensus to endorse endpoint-dependent or endpoint-independent filtering. > Consequently, in the interest of time I'd like to make the modest proposal > that REQ-7 endorse neither, but instead state that both these modes (and > address-specific filtering) should be supported. Is there some advantage to > privileging one over the other? Sounds reasonable - how about I change the text of Req-7 to REQ-7 It is RECOMMENDED that a NAT have an external filtering behavior that is endpoint address dependent or endpoint independent. From audet@nortel.com Mon, 23 May 2005 11:00:14 -0700 (PDT) From: "Francois Audet" Date: Mon, 23 May 2005 11:00:14 -0700 (PDT) Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Message-ID: <1ECE0EB50388174790F9694F77522CCF02674054@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Thanks to all, This is a formal proposal on how to move forward, with concrete text. ------------------------ How about this for REQ 7. In the Requirements section: REQ-7: In order to maximize application transparencyIt is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is desired, it is RECOMMENDED that a NAT have an "Address dependent" behavior. In the REQ-7 justification section would be modified as follows: REQ-7: The recommendation to use endpoint independent filtering is aimed at maximizing feature transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if ti was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could infere with applications that use one than one port. I'd like a Yay or Nay on the text above. --------------------- Wordy terminology: As for the wordy terminology for some of the names of behaviors, I also agree (the reasons for wordy names are historical). I can go through the text and simplify. ------------------------ REQs in-line: Bryan feels strongly about copying/pasting the REQs from section 12 in-line in the text as they occur, to help the reader. I personally think it is a reasonable suggestion. Is there any STRONG objection to this? (Cullen in particular, I'd like to hear from you). ------------------------- Determinism: I propose that to address Bryan's concern, I put a note in section 4.1 and 5.1 refering to the Deterministic behavior section. I also propose to change the first sentence of section 8 to the following: The classification of NATs is further complicated by the fact that under some conditions the same NAT often exhibits different behaviors, especially for mapping and filtering. ------------------------- Again, I'd like a Yay or Nay from people on the points above. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Peterson, Jon > Sent: Friday, May 20, 2005 16:48 > To: Behave > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > In light of the recent Last Call discussions about > behave-nat-udp, I wanted to make a few comments. > > Regarding REQ-7, it seems pretty clear to me that there is no > immediate consensus to endorse endpoint-dependent or > endpoint-independent filtering. Consequently, in the interest > of time I'd like to make the modest proposal that REQ-7 > endorse neither, but instead state that both these modes (and > address-specific filtering) should be supported. Is there > some advantage to privileging one over the other? > > I see no great need to specify the maximum datagram length > that NATs must process. > > I find the conceptual model of behave-nat-udp, which focuses > on functions NATs might perform rather than classifications > of NATs as particular taxonomic entities (Basic, Full Cone, > etc), to be very attractive. That much said, I do agree with > several commentators that the resulting functional > descriptions lead to some very wordy terminologies. There > seems to be some emerging agreement on shorter terms, and I > think that would be most welcome to readers. > > Regarding the terms used in behave-nat-udp versus > ford-behave-gen, I see no immediate problems with the terms > used in behave-nat-udp. The distinction between a "map", a > "binding" and a "NAT session" in ford-behave-gen makes me a > little dizzy, to be honest. I do not find the definition of > "mapping" in behave-nat-udp to be problematic. I don't find > the use of the term "session" to refer to a transport-layer > connection between two endpoints to be problematic. > Terminology can be endlessly debated, but it is not clear to > me that we will gain much leverage on our problem space by > spending a few more cycles refining these terms. > > In Section 4.1, I think it reasonable to define behaviors > such as "External NAT mapping is endpoint address dependent" > just in order to disallow them in the requirements section. I > think it is worth being specific about things that we don't > want implementers to do. > > Given the conceptual model of behave-nat-udp, I think the > distinction between "deterministic" and "non-deterministic" > NATs in Section 8 is valuable. In fact, I think this > non-determinism is one of the primary grounds to move away > from a taxonomic model of NATs and into the functional model > espoused by behave-nat-udp. I didn't find Section 8 to be > particularly obscure when I read it, though no doubt the text > could be made more focused. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From yutaka_takeda@playstation.sony.com Mon, 23 May 2005 15:36:53 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Mon, 23 May 2005 15:36:53 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02674054@zrc2hxm0.corp.nortel.com> Message-ID: <42925AF7.5050701@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain I had a discussion with our engineering team on the new proposal by Francois on REQ-7 this morning. We basically agree with his proposal. First off, some typos we found on the new REQ-7: "transperencyIt" -> "transparency, it" "ti was lucky" -> "it was lucky" "could infere" -> "could interfere" "one than one port" -> "more than one port" I am not confident if I understand following statement correctly. Could you please elaborate for me? "however, such a policy could interfere with applications that use more than one port." Besides the security point of view, avoiding endpoint address port dependent filtering has another significant benefit. If the two hosts (A and B) are behind different NATs where: - Host A is behind Full-cone or Restricted-cone NAT. - Host B is behind Symmetric NAT. (sorry for the use of old terminology) ICE can find connectivity between the two in this case, where if Host A is behind a Port-restricted cone NAT, ICE will not be able to find a direct connectivity between them. This could be mentioned in the REQ-7 justification section for more specific clarification..? I still think the inbound packet filtering is ideally a firewall matter. However, I have to admit that it has been implemented as a NAT feature and Behave needs to address it. Having both endpoint independent and dependent RECOMMENDED leaves it at NAT vendors discretion, which can be viewed as essentially the same thing as I proposed. I also pointed out that address independent helps simplifying an application. As pointed out by Christian, Bryan and Francois, address dependent NAT will not go away in the foreseeable feature anyways, and I agree that address independent filtering does not simply an application at any point, so it was pointless in this dialog. I would like to express my thanks to Bryan for raising the issue with original REQ-7 and others for lots of input and considerations in this regard. - Yutaka Francois Audet wrote: Thanks to all, This is a formal proposal on how to move forward, with concrete text. ------------------------ How about this for REQ 7. In the Requirements section: REQ-7: In order to maximize application transparencyIt is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is desired, it is RECOMMENDED that a NAT have an "Address dependent" behavior. In the REQ-7 justification section would be modified as follows: REQ-7: The recommendation to use endpoint independent filtering is aimed at maximizing feature transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if ti was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could infere with applications that use one than one port. I'd like a Yay or Nay on the text above. --------------------- Wordy terminology: As for the wordy terminology for some of the names of behaviors, I also agree (the reasons for wordy names are historical). I can go through the text and simplify. ------------------------ REQs in-line: Bryan feels strongly about copying/pasting the REQs from section 12 in-line in the text as they occur, to help the reader. I personally think it is a reasonable suggestion. Is there any STRONG objection to this? (Cullen in particular, I'd like to hear from you). ------------------------- Determinism: I propose that to address Bryan's concern, I put a note in section 4.1 and 5.1 refering to the Deterministic behavior section. I also propose to change the first sentence of section 8 to the following: The classification of NATs is further complicated by the fact that under some conditions the same NAT often exhibits different behaviors, especially for mapping and filtering. ------------------------- Again, I'd like a Yay or Nay from people on the points above. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Peterson, Jon > Sent: Friday, May 20, 2005 16:48 > To: Behave > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > In light of the recent Last Call discussions about > behave-nat-udp, I wanted to make a few comments. > > Regarding REQ-7, it seems pretty clear to me that there is no > immediate consensus to endorse endpoint-dependent or > endpoint-independent filtering. Consequently, in the interest > of time I'd like to make the modest proposal that REQ-7 > endorse neither, but instead state that both these modes (and > address-specific filtering) should be supported. Is there > some advantage to privileging one over the other? > > I see no great need to specify the maximum datagram length > that NATs must process. > > I find the conceptual model of behave-nat-udp, which focuses > on functions NATs might perform rather than classifications > of NATs as particular taxonomic entities (Basic, Full Cone, > etc), to be very attractive. That much said, I do agree with > several commentators that the resulting functional > descriptions lead to some very wordy terminologies. There > seems to be some emerging agreement on shorter terms, and I > think that would be most welcome to readers. > > Regarding the terms used in behave-nat-udp versus > ford-behave-gen, I see no immediate problems with the terms > used in behave-nat-udp. The distinction between a "map", a > "binding" and a "NAT session" in ford-behave-gen makes me a > little dizzy, to be honest. I do not find the definition of > "mapping" in behave-nat-udp to be problematic. I don't find > the use of the term "session" to refer to a transport-layer > connection between two endpoints to be problematic. > Terminology can be endlessly debated, but it is not clear to > me that we will gain much leverage on our problem space by > spending a few more cycles refining these terms. > > In Section 4.1, I think it reasonable to define behaviors > such as "External NAT mapping is endpoint address dependent" > just in order to disallow them in the requirements section. I > think it is worth being specific about things that we don't > want implementers to do. > > Given the conceptual model of behave-nat-udp, I think the > distinction between "deterministic" and "non-deterministic" > NATs in Section 8 is valuable. In fact, I think this > non-determinism is one of the primary grounds to move away > from a taxonomic model of NATs and into the functional model > espoused by behave-nat-udp. I didn't find Section 8 to be > particularly obscure when I read it, though no doubt the text > could be made more focused. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Mon, 23 May 2005 16:22:45 -0700 (PDT) From: "Francois Audet" Date: Mon, 23 May 2005 16:22:45 -0700 (PDT) Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Message-ID: <1ECE0EB50388174790F9694F77522CCF026F2E3E@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > -----Original Message----- > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] > Sent: Monday, May 23, 2005 15:37 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > I had a discussion with our engineering team on > the new proposal by Francois on REQ-7 this morning. > We basically agree with his proposal. > > First off, some typos we found on the new REQ-7: > "transperencyIt" -> "transparency, it" "ti was lucky" -> "it > was lucky" "could infere" -> "could interfere" "one than one > port" -> "more than one port" Thanks. Will fix. > I am not confident if I understand following statement > correctly. Could you please elaborate for me? > > "however, such a policy could interfere with applications > that use more > than one port." This is verbatim from the existing text. It is meant to the case of an application behind a NAT, which would pierce a pinhole by sending some packets from a source port, but where the remote application may send packets to more than one local UDP port. Perhaps the text should say "however, such a policy could interfere with applications that expect to receive UDP packets on more than one UDP port." > Besides the security point of view, avoiding endpoint > address port dependent filtering has another significant > benefit. If the two hosts (A and B) are behind different NATs where: > > - Host A is behind Full-cone or Restricted-cone NAT. > - Host B is behind Symmetric NAT. > (sorry for the use of old terminology) > > ICE can find connectivity between the two in this case, > where if Host A is behind a Port-restricted cone NAT, ICE > will not be able to find a direct connectivity between them. > This could be mentioned in the REQ-7 justification section > for more specific clarification..? Can you elaborate on this last point? I can't seem to make sense out of it. Do you mean find connectivity without a Media Relay? If so, can youd describe why, because it seems to me that you will require a media relay if one end has a address/port dependendent mapping. Thanks. From yutaka_takeda@playstation.sony.com Mon, 23 May 2005 17:56:18 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Mon, 23 May 2005 17:56:18 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF026F2E3E@zrc2hxm0.corp.nortel.com> Message-ID: <429279F3.6020607@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain > Can you elaborate on this last point? I can't seem to make sense > out of it. Do you mean find connectivity without a Media Relay? Yes. > If so, can youd describe why, because it seems to me that you will > require a media relay if one end has a address/port dependendent > mapping. Correct. That is what I meant. Let's say host A is behind a symmetric NAT (External IP address=X)(address/port dependent) and host B is behind a port restrected cone NAT (External IP address=Y) (address/port dependent). Each hosts performs binding request with a STUN server and obtain STUN derived addresses, X:p and Y:q respectively, and then exchange the addresses via a proxy server. The, host A and B performs connectivity check against the transport address obtained from the other host. However, packets sent from host A will have a different source port number 'p2' than 'p1', consequently, the packets will be discarded by the host B's NAT even host B performs connectivity check against X:p1. (port must match to receive) If the host B is behind an address dependent or independent NAT, the packets from host A will be eventually received regardless of what source port number it has, and then the host A will receive a response from host B. Host A, then detects a new MAPPED-ADDRESS (X:p2) in the response, and performs an update (see section 9.3 in ICE document) to modifiy the media transport address for host B. Finally, host B also finds connectivity to the X:p2 and terminates the session initiation process. So, from what I understand, by avoiding address/port dependent to be behave compliant NAT, the behave compliant NAT possibly removes the requirement of a media relay (like TURN) in the case where the remote host is behind a Symmetric NAT. Hope this helps. - Yutaka Francois Audet wrote: > -----Original Message----- > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] > Sent: Monday, May 23, 2005 15:37 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > I had a discussion with our engineering team on > the new proposal by Francois on REQ-7 this morning. > We basically agree with his proposal. > > First off, some typos we found on the new REQ-7: > "transperencyIt" -> "transparency, it" "ti was lucky" -> "it > was lucky" "could infere" -> "could interfere" "one than one > port" -> "more than one port" Thanks. Will fix. > I am not confident if I understand following statement > correctly. Could you please elaborate for me? > > "however, such a policy could interfere with applications > that use more > than one port." This is verbatim from the existing text. It is meant to the case of an application behind a NAT, which would pierce a pinhole by sending some packets from a source port, but where the remote application may send packets to more than one local UDP port. Perhaps the text should say "however, such a policy could interfere with applications that expect to receive UDP packets on more than one UDP port." > Besides the security point of view, avoiding endpoint > address port dependent filtering has another significant > benefit. If the two hosts (A and B) are behind different NATs where: > > - Host A is behind Full-cone or Restricted-cone NAT. > - Host B is behind Symmetric NAT. > (sorry for the use of old terminology) > > ICE can find connectivity between the two in this case, > where if Host A is behind a Port-restricted cone NAT, ICE > will not be able to find a direct connectivity between them. > This could be mentioned in the REQ-7 justification section > for more specific clarification..? Can you elaborate on this last point? I can't seem to make sense out of it. Do you mean find connectivity without a Media Relay? If so, can youd describe why, because it seems to me that you will require a media relay if one end has a address/port dependendent mapping. Thanks. From jon.peterson@neustar.biz Tue, 24 May 2005 01:50:27 -0700 (PDT) From: "Peterson, Jon" Date: Tue, 24 May 2005 01:50:27 -0700 (PDT) Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59701502EDC@stntexch03.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Regarding just the REQ-7 text, I do think Bryan's suggestion has some merit. These requirements are intended to constrain NAT implementers, not the deployers of NATs. The implementers of NATscannot anticipatewhat sort of filtering will be desired; that is something that deployers of NATs should be able to configure. Jon Peterson NeuStar, Inc.
-----Original Message-----From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Francois AudetSent: Monday, May 23, 2005 11:00 AMTo: 'Behave'Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Thanks to all, This is a formal proposal on how to move forward, with concrete text. ------------------------ How about this for REQ 7. In the Requirements section: REQ-7: In order to maximize application transparencyIt is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is desired, it is RECOMMENDED that a NAT have an "Address dependent" behavior. In the REQ-7 justification section would be modified as follows: REQ-7: The recommendation to use endpoint independent filtering is aimed at maximizing feature transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if ti was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could infere with applications that use one than one port. I'd like a Yay or Nay on the text above. --------------------- Wordy terminology: As for the wordy terminology for some of the names of behaviors, I also agree (the reasons for wordy names are historical). I can go through the text and simplify. ------------------------ REQs in-line: Bryan feels strongly about copying/pasting the REQs from section 12 in-line in the text as they occur, to help the reader. I personally think it is a reasonable suggestion. Is there any STRONG objection to this? (Cullen in particular, I'd like to hear from you). ------------------------- Determinism: I propose that to address Bryan's concern, I put a note in section 4.1 and 5.1 refering to the Deterministic behavior section. I also propose to change the first sentence of section 8 to the following: The classification of NATs is further complicated by the fact that under some conditions the same NAT often exhibits different behaviors, especially for mapping and filtering. ------------------------- Again, I'd like a Yay or Nay from people on the points above. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Peterson, Jon > Sent: Friday, May 20, 2005 16:48 > To: Behave > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > In light of the recent Last Call discussions about > behave-nat-udp, I wanted to make a few comments. > > Regarding REQ-7, it seems pretty clear to me that there is no > immediate consensus to endorse endpoint-dependent or > endpoint-independent filtering. Consequently, in the interest > of time I'd like to make the modest proposal that REQ-7 > endorse neither, but instead state that both these modes (and > address-specific filtering) should be supported. Is there > some advantage to privileging one over the other? > > I see no great need to specify the maximum datagram length > that NATs must process. > > I find the conceptual model of behave-nat-udp, which focuses > on functions NATs might perform rather than classifications > of NATs as particular taxonomic entities (Basic, Full Cone, > etc), to be very attractive. That much said, I do agree with > several commentators that the resulting functional > descriptions lead to some very wordy terminologies. There > seems to be some emerging agreement on shorter terms, and I > think that would be most welcome to readers. > > Regarding the terms used in behave-nat-udp versus > ford-behave-gen, I see no immediate problems with the terms > used in behave-nat-udp. The distinction between a "map", a > "binding" and a "NAT session" in ford-behave-gen makes me a > little dizzy, to be honest. I do not find the definition of > "mapping" in behave-nat-udp to be problematic. I don't find > the use of the term "session" to refer to a transport-layer > connection between two endpoints to be problematic. > Terminology can be endlessly debated, but it is not clear to > me that we will gain much leverage on our problem space by > spending a few more cycles refining these terms. > > In Section 4.1, I think it reasonable to define behaviors > such as "External NAT mapping is endpoint address dependent" > just in order to disallow them in the requirements section. I > think it is worth being specific about things that we don't > want implementers to do. > > Given the conceptual model of behave-nat-udp, I think the > distinction between "deterministic" and "non-deterministic" > NATs in Section 8 is valuable. In fact, I think this > non-determinism is one of the primary grounds to move away > from a taxonomic model of NATs and into the functional model > espoused by behave-nat-udp. I didn't find Section 8 to be > particularly obscure when I read it, though no doubt the text > could be made more focused. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortel.com Tue, 24 May 2005 09:34:01 -0700 (PDT) From: "Francois Audet" Date: Tue, 24 May 2005 09:34:01 -0700 (PDT) Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Message-ID: <1ECE0EB50388174790F9694F77522CCF026F3459@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message So you prefer this: REQ-7: NATs SHOULD support Endpoint-Independent Filtering, Address-Specific Filtering, and Endpoint-Specific Filtering, as options configurable by the user. Endpoint-Independent Filtering SHOULD be the default. I'm fine with this too. I'm assuming that you are OK with the rest?
-----Original Message-----From: Peterson, Jon [mailto:jon.peterson@xxxxxxxxxxx] Sent: Tuesday, May 24, 2005 01:50To: Audet, Francois [SC100:9T51:EXCH]; BehaveSubject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Regarding just the REQ-7 text, I do think Bryan's suggestion has some merit. These requirements are intended to constrain NAT implementers, not the deployers of NATs. The implementers of NATscannot anticipatewhat sort of filtering will be desired; that is something that deployers of NATs should be able to configure. Jon Peterson NeuStar, Inc.
-----Original Message-----From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Francois AudetSent: Monday, May 23, 2005 11:00 AMTo: 'Behave'Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Thanks to all, This is a formal proposal on how to move forward, with concrete text. ------------------------ How about this for REQ 7. In the Requirements section: REQ-7: In order to maximize application transparencyIt is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is desired, it is RECOMMENDED that a NAT have an "Address dependent" behavior. In the REQ-7 justification section would be modified as follows: REQ-7: The recommendation to use endpoint independent filtering is aimed at maximizing feature transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if ti was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could infere with applications that use one than one port. I'd like a Yay or Nay on the text above. --------------------- Wordy terminology: As for the wordy terminology for some of the names of behaviors, I also agree (the reasons for wordy names are historical). I can go through the text and simplify. ------------------------ REQs in-line: Bryan feels strongly about copying/pasting the REQs from section 12 in-line in the text as they occur, to help the reader. I personally think it is a reasonable suggestion. Is there any STRONG objection to this? (Cullen in particular, I'd like to hear from you). ------------------------- Determinism: I propose that to address Bryan's concern, I put a note in section 4.1 and 5.1 refering to the Deterministic behavior section. I also propose to change the first sentence of section 8 to the following: The classification of NATs is further complicated by the fact that under some conditions the same NAT often exhibits different behaviors, especially for mapping and filtering. ------------------------- Again, I'd like a Yay or Nay from people on the points above. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Peterson, Jon > Sent: Friday, May 20, 2005 16:48 > To: Behave > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > In light of the recent Last Call discussions about > behave-nat-udp, I wanted to make a few comments. > > Regarding REQ-7, it seems pretty clear to me that there is no > immediate consensus to endorse endpoint-dependent or > endpoint-independent filtering. Consequently, in the interest > of time I'd like to make the modest proposal that REQ-7 > endorse neither, but instead state that both these modes (and > address-specific filtering) should be supported. Is there > some advantage to privileging one over the other? > > I see no great need to specify the maximum datagram length > that NATs must process. > > I find the conceptual model of behave-nat-udp, which focuses > on functions NATs might perform rather than classifications > of NATs as particular taxonomic entities (Basic, Full Cone, > etc), to be very attractive. That much said, I do agree with > several commentators that the resulting functional > descriptions lead to some very wordy terminologies. There > seems to be some emerging agreement on shorter terms, and I > think that would be most welcome to readers. > > Regarding the terms used in behave-nat-udp versus > ford-behave-gen, I see no immediate problems with the terms > used in behave-nat-udp. The distinction between a "map", a > "binding" and a "NAT session" in ford-behave-gen makes me a > little dizzy, to be honest. I do not find the definition of > "mapping" in behave-nat-udp to be problematic. I don't find > the use of the term "session" to refer to a transport-layer > connection between two endpoints to be problematic. > Terminology can be endlessly debated, but it is not clear to > me that we will gain much leverage on our problem space by > spending a few more cycles refining these terms. > > In Section 4.1, I think it reasonable to define behaviors > such as "External NAT mapping is endpoint address dependent" > just in order to disallow them in the requirements section. I > think it is worth being specific about things that we don't > want implementers to do. > > Given the conceptual model of behave-nat-udp, I think the > distinction between "deterministic" and "non-deterministic" > NATs in Section 8 is valuable. In fact, I think this > non-determinism is one of the primary grounds to move away > from a taxonomic model of NATs and into the functional model > espoused by behave-nat-udp. I didn't find Section 8 to be > particularly obscure when I read it, though no doubt the text > could be made more focused. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From baford@mit.edu Tue, 24 May 2005 14:03:48 -0700 (PDT) From: Bryan Ford Date: Tue, 24 May 2005 14:03:48 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF026F3459@zrc2hxm0.corp.nortel.com> Message-ID: <200505241703.32820.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 24 May 2005 12:33, Francois Audet wrote (in response to Jon Peterson's message): > So you prefer this: > > REQ-7: NATs SHOULD support Endpoint-Independent Filtering, Address-Specific > Filtering, and Endpoint-Specific Filtering, as options configurable by the > user. Endpoint-Independent Filtering SHOULD be the default. > > I'm fine with this too. Excellent - thanks. One more minor note: although the text above that I suggested recommends that NATs support all three filtering behaviors, I don't have any strong attachment to the third, most restrictive behavior - "Endpoint-Specific Filtering" - and as far as I can tell no one else on this list really appears to either. So I would like to suggest the following minor alteration, which would weaken that part of the recommendation (while keeping it as an allowable implementation option): REQ-7: NATs SHOULD support Endpoint-Independent Filtering and Address-Specific Filtering, and MAY support Endpoint-Specific Filtering, as options configurable by the user. Endpoint-Independent Filtering SHOULD be the default. But I don't have strong feelings either way on this point; either of the above two versions of REQ-7 are fine with me. Thanks, Bryan > > I'm assuming that you are OK with the rest? > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@xxxxxxxxxxx] > Sent: Tuesday, May 24, 2005 01:50 > To: Audet, Francois [SC100:9T51:EXCH]; Behave > Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > Regarding just the REQ-7 text, I do think Bryan's suggestion has some > merit. These requirements are intended to constrain NAT implementers, not > the deployers of NATs. The implementers of NATs cannot anticipate what sort > of filtering will be desired; that is something that deployers of NATs > should be able to configure. > > Jon Peterson > NeuStar, Inc. > > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Francois Audet > Sent: Monday, May 23, 2005 11:00 AM > To: 'Behave' > Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > Thanks to all, > > This is a formal proposal on how to move forward, with concrete text. > > ------------------------ > > How about this for REQ 7. > > In the Requirements section: > > REQ-7: In order to maximize application transparencyIt is RECOMMENDED that > a NAT have an "Endpoint independent filtering" behavior. > If a more stringent filtering behavior is desired, it is RECOMMENDED > that a NAT have an "Address dependent" behavior. > > In the REQ-7 justification section would be modified as follows: > > REQ-7: The recommendation to use endpoint independent filtering is aimed at > maximizing feature transparency, in particular for applications that > receive media simultaneously from multiple locations (e.g., gaming), > or applications that use rendezvous techniques. However, it is also > possible that in some circumstances, it may be preferable to have > a more stringent filtering behavior. Filtering independently of the > external endpoint is not as secure: an unauthorized packet could get > a specific port while the port was kept open if ti was lucky enough > to find the port open. In theory, filtering based on both IP address > and port is more secure than filtering based only on the IP address > (because the external endpoint could in reality be two endpoints > behind > another NAT, where one of the two endpoints is an attacker): > however, such > a policy could infere with applications that use one than one port. > > I'd like a Yay or Nay on the text above. > > --------------------- > > Wordy terminology: > As for the wordy terminology for some of the names of behaviors, I also > agree > (the reasons for wordy names are historical). I can go through the text > and simplify. > > ------------------------ > > REQs in-line: > Bryan feels strongly about copying/pasting the REQs from section 12 > in-line in the > text as they occur, to help the reader. I personally think it is a > reasonable > suggestion. Is there any STRONG objection to this? (Cullen in particular, > I'd like to > hear from you). > > ------------------------- > > Determinism: > I propose that to address Bryan's concern, I put a note in section 4.1 > and 5.1 > refering to the Deterministic behavior section. I also propose to change > the first > sentence of section 8 to the following: > The classification of NATs is further complicated by the fact that > under some > conditions the same NAT often exhibits different behaviors, especially > for > mapping and filtering. > > ------------------------- > > Again, I'd like a Yay or Nay from people on the points above. > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > ] On Behalf Of > > > Peterson, Jon > > Sent: Friday, May 20, 2005 16:48 > > To: Behave > > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > > > > > In light of the recent Last Call discussions about > > behave-nat-udp, I wanted to make a few comments. > > > > Regarding REQ-7, it seems pretty clear to me that there is no > > immediate consensus to endorse endpoint-dependent or > > endpoint-independent filtering. Consequently, in the interest > > of time I'd like to make the modest proposal that REQ-7 > > endorse neither, but instead state that both these modes (and > > address-specific filtering) should be supported. Is there > > some advantage to privileging one over the other? > > > > I see no great need to specify the maximum datagram length > > that NATs must process. > > > > I find the conceptual model of behave-nat-udp, which focuses > > on functions NATs might perform rather than classifications > > of NATs as particular taxonomic entities (Basic, Full Cone, > > etc), to be very attractive. That much said, I do agree with > > several commentators that the resulting functional > > descriptions lead to some very wordy terminologies. There > > seems to be some emerging agreement on shorter terms, and I > > think that would be most welcome to readers. > > > > Regarding the terms used in behave-nat-udp versus > > ford-behave-gen, I see no immediate problems with the terms > > used in behave-nat-udp. The distinction between a "map", a > > "binding" and a "NAT session" in ford-behave-gen makes me a > > little dizzy, to be honest. I do not find the definition of > > "mapping" in behave-nat-udp to be problematic. I don't find > > the use of the term "session" to refer to a transport-layer > > connection between two endpoints to be problematic. > > Terminology can be endlessly debated, but it is not clear to > > me that we will gain much leverage on our problem space by > > spending a few more cycles refining these terms. > > > > In Section 4.1, I think it reasonable to define behaviors > > such as "External NAT mapping is endpoint address dependent" > > just in order to disallow them in the requirements section. I > > think it is worth being specific about things that we don't > > want implementers to do. > > > > Given the conceptual model of behave-nat-udp, I think the > > distinction between "deterministic" and "non-deterministic" > > NATs in Section 8 is valuable. In fact, I think this > > non-determinism is one of the primary grounds to move away > > from a taxonomic model of NATs and into the functional model > > espoused by behave-nat-udp. I didn't find Section 8 to be > > particularly obscure when I read it, though no doubt the text > > could be made more focused. > > > > Jon Peterson > > NeuStar, Inc. > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortel.com Tue, 24 May 2005 14:16:45 -0700 (PDT) From: "Francois Audet" Date: Tue, 24 May 2005 14:16:45 -0700 (PDT) Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Message-ID: <1ECE0EB50388174790F9694F77522CCF026F3AEE@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Yeah, I tought it would be something like that. Very interesting. The magic of ICE... I am not sure we need to explain the whole thing in this document since it seems more appropriate for the application document (or even for ICE or NAT scenarios). I'll let Johnathan decide if it belongs there in ICE or not as one of its benefits. I could add something like this in the REQ-7 justification: Note - Using Endpoint Independent Filtering or Address Dependent Filetering instead of Address and Port Dependent Filtering on a NAT (say NAT-A) also has benefits when the other enpoint is behind a non-BEHAVE compliant NAT (say NAT-B) which doesn't support REQ-1. When the endpoints use ICE, if NAT-A uses Address and Port Dependent Filtering, connectivity will require a Media Relay. However, if NAT-A uses Endpoint Indepent Filtering or Address Dependent Filtering, ICE will ultimately find connectivity without requiring a Media Relay. > -----Original Message----- > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] > Sent: Monday, May 23, 2005 17:49 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > Can you elaborate on this last point? I can't seem to make > sense > out of it. Do you mean find connectivity without a > Media Relay? > > Yes. > > > If so, can youd describe why, because it seems to me that > you will > require a media relay if one end has a > address/port dependendent > mapping. > > Correct. That is what I meant. > Let's say host A is behind a symmetric NAT (External IP > address=X)(address/port dependent) and host B is behind a port > restrected cone NAT (External IP address=Y) (address/port dependent). > Each hosts performs binding request with a STUN server and > obtain STUN > derived addresses, X:p and Y:q respectively, and then exchange the > addresses via a proxy server. > > The, host A and B performs connectivity check against the transport > address obtained from the other host. However, packets sent > from host A > will have a different source port number 'p2' than 'p1', > consequently, > the packets will be discarded by the host B's NAT even host B > performs connectivity check against X:p1. (port must match to receive) > > If the host B is behind an address dependent or independent NAT, the > packets from host A will be eventually received regardless of what > source port number it has, and then the host A will receive a > response > from host B. Host A, then detects a new MAPPED-ADDRESS (X:p2) in the > response, and performs an update (see section 9.3 in ICE document) to > modifiy the media transport address for host B. Finally, host B also > finds connectivity to the X:p2 and terminates the session initiation > process. > > So, from what I understand, by avoiding address/port dependent to be > behave compliant NAT, the behave compliant NAT possibly removes the > requirement of a media relay (like TURN) in the case where the remote > host is behind a Symmetric NAT. > > Hope this helps. > > - Yutaka > > > Francois Audet wrote: > > > > > > > -----Original Message----- > > > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > > > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] > > > Sent: Monday, May 23, 2005 15:37 > > > To: Audet, Francois [SC100:9T51:EXCH] > > > Cc: 'Behave' > > > Subject: Re: [Ietf-behave] comments on > draft-ietf-behave-nat-udp-01 > > > > > > > > > > I had a discussion with our engineering team on > > > the new proposal by Francois on REQ-7 this morning. > > > We basically agree with his proposal. > > > > > > First off, some typos we found on the new REQ-7: > > > "transperencyIt" -> "transparency, it" "ti was lucky" -> "it > > > was lucky" "could infere" -> "could interfere" "one than one > > > port" -> "more than one port" > > > > Thanks. Will fix. > > > > > I am not confident if I understand following statement > > > correctly. Could you please elaborate for me? > > > > > > "however, such a policy could interfere with > applications > that > > use more > than one port." > > > > This is verbatim from the existing text. It is meant to the > case of an > > application behind a NAT, which would pierce a pinhole by > sending some > > packets from a source port, but where the remote > application may send > > packets to more than one local UDP port. > > > > Perhaps the text should say "however, such a policy could interfere > > with applications that expect to receive UDP packets on > more than one > > UDP port." > > > > > Besides the security point of view, avoiding endpoint > > > address port dependent filtering has another significant > > > benefit. If the two hosts (A and B) are behind different NATs > > where: > > - Host A is behind Full-cone or Restricted-cone NAT. > > > - Host B is behind Symmetric NAT. > > > (sorry for the use of old terminology) > > > > > > ICE can find connectivity between the two in this case, > > > where if Host A is behind a Port-restricted cone NAT, ICE > > > will not be able to find a direct connectivity between them. > > > This could be mentioned in the REQ-7 justification section > > > for more specific clarification..? > > > > Can you elaborate on this last point? I can't seem to make > sense out > > of it. Do you mean find connectivity without a Media Relay? > If so, can > > youd describe why, because it seems to me that you will require a > > media relay if one end has a address/port dependendent mapping. > > > > Thanks. > > > > From audet@nortel.com Tue, 24 May 2005 14:19:06 -0700 (PDT) From: "Francois Audet" Date: Tue, 24 May 2005 14:19:06 -0700 (PDT) Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Message-ID: <1ECE0EB50388174790F9694F77522CCF026F3B04@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Agreed. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Bryan Ford > Sent: Tuesday, May 24, 2005 14:04 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > On Tuesday 24 May 2005 12:33, Francois Audet wrote (in > response to Jon > Peterson's message): > > So you prefer this: > > > > REQ-7: NATs SHOULD support Endpoint-Independent Filtering, > > Address-Specific Filtering, and Endpoint-Specific Filtering, as > > options configurable by the user. Endpoint-Independent Filtering > > SHOULD be the default. > > > > I'm fine with this too. > > Excellent - thanks. One more minor note: although the text > above that I > suggested recommends that NATs support all three filtering > behaviors, I don't > have any strong attachment to the third, most restrictive behavior - > "Endpoint-Specific Filtering" - and as far as I can tell no > one else on this > list really appears to either. So I would like to suggest > the following > minor alteration, which would weaken that part of the > recommendation (while > keeping it as an allowable implementation option): > > REQ-7: NATs SHOULD support Endpoint-Independent Filtering and > Address-Specific Filtering, and MAY support Endpoint-Specific > Filtering, as options > configurable by the user. Endpoint-Independent Filtering > SHOULD be the > default. > > But I don't have strong feelings either way on this point; > either of the above > two versions of REQ-7 are fine with me. > > Thanks, > Bryan > > > > > I'm assuming that you are OK with the rest? > > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@xxxxxxxxxxx] > > Sent: Tuesday, May 24, 2005 01:50 > > To: Audet, Francois [SC100:9T51:EXCH]; Behave > > Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > > > > > Regarding just the REQ-7 text, I do think Bryan's > suggestion has some > > merit. These requirements are intended to constrain NAT > implementers, > > not the deployers of NATs. The implementers of NATs cannot > anticipate > > what sort of filtering will be desired; that is something that > > deployers of NATs should be able to configure. > > > > Jon Peterson > > NeuStar, Inc. > > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf > Of Francois > > Audet > > Sent: Monday, May 23, 2005 11:00 AM > > To: 'Behave' > > Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > > > > > Thanks to all, > > > > This is a formal proposal on how to move forward, with > concrete text. > > > > ------------------------ > > > > How about this for REQ 7. > > > > In the Requirements section: > > > > REQ-7: In order to maximize application transparencyIt is > RECOMMENDED that > > a NAT have an "Endpoint independent filtering" behavior. > > If a more stringent filtering behavior is desired, > it is RECOMMENDED > > that a NAT have an "Address dependent" behavior. > > > > In the REQ-7 justification section would be modified as follows: > > > > REQ-7: The recommendation to use endpoint independent > filtering is aimed at > > maximizing feature transparency, in particular for > applications that > > receive media simultaneously from multiple locations > (e.g., gaming), > > or applications that use rendezvous techniques. > However, it is also > > possible that in some circumstances, it may be > preferable to have > > a more stringent filtering behavior. Filtering > independently of the > > external endpoint is not as secure: an unauthorized > packet could get > > a specific port while the port was kept open if ti > was lucky enough > > to find the port open. In theory, filtering based on > both IP address > > and port is more secure than filtering based only on > the IP address > > (because the external endpoint could in reality be two > > endpoints behind > > another NAT, where one of the two endpoints is an attacker): > > however, such > > a policy could infere with applications that use one > than one > > port. > > > > I'd like a Yay or Nay on the text above. > > > > --------------------- > > > > Wordy terminology: > > As for the wordy terminology for some of the names of > behaviors, I > > also agree > > (the reasons for wordy names are historical). I can go > through the > > text and simplify. > > > > ------------------------ > > > > REQs in-line: > > Bryan feels strongly about copying/pasting the REQs from > section 12 > > in-line in the > > text as they occur, to help the reader. I personally > think it is a > > reasonable > > suggestion. Is there any STRONG objection to this? (Cullen in > > particular, I'd like to > > hear from you). > > > > ------------------------- > > > > Determinism: > > I propose that to address Bryan's concern, I put a note > in section > > 4.1 and 5.1 > > refering to the Deterministic behavior section. I also propose to > > change the first > > sentence of section 8 to the following: > > The classification of NATs is further complicated by > the fact that > > under some > > conditions the same NAT often exhibits different behaviors, > > especially for > > mapping and filtering. > > > > ------------------------- > > > > Again, I'd like a Yay or Nay from people on the points above. > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > ] On Behalf Of > > > > > Peterson, Jon > > > Sent: Friday, May 20, 2005 16:48 > > > To: Behave > > > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > > > > > > > > > In light of the recent Last Call discussions about > behave-nat-udp, I > > > wanted to make a few comments. > > > > > > Regarding REQ-7, it seems pretty clear to me that there is no > > > immediate consensus to endorse endpoint-dependent or > > > endpoint-independent filtering. Consequently, in the interest of > > > time I'd like to make the modest proposal that REQ-7 endorse > > > neither, but instead state that both these modes (and > > > address-specific filtering) should be supported. Is there some > > > advantage to privileging one over the other? > > > > > > I see no great need to specify the maximum datagram > length that NATs > > > must process. > > > > > > I find the conceptual model of behave-nat-udp, which focuses on > > > functions NATs might perform rather than classifications > of NATs as > > > particular taxonomic entities (Basic, Full Cone, etc), to be very > > > attractive. That much said, I do agree with several commentators > > > that the resulting functional descriptions lead to some > very wordy > > > terminologies. There seems to be some emerging agreement > on shorter > > > terms, and I think that would be most welcome to readers. > > > > > > Regarding the terms used in behave-nat-udp versus > ford-behave-gen, I > > > see no immediate problems with the terms used in > behave-nat-udp. The > > > distinction between a "map", a "binding" and a "NAT session" in > > > ford-behave-gen makes me a little dizzy, to be honest. I > do not find > > > the definition of "mapping" in behave-nat-udp to be > problematic. I > > > don't find the use of the term "session" to refer to a > > > transport-layer connection between two endpoints to be > problematic. > > > Terminology can be endlessly debated, but it is not clear to > > > me that we will gain much leverage on our problem space by > > > spending a few more cycles refining these terms. > > > > > > In Section 4.1, I think it reasonable to define behaviors such as > > > "External NAT mapping is endpoint address dependent" just > in order > > > to disallow them in the requirements section. I think it is worth > > > being specific about things that we don't want implementers to do. > > > > > > Given the conceptual model of behave-nat-udp, I think the > > > distinction between "deterministic" and > "non-deterministic" NATs in > > > Section 8 is valuable. In fact, I think this > non-determinism is one > > > of the primary grounds to move away from a taxonomic > model of NATs > > > and into the functional model espoused by behave-nat-udp. > I didn't > > > find Section 8 to be particularly obscure when I read it, > though no > > > doubt the text could be made more focused. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From fluffy@cisco.com Tue, 24 May 2005 18:33:13 -0700 (PDT) From: Cullen Jennings Date: Tue, 24 May 2005 18:33:13 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF026F3459@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 I can't imagine how to explain to a residential NAT user what these options even mean much less how they should or would configure them. The high end enterprise firewalls already have many configuration options for filtering. I don't think the important thing for this group is what NATs can be configured to do or not do - I'm fine if someone wants to make a configurable NAT. The issues this group needs to tackle is what is the minimal behavior that an application can count on getting. If we say the NAT MAY do A or may do B, then that is fine, the application can't assume that it is A or B but can assume it is one or the other. Statements about the default configuration SHOULD be B won't help the application. I strongly object to anything that says the "Endpoint-Independent Filtering SHOULD be the default." - For the Linksys devices, they will basically never be change from the default. All the discussion on this list has led me to feel that the best thing for Linksys to do is more restrictive filtering. I have not meant a single person at Linksys that believes this is a good idea. I can not imagine a single combined firewall NAT what would ship with this as the default. I'm pretty sure the Cisco ones won't. I imagine the feeling will be similar at other NAT and FW manufactures. I think that including this statement will more or less guarantee that over 90% of devices shipped do not comply with this recommendation. The obvious solution to this lack of agreement is say that NATs can MAY choose any type of filtering configuration and MAY be configurable. Or perhaps people want to say that they MUST not be address port filtering (though I'm OK if they are). Cullen On 5/24/05 9:33 AM, "Francois Audet" wrote: So you prefer this: REQ-7: NATs SHOULD support Endpoint-Independent Filtering, Address-Specific Filtering, and Endpoint-Specific Filtering, as options configurable by the user. Endpoint-Independent Filtering SHOULD be the default. I'm fine with this too. I'm assuming that you are OK with the rest? -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@xxxxxxxxxxx] Sent: Tuesday, May 24, 2005 01:50 To: Audet, Francois [SC100:9T51:EXCH]; Behave Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Regarding just the REQ-7 text, I do think Bryan's suggestion has some merit. These requirements are intended to constrain NAT implementers, not the deployers of NATs. The implementers of NATs cannot anticipate what sort of filtering will be desired; that is something that deployers of NATs should be able to configure. Jon Peterson NeuStar, Inc. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Francois Audet Sent: Monday, May 23, 2005 11:00 AM To: 'Behave' Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Thanks to all, This is a formal proposal on how to move forward, with concrete text. ------------------------ How about this for REQ 7. In the Requirements section: REQ-7: In order to maximize application transparencyIt is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is desired, it is RECOMMENDED that a NAT have an "Address dependent" behavior. In the REQ-7 justification section would be modified as follows: REQ-7: The recommendation to use endpoint independent filtering is aimed at maximizing feature transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if ti was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could infere with applications that use one than one port. I'd like a Yay or Nay on the text above. --------------------- Wordy terminology: As for the wordy terminology for some of the names of behaviors, I also agree (the reasons for wordy names are historical). I can go through the text and simplify. ------------------------ REQs in-line: Bryan feels strongly about copying/pasting the REQs from section 12 in-line in the text as they occur, to help the reader. I personally think it is a reasonable suggestion. Is there any STRONG objection to this? (Cullen in particular, I'd like to hear from you). ------------------------- Determinism: I propose that to address Bryan's concern, I put a note in section 4.1 and 5.1 refering to the Deterministic behavior section. I also propose to change the first sentence of section 8 to the following: The classification of NATs is further complicated by the fact that under some conditions the same NAT often exhibits different behaviors, especially for mapping and filtering. ------------------------- Again, I'd like a Yay or Nay from people on the points above. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Peterson, Jon > Sent: Friday, May 20, 2005 16:48 > To: Behave > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > In light of the recent Last Call discussions about > behave-nat-udp, I wanted to make a few comments. > > Regarding REQ-7, it seems pretty clear to me that there is no > immediate consensus to endorse endpoint-dependent or > endpoint-independent filtering. Consequently, in the interest > of time I'd like to make the modest proposal that REQ-7 > endorse neither, but instead state that both these modes (and > address-specific filtering) should be supported. Is there > some advantage to privileging one over the other? > > I see no great need to specify the maximum datagram length > that NATs must process. > > I find the conceptual model of behave-nat-udp, which focuses > on functions NATs might perform rather than classifications > of NATs as particular taxonomic entities (Basic, Full Cone, > etc), to be very attractive. That much said, I do agree with > several commentators that the resulting functional > descriptions lead to some very wordy terminologies. There > seems to be some emerging agreement on shorter terms, and I > think that would be most welcome to readers. > > Regarding the terms used in behave-nat-udp versus > ford-behave-gen, I see no immediate problems with the terms > used in behave-nat-udp. The distinction between a "map", a > "binding" and a "NAT session" in ford-behave-gen makes me a > little dizzy, to be honest. I do not find the definition of > "mapping" in behave-nat-udp to be problematic. I don't find > the use of the term "session" to refer to a transport-layer > connection between two endpoints to be problematic. > Terminology can be endlessly debated, but it is not clear to > me that we will gain much leverage on our problem space by > spending a few more cycles refining these terms. > > In Section 4.1, I think it reasonable to define behaviors > such as "External NAT mapping is endpoint address dependent" > just in order to disallow them in the requirements section. I > think it is worth being specific about things that we don't > want implementers to do. > > Given the conceptual model of behave-nat-udp, I think the > distinction between "deterministic" and "non-deterministic" > NATs in Section 8 is valuable. In fact, I think this > non-determinism is one of the primary grounds to move away > from a taxonomic model of NATs and into the functional model > espoused by behave-nat-udp. I didn't find Section 8 to be > particularly obscure when I read it, though no doubt the text > could be made more focused. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From kbiswas@cisco.com Tue, 24 May 2005 18:48:31 -0700 (PDT) From: "Kaushik Biswas (kbiswas)" Date: Tue, 24 May 2005 18:48:31 -0700 (PDT) Subject: RE: [Ietf-behave] on the behave charter Message-ID: <378E78E5F361564BB066432F6415764B34B0A8@xmb-sjc-228.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Pyda Srisuresh Sent: Sunday, May 22, 2005 12:56 PM To: Bryan Ford; ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] on the behave charter If there MUST be just one draft. I agree with what Bryan says below. Large portions of behave-gen should be merged with the behave-udp draft. [Kaushik] Agreed. Cleaner approach would be to have the protocol-independent discussions in a separate draft or to atleast have a separate section in the udp-draft merging the protocol-independent stuff from behave-gen. Thanks, Kaushik cheers, suresh --- Bryan Ford wrote: > On Friday 20 May 2005 19:35, Peterson, Jon wrote: > > In response to some of the discussion on this list related to > > introducing a new charter milestone for a general > > transport-independent framework and requirements draft which would > > be independent of the transport-specific milestones currently on the charter, I have a few comments. > > > > As some comments to the list have pointed out, there are > > requirements in the UDP draft which are not specific to UDP. Those > > requirements should no doubt be identified as such (I believe the > > authors of the UDP draft have agreed to this), and preferably split > > into a subsection specifically designated for such requirements. > > In the interest of getting the UDP document published quickly, I would > be amenable to this compromise strategy, under the condition that the > new transport-independent subsection you propose incorporates some of > the important text from the behave-gen draft > (draft-ford-behave-gen-01.txt) that provide important general > information or address issues currently missing from the UDP draft. Specifically: > > * Section 2 of behave-gen, which provides the logical model of NAT > operation essential to making the actual behavioral requirements clear > and precise for NAT implementors. I could live with compressing or > eliminating section 2.4 on the legacy RFC3489 terminology since I know > there are strong objections to > > even mentioning those terms, but I think the rest of the section is > essential. > > * Section 3.3 in behave-gen provides a more complete discussion of > receive fragmentation behavior than the current section 11 of the UDP > draft, and should be included or merged. Also, the specific > requirements regarding fragmentation support needs to be updated as > per the recent fragmentation discussion on the list: i.e., the NAT > MUST support receiving fragmented packets. > > * Section 3.4 in behave-gen, on outbound fragmentation issues. > > * Section 3.6, on DHCP-configured NATs and conflicting private IP > address spaces. > > * Section 3.8, on ICMP error handling, provides a more complete and > transport-independent discussion of this issue than the current > section 9 of behave-udp, and thus should be incorporated. > > * Section 3.10, on ALG support recommendations. > > * Section 3.11, on denial-of-service protection. > > * Section 4, "Hints to Implementors": I think it would be useful to > include at least some of this section, although it is only for > information and doesn't contain any normative requirements. > > > I think it is important for the UDP work to complete expeditiously. > > I furthermore believe that these general requirements are necessary > > to understanding how to engineer UDP NAT behavior. I foresee no > > great difficulty in having other drafts, like the TCP draft, > > reference this section of the UDP document, provided that its content is sound. > > I agree, again provided that its content is sound, and provided that > the transport-independent portions of the UDP draft are clearly marked > as such in > > a separate section or sections for that purpose, so that there will be > no ambiguity on which parts also apply to other transports. > > Cheers, > Bryan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From ssenthil@cisco.com Wed, 25 May 2005 06:20:37 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Wed, 25 May 2005 06:20:37 -0700 (PDT) Subject: RE: [Ietf-behave] on the behave charter Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB233193@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I strongly think the right approach would be a separate draft for the transport independent requirements. Having the general requirements split across TCP and UDP drafts would be a distraction to the NAT implementers and people who deploy NAT. Senthil -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Peterson, Jon Sent: Friday, May 20, 2005 4:36 PM To: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: [Ietf-behave] on the behave charter In response to some of the discussion on this list related to introducing a new charter milestone for a general transport-independent framework and requirements draft which would be independent of the transport-specific milestones currently on the charter, I have a few comments. As some comments to the list have pointed out, there are requirements in the UDP draft which are not specific to UDP. Those requirements should no doubt be identified as such (I believe the authors of the UDP draft have agreed to this), and preferably split into a subsection specifically designated for such requirements. I think it is important for the UDP work to complete expeditiously. I furthermore believe that these general requirements are necessary to understanding how to engineer UDP NAT behavior. I foresee no great difficulty in having other drafts, like the TCP draft, reference this section of the UDP document, provided that its content is sound. Are there any advocates of a separate transport-independent draft who believe that this approach is unworkable? Jon Peterson NeuStar, Inc. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From baford@mit.edu Wed, 25 May 2005 09:08:22 -0700 (PDT) From: Bryan Ford Date: Wed, 25 May 2005 09:08:22 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02674054@zrc2hxm0.corp.nortel.com> Message-ID: <200505251208.19744.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Hi Francois, On Monday 23 May 2005 14:00, Francois Audet wrote: > Thanks to all, > > This is a formal proposal on how to move forward, with concrete text. Excellent - thanks. > ------------------------ > > How about this for REQ 7. As per the subsequent discussion involving Jon Peterson, I would prefer the stronger wording that explicitly says NATs SHOULD implement both Endpoint-Independent and Address-Specific Filtering and SHOULD default to Endpoint-Independent. However, I find your proposed justification text perfectly reasonable (with the typo fixes suggested by others). > ------------------------ > > REQs in-line: > Bryan feels strongly about copying/pasting the REQs from section 12 > in-line in the > text as they occur, to help the reader. I personally think it is a > reasonable > suggestion. Is there any STRONG objection to this? (Cullen in particular, > I'd like to > hear from you). Just to clarify my proposal and make it more concrete, let's arbitrarily take Section 4.2 (Port Parity), since it's short, as an "example" section; here's how I envision this editorial change might make it look: --- 4.2.2 Port Parity Some NATs preserve the parity of the UDP port, i.e., an even port will be mapped to an even port, and an odd port will be mapped to an odd port. This behavior respects the RFC 3550 [8] rule that RTP use even ports, and RTCP use odd ports. Some NATs preserve the parity of the UDP port, i.e., an even port will be mapped to an even port, and an odd port will be mapped to an odd port. This behavior respects the RFC 3550 rule that RTP use even ports and RTCP use odd ports when the application takes a single port number as a parameter and derives the RTP and RTCP port pair from that number. RFC 3550 allows any port numbers to be used for RTP and RTCP if the two numbers are specified separately, for example using RFC 3605 [9]. However, some implementations do not include RFC 3605 and do not recognize when the peer has specified the RTCP port separately using RFC 3605. If such an implementation receives an odd RTP port number from the peer (perhaps after having been translated by a NAT), and then follows the RFC 3550 rule to change the RTP port to the next lower even number, this would obviously result in the loss of RTP. NAT-friendly application aspects are outside the scope of this document. It is expected that this issue will fade away with time, as implementations improve. Preserving the port parity allows for supporting communication with peers that do not support explicit specification of both RTP and RTCP port numbers. REQ-4 It is RECOMMENDED that a NAT have a "Port parity preservation" behavior of "Yes". Justification for REQ-4: This is to avoid breaking peer-to-peer applications which do not explicity and separately specify RTP and RTCP port numbers and which follow the RFC 3550 rule to decrement an odd RTP port to make it even. The same considerations as per the IP address pooling requirement apply. --- Then the text of REQ-4 above again reappears verbatim in the checklist in section 12 (i.e., the requirements are copied/pasted). The justification text, however, (currently in section 12.1 of the udp) is _moved_ in-line as shown above and section 12.1 disappears from the draft. Of course, once the justification paragraphs are placed in-line some of them may turn out to be overly redundant with the regular in-line body text they are next to and need further editing. In any case, I'm not terribly concerned with the specific formatting, placement, or editing details of how this change is made, and happily leave those details to Francois - the above text is only meant to be an illustrative example, not a formal template. > ------------------------- > > Determinism: > I propose that to address Bryan's concern, I put a note in section 4.1 > and 5.1 > refering to the Deterministic behavior section. I also propose to change > the first > sentence of section 8 to the following: > The classification of NATs is further complicated by the fact that > under some > conditions the same NAT often exhibits different behaviors, especially > for > mapping and filtering. This seems like a reasonable compromise. (Yay.) Cheers, Bryan From srisuresh@yahoo.com Wed, 25 May 2005 09:25:07 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 25 May 2005 09:25:07 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: Message-ID: <20050525162507.47863.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Whatever conclusion we come to, I believe the draft ought to include the rationale behind. Without the raionale, the reader who looks at the RFC two years from now will be at a loss as to why the requirement was made the way it was. My comments inline. cheers, suresh --- Cullen Jennings wrote: > > I can't imagine how to explain to a residential NAT user what these options > even mean much less how they should or would configure them. The high end > enterprise firewalls already have many configuration options for filtering. > I don't think the important thing for this group is what NATs can be > configured to do or not do - I'm fine if someone wants to make a > configurable NAT. The issues this group needs to tackle is what is the > minimal behavior that an application can count on getting. [suresh] Agreed. > If we say the NAT > MAY do A or may do B, then that is fine, the application can't assume that > it is A or B but can assume it is one or the other. Statements about the > default configuration SHOULD be B won't help the application. > > I strongly object to anything that says the "Endpoint-Independent Filtering > SHOULD be the default." - [suresh] I am OK with requiring the default behavior to be one of endpoint Address dependent filtering (i.e, Addres restricted Cone NAT behavior) or endpoint independent filtering (i.e., full COne NAT behavior). In the case of the former. it would be nice if the NAT could selectively enable endpoint independent filtering (i.e., Full Cone NAT behavior) for specific applications (such as peer-to-peer applications). > For the Linksys devices, they will basically never > be change from the default. All the discussion on this list has led me to > feel that the best thing for Linksys to do is more restrictive filtering. [suresh] You meant the opposite right. Endpoint independent (i.e., Full-Cone NAT behavior) is less restrictive. > I > have not meant a single person at Linksys that believes this is a good idea. > I can not imagine a single combined firewall NAT what would ship with this > as the default. I'm pretty sure the Cisco ones won't. I imagine the feeling > will be similar at other NAT and FW manufactures. I think that including > this statement will more or less guarantee that over 90% of devices shipped > do not comply with this recommendation. > [suresh] I do not buy the above argument. NAT vendors, especially the vendors that supply to residential customers have catered predominantly to client-server applications thus far. Peer-to-peer application support has not been a priority. As more residential customers are seeking peer-to-peer application support on their NAT devices, the NAT vendors will change the tune according to the market needs. As Bryan said, the argument that Full Cone NAT behavior is less secure is rather weak. Once a host initiated a UDP based application, the application should be prepared to receive UDP datagrams from any IP address out there and drop datagrams that it does not care for. That is how it is with the Internet without NATs. The behavior ought not to be any different by virtue of keepign the NATs. I doubt if there are any applicatiosn out there that assume a NAT and depend on NATs to provide the Address restricted filtering behavior to them. Cullen - Is there a specific concern why Linksys would want to refuse to provide endpoint independent filterign behavior as the default? That would be useful in bringing the discussion to a close. > The obvious solution to this lack of agreement is say that NATs can MAY > choose any type of filtering configuration and MAY be configurable. Or > perhaps people want to say that they MUST not be address port filtering > (though I'm OK if they are). > > Cullen > cheers, suresh > On 5/24/05 9:33 AM, "Francois Audet" wrote: > > > So you prefer this: > >> > >> > >> REQ-7: NATs SHOULD support Endpoint-Independent Filtering, > Address-Specific > >> Filtering, and Endpoint-Specific Filtering, as options configurable by > the > >> user. Endpoint-Independent Filtering SHOULD be the default. > > > > I'm fine with this too. > > > > I'm assuming that you are OK with the rest? > >> > >> > >> -----Original Message----- > >> From: Peterson, Jon [mailto:jon.peterson@xxxxxxxxxxx] > >> Sent: Tuesday, May 24, 2005 01:50 > >> To: Audet, Francois [SC100:9T51:EXCH]; Behave > >> Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > >> > >> > >> > >> > >> Regarding just the REQ-7 text, I do think Bryan's suggestion has some > merit. > >> These requirements are intended to constrain NAT implementers, not the > >> deployers of NATs. The implementers of NATs cannot anticipate what sort > of > >> filtering will be desired; that is something that deployers of NATs > should > >> be able to configure. > >> > >> > >> > >> Jon Peterson > >> > >> NeuStar, Inc. > >> > >>> > >>> -----Original Message----- > >>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Francois > Audet > >>> Sent: Monday, May 23, 2005 11:00 AM > >>> To: 'Behave' > >>> Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > >>> > >>> > >>> > >>> Thanks to all, > >>> > >>> > >>> This is a formal proposal on how to move forward, with concrete text. > >>> > >>> > >>> ------------------------ > >>> > >>> > >>> How about this for REQ 7. > >>> > >>> > >>> In the Requirements section: > >>> > >>> > >>> REQ-7: In order to maximize application transparencyIt is RECOMMENDED > that > >>> a NAT have an "Endpoint independent filtering" behavior. > >>> If a more stringent filtering behavior is desired, it is > RECOMMENDED > >>> that a NAT have an "Address dependent" behavior. > >>> > >>> > >>> In the REQ-7 justification section would be modified as follows: > >>> > >>> > >>> REQ-7: The recommendation to use endpoint independent filtering is aimed > at > >>> maximizing feature transparency, in particular for applications > that > >>> receive media simultaneously from multiple locations (e.g., > gaming), > >>> or applications that use rendezvous techniques. However, it is > also > >>> possible that in some circumstances, it may be preferable to have > >>> a more stringent filtering behavior. Filtering independently of > the > >>> external endpoint is not as secure: an unauthorized packet could > get > >>> a specific port while the port was kept open if ti was lucky > enough > >>> to find the port open. In theory, filtering based on both IP > address > >>> and port is more secure than filtering based only on the IP > address > >>> (because the external endpoint could in reality be two endpoints > >>> behind > >>> another NAT, where one of the two endpoints is an attacker): > >>> however, such > >>> a policy could infere with applications that use one than one > port. > >>> > >>> > >>> I'd like a Yay or Nay on the text above. > >>> > >>> > >>> --------------------- > >>> > >>> > >>> Wordy terminology: > >>> As for the wordy terminology for some of the names of behaviors, I > also > >>> agree > >>> (the reasons for wordy names are historical). I can go through the > text > >>> and simplify. > >>> > >>> > >>> ------------------------ > >>> > >>> > >>> REQs in-line: > >>> Bryan feels strongly about copying/pasting the REQs from section 12 > >>> in-line in the > >>> text as they occur, to help the reader. I personally think it is a > >>> reasonable > >>> suggestion. Is there any STRONG objection to this? (Cullen in > particular, > >>> I'd like to > >>> hear from you). > >>> > >>> > >>> ------------------------- > >>> > >>> > >>> Determinism: > >>> I propose that to address Bryan's concern, I put a note in section 4.1 > >>> and 5.1 > >>> refering to the Deterministic behavior section. I also propose to > change > >>> the first > >>> sentence of section 8 to the following: > >>> The classification of NATs is further complicated by the fact that > >>> under some > >>> conditions the same NAT often exhibits different behaviors, > especially > >>> for > >>> mapping and filtering. > >>> > >>> > >>> ------------------------- > >>> > >>> > >>> Again, I'd like a Yay or Nay from people on the points above. > >>> > >>> > >>> > >>>> > -----Original Message----- > >>>> > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>> > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > >>>> > Peterson, Jon > >>>> > Sent: Friday, May 20, 2005 16:48 > >>>> > To: Behave > >>>> > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > >>>> > > >>>> > > >>>> > > >>>> > In light of the recent Last Call discussions about > >>>> > behave-nat-udp, I wanted to make a few comments. > >>>> > > >>>> > Regarding REQ-7, it seems pretty clear to me that there is no > >>>> > immediate consensus to endorse endpoint-dependent or > >>>> > endpoint-independent filtering. Consequently, in the interest > >>>> > of time I'd like to make the modest proposal that REQ-7 > >>>> > endorse neither, but instead state that both these modes (and > >>>> > address-specific filtering) should be supported. Is there > >>>> > some advantage to privileging one over the other? > >>>> > > >>>> > I see no great need to specify the maximum datagram length > >>>> > that NATs must process. > >>>> > > >>>> > I find the conceptual model of behave-nat-udp, which focuses > >>>> > on functions NATs might perform rather than classifications > >>>> > of NATs as particular taxonomic entities (Basic, Full Cone, > >>>> > etc), to be very attractive. That much said, I do agree with > >>>> > several commentators that the resulting functional > >>>> > descriptions lead to some very wordy terminologies. There > >>>> > seems to be some emerging agreement on shorter terms, and I > >>>> > think that would be most welcome to readers. > >>>> > > >>>> > Regarding the terms used in behave-nat-udp versus > >>>> > ford-behave-gen, I see no immediate problems with the terms > >>>> > used in behave-nat-udp. The distinction between a "map", a > >>>> > "binding" and a "NAT session" in ford-behave-gen makes me a > >>>> > little dizzy, to be honest. I do not find the definition of > >>>> > "mapping" in behave-nat-udp to be problematic. I don't find > >>>> > the use of the term "session" to refer to a transport-layer > >>>> > connection between two endpoints to be problematic. > >>>> > Terminology can be endlessly debated, but it is not clear to > >>>> > me that we will gain much leverage on our problem space by > >>>> > spending a few more cycles refining these terms. > >>>> > > >>>> > In Section 4.1, I think it reasonable to define behaviors > >>>> > such as "External NAT mapping is endpoint address dependent" > >>>> > just in order to disallow them in the requirements section. I > >>>> > think it is worth being specific about things that we don't > >>>> > want implementers to do. > >>>> > > >>>> > Given the conceptual model of behave-nat-udp, I think the > >>>> > distinction between "deterministic" and "non-deterministic" > >>>> > NATs in Section 8 is valuable. In fact, I think this > >>>> > non-determinism is one of the primary grounds to move away > >>>> > from a taxonomic model of NATs and into the functional model > >>>> > espoused by behave-nat-udp. I didn't find Section 8 to be > >>>> > particularly obscure when I read it, though no doubt the text > >>>> > could be made more focused. > >>>> > > >>>> > Jon Peterson > >>>> > NeuStar, Inc. > >>>> > > >>>> > _______________________________________________ > >>>> > Ietf-behave mailing list > >>>> > Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>> > > >>>> > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From baford@mit.edu Wed, 25 May 2005 10:33:09 -0700 (PDT) From: Bryan Ford Date: Wed, 25 May 2005 10:33:09 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: Message-ID: <200505251333.07402.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 24 May 2005 21:33, Cullen Jennings wrote: > I can't imagine how to explain to a residential NAT user what these options > even mean much less how they should or would configure them. I can - it doesn't need to involve explaining the minute technical details involved, just the fact that there is a security/connectivity tradeoff. Residental NAT/router vendors already typically provide an easy-to-use "configuration wizard" of some kind that walks the users through the process of configuring the upstream link, entering ISP account names/passwords, etc. It would be easy to include a page (some might already have one in fact) that looks something like this: Configuration Wizard Step #: Security Level Some of the optional security features that your new LinkGear router provides may interfere with the functioning or connectivity of popular applications. You may choose to enable these features for maximum protection of your private network, or disable them to ensure maximum application compatibility while still providing strong protection for your private network. Click the "Advanced" button for more technical details or to configure individual security features. Security Level: * High security, but Application-Friendly behavior o Maximum security Note: If you choose "Maximum security" now, and later find that some applications do not work as well as desired, you may wish to change it back to "High security." +-------------+ +-------------+ +-------------+ | Advanced | | Next -> | | Cancel | +-------------+ +-------------+ +-------------+ This page doesn't need to control just the Endpoint-Independent vs Restricted Filtering behavior, but might also control other behaviors that involve a security/connectivity tradeoff, all of which can presumably be configured separately via the "Advanced" button by those users who actually do know what they are doing. I'm not suggesting we tell NAT vendors how they should design their user interfaces or present potential configuration options to the user; I only presented the above example to illustrate the fact that there _are_ reasonable ways to make such configuration options accessible even to unsophisticated users. > The high end > enterprise firewalls already have many configuration options for filtering. > I don't think the important thing for this group is what NATs can be > configured to do or not do - I'm fine if someone wants to make a > configurable NAT. The issues this group needs to tackle is what is the > minimal behavior that an application can count on getting. If we say the > NAT MAY do A or may do B, then that is fine, the application can't assume > that it is A or B but can assume it is one or the other. Statements about > the default configuration SHOULD be B won't help the application. By this reasoning, many of the other recommendations in the behave-udp draft should be eliminated because they are only "recommendations" and not "requirements" that applications can depend on with certainty. REQ-4, for example, says that 'It is RECOMMENDED that a NAT have a "Port parity preservation" behavior of "Yes".' Since port parity preservation is only RECOMMENDED, applications can't depend on it, right? Therefore, by your reasoning REQ-4 should be eliminated, shouldn't it? The same goes for REQ-2, REQ-3(a), REQ-9, and REQ-11. The point is that there are sometimes good reasons to include recommendations that aren't absolute requirements, and I've already detailed what I feel are good reasons for having Endpoint-Independent Filtering be the recommended default even if applications can't depend on _always_ having Endpoint-Independent Filtering behavior. I won't rehash those arguments again here. > I strongly object to anything that says the "Endpoint-Independent Filtering > SHOULD be the default." - For the Linksys devices, they will basically > never be change from the default. Let's let Linksys decide that, and focus instead on doing the right thing from the perspective of what this working group is trying to accomplish. The title of this working group is "Behavior Engineering for Hindrance Avoidance." Recommending Endpoint-Independent Filtering is consistent with the goal of "Avoiding Hindrance" to applications. Address-Specific Filtering, in contrast, _is_ a hindrance to application functioning and connectivity, and in fact it is a hindrance that is technically completely non-essential to the correct operation of a NAT: it is purely a firewall behavior. Recommending firewall behavior is officially outside the scope of this WG, whereas making recommendations toward enhancing application connectivity and "avoiding hindrance" is very much in-scope. It seems very clear to me where this working group's priorities need to be. Arguing that we shouldn't make recommendations consistent with the working group's basic purpose and charter, purely on the basis that there is likely to be some vendor resistance, just seems fatalistic to me. If you don't think the specifications this working group produces have a chance of influencing the vendors, why bother with the working group at all? Even if many vendors choose not to adopt the proposed advice that "Endpoint-Independent Filtering SHOULD be the default", the existence of that recommendation will still at least make them stop and think twice about the security/connectivity tradeoffs involved. And it might perhaps at least get them to implement Endpoint-Independent Filtering as a configuration option, where otherwise they probably wouldn't have implemented it at all. It is reasonable to expect security to be a top concern for NAT vendors, but given this working group's charter it is appropriate and essential that this group conterbalance those security concerns with reasonable recommendations that promote application connectivity and "hindrance avoidance". Existing industry momentum isn't a good excuse to ignore our charter. Cheers, Bryan From audet@nortel.com Wed, 25 May 2005 11:26:15 -0700 (PDT) From: "Francois Audet" Date: Wed, 25 May 2005 11:26:15 -0700 (PDT) Subject: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-7 Message-ID: <1ECE0EB50388174790F9694F77522CCF0275F063@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: draft-ietf-behave-nat-udp-01, REQ-7 Man, this is difficult.... We have the following proposals on the table: REQ-7: Favored by Bryan, Sriruresh, Yutaka NATs SHOULD support Endpoint Independent Filtering and Address Dependent Filtering, and MAY support Address and Port Dependent Filtering, as options configurable by the user. It is RECOMMENDED that Endpoint Independent Filtering be the default. Cullen strongly opposes the last sentence, and the configuration option. REQ-7: Favored by Cullen (as co-author, not chair), and maybe others A NAT should support Endpoint Independent Filtering or Address and Port Dependent Filtering. I am not sure if Bryan strongly opposes Cullen's proposal, or if he mildly opposes it. I'm not sure either what are Christian and Jon's preferences at this point. Personally, I don't really care as I believe the justification (below) is more important since there is no MUST. I do have a mild preference for Cullen's. REQ-7 justification: The recommendation to use Endpoint Independent Filtering is aimed at maximizing application transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if it was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could interfere with applications that expect to receive UDP packets on more than one UDP port. Using Endpoint Independent Filtering or Address Dependent Filetering instead of Address and Port Dependent Filtering on a NAT (say NAT-A) also has benefits when the other enpoint is behind a non-BEHAVE compliant NAT (say NAT-B) which doesn't support REQ-1. When the endpoints use ICE, if NAT-A uses Address and Port Dependent Filtering, connectivity will require a Media Relay. However, if NAT-A uses Endpoint Indepent Filtering or Address Dependent Filtering, ICE will ultimately find connectivity without requiring a Media Relay. I believe we have a rough concensus on the justification text above. It makes it clear why you would choose one or the other. My proposal: - Adopt Cullen's text. However, include in the justification, the following text: A NAT vendor could could satisfy the maximum application transparency requirement versus the maximum security requirement by having a configuration option allowing choosing between, respectively, Endpoint Independent Filtering and Address Dependent Filtering. If this proposal fails, then I'm not sure what to do. Seems to me we've beaten this to death and we might need a Chair or AD make a decision... From jon.peterson@neustar.biz Wed, 25 May 2005 15:48:53 -0700 (PDT) From: "Peterson, Jon" Date: Wed, 25 May 2005 15:48:53 -0700 (PDT) Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59701502EED@stntexch03.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain Title: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Cullen, I'm not sure I agree that this sort of configuration option is beyond the ken of residential NAT users. I can imagine a very simple knob; users could choose between "more secure" and "more compatible" with a little explanatory text saying that some peer-to-peer applications won't work in the "more secure" mode. Residential NATs, including those coming from Linksys, already have many screens worth of configuration information, many options for port filtering, forwarding, and so on. I do agree that it would be preferable if we could all agree on a default behavior, but realistically, I don't see us arriving at a consensus on this matter. Iam persuaded by the argument that some applications will break in the face of address-dependent filtering, but I also believe address-independent filtering weakens security.I really have a hard time seeing how we can expect to deal with the fact that sometimes users want more security, and sometimes they want more compatibility, without suggesting that we make these configurable options. The bestsituation for applications and end users seems to be one in whch end users are empowered to make the choice. Jon Peterson NeuStar, Inc.
-----Original Message-----From: Cullen Jennings [mailto:fluffy@xxxxxxxxx]Sent: Tuesday, May 24, 2005 6:33 PMTo: Francois Audet; Peterson, Jon; BehaveSubject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01I can't imagine how to explain to a residential NAT user what these options even mean much less how they should or would configure them. The high end enterprise firewalls already have many configuration options for filtering. I don't think the important thing for this group is what NATs can be configured to do or not do - I'm fine if someone wants to make a configurable NAT. The issues this group needs to tackle is what is the minimal behavior that an application can count on getting. If we say the NAT MAY do A or may do B, then that is fine, the application can't assume that it is A or B but can assume it is one or the other. Statements about the default configuration SHOULD be B won't help the application. I strongly object to anything that says the "Endpoint-Independent Filtering SHOULD be the default." - For the Linksys devices, they will basically never be change from the default. All the discussion on this list has led me to feel that the best thing for Linksys to do is more restrictive filtering. I have not meant a single person at Linksys that believes this is a good idea. I can not imagine a single combined firewall NAT what would ship with this as the default. I'm pretty sure the Cisco ones won't. I imagine the feeling will be similar at other NAT and FW manufactures. I think that including this statement will more or less guarantee that over 90% of devices shipped do not comply with this recommendation. The obvious solution to this lack of agreement is say that NATs can MAY choose any type of filtering configuration and MAY be configurable. Or perhaps people want to say that they MUST not be address port filtering (though I'm OK if they are). Cullen On 5/24/05 9:33 AM, "Francois Audet" wrote: So you prefer this: REQ-7: NATs SHOULD support Endpoint-Independent Filtering, Address-Specific Filtering, and Endpoint-Specific Filtering, as options configurable by the user. Endpoint-Independent Filtering SHOULD be the default.I'm fine with this too.I'm assuming that you are OK with the rest? -----Original Message-----From: Peterson, Jon [mailto:jon.peterson@xxxxxxxxxxx] Sent: Tuesday, May 24, 2005 01:50To: Audet, Francois [SC100:9T51:EXCH]; BehaveSubject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01Regarding just the REQ-7 text, I do think Bryan's suggestion has some merit. These requirements are intended to constrain NAT implementers, not the deployers of NATs. The implementers of NATs cannot anticipate what sort of filtering will be desired; that is something that deployers of NATs should be able to configure.Jon PetersonNeuStar, Inc. -----Original Message-----From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Francois AudetSent: Monday, May 23, 2005 11:00 AMTo: 'Behave'Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01Thanks to all, This is a formal proposal on how to move forward, with concrete text. ------------------------ How about this for REQ 7. In the Requirements section: REQ-7: In order to maximize application transparencyIt is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is desired, it is RECOMMENDED that a NAT have an "Address dependent" behavior. In the REQ-7 justification section would be modified as follows: REQ-7: The recommendation to use endpoint independent filtering is aimed at maximizing feature transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if ti was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could infere with applications that use one than one port. I'd like a Yay or Nay on the text above. --------------------- Wordy terminology: As for the wordy terminology for some of the names of behaviors, I also agree (the reasons for wordy names are historical). I can go through the text and simplify. ------------------------ REQs in-line: Bryan feels strongly about copying/pasting the REQs from section 12 in-line in the text as they occur, to help the reader. I personally think it is a reasonable suggestion. Is there any STRONG objection to this? (Cullen in particular, I'd like to hear from you). ------------------------- Determinism: I propose that to address Bryan's concern, I put a note in section 4.1 and 5.1 refering to the Deterministic behavior section. I also propose to change the first sentence of section 8 to the following: The classification of NATs is further complicated by the fact that under some conditions the same NAT often exhibits different behaviors, especially for mapping and filtering. ------------------------- Again, I'd like a Yay or Nay from people on the points above. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Peterson, Jon > Sent: Friday, May 20, 2005 16:48 > To: Behave > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > In light of the recent Last Call discussions about > behave-nat-udp, I wanted to make a few comments. > > Regarding REQ-7, it seems pretty clear to me that there is no > immediate consensus to endorse endpoint-dependent or > endpoint-independent filtering. Consequently, in the interest > of time I'd like to make the modest proposal that REQ-7 > endorse neither, but instead state that both these modes (and > address-specific filtering) should be supported. Is there > some advantage to privileging one over the other? > > I see no great need to specify the maximum datagram length > that NATs must process. > > I find the conceptual model of behave-nat-udp, which focuses > on functions NATs might perform rather than classifications > of NATs as particular taxonomic entities (Basic, Full Cone, > etc), to be very attractive. That much said, I do agree with > several commentators that the resulting functional > descriptions lead to some very wordy terminologies. There > seems to be some emerging agreement on shorter terms, and I > think that would be most welcome to readers. > > Regarding the terms used in behave-nat-udp versus > ford-behave-gen, I see no immediate problems with the terms > used in behave-nat-udp. The distinction between a "map", a > "binding" and a "NAT session" in ford-behave-gen makes me a > little dizzy, to be honest. I do not find the definition of > "mapping" in behave-nat-udp to be problematic. I don't find > the use of the term "session" to refer to a transport-layer > connection between two endpoints to be problematic. > Terminology can be endlessly debated, but it is not clear to > me that we will gain much leverage on our problem space by > spending a few more cycles refining these terms. > > In Section 4.1, I think it reasonable to define behaviors > such as "External NAT mapping is endpoint address dependent" > just in order to disallow them in the requirements section. I > think it is worth being specific about things that we don't > want implementers to do. > > Given the conceptual model of behave-nat-udp, I think the > distinction between "deterministic" and "non-deterministic" > NATs in Section 8 is valuable. In fact, I think this > non-determinism is one of the primary grounds to move away > from a taxonomic model of NATs and into the functional model > espoused by behave-nat-udp. I didn't find Section 8 to be > particularly obscure when I read it, though no doubt the text > could be made more focused. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________Ietf-behave mailing listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Wed, 25 May 2005 19:19:24 -0700 (PDT) From: Cullen Jennings Date: Wed, 25 May 2005 19:19:24 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD59701502EED@stntexch03.cis.neustar.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 I think we are 99% in agreement. Yes, end users should have the choice to buy a NAT that does A, a NAT that does B, or a NAT that is configurable to do A or B and all three of these choices should be an BEHAVE compliant NAT. I'm totally great with that. But when we start discussing what the user interfaces for wizards to configure NATs look like we are way off the right path. I'll even encourage vendors to make NATs configurable but telling them the the default has to be full cone is just a good way to ensure that there are no BEHAVE compliant NATs. So I am also in agreement with you on we are not going to agree on what the default behavior should be. I think we should go with the proposal Francois send out earlier today. Cullen On 5/25/05 3:48 PM, "Peterson, Jon" wrote: Cullen, I'm not sure I agree that this sort of configuration option is beyond the ken of residential NAT users. I can imagine a very simple knob; users could choose between "more secure" and "more compatible" with a little explanatory text saying that some peer-to-peer applications won't work in the "more secure" mode. Residential NATs, including those coming from Linksys, already have many screens worth of configuration information, many options for port filtering, forwarding, and so on. I do agree that it would be preferable if we could all agree on a default behavior, but realistically, I don't see us arriving at a consensus on this matter. I am persuaded by the argument that some applications will break in the face of address-dependent filtering, but I also believe address-independent filtering weakens security. I really have a hard time seeing how we can expect to deal with the fact that sometimes users want more security, and sometimes they want more compatibility, without suggesting that we make these configurable options. The best situation for applications and end users seems to be one in whch end users are empowered to make the choice. Jon Peterson NeuStar, Inc. -----Original Message----- From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] Sent: Tuesday, May 24, 2005 6:33 PM To: Francois Audet; Peterson, Jon; Behave Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 I can't imagine how to explain to a residential NAT user what these options even mean much less how they should or would configure them. The high end enterprise firewalls already have many configuration options for filtering. I don't think the important thing for this group is what NATs can be configured to do or not do - I'm fine if someone wants to make a configurable NAT. The issues this group needs to tackle is what is the minimal behavior that an application can count on getting. If we say the NAT MAY do A or may do B, then that is fine, the application can't assume that it is A or B but can assume it is one or the other. Statements about the default configuration SHOULD be B won't help the application. I strongly object to anything that says the "Endpoint-Independent Filtering SHOULD be the default." - For the Linksys devices, they will basically never be change from the default. All the discussion on this list has led me to feel that the best thing for Linksys to do is more restrictive filtering. I have not meant a single person at Linksys that believes this is a good idea. I can not imagine a single combined firewall NAT what would ship with this as the default. I'm pretty sure the Cisco ones won't. I imagine the feeling will be similar at other NAT and FW manufactures. I think that including this statement will more or less guarantee that over 90% of devices shipped do not comply with this recommendation. The obvious solution to this lack of agreement is say that NATs can MAY choose any type of filtering configuration and MAY be configurable. Or perhaps people want to say that they MUST not be address port filtering (though I'm OK if they are). Cullen On 5/24/05 9:33 AM, "Francois Audet" wrote: So you prefer this: REQ-7: NATs SHOULD support Endpoint-Independent Filtering, Address-Specific Filtering, and Endpoint-Specific Filtering, as options configurable by the user. Endpoint-Independent Filtering SHOULD be the default. I'm fine with this too. I'm assuming that you are OK with the rest? -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@xxxxxxxxxxx] Sent: Tuesday, May 24, 2005 01:50 To: Audet, Francois [SC100:9T51:EXCH]; Behave Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Regarding just the REQ-7 text, I do think Bryan's suggestion has some merit. These requirements are intended to constrain NAT implementers, not the deployers of NATs. The implementers of NATs cannot anticipate what sort of filtering will be desired; that is something that deployers of NATs should be able to configure. Jon Peterson NeuStar, Inc. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Francois Audet Sent: Monday, May 23, 2005 11:00 AM To: 'Behave' Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Thanks to all, This is a formal proposal on how to move forward, with concrete text. ------------------------ How about this for REQ 7. In the Requirements section: REQ-7: In order to maximize application transparencyIt is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is desired, it is RECOMMENDED that a NAT have an "Address dependent" behavior. In the REQ-7 justification section would be modified as follows: REQ-7: The recommendation to use endpoint independent filtering is aimed at maximizing feature transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if ti was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could infere with applications that use one than one port. I'd like a Yay or Nay on the text above. --------------------- Wordy terminology: As for the wordy terminology for some of the names of behaviors, I also agree (the reasons for wordy names are historical). I can go through the text and simplify. ------------------------ REQs in-line: Bryan feels strongly about copying/pasting the REQs from section 12 in-line in the text as they occur, to help the reader. I personally think it is a reasonable suggestion. Is there any STRONG objection to this? (Cullen in particular, I'd like to hear from you). ------------------------- Determinism: I propose that to address Bryan's concern, I put a note in section 4.1 and 5.1 refering to the Deterministic behavior section. I also propose to change the first sentence of section 8 to the following: The classification of NATs is further complicated by the fact that under some conditions the same NAT often exhibits different behaviors, especially for mapping and filtering. ------------------------- Again, I'd like a Yay or Nay from people on the points above. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Peterson, Jon > Sent: Friday, May 20, 2005 16:48 > To: Behave > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > > > > In light of the recent Last Call discussions about > behave-nat-udp, I wanted to make a few comments. > > Regarding REQ-7, it seems pretty clear to me that there is no > immediate consensus to endorse endpoint-dependent or > endpoint-independent filtering. Consequently, in the interest > of time I'd like to make the modest proposal that REQ-7 > endorse neither, but instead state that both these modes (and > address-specific filtering) should be supported. Is there > some advantage to privileging one over the other? > > I see no great need to specify the maximum datagram length > that NATs must process. > > I find the conceptual model of behave-nat-udp, which focuses > on functions NATs might perform rather than classifications > of NATs as particular taxonomic entities (Basic, Full Cone, > etc), to be very attractive. That much said, I do agree with > several commentators that the resulting functional > descriptions lead to some very wordy terminologies. There > seems to be some emerging agreement on shorter terms, and I > think that would be most welcome to readers. > > Regarding the terms used in behave-nat-udp versus > ford-behave-gen, I see no immediate problems with the terms > used in behave-nat-udp. The distinction between a "map", a > "binding" and a "NAT session" in ford-behave-gen makes me a > little dizzy, to be honest. I do not find the definition of > "mapping" in behave-nat-udp to be problematic. I don't find > the use of the term "session" to refer to a transport-layer > connection between two endpoints to be problematic. > Terminology can be endlessly debated, but it is not clear to > me that we will gain much leverage on our problem space by > spending a few more cycles refining these terms. > > In Section 4.1, I think it reasonable to define behaviors > such as "External NAT mapping is endpoint address dependent" > just in order to disallow them in the requirements section. I > think it is worth being specific about things that we don't > want implementers to do. > > Given the conceptual model of behave-nat-udp, I think the > distinction between "deterministic" and "non-deterministic" > NATs in Section 8 is valuable. In fact, I think this > non-determinism is one of the primary grounds to move away > from a taxonomic model of NATs and into the functional model > espoused by behave-nat-udp. I didn't find Section 8 to be > particularly obscure when I read it, though no doubt the text > could be made more focused. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Wed, 25 May 2005 19:46:40 -0700 (PDT) From: Cullen Jennings Date: Wed, 25 May 2005 19:46:40 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <20050525162507.47863.qmail@web40427.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 5/25/05 9:25 AM, "Pyda Srisuresh" wrote: >> I >> have not meant a single person at Linksys that believes this is a good idea. >> I can not imagine a single combined firewall NAT what would ship with this >> as the default. I'm pretty sure the Cisco ones won't. I imagine the feeling >> will be similar at other NAT and FW manufactures. I think that including >> this statement will more or less guarantee that over 90% of devices shipped >> do not comply with this recommendation. >> > [suresh] I do not buy the above argument. NAT vendors, especially the vendors > that supply to residential customers have catered predominantly to > client-server applications thus far. Peer-to-peer application support has not > been a priority. As more residential customers are seeking peer-to-peer > application support on their NAT devices, the NAT vendors will change the tune > according to the market needs. Well you may be right that applications will change the NATs that people buy - but I was not arguing if you were right or wrong. I was just saying none of these people I listed above believe that full cone is the way to go. You are right that peer-to-peer will become more important - that is the whole point of Behave. However, full cone is not required for applications to work with BEHAVE compliant NATs. The residential vendors do want the xbox games to work, and the PS2 games, and SIP, and Skype, and on and on, and they think they will be able to get these to work and provide the "improved" security. I will if the "improved" really is better below. > > As Bryan said, the argument that Full Cone NAT behavior is less secure is > rather weak. Once a host initiated a UDP based application, the application > should be prepared to receive UDP datagrams from any IP address out there and > drop datagrams that it does not care for. That is how it is with the Internet > without NATs. The behavior ought not to be any different by virtue of keepign > the NATs. I doubt if there are any applicatiosn out there that assume a NAT > and > depend on NATs to provide the Address restricted filtering behavior to them. Uh yah, we more or less discussed this one to death. Nice argument in theory but somewhat worse in practice. Let's say you have skype running behind a full cone NAT and that skype turns out to have a buffer overflow bug. If you are behind a full cone NAT anyone can attack you. If you are behind an address restricted NAT, they can not attack you unless they can guess an address you have have connected to and can spoof a packet from it. Both of these are often tricky. > > Cullen - Is there a specific concern why Linksys would want to refuse to > provide endpoint independent filterign behavior as the default? That would be > useful in bringing the discussion to a close. Yes 1) It is perceived as less secure than their competitors. I understand you don't believe the first, but they do. I brought up the point but what if people want to run servers and the response what a feeling that folks that want to run a server behind a NAT are generally competent enough to go and statically forward a port on the NAT to that server. Here they more or less end up defining a server as something only someone who could forward a port would run. This is a totally circular definition of a server and void of any logic but welcome to my world. Cullen From fluffy@cisco.com Wed, 25 May 2005 19:51:12 -0700 (PDT) From: Cullen Jennings Date: Wed, 25 May 2005 19:51:12 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <200505251333.07402.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 5/25/05 10:33 AM, "Bryan Ford" wrote: > > I'm not suggesting we tell NAT vendors how they should design their user > interfaces or present potential configuration options to the user; I only > presented the above example to illustrate the fact that there _are_ > reasonable ways to make such configuration options accessible even to > unsophisticated users. Just as a side note of irrelevant information ... You do realize that many residential NATs (mostly ones embedded in DLS and Cable modems) are configured and locked by the service provider and the end user can not effect the configuration of them. Given that for most applications it is what happens on the outermost NAT this is a bit of a bummer. Perhaps we should specify that they MUST be configurable by the end user using UPnP :-) Cullen From fluffy@cisco.com Wed, 25 May 2005 20:01:35 -0700 (PDT) From: Cullen Jennings Date: Wed, 25 May 2005 20:01:35 -0700 (PDT) Subject: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0275F063@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Re: draft-ietf-behave-nat-udp-01, REQ-7 I'm in agreement with that. (and fix my typo s/should/SHOULD/ ) On 5/25/05 11:25 AM, "Francois Audet" wrote: Man, this is difficult.... We have the following proposals on the table: REQ-7: Favored by Bryan, Sriruresh, Yutaka NATs SHOULD support Endpoint Independent Filtering and Address Dependent Filtering, and MAY support Address and Port Dependent Filtering, as options configurable by the user. It is RECOMMENDED that Endpoint Independent Filtering be the default. Cullen strongly opposes the last sentence, and the configuration option. REQ-7: Favored by Cullen (as co-author, not chair), and maybe others A NAT should support Endpoint Independent Filtering or Address and Port Dependent Filtering. I am not sure if Bryan strongly opposes Cullen's proposal, or if he mildly opposes it. I'm not sure either what are Christian and Jon's preferences at this point. Personally, I don't really care as I believe the justification (below) is more important since there is no MUST. I do have a mild preference for Cullen's. REQ-7 justification: The recommendation to use Endpoint Independent Filtering is aimed at maximizing application transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if it was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could interfere with applications that expect to receive UDP packets on more than one UDP port. Using Endpoint Independent Filtering or Address Dependent Filetering instead of Address and Port Dependent Filtering on a NAT (say NAT-A) also has benefits when the other enpoint is behind a non-BEHAVE compliant NAT (say NAT-B) which doesn't support REQ-1. When the endpoints use ICE, if NAT-A uses Address and Port Dependent Filtering, connectivity will require a Media Relay. However, if NAT-A uses Endpoint Indepent Filtering or Address Dependent Filtering, ICE will ultimately find connectivity without requiring a Media Relay. I believe we have a rough concensus on the justification text above. It makes it clear why you would choose one or the other. My proposal: - Adopt Cullen's text. However, include in the justification, the following text: A NAT vendor could could satisfy the maximum application transparency requirement versus the maximum security requirement by having a configuration option allowing choosing between, respectively, Endpoint Independent Filtering and Address Dependent Filtering. If this proposal fails, then I'm not sure what to do. Seems to me we've beaten this to death and we might need a Chair or AD make a decision... From baford@mit.edu Thu, 26 May 2005 08:25:21 -0700 (PDT) From: Bryan Ford Date: Thu, 26 May 2005 08:25:21 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: Message-ID: <200505261125.18879.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 25 May 2005 22:19, Cullen Jennings wrote: > I think we are 99% in agreement. Yes, end users should have the choice to > buy a NAT that does A, a NAT that does B, or a NAT that is configurable to > do A or B and all three of these choices should be an BEHAVE compliant NAT. I feel very strongly that when it comes to firewalling options incidental to the basic NAT function, users should be able to EXPECT that any NAT they buy off the shelf will be configurable to do A (Endpoint-Independent Filtering) or B (Address-Dependent Filtering), and that the "out-of-the-box" default behavior should be one that offers the best security that can be provided without fundamentally limiting the application's Internet connectivity paradigm. (Which Address-Dependent Filtering does, by making the application only a "second-class network citizen" always dependent on well-known servers for all its connectivity). I fail to see how it is too much to ask vendors to implement both options, especially given that you get Endpoint-Independent Filtering from Address-Specific Filtering simply by turning off the check on new inbound sessions to existing bindings. We're talking an absolutely trivial implementation cost here. > I'm totally great with that. But when we start discussing what the user > interfaces for wizards to configure NATs look like we are way off the right > path. Please re-read this part of my earlier message: > > [Bryan] > > I'm not suggesting we tell NAT vendors how they should design their user > > interfaces or present potential configuration options to the user; I only > > presented the above example to illustrate the fact that there _are_ > > reasonable ways to make such configuration options accessible even to > > unsophisticated users. You were the one who brought up the topic of "user interfaces ... to configure NATs" when you said, "I can't imagine how to explain to a residential NAT user what these options even mean much less how they should or would configure them." I was providing an illustrative example to answer your question, that's all, and I made that very clear. Taking my illustrative example as the basis to make the claim that "we are way off the right path" is totally unfair. > [Cullen again] > I'll even encourage vendors to make NATs configurable but telling > them the the default has to be full cone is just a good way to ensure that > there are no BEHAVE compliant NATs. So I am also in agreement with you on > we are not going to agree on what the default behavior should be. The key word you're somehow missing is "should". Please re-read the actual proposed text: REQ-7: NATs SHOULD support Endpoint Independent Filtering and Address Dependent Filtering, and MAY support Address and Port Dependent Filtering, as options configurable by the user. It is RECOMMENDED that Endpoint Independent Filtering be the default. Notice that there are no MUSTs here, only a SHOULD and a RECOMMENDED. With the above text, NAT vendors are perfectly permitted to ignore the above recommendations and still produce a NAT that they can legitimately call BEHAVE-compliant. The suggested recommendations are there to make it clear that Endpoint-Independent Filtering behavior provides the closest thing to the full connectivity model the Internet was originally designed to implement, and as such should be held up as a standard to be deviated from only when there are overriding security concerns. The text above uses SHOULDs instead of MUSTs precisely _because_ we recognize that there are sometimes overriding security concerns that warrant deviation from the ideal of unrestricted connectivity; nevertheless, the existence of those concerns should not prevent us from promoting full connectivity as the standard. Bryan From srisuresh@yahoo.com Thu, 26 May 2005 08:51:54 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 26 May 2005 08:51:54 -0700 (PDT) Subject: Configurable vs. non-configurable NATs (WAS Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01) In-Reply-To: <200505251333.07402.baford@mit.edu> Message-ID: <20050526155153.43476.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Bryan Ford wrote: > On Tuesday 24 May 2005 21:33, Cullen Jennings wrote: <... stuff deleted> > > The high end > > enterprise firewalls already have many configuration options for filtering. > > I don't think the important thing for this group is what NATs can be > > configured to do or not do - I'm fine if someone wants to make a > > configurable NAT. The issues this group needs to tackle is what is the > > minimal behavior that an application can count on getting. If we say the > > NAT MAY do A or may do B, then that is fine, the application can't assume > > that it is A or B but can assume it is one or the other. Statements about > > the default configuration SHOULD be B won't help the application. > > By this reasoning, many of the other recommendations in the behave-udp draft > should be eliminated because they are only "recommendations" and not > "requirements" that applications can depend on with certainty. REQ-4, for > example, says that 'It is RECOMMENDED that a NAT have a "Port parity > preservation" behavior of "Yes".' Since port parity preservation is only > RECOMMENDED, applications can't depend on it, right? Therefore, by your > reasoning REQ-4 should be eliminated, shouldn't it? The same goes for REQ-2, > > REQ-3(a), REQ-9, and REQ-11. > > The point is that there are sometimes good reasons to include recommendations > > that aren't absolute requirements, and I've already detailed what I feel are > good reasons for having Endpoint-Independent Filtering be the recommended > default even if applications can't depend on _always_ having > Endpoint-Independent Filtering behavior. I won't rehash those arguments > again here. > [suresh] I have the same kind of dilemma that Bryan has. An argument has been made several times on this list that residential NATs are not up for configurtion. And, residential NAT vendors are a big beneficiary of the BEhave WG. Putting the two together, it seems SHOULDs (i..e, recommendations) and MAYs have little relevance in the WG drafts. Any cofigurability recommendations (SHOULDs) are being argued out. Now, is this the right thing to do for us as a WG, given that the beneficiaries of the WG outght to include configurable, non-residential NAT vendors too. Question to the WG: Should we make distinction between configurable NAT devices vs non-configurable NAT devices when making the behave requirements? I am only refering to the cases where this disctinction seems warranted. The recommendations may vary, depending upon whether a NAt device is configurable or not. cheers, suresh From baford@mit.edu Thu, 26 May 2005 09:01:27 -0700 (PDT) From: Bryan Ford Date: Thu, 26 May 2005 09:01:27 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: Message-ID: <200505261201.24545.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 25 May 2005 22:46, Cullen Jennings wrote: > On 5/25/05 9:25 AM, "Pyda Srisuresh" wrote: > >> > >> I have not meant a single person at Linksys that believes this is a good > >> idea. I can not imagine a single combined firewall NAT what would ship > >> with this as the default. I'm pretty sure the Cisco ones won't. I > >> imagine the feeling will be similar at other NAT and FW manufactures. I > >> think that including this statement will more or less guarantee that > >> over 90% of devices shipped do not comply with this recommendation. > > > > [suresh] I do not buy the above argument. NAT vendors, especially the > > vendors that supply to residential customers have catered predominantly > > to client-server applications thus far. Peer-to-peer application support > > has not been a priority. As more residential customers are seeking > > peer-to-peer application support on their NAT devices, the NAT vendors > > will change the tune according to the market needs. > > Well you may be right that applications will change the NATs that people > buy - but I was not arguing if you were right or wrong. I was just saying > none of these people I listed above believe that full cone is the way to > go. If these people you mention feel so strongly this way, why aren't they participating on this list and expressing support for your POV? I suspect most of them simply haven't actually taken the time to think through the security/connectivity tradeoffs carefully, especially with an eye toward the long-term effects of different connectivity paradigms on the Internet, because that's not they're job - their job is to implement NATs that the marketing folks can sell right NOW. And as Suresh points out, marketing trends change with the winds. It's _our_ job to think about the long-term effects of different NAT behaviors on the overall functionality and robustness of the Internet and make recommendations that will hopefully over time reduce the harm that NATs are causing. That's what this WG was set up to accomplish. Address-Specific Filtering constitutes basic harm to the connectivity of the Internet, and we need to make it clear that such connectivity restrictions, while sometimes justifiable, should not be implemented lightly or without the user's consent. > > As Bryan said, the argument that Full Cone NAT behavior is less secure is > > rather weak. Once a host initiated a UDP based application, the > > application should be prepared to receive UDP datagrams from any IP > > address out there and drop datagrams that it does not care for. That is > > how it is with the Internet without NATs. The behavior ought not to be > > any different by virtue of keepign the NATs. I doubt if there are any > > applicatiosn out there that assume a NAT and > > depend on NATs to provide the Address restricted filtering behavior to > > them. > > Uh yah, we more or less discussed this one to death. Nice argument in > theory but somewhat worse in practice. Let's say you have skype running > behind a full cone NAT and that skype turns out to have a buffer overflow > bug. If you are behind a full cone NAT anyone can attack you. If you are > behind an address restricted NAT, they can not attack you unless they can > guess an address you have have connected to and can spoof a packet from it. > Both of these are often tricky. If you are behind a full cone NAT the attacker still needs to guess the public port number on the NAT you are using to communicate, and any decent NAT will make this port number unpredictable. In fact, as I pointed out before, it will often be just as easy if not easier for an attacker to guess the remote server's IP address and port number you are talking with than to guess the public NAT port you are using, because the server's IP address and port number are often well-known: e.g., it's typically one of a small number of servers operated by the company selling the application you're running, which anyone running that application can easily find. When the application is talking with well-known servers whose addresses and port numbers can easily be found or guessed, Address-Dependent Filtering provides absolutely zero added security. > > Cullen - Is there a specific concern why Linksys would want to refuse to > > provide endpoint independent filterign behavior as the default? That > > would be useful in bringing the discussion to a close. > > Yes > > 1) It is perceived as less secure than their competitors. > > I understand you don't believe the first, but they do. This is all the more reason we should do what we can to influence this (mis)perception rather than just giving in to it or endorsing it. > I brought up the > point but what if people want to run servers and the response what a > feeling that folks that want to run a server behind a NAT are generally > competent enough to go and statically forward a port on the NAT to that > server. Here they more or less end up defining a server as something only > someone who could forward a port would run. This is a totally circular > definition of a server and void of any logic but welcome to my world. Plus, it's really really hard to go statically configure a forwarding port on a NAT you don't control: e.g., an ISP-deployed NAT. These kinds of misperceptions are something we need to be working against intelligently, not just throwing our hands up and proclaiming the Internet's "first-class connectivity for all hosts" paradigm to be officially and permanently dead. Bryan Joel: "Is there any risk of brain damage?" Howard: "Well, technically, the procedure _is_ brain damage." From srisuresh@yahoo.com Thu, 26 May 2005 09:01:42 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 26 May 2005 09:01:42 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: Message-ID: <20050526160142.29517.qmail@web40428.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, you argue that residential NAT vendors will refuse to go with endpoint independent filtering behavior. You say that as a representive of the Linksys group within Cisco. You also say that configuration is not an option for residential NAT vendors such as Linksys. So, how is this a 99% in agreement with Jon who, I believe, is suggesting a configurable option even for residential NAT vendors? cheers, suresh --- Cullen Jennings wrote: > > I think we are 99% in agreement. Yes, end users should have the choice to > buy a NAT that does A, a NAT that does B, or a NAT that is configurable to > do A or B and all three of these choices should be an BEHAVE compliant NAT. > I'm totally great with that. But when we start discussing what the user > interfaces for wizards to configure NATs look like we are way off the right > path. I'll even encourage vendors to make NATs configurable but telling them > the the default has to be full cone is just a good way to ensure that there > are no BEHAVE compliant NATs. So I am also in agreement with you on we are > not going to agree on what the default behavior should be. > > I think we should go with the proposal Francois send out earlier today. > > Cullen > > > > On 5/25/05 3:48 PM, "Peterson, Jon" wrote: > > > > > Cullen, > > > > I'm not sure I agree that this sort of configuration option is beyond the > ken > > of residential NAT users. I can imagine a very simple knob; users could > choose > > between "more secure" and "more compatible" with a little explanatory text > > saying that some peer-to-peer applications won't work in the "more secure" > > mode. Residential NATs, including those coming from Linksys, already have > many > > screens worth of configuration information, many options for port > filtering, > > forwarding, and so on. > > > > I do agree that it would be preferable if we could all agree on a default > > behavior, but realistically, I don't see us arriving at a consensus on this > > matter. I am persuaded by the argument that some applications will break in > > the face of address-dependent filtering, but I also believe > > address-independent filtering weakens security. I really have a hard time > > seeing how we can expect to deal with the fact that sometimes users want > more > > security, and sometimes they want more compatibility, without suggesting > that > > we make these configurable options. The best situation for applications and > > end users seems to be one in whch end users are empowered to make the > choice. > > > > Jon Peterson > > NeuStar, Inc. > >> > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > >> Sent: Tuesday, May 24, 2005 6:33 PM > >> To: Francois Audet; Peterson, Jon; Behave > >> Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > >> > >> > >> I can't imagine how to explain to a residential NAT user what these > options > >> even mean much less how they should or would configure them. The high end > >> enterprise firewalls already have many configuration options for > filtering. > >> I don't think the important thing for this group is what NATs can be > >> configured to do or not do - I'm fine if someone wants to make a > >> configurable NAT. The issues this group needs to tackle is what is the > >> minimal behavior that an application can count on getting. If we say the > NAT > >> MAY do A or may do B, then that is fine, the application can't assume > that > >> it is A or B but can assume it is one or the other. Statements about the > >> default configuration SHOULD be B won't help the application. > >> > >> I strongly object to anything that says the "Endpoint-Independent > Filtering > >> SHOULD be the default." - For the Linksys devices, they will basically > never > >> be change from the default. All the discussion on this list has led me to > >> feel that the best thing for Linksys to do is more restrictive filtering. > I > >> have not meant a single person at Linksys that believes this is a good > idea. > >> I can not imagine a single combined firewall NAT what would ship with > this > >> as the default. I'm pretty sure the Cisco ones won't. I imagine the > feeling > >> will be similar at other NAT and FW manufactures. I think that including > >> this statement will more or less guarantee that over 90% of devices > shipped > >> do not comply with this recommendation. > >> > >> The obvious solution to this lack of agreement is say that NATs can MAY > >> choose any type of filtering configuration and MAY be configurable. Or > >> perhaps people want to say that they MUST not be address port filtering > >> (though I'm OK if they are). > >> > >> Cullen > >> > >> On 5/24/05 9:33 AM, "Francois Audet" wrote: > >> > >> > >>> So you prefer this: > >>> > >>>> > >>>> > >>>> REQ-7: NATs SHOULD support Endpoint-Independent Filtering, > >>>> Address-Specific Filtering, and Endpoint-Specific Filtering, as > options > >>>> configurable by the user. Endpoint-Independent Filtering SHOULD be the > >>>> default. > >>> > >>> I'm fine with this too. > >>> > >>> I'm assuming that you are OK with the rest? > >>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Peterson, Jon [mailto:jon.peterson@xxxxxxxxxxx] > >>>> Sent: Tuesday, May 24, 2005 01:50 > >>>> To: Audet, Francois [SC100:9T51:EXCH]; Behave > >>>> Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > >>>> > >>>> > >>>> > >>>> > >>>> Regarding just the REQ-7 text, I do think Bryan's suggestion has some > >>>> merit. These requirements are intended to constrain NAT implementers, > not > >>>> the deployers of NATs. The implementers of NATs cannot anticipate what > >>>> sort of filtering will be desired; that is something that deployers of > >>>> NATs should be able to configure. > >>>> > >>>> > >>>> > >>>> Jon Peterson > >>>> > >>>> NeuStar, Inc. > >>>> > >>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Francois > >>>>> Audet > >>>>> Sent: Monday, May 23, 2005 11:00 AM > >>>>> To: 'Behave' > >>>>> Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > >>>>> > >>>>> > >>>>> > >>>>> Thanks to all, > >>>>> > >>>>> > >>>>> This is a formal proposal on how to move forward, with concrete text. > >>>>> > >>>>> > >>>>> ------------------------ > >>>>> > >>>>> > >>>>> How about this for REQ 7. > >>>>> > >>>>> > >>>>> In the Requirements section: > >>>>> > >>>>> > >>>>> REQ-7: In order to maximize application transparencyIt is RECOMMENDED > >>>>> that > >>>>> a NAT have an "Endpoint independent filtering" behavior. > >>>>> If a more stringent filtering behavior is desired, it is > >>>>> RECOMMENDED > >>>>> that a NAT have an "Address dependent" behavior. > >>>>> > >>>>> > >>>>> In the REQ-7 justification section would be modified as follows: > >>>>> > >>>>> > >>>>> REQ-7: The recommendation to use endpoint independent filtering is > aimed > >>>>> at > >>>>> maximizing feature transparency, in particular for > applications > >>>>> that > >>>>> receive media simultaneously from multiple locations (e.g., > >>>>> gaming), > >>>>> or applications that use rendezvous techniques. However, it is > >>>>> also > >>>>> possible that in some circumstances, it may be preferable to > have > >>>>> a more stringent filtering behavior. Filtering independently > of > >>>>> the > >>>>> external endpoint is not as secure: an unauthorized packet > could > >>>>> get > >>>>> a specific port while the port was kept open if ti was lucky > >>>>> enough > >>>>> to find the port open. In theory, filtering based on both IP > >>>>> address > >>>>> and port is more secure than filtering based only on the IP > >>>>> address > >>>>> (because the external endpoint could in reality be two > endpoints > >>>>> behind > >>>>> another NAT, where one of the two endpoints is an attacker): > >>>>> however, such > >>>>> a policy could infere with applications that use one than one > >>>>> port. > >>>>> > >>>>> > >>>>> I'd like a Yay or Nay on the text above. > >>>>> > >>>>> > >>>>> --------------------- > >>>>> > >>>>> > >>>>> Wordy terminology: > >>>>> As for the wordy terminology for some of the names of behaviors, I > >>>>> also agree > >>>>> (the reasons for wordy names are historical). I can go through the > >>>>> text and simplify. > >>>>> > >>>>> > >>>>> ------------------------ > >>>>> > >>>>> > >>>>> REQs in-line: > >>>>> Bryan feels strongly about copying/pasting the REQs from section 12 > >>>>> in-line in the > >>>>> text as they occur, to help the reader. I personally think it is a > >>>>> reasonable > >>>>> suggestion. Is there any STRONG objection to this? (Cullen in > >>>>> particular, I'd like to > >>>>> hear from you). > >>>>> > >>>>> > >>>>> ------------------------- > >>>>> > >>>>> > >>>>> Determinism: > >>>>> I propose that to address Bryan's concern, I put a note in section > 4.1 > >>>>> and 5.1 > >>>>> refering to the Deterministic behavior section. I also propose to > >>>>> change the first > >>>>> sentence of section 8 to the following: > >>>>> The classification of NATs is further complicated by the fact > that > >>>>> under some > >>>>> conditions the same NAT often exhibits different behaviors, > >>>>> especially for > >>>>> mapping and filtering. > >>>>> > >>>>> > >>>>> ------------------------- > >>>>> > >>>>> > >>>>> Again, I'd like a Yay or Nay from people on the points above. > >>>>> > >>>>> > >>>>> > >>>>>> > -----Original Message----- > >>>>>> > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>>>> > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > >>>>>> > Peterson, Jon > >>>>>> > Sent: Friday, May 20, 2005 16:48 > >>>>>> > To: Behave > >>>>>> > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > In light of the recent Last Call discussions about > >>>>>> > behave-nat-udp, I wanted to make a few comments. > >>>>>> > > >>>>>> > Regarding REQ-7, it seems pretty clear to me that there is no > >>>>>> > immediate consensus to endorse endpoint-dependent or > >>>>>> > endpoint-independent filtering. Consequently, in the interest > >>>>>> > of time I'd like to make the modest proposal that REQ-7 > >>>>>> > endorse neither, but instead state that both these modes (and > >>>>>> > address-specific filtering) should be supported. Is there > >>>>>> > some advantage to privileging one over the other? > >>>>>> > > >>>>>> > I see no great need to specify the maximum datagram length > >>>>>> > that NATs must process. > >>>>>> > > >>>>>> > I find the conceptual model of behave-nat-udp, which focuses > >>>>>> > on functions NATs might perform rather than classifications > >>>>>> > of NATs as particular taxonomic entities (Basic, Full Cone, > >>>>>> > etc), to be very attractive. That much said, I do agree with > >>>>>> > several commentators that the resulting functional > >>>>>> > descriptions lead to some very wordy terminologies. There > >>>>>> > seems to be some emerging agreement on shorter terms, and I > >>>>>> > think that would be most welcome to readers. > >>>>>> > > >>>>>> > Regarding the terms used in behave-nat-udp versus > >>>>>> > ford-behave-gen, I see no immediate problems with the terms > >>>>>> > used in behave-nat-udp. The distinction between a "map", a > >>>>>> > "binding" and a "NAT session" in ford-behave-gen makes me a > >>>>>> > little dizzy, to be honest. I do not find the definition of > >>>>>> > "mapping" in behave-nat-udp to be problematic. I don't find > >>>>>> > the use of the term "session" to refer to a transport-layer > >>>>>> > connection between two endpoints to be problematic. > >>>>>> > Terminology can be endlessly debated, but it is not clear to > >>>>>> > me that we will gain much leverage on our problem space by > >>>>>> > spending a few more cycles refining these terms. > >>>>>> > > >>>>>> > In Section 4.1, I think it reasonable to define behaviors > >>>>>> > such as "External NAT mapping is endpoint address dependent" > >>>>>> > just in order to disallow them in the requirements section. I > >>>>>> > think it is worth being specific about things that we don't > >>>>>> > want implementers to do. > >>>>>> > > >>>>>> > Given the conceptual model of behave-nat-udp, I think the > >>>>>> > distinction between "deterministic" and "non-deterministic" > >>>>>> > NATs in Section 8 is valuable. In fact, I think this > >>>>>> > non-determinism is one of the primary grounds to move away > >>>>>> > from a taxonomic model of NATs and into the functional model > >>>>>> > espoused by behave-nat-udp. I didn't find Section 8 to be > >>>>>> > particularly obscure when I read it, though no doubt the text > >>>>>> > could be made more focused. > >>>>>> > > >>>>>> > Jon Peterson > >>>>>> > NeuStar, Inc. > >>>>>> > > >>>>>> > _______________________________________________ > >>>>>> > Ietf-behave mailing list > >>>>>> > Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>>>> > > >>>>>> > > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ietf-behave mailing list > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Thu, 26 May 2005 09:14:44 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 26 May 2005 09:14:44 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0275F063@zrc2hxm0.corp.nortel.com> Message-ID: <20050526161444.95452.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Francois, The following would work for me. NATs MUST support one of Endpoint Independent Filtering or Endpoint Address Dependent Filtering for UDP sessions by default. A NAT device is RECOMMENDED to have filtering behavior for UDP available as a configurable option amongst a) endpoint dependent filtering, b) Endpoint address dependent filtering, and c) Endpoint independent filtering. In the case a NAT device is configured to support Endpoint Address dependent filtering, it is RECOMMENDED that the NAT device has provision to selectively enable endpoint independent filtering for applications that benefit from the option. cheers, suresh --- Francois Audet wrote: > Man, this is difficult.... > > We have the following proposals on the table: > > REQ-7: Favored by Bryan, Sriruresh, Yutaka > > NATs SHOULD support Endpoint Independent Filtering and Address > Dependent Filtering, and MAY support Address and Port Dependent > Filtering, as options configurable by the user. It is RECOMMENDED > that Endpoint Independent Filtering be the default. > > Cullen strongly opposes the last sentence, and the configuration > option. > > > > REQ-7: Favored by Cullen (as co-author, not chair), and maybe others > > A NAT should support Endpoint Independent Filtering > or Address and Port Dependent Filtering. > > > I am not sure if Bryan strongly opposes Cullen's proposal, or if he > mildly opposes it. > > I'm not sure either what are Christian and Jon's preferences at this point. > > Personally, I don't really care as I believe the justification > (below) is more important since there is no MUST. I do have a mild > preference for Cullen's. > > REQ-7 justification: > > The recommendation to use Endpoint Independent Filtering is aimed at > maximizing > application transparency, in particular for applications that > receive media > simultaneously from multiple locations (e.g., gaming), or > applications that use > rendezvous techniques. However, it is also possible that in some > circumstances, it > may be preferable to have a more stringent filtering behavior. > Filtering > independently of the external endpoint is not as secure: an > unauthorized packet > could get a specific port while the port was kept open if it was > lucky enough to > find the port open. In theory, filtering based on both IP address > and port is more > secure than filtering based only on the IP address (because the > external endpoint > could in reality be two endpoints behind another NAT, where one of > the two > endpoints is an attacker): however, such a policy could interfere > with > applications that expect to receive UDP packets on more than one UDP > port. > Using Endpoint Independent Filtering or Address Dependent Filetering > instead of > Address and Port Dependent Filtering on a NAT (say NAT-A) also has > benefits > when the other enpoint is behind a non-BEHAVE compliant NAT (say > NAT-B) which > doesn't support REQ-1. When the endpoints use ICE, if NAT-A uses > Address and Port > Dependent Filtering, connectivity will require a Media Relay. > However, if NAT-A > uses Endpoint Indepent Filtering or Address Dependent Filtering, ICE > will > ultimately find connectivity without requiring a Media Relay. > > > I believe we have a rough concensus on the justification text above. It > makes it > clear why you would choose one or the other. > > My proposal: > > - Adopt Cullen's text. However, include in the justification, the following > text: > > A NAT vendor could could satisfy the maximum application > transparency > requirement versus the maximum security requirement by having a > configuration > option allowing choosing between, respectively, Endpoint Independent > Filtering > and Address Dependent Filtering. > > If this proposal fails, then I'm not sure what to do. Seems to me we've > beaten this > to death and we might need a Chair or AD make a decision... > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Thu, 26 May 2005 09:33:21 -0700 (PDT) From: Cullen Jennings Date: Thu, 26 May 2005 09:33:21 -0700 (PDT) Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <200505261125.18879.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 5/26/05 8:25 AM, "Bryan Ford" wrote: > Notice that there are no MUSTs here, only a SHOULD and a RECOMMENDED. With > the above text, NAT vendors are perfectly permitted to ignore the above > recommendations and still produce a NAT that they can legitimately call > BEHAVE-compliant. Ah, I have found the heart of the problem. We don't agree on what SHOULD means and vendors would like to be fully compliant. Tell you what, how about we switch the SHOULD to a MAY and Francois has already proposed text that tells the NAT vendor why this is a good idea. You From baford@mit.edu Thu, 26 May 2005 09:38:14 -0700 (PDT) From: Bryan Ford Date: Thu, 26 May 2005 09:38:14 -0700 (PDT) Subject: Re: Configurable vs. non-configurable NATs (WAS Re: =?iso-8859-1?q?=5BIetf-behave=5D=09comments_on?= =?iso-8859-1?q?_draft-ietf-behave-nat-udp-01?=) In-Reply-To: <20050526155153.43476.qmail@web40429.mail.yahoo.com> Message-ID: <200505261238.11951.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 26 May 2005 11:51, Pyda Srisuresh wrote: > An argument has been made several times on this list that residential NATs > are not up for configurtion. And, residential NAT vendors are a big > beneficiary of the BEhave WG. I think that most residential NATs that are sold as stand-alone products, such as the typical boxed Linksys NAT-router, DO have a great many configuration options and would have no problem adding filtering behavior as one more. The "configuration-locked" residental NATs Cullen was referring to I think are generally only low-end devices that ISPs provide on sign-up to their services. If the customer doesn't choose the NAT that they use anyway, there's no issue with the customer perceiving one NAT to be "more secure" than another and making a purchasing decision on that basis. > Question to the WG: Should we make distinction between configurable NAT > devices vs non-configurable NAT devices when making the behave > requirements? I am only refering to the cases where this disctinction seems > warranted. The recommendations may vary, depending upon whether a NAt > device is configurable or not. I think that the proposed recommendation text already does a pretty reasonable job of covering the various important cases. Let me split apart the recommendation's two sentences just for clarity: REQ-7: (a) NATs SHOULD support Endpoint Independent Filtering and Address Dependent Filtering, and MAY support Address and Port Dependent Filtering, as options configurable by the user. (b) It is RECOMMENDED that Endpoint Independent Filtering be the default. Now consider some of the important cases: * Boxed retail residential NATs: vendor has no reason not to heed recommendation (a). Vendor may choose not to heed (b) if he perceives that customers are choosing his box more on the basis of security than on application compatibility and that being able to market the box as providing maximum security is the overriding concern. But then a competing vendor may decide to heed both (a) and (b) and market their box as being more compatible or application-friendly. All fine and appropriate. * Non-configurable ISP-supplied NATs: vendor chooses not to heed recommendation (a) because he perceives low implementation cost and minimal behavioral variation across customers to be overriding concerns that demand non-configurability. Nevertheless, recommendation (b) makes it clear that Endpoint Independent Filtering is the preferred behavior, and since the ISP isn't in the business of selling NATs and isn't giving its customers choice between NATs anyway, the ISP has little or no reason not to heed recommendation (b) and make the NAT (always) provide Endpoint Independent Filtering. * Larger NAT routers: vendor has no reason not to heed either (a) or (b) if the box is marketed primarily as a NAT or general-purpose router. Vendor might have reason not to heed (b) if the box is marketed primarily for its firewall functionality, making security paramount. In essence, as long as the two sentences of REQ-7 are treated as semi-independent sub-recommendations, I think the text already has reasonable and fairly obvious interpretations regardless of which type of NAT we're talking about. Perhaps explicitly separating the two recommendations into (a) and (b) points as above would be worthwhile in order to make it clear that, if a vendor chooses not to heed one point, he should still heed the other if possible. Cheers, Bryan From audet@nortel.com Thu, 26 May 2005 09:39:39 -0700 (PDT) From: "Francois Audet" Date: Thu, 26 May 2005 09:39:39 -0700 (PDT) Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 Message-ID: <1ECE0EB50388174790F9694F77522CCF027BE0B8@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 > Yes > > 1) It is perceived as less secure than their competitors. > > > I understand you don't believe the first, but they do. I > brought up the point but what if people want to run servers > and the response what a feeling that folks that want to run a > server behind a NAT are generally competent enough to go and > statically forward a port on the NAT to that server. Here > they more or less end up defining a server as something only > someone who could forward a port would run. This is a totally > circular definition of a server and void of any logic but > welcome to my world. For what it's worth, I've seen exactly the same as what Cullent is saying for the NAT manufacturers I talked to. They viewed "Address/Port restricted Cone NATs" as "Just as secure as Symmetric NATs" but they actually work for VoIP. Getting them to do "Address restricted" already takes a lot of convincing to do. From audet@nortel.com Thu, 26 May 2005 10:26:40 -0700 (PDT) From: "Francois Audet" Date: Thu, 26 May 2005 10:26:40 -0700 (PDT) Subject: [Ietf-behave] RE: draft-ietf-behave-nat-udp-01, REQ-7 Message-ID: <1ECE0EB50388174790F9694F77522CCF027BE1C8@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: Message Bryan, Would you agree with this proposal? I know you'd prefer having the recommendation in the REQ instead of the justification, but Cullen has stong objections. At this point, I'm thinking that proposal is the best compromise. Let us know.
-----Original Message-----From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] Sent: Wednesday, May 25, 2005 20:01To: Audet, Francois [SC100:9T51:EXCH]; 'Bryan Ford'; BehaveCc: Jon PetersonSubject: Re: draft-ietf-behave-nat-udp-01, REQ-7I'm in agreement with that. (and fix my typo s/should/SHOULD/ )On 5/25/05 11:25 AM, "Francois Audet" wrote: Man, this is difficult.... We have the following proposals on the table: REQ-7: Favored by Bryan, Sriruresh, Yutaka NATs SHOULD support Endpoint Independent Filtering and Address Dependent Filtering, and MAY support Address and Port Dependent Filtering, as options configurable by the user. It is RECOMMENDED that Endpoint Independent Filtering be the default. Cullen strongly opposes the last sentence, and the configuration option. REQ-7: Favored by Cullen (as co-author, not chair), and maybe others A NAT should support Endpoint Independent Filtering or Address and Port Dependent Filtering. I am not sure if Bryan strongly opposes Cullen's proposal, or if he mildly opposes it. I'm not sure either what are Christian and Jon's preferences at this point. Personally, I don't really care as I believe the justification (below) is more important since there is no MUST. I do have a mild preference for Cullen's. REQ-7 justification: The recommendation to use Endpoint Independent Filtering is aimed at maximizing application transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if it was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could interfere with applications that expect to receive UDP packets on more than one UDP port. Using Endpoint Independent Filtering or Address Dependent Filetering instead of Address and Port Dependent Filtering on a NAT (say NAT-A) also has benefits when the other enpoint is behind a non-BEHAVE compliant NAT (say NAT-B) which doesn't support REQ-1. When the endpoints use ICE, if NAT-A uses Address and Port Dependent Filtering, connectivity will require a Media Relay. However, if NAT-A uses Endpoint Indepent Filtering or Address Dependent Filtering, ICE will ultimately find connectivity without requiring a Media Relay. I believe we have a rough concensus on the justification text above. It makes it clear why you would choose one or the other. My proposal: - Adopt Cullen's text. However, include in the justification, the following text: A NAT vendor could could satisfy the maximum application transparency requirement versus the maximum security requirement by having a configuration option allowing choosing between, respectively, Endpoint Independent Filtering and Address Dependent Filtering. If this proposal fails, then I'm not sure what to do. Seems to me we've beaten this to death and we might need a Chair or AD make a decision... From yutaka_takeda@playstation.sony.com Thu, 26 May 2005 11:18:15 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Thu, 26 May 2005 11:18:15 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: Message-ID: <429612D3.504@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain I am ok with this, too.. assuming that Fancois meant: REQ-7: A NAT SHOULD support Endpoint Independent Filtering or Address Dependent Filtering. Observing the arguments, it is convincing me that the arguments on the default filtering behavior is not a behave's primary goal, nothing more than just an option for router developers to choose. (as well as other firewall options which are out of scope of behave, which how I view) REQ-1, 3, 5, 6, 8 already cover the most important aspects of NAT behavior for us to design applications in a deterministic manner. REQ-7 justification looks very good to me. Especially, that Endpoint-specific filtering is not a recommendation and mentioning in the justification the benefit of the recommendation in REQ-7 with using ICE is very important for us to reduce requirement to a media relay, particularly in the transition to full deployment of behave compliant NATs. - Yutaka Cullen Jennings wrote: I'm in agreement with that. (and fix my typo s/should/SHOULD/ ) On 5/25/05 11:25 AM, "Francois Audet" wrote: Man, this is difficult.... We have the following proposals on the table: REQ-7: Favored by Bryan, Sriruresh, Yutaka NATs SHOULD support Endpoint Independent Filtering and Address Dependent Filtering, and MAY support Address and Port Dependent Filtering, as options configurable by the user. It is RECOMMENDED that Endpoint Independent Filtering be the default. Cullen strongly opposes the last sentence, and the configuration option. REQ-7: Favored by Cullen (as co-author, not chair), and maybe others A NAT should support Endpoint Independent Filtering or Address and Port Dependent Filtering. I am not sure if Bryan strongly opposes Cullen's proposal, or if he mildly opposes it. I'm not sure either what are Christian and Jon's preferences at this point. Personally, I don't really care as I believe the justification (below) is more important since there is no MUST. I do have a mild preference for Cullen's. REQ-7 justification: The recommendation to use Endpoint Independent Filtering is aimed at maximizing application transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if it was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could interfere with applications that expect to receive UDP packets on more than one UDP port. Using Endpoint Independent Filtering or Address Dependent Filetering instead of Address and Port Dependent Filtering on a NAT (say NAT-A) also has benefits when the other enpoint is behind a non-BEHAVE compliant NAT (say NAT-B) which doesn't support REQ-1. When the endpoints use ICE, if NAT-A uses Address and Port Dependent Filtering, connectivity will require a Media Relay. However, if NAT-A uses Endpoint Indepent Filtering or Address Dependent Filtering, ICE will ultimately find connectivity without requiring a Media Relay. I believe we have a rough concensus on the justification text above. It makes it clear why you would choose one or the other. My proposal: - Adopt Cullen's text. However, include in the justification, the following text: A NAT vendor could could satisfy the maximum application transparency requirement versus the maximum security requirement by having a configuration option allowing choosing between, respectively, Endpoint Independent Filtering and Address Dependent Filtering. If this proposal fails, then I'm not sure what to do. Seems to me we've beaten this to death and we might need a Chair or AD make a decision... ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Thu, 26 May 2005 11:33:22 -0700 (PDT) From: "Francois Audet" Date: Thu, 26 May 2005 11:33:22 -0700 (PDT) Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Message-ID: <1ECE0EB50388174790F9694F77522CCF027BE332@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Correct. > -----Original Message----- > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] > Sent: Thursday, May 26, 2005 11:18 > To: Cullen Jennings > Cc: Audet, Francois [SC100:9T51:EXCH]; 'Bryan Ford'; Behave > Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 > > > I am ok with this, too.. > assuming that Fancois meant: > > REQ-7: > A NAT SHOULD support Endpoint Independent Filtering > or Address Dependent Filtering. > > Observing the arguments, it is convincing me that the > arguments on the default filtering behavior is not a behave's > primary goal, nothing more than just an option for router > developers to choose. (as well as other firewall options > which are out of scope of behave, which how I view) > > REQ-1, 3, 5, 6, 8 already cover the most important aspects of > NAT behavior for us to design applications in a deterministic manner. > > REQ-7 justification looks very good to me. Especially, that > Endpoint-specific filtering is not a recommendation and > mentioning in the justification the benefit of the > recommendation in REQ-7 with using > ICE is very important for us to reduce requirement to a media > relay, particularly in the transition to full deployment of > behave compliant NATs. > > - Yutaka > > > Cullen Jennings wrote: > > > > I'm in agreement with that. (and fix my typo s/should/SHOULD/ ) > > > > On 5/25/05 11:25 AM, "Francois Audet" wrote: > > > > Man, this is difficult.... > > > > We have the following proposals on the table: > > > > REQ-7: Favored by Bryan, Sriruresh, Yutaka > > > > NATs SHOULD support Endpoint Independent > Filtering and Address > > Dependent Filtering, and MAY support Address > and Port Dependent > > Filtering, as options configurable by the user. It is > > RECOMMENDED > > that Endpoint Independent Filtering be the default. > > > > Cullen strongly opposes the last sentence, and the > configuration > > option. > > > > > > > > REQ-7: Favored by Cullen (as co-author, not chair), and maybe > > others > > > > A NAT should support Endpoint Independent Filtering > > or Address and Port Dependent Filtering. > > > > > > I am not sure if Bryan strongly opposes Cullen's > proposal, or if he > > mildly opposes it. > > > > I'm not sure either what are Christian and Jon's > preferences at this > > point. > > > > Personally, I don't really care as I believe the justification > > (below) is more important since there is no MUST. I do > have a mild > > preference for Cullen's. > > > > REQ-7 justification: > > > > The recommendation to use Endpoint Independent > Filtering is > > aimed at maximizing > > application transparency, in particular for applications > > that receive media > > simultaneously from multiple locations (e.g., > gaming), or > > applications that use > > rendezvous techniques. However, it is also > possible that in > > some circumstances, it > > may be preferable to have a more stringent filtering > > behavior. Filtering > > independently of the external endpoint is not > as secure: an > > unauthorized packet > > could get a specific port while the port was > kept open if it > > was lucky enough to > > find the port open. In theory, filtering based > on both IP > > address and port is more > > secure than filtering based only on the IP > address (because > > the external endpoint > > could in reality be two endpoints behind > another NAT, where > > one of the two > > endpoints is an attacker): however, such a policy could > > interfere with > > applications that expect to receive UDP packets > on more than > > one UDP port. > > Using Endpoint Independent Filtering or Address > Dependent > > Filetering instead of > > Address and Port Dependent Filtering on a NAT > (say NAT-A) > > also has benefits > > when the other enpoint is behind a non-BEHAVE > compliant NAT > > (say NAT-B) which > > doesn't support REQ-1. When the endpoints use > ICE, if NAT-A > > uses Address and Port > > Dependent Filtering, connectivity will require a Media > > Relay. However, if NAT-A > > uses Endpoint Indepent Filtering or Address Dependent > > Filtering, ICE will > > ultimately find connectivity without requiring a Media > > Relay. > > > > > > I believe we have a rough concensus on the > justification text above. > > It makes it > > clear why you would choose one or the other. > > > > My proposal: > > > > - Adopt Cullen's text. However, include in the > justification, the > > following text: > > > > A NAT vendor could could satisfy the maximum application > > transparency > > requirement versus the maximum security requirement by > > having a configuration > > option allowing choosing between, respectively, Endpoint > > Independent Filtering > > and Address Dependent Filtering. > > > > If this proposal fails, then I'm not sure what to do. > Seems to me > > we've beaten this > > to death and we might need a Chair or AD make a decision... > > > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > From baford@mit.edu Fri, 27 May 2005 03:29:08 -0700 (PDT) From: Bryan Ford Date: Fri, 27 May 2005 03:29:08 -0700 (PDT) Subject: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF027BE1C8@zrc2hxm0.corp.nortel.com> Message-ID: <200505270629.01679.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 26 May 2005 13:25, Francois Audet wrote: > Bryan, > > Would you agree with this proposal? I assume the proposal is this: > REQ-7: Favored by Cullen (as co-author, not chair), and maybe others > > A NAT should support Endpoint Independent Filtering > or Address and Port Dependent Filtering. No, I'm not OK with this, because it says nothing useful. I feel very strongly that it is not unreasonable, and it may be highly beneficial to the long-term health of the Internet: (a) to ask NAT vendors to allow users to disable connectivity-limiting firewall functionality - i.e., make the behavior configurable - unless there is some specific overriding concern that dictates the NAT be non-configurable. (b) to affirm "full first-class connectivity" as the norm for the Internet unless there are overriding security concerns that dictate otherwise. I do sympathize with Cullen's (and your) concerns about potential vendor resistance, but that's why these are soft recommendations rather than hard requirements. I cannot see the harm it will do to show a little backbone and stick up for preserving the basic connectivity principles the Internet was built on. The vendors will make the final decision anyway; the least we can do is ask them to think about it. In light of the concerns over potential vendor resistance to recommendation (b) above (I frankly don't see much resistance to (a) being likely), I offer the following counter-proposal, which makes it more explicit that there can be legitimate reasons to go against that recommendation: REQ-7: NATs SHOULD support Endpoint Independent Filtering and Address Dependent Filtering, and MAY support Address and Port Dependent Filtering, as options configurable by the user. It is RECOMMENDED that Endpoint Independent Filtering be the default, unless the NAT is designed primarily as a firewall for which security concerns take precedence over concerns of connectivity or compatibility. Would this text answer your objections, Cullen? Cheers, Bryan From baford@mit.edu Fri, 27 May 2005 06:50:42 -0700 (PDT) From: Bryan Ford Date: Fri, 27 May 2005 06:50:42 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF027BE1C8@zrc2hxm0.corp.nortel.com> Message-ID: <200505270950.39797.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain As part 2 in my attempt to address Cullen's concerns about potential vendor resistance to recommending Endpoint Independent Filtering as the default behavior, I offer the following explanatory text be added to section "13. Security Considerations". (Also, delete the existing paragraph in Section 13 about filtering behavior, and add a forward reference to section 13.1 in the brief justification text for REQ-7.) Suggestions for improvements to this text are welcome. 13.1 Filtering Behavior The alternative filtering behaviors discussed in section 5.1 represent a difficult and controversial tradeoff between security and robust connectivity. The recommendation that Endpoint-Independent Filtering be the default, except in situations where security considerations are paramount, is made because the more restrictive filtering behaviors provide only minor incremental security benefits, at the cost of depriving applications of any "first-class" Internet contact point at which they can accept communication sessions initiated by other nodes without the help of third parties. Regardless of filtering behavior, any BEHAVE-compliant NAT inherently provides internal hosts and applications considerable protection against unwanted incoming traffic, because a potential attacker can only send traffic to internal endpoints that internal applications are already using to communicate with external entities, and the attacker must guess the public UDP port number the NAT has assigned for that communication. The public port number, though only chosen from a 16-bit space, is generally outside the well-known port number range that attracts the bulk of malicious Internet traffic, and is not particularly easy to guess because NATs usually (and should) select public ports unpredictably. With the more restrictive Address-Specific Filtering, an attacker must also know or guess the IP address of some external host the application is communicating with in order to send unwanted packets with spoofed source IP addresses. Endpoint-Specific Filtering requires the attacker to guess both the external IP address and port number. The external IP address and port number an application is communicating with, however, often corresponds to one of a limited number of well-known public servers: an attacker can work around Address-Specific or Endpoint-Specific Filtering simply by scanning public DNS records or by signing up as a client of the same application service he wishes to attack. Even if the NAT does not filter incoming packets based on external IP address or port number, the end-host usually does so early in the processing of incoming packets, either in the host OS or the application itself. Applications that use a UDP socket to communicate only with one specific remote endpoint often place that socket in "connected" mode, in which case the operating system's UDP protocol stack automatically filters out all incoming UDP packets to that port except those with the expected source IP address and port number. Applications that use a UDP socket to communicate with several remote endpoints generally have to check the source IP address and port number in incoming packets before doing much other packet processing anyway, merely in order to distinguish the different UDP sessions the application is involved in. Counterbalancing the incremental security benefits that Address-Specific or Endpoint-Specific Filtering provide is the fact that these restrictive filtering behaviors prevent applications behind the NAT from having a "first-class" Internet presence. Applications behind NATs with restrictive filtering can only accept peer-to-peer-style communication sessions from other hosts via hole punching techniques, with the help of a third-party "rendezvous server" whose traffic isn't filtered in this fashion. In many self-organizing application protocols, in which some participating nodes are chosen to act as "supernodes" so as to help other nodes discover each other and establish connections, only nodes behind NATs with Endpoint-Independent Filtering are typically eligible to serve as supernodes, and the protocol collapses if there not enough supernodes available in the network. Similarly, a host behind a NAT with Endpoint-Independent Filtering can reliably accept peer-to-peer communication sessions initiated by other hosts behind legacy NATs that don't provide Consistent Endpoint Translation (section 4.1), whereas hosts behind NATs with restrictive filtering can only communicate reliably if both NATs provide Consistent Endpoint Translation and a third-party rendezvous server is available. For the above reasons, the decision to limit application connectivity by imposing Address-Specific or Endpoint-Specific Filtering should generally be left to the NAT user or administrator whenever possible, and should only be enabled by default in NAT products whose firewall functionality is considered of primary importance over considerations of application compatibility or robust connectivity. From audet@nortel.com Fri, 27 May 2005 11:14:29 -0700 (PDT) From: "Francois Audet" Date: Fri, 27 May 2005 11:14:29 -0700 (PDT) Subject: [Ietf-behave] RE: draft-ietf-behave-nat-udp-01, REQ-7 Message-ID: <1ECE0EB50388174790F9694F77522CCF0281D16A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: draft-ietf-behave-nat-udp-01, REQ-7 You wording is starting to look like something I proposed a while ago... I think the "configurable option" thing should be a sub-item (with a MAY). So either my old wording: REQ-7: In order to maximize application transparency, it is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is desired, it is RECOMMENDED that a NAT have an "Address dependent" behavior. a) The filtering behavior MAY be a user configurable option. or your wording: REQ-7: NATs SHOULD support Endpoint Independent Filtering and Address Dependent Filtering, and MAY support Address and Port Dependent Filtering. It is RECOMMENDED that Endpoint Independent Filtering be the default, unless the NAT is designed primarily as a firewall for which security concerns take precedence over concerns of connectivity or compatibility. b) The filtering behavior MAY be a user configurable option. > -----Original Message----- > From: Bryan Ford [mailto:baford@xxxxxxx] > Sent: Friday, May 27, 2005 03:29 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Cullen Jennings'; 'Behave'; 'Jon Peterson' > Subject: Re: draft-ietf-behave-nat-udp-01, REQ-7 > > > On Thursday 26 May 2005 13:25, Francois Audet wrote: > > Bryan, > > > > Would you agree with this proposal? > > I assume the proposal is this: > > > REQ-7: Favored by Cullen (as co-author, not chair), and maybe others > > > > A NAT should support Endpoint Independent Filtering > > or Address and Port Dependent Filtering. > > No, I'm not OK with this, because it says nothing useful. I > feel very > strongly that it is not unreasonable, and it may be highly > beneficial to the > long-term health of the Internet: > > (a) to ask NAT vendors to allow users to disable > connectivity-limiting > firewall functionality - i.e., make the behavior configurable > - unless there > is some specific overriding concern that dictates the NAT be > non-configurable. > > (b) to affirm "full first-class connectivity" as the norm for > the Internet > unless there are overriding security concerns that dictate otherwise. > > I do sympathize with Cullen's (and your) concerns about > potential vendor > resistance, but that's why these are soft recommendations > rather than hard > requirements. I cannot see the harm it will do to show a > little backbone and > stick up for preserving the basic connectivity principles the > Internet was > built on. The vendors will make the final decision anyway; > the least we can > do is ask them to think about it. > > In light of the concerns over potential vendor resistance to > recommendation > (b) above (I frankly don't see much resistance to (a) being > likely), I offer > the following counter-proposal, which makes it more explicit > that there can > be legitimate reasons to go against that recommendation: > > REQ-7: > NATs SHOULD support Endpoint Independent Filtering > and Address > Dependent Filtering, and MAY support Address and > Port Dependent > Filtering, as options configurable by the user. It > is RECOMMENDED > that Endpoint Independent Filtering be the default, > unless the NAT > is designed primarily as a firewall for which > security concerns > take precedence over concerns of connectivity or > compatibility. > > Would this text answer your objections, Cullen? > > Cheers, > Bryan > > From baford@mit.edu Fri, 27 May 2005 11:34:44 -0700 (PDT) From: Bryan Ford Date: Fri, 27 May 2005 11:34:44 -0700 (PDT) Subject: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0281D16A@zrc2hxm0.corp.nortel.com> Message-ID: <200505271434.25672.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Friday 27 May 2005 14:13, Francois Audet wrote: > You wording is starting to look like something I proposed a while ago... > > I think the "configurable option" thing should be a sub-item (with a MAY). > > So either my old wording: > > REQ-7: In order to maximize application transparency, it is RECOMMENDED > that > > a NAT have an "Endpoint independent filtering" behavior. > If a more stringent filtering behavior is desired, it is RECOMMENDED > that a NAT have an "Address dependent" behavior. > > a) The filtering behavior MAY be a user configurable option. > > or your wording: > > REQ-7: NATs SHOULD support Endpoint Independent Filtering and Address > Dependent Filtering, and MAY support Address and Port Dependent > Filtering. It is RECOMMENDED that Endpoint Independent Filtering > be the default, unless the NAT is designed primarily as a firewall > for which security concerns take precedence over concerns of > connectivity or compatibility. > > b) The filtering behavior MAY be a user configurable option. I prefer the more explicit wording of the latter, but I could live with the following two-word modification to your version: REQ-7: In order to maximize application transparency, it is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is required, it is RECOMMENDED that a NAT have an "Address dependent" behavior. a) The filtering behavior SHOULD be a user configurable option. Change 1: "desired" -> "required" in the main recommendation. Change 2: "MAY" -> "SHOULD" in the sub-point. Using "MAY" here makes the recommendation completely vacuous; it's trivially and obviously the case that for any behavior we leave to the discretion of the NAT designer, they MAY (are free to) make it user-configurable if they want to. The crucial point here is that vendors SHOULD (be encouraged to) make it configurable. And I would still like the proposed text (or some variation of it) to be added to the "Security Considerations" section, with a forward reference from the REQ-7 justification text. Is this acceptable? Cheers, Bryan > > -----Original Message----- > > From: Bryan Ford [mailto:baford@xxxxxxx] > > Sent: Friday, May 27, 2005 03:29 > > To: Audet, Francois [SC100:9T51:EXCH] > > Cc: 'Cullen Jennings'; 'Behave'; 'Jon Peterson' > > Subject: Re: draft-ietf-behave-nat-udp-01, REQ-7 > > > > On Thursday 26 May 2005 13:25, Francois Audet wrote: > > > Bryan, > > > > > > Would you agree with this proposal? > > > > I assume the proposal is this: > > > REQ-7: Favored by Cullen (as co-author, not chair), and maybe others > > > > > > A NAT should support Endpoint Independent Filtering > > > or Address and Port Dependent Filtering. > > > > No, I'm not OK with this, because it says nothing useful. I > > feel very > > strongly that it is not unreasonable, and it may be highly > > beneficial to the > > long-term health of the Internet: > > > > (a) to ask NAT vendors to allow users to disable > > connectivity-limiting > > firewall functionality - i.e., make the behavior configurable > > - unless there > > is some specific overriding concern that dictates the NAT be > > non-configurable. > > > > (b) to affirm "full first-class connectivity" as the norm for > > the Internet > > unless there are overriding security concerns that dictate otherwise. > > > > I do sympathize with Cullen's (and your) concerns about > > potential vendor > > resistance, but that's why these are soft recommendations > > rather than hard > > requirements. I cannot see the harm it will do to show a > > little backbone and > > stick up for preserving the basic connectivity principles the > > Internet was > > built on. The vendors will make the final decision anyway; > > the least we can > > do is ask them to think about it. > > > > In light of the concerns over potential vendor resistance to > > recommendation > > (b) above (I frankly don't see much resistance to (a) being > > likely), I offer > > the following counter-proposal, which makes it more explicit > > that there can > > be legitimate reasons to go against that recommendation: > > > > REQ-7: > > NATs SHOULD support Endpoint Independent Filtering > > and Address > > Dependent Filtering, and MAY support Address and > > Port Dependent > > Filtering, as options configurable by the user. It > > is RECOMMENDED > > that Endpoint Independent Filtering be the default, > > unless the NAT > > is designed primarily as a firewall for which > > security concerns > > take precedence over concerns of connectivity or > > compatibility. > > > > Would this text answer your objections, Cullen? > > > > Cheers, > > Bryan From fluffy@cisco.com Fri, 27 May 2005 11:36:35 -0700 (PDT) From: Cullen Jennings Date: Fri, 27 May 2005 11:36:35 -0700 (PDT) Subject: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <200505270629.01679.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 5/27/05 3:29 AM, "Bryan Ford" wrote: > On Thursday 26 May 2005 13:25, Francois Audet wrote: >> Bryan, >> >> Would you agree with this proposal? > > I assume the proposal is this: > >> REQ-7: Favored by Cullen (as co-author, not chair), and maybe others >> >> A NAT should support Endpoint Independent Filtering >> or Address and Port Dependent Filtering. > > No, I'm not OK with this, because it says nothing useful. I feel very > strongly that it is not unreasonable, and it may be highly beneficial to the > long-term health of the Internet: > > (a) to ask NAT vendors to allow users to disable connectivity-limiting > firewall functionality Most NATs are also a firewall, this group is not doing firewall stuff but saying that the default configuration has to be incompatible with normal firewall functionality is just not realistic > - i.e., make the behavior configurable - unless there > is some specific overriding concern that dictates the NAT be > non-configurable. > > (b) to affirm "full first-class connectivity" as the norm for the Internet > unless there are overriding security concerns that dictate otherwise. Completely agree, however the right way to do this is to get rid of NATs. > > I do sympathize with Cullen's (and your) concerns about potential vendor > resistance, but that's why these are soft recommendations When you say soft, I think you better go reread the definition of SHOULD. Seriously, I know this is an antagonistic thing to say but do go have a look at it. It does not mean this is a good ideas but you are fine to ignore it and fully complaint with this spec if choose to totally ignore it with no reason. The way you are using SHOULD is really more like MAY. As I said in previous email, I'm fine with MAY and text around why the MAY is a good idea. > rather than hard > requirements. I cannot see the harm it will do to show a little backbone and > stick up for preserving the basic connectivity principles the Internet was > built on. The vendors will make the final decision anyway; the least we can > do is ask them to think about it. Yes and the text in the why it should be that way does ask them to think about and provides the reasons why they might want to do full cone. I'm fine with expanding that text if you have great ideas on how else to describe the benefits of full cone. > > In light of the concerns over potential vendor resistance to recommendation > (b) above (I frankly don't see much resistance to (a) being likely), I offer > the following counter-proposal, which makes it more explicit that there can > be legitimate reasons to go against that recommendation: > > REQ-7: > NATs SHOULD support Endpoint Independent Filtering and Address > Dependent Filtering, and MAY support Address and Port Dependent > Filtering, as options configurable by the user. It is RECOMMENDED > that Endpoint Independent Filtering be the default, unless the NAT > is designed primarily as a firewall for which security concerns > take precedence over concerns of connectivity or compatibility. > > Would this text answer your objections, Cullen? In a word - No. I'm not sure there is much more to say that has not already been said. Thoughts? > > Cheers, > Bryan From sg266@cornell.edu Sun, 29 May 2005 01:12:07 -0700 (PDT) From: Saikat Guha Date: Sun, 29 May 2005 01:12:07 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: Message-ID: <1117354319.29206.121.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-05-27 at 11:36 -0700, Cullen Jennings wrote: > On 5/27/05 3:29 AM, "Bryan Ford" wrote: > > On Thursday 26 May 2005 13:25, Francois Audet wrote: > >> A NAT should support Endpoint Independent Filtering > >> or Address and Port Dependent Filtering. > > > > it may be highly beneficial to the > > long-term health of the Internet: > > > > (a) to ask NAT vendors to allow users to disable connectivity-limiting > > firewall functionality > > > Most NATs are also a firewall, this group is not doing firewall stuff but > saying that the default configuration has to be incompatible with normal > firewall functionality is just not realistic I agree. My view is that, in the long term: 1) consistency among vendors is important (thats what the NAT problem is about in the first place) 2) security is important (opportunistic firewalling is unavoidable) Taking a step back, the whole idea of EF=I is it is supposedly more 'application-friendly' and EF=A and EF=ADP are less so. I disagree. I believe both are equally app friendly (or unfriendly). Consider what needs to be done to setup UDP (assuming NAT is NB=I which is uncontested): +---+ | S | +---+ +---+ +---+ | +---+ +---+ | A |--| N |---+---| M |--| B | +---+ +---+ +---+ +---+ A wants to set up UDP with B. N and M are NATs. S is a STUN-like server. EF=I ---- 1. A sends packet to S to learn binding 2. B sends packet to S (so it can learn A's address) 3. S sends A's binding to B 4. B sends packet to A's binding 5. A sends packet to B's binding (src of pkt #4) Here packets 1-3 are unavoidable. A needs to reserve a binding and B needs to learn of it. Now consider the case with EF=A EF=A ---- 1. A sends packet to S to learn binding 2. B sends packet to S (so it can learn A's address) 3. S sends A's binding to B 4. S sends B's binding to A 5. B sends packet to A's binding (dropped) 6. A sends packet to B's binding 7. B sends packet to A's binding The only change is that A explicitly learns B's binding from S and not from the packet B sent. You may say #7 is an extra packet ... but think of it as a retry that would have to be implemented for the previous case in the event that pkt #4 is dropped due to congestion. The only difference is handling that one extra packet from S to A. FWIW, it even _simplifies_ the application's state machine since the connection setup becomes identical on either side ... and agnostic to the EF type of the NATs. The first reaction is that if it were EF=I, then a new NAT'ed host C wouldn't go through this long process. Not true. If you repeat the analysis above, you'll find that, as before, only one extra packet (from S to A) is needed. Furthermore, the "complexity" of the application is the maximum complexity at A, B, C and not the complexity of one branch of some if-statement. In the long term, what does EF=I taken in conjunction with the other recommendations buy us over EF=A? - Better p2p connectivity? NO! Anywhere where EF=I works, EF=A works. - Simpler application? NO! See above. - A warm mushy feeling that we didn't tackle security in the NAT document? Yes. In contrast, EF=A enhances security (think buffer overflows) and the icky feeling that the NAT document proposed *what the NAT vendors will end up doing anyway*. I'd say it makes the apps simpler even. If I were to be so bold as to invite a flame war, I would make the following suggestion: ++++++++++++++++++ REQ-7: It is RECOMMENDED that a NAT have an "Endpoint Address dependent filtering" behavior. ++++++++++++++++++ Before you hit reply ... consider what happens in the long run. 1) NAT behavior becomes more consistent 2) Connection setup becomes NAT-agnostic -- simplifies application (the complexity in apps is not the extra packet/logic but rather deciding what to do dynamically based on the type of NAT) 3) Given the two evils, we recommend the one that enhances security rather than pretend that security has no place in the NAT rfc. (Note EF=I is still RFC compliant ... just not recommended) -- Saikat (who hopes Bryan won't bite his head off. :-p ) Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00030.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00030.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ21YbFBuRmx0cWk2OTEvb1JBc3cvQUp3SjVVSzBFbWxsbjlPalZ4cHBO Q3d0Y2ZYN0FBQ2JCR01UCmlhcTlWT3Qzd3VhM1Y3b05lYWJJdkxVPQo9QzlDNgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From srisuresh@yahoo.com Mon, 30 May 2005 10:06:47 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 30 May 2005 10:06:47 -0700 (PDT) Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF027BE0B8@zrc2hxm0.corp.nortel.com> Message-ID: <20050530170647.8253.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Francois, I understand what you and Cullen are saying about the perception. I donot disagree on that. cheers, suresh --- Francois Audet wrote: > > Yes > > > > 1) It is perceived as less secure than their competitors. > > > > > > I understand you don't believe the first, but they do. I > > brought up the point but what if people want to run servers > > and the response what a feeling that folks that want to run a > > server behind a NAT are generally competent enough to go and > > statically forward a port on the NAT to that server. Here > > they more or less end up defining a server as something only > > someone who could forward a port would run. This is a totally > > circular definition of a server and void of any logic but > > welcome to my world. > > > For what it's worth, I've seen exactly the same as what Cullent is > saying for the NAT manufacturers I talked to. > > They viewed "Address/Port restricted Cone NATs" as "Just as secure as > Symmetric NATs" but they actually work for VoIP. > > Getting them to do "Address restricted" already takes a lot of convincing > to do. > From srisuresh@yahoo.com Mon, 30 May 2005 11:42:55 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 30 May 2005 11:42:55 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1117354319.29206.121.camel@mazinger.u.cs.cornell.edu> Message-ID: <20050530184255.21293.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Saikat, The goal of this WG is to make NATs deterministic. The most important thing this WG should agree on is one of requiring NATs to support Bindings - Address bindings and/or port bindings. The good news is that we all agree on this. The next important thing is to make NATs application friendly, without violating the fundamental NAT behabior. That is what the current argument is all about - The extent of application friendliness. Any of the Cone NAT behaviors mandate the NAT to have a unidirectional Binding. TCP sessions are uneffected by the variations in Cone NAT behaviors because TCP sessions are point to point. Cone NAT behavior varies with UDP sessions because even though the binding is unirectional, UDP sessions are not like TCP and can have wildcards on the destination address and port. Wildcard on the destination port alone makes it an Address restricted Cone NAT, where as wildcard on address & port makes it a Full Cone NAT. Address restricted Cone NAT behavior argues for more restrictive wildcarding and might be more agreeable to the NAT vendors. Whereas, Full Cone NAT behavior argues for more applicaton friedliness and maximum possible wildcarding. As a general rule, One could argue that Bi-directional NAT is more application friendly over Traditional NAT because Bi-directional NAT mandate bi-directional Bindings, unlike Traditional NAT which mandates uni-directional Bindings. Arguably, Full Cone NAT degenrates the uni-directional binding to be bidirectional when wildcarding is done on UDP sessions for destnation address and port. In summary, I do believe, there is merit to both arguments and both arguments have a place in different drafts. Behave-gen to recommend Bi-directional NAT in preference to Traditional NAT for application friendliness. And, the behave-udp to recommend Address restricted Cone NAT behavior for UDP in the context of a traditional NAT. One more reason, why I believe, we need to treat behave-gen and behave-udp as two different drafts with different scopes and NOT combine them into one within the UDP draft. Any comments? cheers, suresh --- Saikat Guha wrote: > On Fri, 2005-05-27 at 11:36 -0700, Cullen Jennings wrote: > > On 5/27/05 3:29 AM, "Bryan Ford" wrote: > > > On Thursday 26 May 2005 13:25, Francois Audet wrote: > > >> A NAT should support Endpoint Independent Filtering > > >> or Address and Port Dependent Filtering. > > > > > > it may be highly beneficial to the > > > long-term health of the Internet: > > > > > > (a) to ask NAT vendors to allow users to disable connectivity-limiting > > > firewall functionality > > > > > Most NATs are also a firewall, this group is not doing firewall stuff but > > saying that the default configuration has to be incompatible with normal > > firewall functionality is just not realistic > > I agree. My view is that, in the long term: > 1) consistency among vendors is important > (thats what the NAT problem is about in the first place) > 2) security is important > (opportunistic firewalling is unavoidable) > > Taking a step back, the whole idea of EF=I is it is supposedly more > 'application-friendly' and EF=A and EF=ADP are less so. I disagree. I > believe both are equally app friendly (or unfriendly). Consider what > needs to be done to setup UDP (assuming NAT is NB=I which is > uncontested): > +---+ > | S | > +---+ > +---+ +---+ | +---+ +---+ > | A |--| N |---+---| M |--| B | > +---+ +---+ +---+ +---+ > > A wants to set up UDP with B. N and M are NATs. S is a STUN-like server. > > EF=I > ---- > 1. A sends packet to S to learn binding > 2. B sends packet to S (so it can learn A's address) > 3. S sends A's binding to B > 4. B sends packet to A's binding > 5. A sends packet to B's binding (src of pkt #4) > > Here packets 1-3 are unavoidable. A needs to reserve a binding and B > needs to learn of it. Now consider the case with EF=A > > EF=A > ---- > 1. A sends packet to S to learn binding > 2. B sends packet to S (so it can learn A's address) > 3. S sends A's binding to B > 4. S sends B's binding to A > 5. B sends packet to A's binding (dropped) > 6. A sends packet to B's binding > 7. B sends packet to A's binding > > The only change is that A explicitly learns B's binding from S and not > from the packet B sent. You may say #7 is an extra packet ... but think > of it as a retry that would have to be implemented for the previous case > in the event that pkt #4 is dropped due to congestion. The only > difference is handling that one extra packet from S to A. FWIW, it even > _simplifies_ the application's state machine since the connection setup > becomes identical on either side ... and agnostic to the EF type of the > NATs. > > The first reaction is that if it were EF=I, then a new NAT'ed host C > wouldn't go through this long process. Not true. If you repeat the > analysis above, you'll find that, as before, only one extra packet (from > S to A) is needed. Furthermore, the "complexity" of the application is > the maximum complexity at A, B, C and not the complexity of one branch > of some if-statement. > > In the long term, what does EF=I taken in conjunction with the other > recommendations buy us over EF=A? > - Better p2p connectivity? NO! Anywhere where EF=I works, EF=A works. > - Simpler application? NO! See above. > - A warm mushy feeling that we didn't tackle security in the NAT > document? Yes. > > In contrast, EF=A enhances security (think buffer overflows) and the > icky feeling that the NAT document proposed *what the NAT vendors will > end up doing anyway*. I'd say it makes the apps simpler even. > > If I were to be so bold as to invite a flame war, I would make the > following suggestion: > ++++++++++++++++++ > REQ-7: > It is RECOMMENDED that a NAT have an "Endpoint Address dependent > filtering" behavior. > ++++++++++++++++++ > > Before you hit reply ... consider what happens in the long run. > > 1) NAT behavior becomes more consistent > 2) Connection setup becomes NAT-agnostic -- simplifies application > (the complexity in apps is not the extra packet/logic but rather > deciding what to do dynamically based on the type of NAT) > 3) Given the two evils, we recommend the one that enhances security > rather than pretend that security has no place in the NAT rfc. > > (Note EF=I is still RFC compliant ... just not recommended) > > -- > Saikat > (who hopes Bryan won't bite his head off. :-p ) > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Mon, 30 May 2005 12:03:40 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 30 May 2005 12:03:40 -0700 (PDT) Subject: Re: [Ietf-behave] TCP through NATs (was Re: How should NATs reject TCP packets?) In-Reply-To: Message-ID: <20050530190340.30139.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, Reset handling is also done in firewalls. That is not to say, Reset handling is a firewall issue. I disgaree with your remark that reet handling is a firewall only issue. Reset handlign is covered in draft-sivakumar-behave-nat-tcp-01 draft. You mention WG meeting notes below. I dont recall seeign one one on the list. Were the WG meetign minutes mailed to the list already? If so, could you pint me to the mail that includes this. Thanks. cheers, suresh --- Cullen Jennings wrote: > On 5/17/05 3:03 PM, "Saikat Guha" wrote: > > > On Tue, 2005-05-17 at 07:35 -0700, Cullen Jennings wrote: > >> If you want STUNT to work and you want to do it on fairly normal OS > without > >> replacing the TCP stacks, what behavior do you need to assume here and how > >> much can you still leave open? > > > > We studied TCP through existing NATs; the results are under submission: > > http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf > > > > In response to Cullen's question, when it comes to packet filtering, it > > would be nice to assume: > > 1. TCP simultaneous open (or even just SYN-in after a SYN-out) works > > 2. One of: > > a) NATs don't generate either RSTs or ICMP Unreachables in > > response to unsolicited SYNs. > > or > > b) NATs don't release the mapping if a) is violated i.e. if they > > receive a RST/ICMP in response to a SYN > > Yes, I had come to more or less the same conclusion. I note that from the > notes of the last WG meeting we had concluded on 1 and 2a. Some notes are: > > ? 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". > > also > > ? 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. > > So unless people have some new information of why we would not want to do > the stuff above, this might be a somewhat already decided issue. > > I think that we had come to the conclusion that we would allow an inbound > SYN and if there was no where to send it we would silently discard it. We > had also come to the conclusion we were not going to extensively talk about > RST handling because we did not need to and it was a firewall issue. > > > Cullen > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From sg266@cornell.edu Wed, 1 Jun 2005 03:52:36 -0700 (PDT) From: Saikat Guha Date: Wed, 1 Jun 2005 03:52:36 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <20050530184255.21293.qmail@web40425.mail.yahoo.com> Message-ID: <1117620907.26005.92.camel@mazinger.u.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Just so we are on the same page, I define 'wildcard' as follows. Any host can send a packet to the UDP service endpoint without first communicating with some other host. For example, once a root DNS server is up and running *any* host on the internet can query it and receive a response without first communicating with any other host. On Mon, 2005-05-30 at 11:42 -0700, Pyda Srisuresh wrote: > The next important thing is to make NATs application friendly, without > violating the fundamental NAT behabior. [...] Cone NAT behavior varies > with UDP sessions because even though the binding is unirectional, UDP > sessions are not like TCP and can have wildcards on the destination > address and port. Wildcard on the destination port alone makes it an > Address restricted Cone NAT, where as wildcard on address & > port makes it a Full Cone NAT. Indeed 'wildcard'-ing is essential for UDP, but Full Cone does NOT support it. Full Cone is no more application friendly than Restricted Cone. Consider a UDP NAT wildcard scenario -- one wants to deploy a root DNS server ... behind a NAT. Futher assume that the NAT is Full Cone. Even so, you cannot do it. No matter what, there is NO way for a new host to send a packet to the DNS server without interacting with some other host first. Even if the NAT is Full Cone. Let me illustrate the point. Host A --------- NAT N --------- Internet ---------- C | +--------------- B - DNS server runs on A (UDP port 53). Case 1 ====== - C sends a DNS query to N at port 53. Packet is dropped. Case 2 ====== - A (somehow) sends a packet to B from port 53 (N maps A:53 <=> N:1424) - C sends a packet to N at port 53. Packet is dropped Ofcourse C needs to talk to someone to learn that the DNS server is externally at port 1424. Even if N is Full Cone, C cannot just show up and talk to A straight away. Here is what needs to be changed in the DNS server and resolver such that A can host the root DNS for C: 1. A MUST send an initial packet to B 2. C MUST query B (directly or indirectly) to get A's mapping ^ | +------- unavoidable no matter what kind of Cone it is 3. A MUST send keep-alives (to keep mapping open; irrelevant point mentioned for completeness) No matter what, C _cannot_ send a packet to A without communicating with someone A has sent a packet to. Ergo, no more wildcard-ing even for Full Cone. With a Restricted Cone NAT, one needs to make one additional change: 4. C MUST inform A (through B) that it wishes to query A If you define wildcard-ing as "C can somehow send a packet to A" then, as we all know, it is possible with any cone through the use of STUN. The trick to wildcard-ing is in C sending a packet to A without talking to anyone first; and that I claim is not possible. If you define wildcard-ing as "A receives C's intent to communicate without knowing about C", then, as I have maintained, both Full Cone and Restricted Cone are equivalent. The "intent to communicate" in the Full Cone case would be C's initial UDP packet while that in the Restricted Cone case would be B's signal to A that C wants to talk. In either case, A doesn't need to know about C before C wants to talk to A -- and therefore C is a wildcard regardless of the type of NAT. Now if you mandate that NATs MUST be port-preserving, then the story changes. But as long as port-preservation is not a MUST, Full Cone is equivalent to Restricted Cone. Ofcourse, port-preservation cannot be a MUST since NATs by definition support multiple internal hosts and any number of them can use the same port simultaneously. Can someone come up with an existing application that doesn't work with NATs today and list each "application friendly" change that needs to be made so it works with Full Cone NATs? -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00031.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00031.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4wIChHTlUv TGludXgpCgppRDhEQlFCQ25ZcXJuRmx0cWk2OTEvb1JBa0FwQUo5T04zazJMbFJqOWdMMnFQaTFr WnRYK3FGWFJBQ2VLT3hlCmw0YUZ2NWlzSEhjY2tPY3NKSVdUcERNPQo9S2VQaQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From fluffy@cisco.com Wed, 1 Jun 2005 06:23:53 -0700 (PDT) From: Cullen Jennings Date: Wed, 1 Jun 2005 06:23:53 -0700 (PDT) Subject: Re: [Ietf-behave] TCP through NATs (was Re: How should NATs reject TCP packets?) In-Reply-To: <20050530190340.30139.qmail@web40426.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 5/30/05 12:03 PM, "Pyda Srisuresh" wrote: > Cullen, > > Reset handling is also done in firewalls. That is not to say, Reset handling > is > a firewall issue. I disgaree with your remark that reet handling is a firewall > only issue. That's a fair comment - I did not mean to imply that we say nothing about RST. What do you think we have to say about RST to make STUNT reliably work? Are you in agreement with the conclusions that came up in last WG meeting? > You mention WG meeting notes below. I dont recall seeign one one on the list. > Were the WG meetign minutes mailed to the list already? If so, could you pint > me to the mail that includes this. Thanks. Not online right now but check around 3/7 or so. You can find them off the auxiliary web page for the WG and by now I imagine they are in the minutes from the last IETF. Cullen > > cheers, > suresh > > --- Cullen Jennings wrote: > >> On 5/17/05 3:03 PM, "Saikat Guha" wrote: >> >>> On Tue, 2005-05-17 at 07:35 -0700, Cullen Jennings wrote: >>>> If you want STUNT to work and you want to do it on fairly normal OS >> without >>>> replacing the TCP stacks, what behavior do you need to assume here and how >>>> much can you still leave open? >>> >>> We studied TCP through existing NATs; the results are under submission: >>> http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf >>> >>> In response to Cullen's question, when it comes to packet filtering, it >>> would be nice to assume: >>> 1. TCP simultaneous open (or even just SYN-in after a SYN-out) works >>> 2. One of: >>> a) NATs don't generate either RSTs or ICMP Unreachables in >>> response to unsolicited SYNs. >>> or >>> b) NATs don't release the mapping if a) is violated i.e. if they >>> receive a RST/ICMP in response to a SYN >> >> Yes, I had come to more or less the same conclusion. I note that from the >> notes of the last WG meeting we had concluded on 1 and 2a. Some notes are: >> >> ? 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". >> >> also >> >> ? 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. >> >> So unless people have some new information of why we would not want to do >> the stuff above, this might be a somewhat already decided issue. >> >> I think that we had come to the conclusion that we would allow an inbound >> SYN and if there was no where to send it we would silently discard it. We >> had also come to the conclusion we were not going to extensively talk about >> RST handling because we did not need to and it was a firewall issue. >> >> >> Cullen >> >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> > From fluffy@cisco.com Wed, 1 Jun 2005 06:25:19 -0700 (PDT) From: Cullen Jennings Date: Wed, 1 Jun 2005 06:25:19 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1117351699.29206.120.camel@mazinger.u.cs.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I agree with Saikat reasoning and would be fine with his proposed text of. > REQ-7: > It is RECOMMENDED that a NAT have an "Endpoint Address dependent > filtering" behavior. I think some other people might have objected to the "Endpoint" filtering at some point but I did not. I could also be convinced to go with something along the lines of Bryan's proposal of > REQ-7: In order to maximize application transparency, it is RECOMMENDED that > a NAT have an "Endpoint independent filtering" behavior. If a more stringent > filtering behavior is required, it is RECOMMENDED that a NAT have an > "Address dependent" behavior. We would need to restructure this slightly because I don't think we can simultaneously RECOMMEND two contradictory things but I would be ok with keeping he meaning the same. On the subpoint of > a) The filtering behavior SHOULD be a user configurable option. I could deal with this if we change to MAY but strongly object to the SHOULD. There are going to be devices where this is difficult. There are going to be devices that only support one type. In many case the administrator of the NAT is very different from the user of it. There is no reason why the WG should tell vendors how to build this. Having it as MAY or SHOULD does not change any interoperability issues between devices. Any standards body should focus on things that it needs to specify to ensure interoperability. Once vendors start down the slipper slope of not being fully compliant, pain and suffering will ensue - I'd rather avoid that. It's about as useful for the draft to say that all NAT user manuals SHOULD be in gender neutral language. It has no effect on interoperability. I can not see any good come it and I can see harm caused by it when key vendors that are not fully complaint start justifying why it is not useful to be fully complaint with BEHAVE. I know it sounds weird to care about this, but I would like to have a chance of getting the largest vendor of residential and corporate NATs to do this and this is not going to help. I also be fine with other proposals like >> NATs SHOULD support Endpoint Independent Filtering or Address >> Dependent Filtering, and MAY support Address and Port Dependent >> Filtering, as options configurable by the administrator. >> and I'd be fine with > REQ-7: > A NAT SHOULD support Endpoint Independent Filtering > or Address Dependent Filtering. Cullen On 5/29/05 12:28 AM, "Saikat Guha" wrote: > On Fri, 2005-05-27 at 11:36 -0700, Cullen Jennings wrote: >> On 5/27/05 3:29 AM, "Bryan Ford" wrote: >>> On Thursday 26 May 2005 13:25, Francois Audet wrote: >>>> A NAT should support Endpoint Independent Filtering >>>> or Address and Port Dependent Filtering. >>> >>> it may be highly beneficial to the >>> long-term health of the Internet: >>> >>> (a) to ask NAT vendors to allow users to disable connectivity-limiting >>> firewall functionality >>> >> Most NATs are also a firewall, this group is not doing firewall stuff but >> saying that the default configuration has to be incompatible with normal >> firewall functionality is just not realistic > > I agree. My view is that, in the long term: > 1) consistency among vendors is important > (thats what the NAT problem is about in the first place) > 2) security is important > (opportunistic firewalling is unavoidable) > > Taking a step back, the whole idea of EF=I is it is supposedly more > 'application-friendly' and EF=A and EF=ADP are less so. I disagree. I > believe both are equally app friendly (or unfriendly). Consider what > needs to be done to setup UDP (assuming NAT is NB=I which is > uncontested): > +---+ > | S | > +---+ > +---+ +---+ | +---+ +---+ > | A |--| N |---+---| M |--| B | > +---+ +---+ +---+ +---+ > > A wants to set up UDP with B. N and M are NATs. S is a STUN-like server. > > EF=I > ---- > 1. A sends packet to S to learn binding > 2. B sends packet to S (so it can learn A's address) > 3. S sends A's binding to B > 4. B sends packet to A's binding > 5. A sends packet to B's binding (src of pkt #4) > > Here packets 1-3 are unavoidable. A needs to reserve a binding and B > needs to learn of it. Now consider the case with EF=A > > EF=A > ---- > 1. A sends packet to S to learn binding > 2. B sends packet to S (so it can learn A's address) > 3. S sends A's binding to B > 4. S sends B's binding to A > 5. B sends packet to A's binding (dropped) > 6. A sends packet to B's binding > 7. B sends packet to A's binding > > The only change is that A explicitly learns B's binding from S and not > from the packet B sent. You may say #7 is an extra packet ... but think > of it as a retry that would have to be implemented for the previous case > in the event that pkt #4 is dropped due to congestion. The only > difference is handling that one extra packet from S to A. FWIW, it even > _simplifies_ the application's state machine since the connection setup > becomes identical on either side ... and agnostic to the EF type of the > NATs. > > The first reaction is that if it were EF=I, then a new NAT'ed host C > wouldn't go through this long process. Not true. If you repeat the > analysis above, you'll find that, as before, only one extra packet (from > S to A) is needed. Furthermore, the "complexity" of the application is > the maximum complexity at A, B, C and not the complexity of one branch > of some if-statement. > > In the long term, what does EF=I taken in conjunction with the other > recommendations buy us over EF=A? > - Better p2p connectivity? NO! Anywhere where EF=I works, EF=A works. > - Simpler application? NO! See above. > - A warm mushy feeling that we didn't tackle security in the NAT > document? Yes. > > In contrast, EF=A enhances security (think buffer overflows) and the > icky feeling that the NAT document proposed *what the NAT vendors will > end up doing anyway*. I'd say it makes the apps simpler even. > > If I were to be so bold as to invite a flame war, I would make the > following suggestion: > ++++++++++++++++++ > REQ-7: > It is RECOMMENDED that a NAT have an "Endpoint Address dependent > filtering" behavior. > ++++++++++++++++++ > > Before you hit reply ... consider what happens in the long run. > > 1) NAT behavior becomes more consistent > 2) Connection setup becomes NAT-agnostic -- simplifies application > (the complexity in apps is not the extra packet/logic but rather > deciding what to do dynamically based on the type of NAT) > 3) Given the two evils, we recommend the one that enhances security > rather than pretend that security has no place in the NAT rfc. > > (Note EF=I is still RFC compliant ... just not recommended) From baford@mit.edu Wed, 1 Jun 2005 09:32:00 -0700 (PDT) From: Bryan Ford Date: Wed, 1 Jun 2005 09:32:00 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: Message-ID: <200506011231.57444.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 01 June 2005 09:25, Cullen Jennings wrote: > > a) The filtering behavior SHOULD be a user configurable option. > > I could deal with this if we change to MAY but strongly object to the > SHOULD. There are going to be devices where this is difficult. There are > going to be devices that only support one type. In many case the > administrator of the NAT is very different from the user of it. Excellent point - in fact, your comment made me realize that the wording of the proposed recommendation above (suggested by Francois) does not quite match what I had in mind - what I actually want is more along the lines of: a) The filtering behavior SHOULD be an option configurable by the administrator of the NAT. I completely agree that we can't expect the NAT's behavior to be configurable by the "end-user" (the bloke making connections through the NAT), when the end-user isn't the one who actually controls the NAT. My intention (from the start) was only that this aspect of the NAT behavior should be configurable by whomever actually _does_ deploy and control the NAT. In the case of ISP-deployed or corporate NATs, it should be configurable by the ISP's or company's network administrator, not necessarily by individual users of the company's network. Similarly, in the case of low-end "locked" residential NATs that the ISP provides and controls exclusively, the ISP is effectively making itself the "administrator" of the NAT, and taking this power away from the end user. Neither of these situations create any problems for the NAT being made configurable by the NAT's _administrator_ (e.g., the ISP), as per the revised wording above. As Jon Peterson pointed out a while ago, the BEHAVE group's documents are intended to constrain NAT _vendors_, not the deployers or administrators of NATs, and what I care about with regards to this point is that the _vendor_ should not "hard-wire" a restrictive filtering policy into the NAT that cannot be disabled by whomever purchases and subsequently administers the NAT. Whether the _end user_ actually gets to make that decision is a separate issue that depends on the relationship between the user and the NAT's administrator, and I don't propose to make any statement in that regard in a BEHAVE document. I can see no practical reason why any new NAT should not have filtering behavior configurable by whomever actually holds the power and responsibility for configuring and administering the NAT. I apologize if this minor confusion between "user" and "administrator" has been a major source of disagreement; I should have caught this wording subtlety earlier. Cheers, Bryan From paul.hoffman@cybersecurity.org Wed, 1 Jun 2005 14:42:01 -0700 (PDT) From: Paul Hoffman Date: Wed, 1 Jun 2005 14:42:01 -0700 (PDT) Subject: [Ietf-behave] New TCP requirements draft Message-ID: MIME-Version: 1.0 Content-Type: text/plain Greetings again. Now that looks like the UDP requirements document is going to be organized more along the "general NAT requirements first, UDP-specific requirements second" model, I thought it would be good to take a stab at a draft that had *only* TCP-specific requirements. Please see , which gets its definitions from the UDP requirements document. This document is purposely quite short. The goal of this WG is to create documents that are easily understood by all NAT developers, not just the most technical ones (and not just the ones who like reading standards documents). To reach that goal, we need to limit the rationale descriptions to just enough for a developer to believe we have some reason for our requirements. If I missed any TCP-specific requirements, I'm happy to revise the document. --Paul Hoffman, Director --Cybersecurity Association --www.cybersecurity.org From srisuresh@yahoo.com Thu, 2 Jun 2005 07:14:55 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 2 Jun 2005 07:14:55 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1117620907.26005.92.camel@mazinger.u.cs.cornell.edu> Message-ID: <20050602141455.11095.qmail@web40422.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Hi Saikat, I may not have been clear in my previous e-mail. Please see my explanation of wildcarding below. Bi-directional NAT in general is more application friendly than Traditional NAT. This is because the Bindings are bi-directional for Bi-directional NAT and uni-directional for Traditional NAT. Full-Cone NAT degenrates into Bi-directional NAT, due to wildcarding employed in the NAT Sessions for UDP. Specific comments below inline. cheers, suresh --- Saikat Guha wrote: > Just so we are on the same page, I define 'wildcard' as follows. Any > host can send a packet to the UDP service endpoint without first > communicating with some other host. For example, once a root DNS server > is up and running *any* host on the internet can query it and receive a > response without first communicating with any other host. > [suresh] There is a variation to this - wildcard on the IP address, and wildcard on the UDP port. Say, a host (A) in the private domain initiated a UDP session outbound to an external endpoint B:b (B is the external address and b is the UDP port on B). Say, the NAT representation of the private endpoint in the external domain is N:n. Now, if the corresponding NAT session had wildcard on the destination port, The NAT device will let in packets from any UDP port from the address B, not just b (i.e., B:*) to N:n usign the same NAT Session. If the corresponding NAT Session had wildcard on the destination address and destination port, the NAT device will let in packets from any external address/port, not just B:b (i..e, *:*) to N:n using the same NAT Session. The former is the Address Restricted Cone NAT and the latter is Full Cone NAT. > On Mon, 2005-05-30 at 11:42 -0700, Pyda Srisuresh wrote: > > The next important thing is to make NATs application friendly, without > > violating the fundamental NAT behabior. [...] Cone NAT behavior varies > > with UDP sessions because even though the binding is unirectional, UDP > > sessions are not like TCP and can have wildcards on the destination > > address and port. Wildcard on the destination port alone makes it an > > Address restricted Cone NAT, where as wildcard on address & > > port makes it a Full Cone NAT. > > Indeed 'wildcard'-ing is essential for UDP, but Full Cone does NOT > support it. Full Cone is no more application friendly than Restricted > Cone. > > Consider a UDP NAT wildcard scenario -- one wants to deploy a root DNS > server ... behind a NAT. Futher assume that the NAT is Full Cone. Even > so, you cannot do it. No matter what, there is NO way for a new host to > send a packet to the DNS server without interacting with some other host > first. Even if the NAT is Full Cone. Let me illustrate the point. > > Host A --------- NAT N --------- Internet ---------- C > | > +--------------- B > > - DNS server runs on A (UDP port 53). > > Case 1 > ====== > - C sends a DNS query to N at port 53. Packet is dropped. > > Case 2 > ====== > - A (somehow) sends a packet to B from port 53 > (N maps A:53 <=> N:1424) > - C sends a packet to N at port 53. Packet is dropped > > Ofcourse C needs to talk to someone to learn that the DNS server is > externally at port 1424. Even if N is Full Cone, C cannot just show up > and talk to A straight away. > > Here is what needs to be changed in the DNS server and resolver such > that A can host the root DNS for C: > > 1. A MUST send an initial packet to B > 2. C MUST query B (directly or indirectly) to get A's mapping > ^ > | > +------- unavoidable no matter what kind of Cone it is > > 3. A MUST send keep-alives > (to keep mapping open; irrelevant point mentioned for completeness) > > No matter what, C _cannot_ send a packet to A without communicating with > someone A has sent a packet to. Ergo, no more wildcard-ing even for Full > Cone. > > With a Restricted Cone NAT, one needs to make one additional change: > > 4. C MUST inform A (through B) that it wishes to query A > > If you define wildcard-ing as "C can somehow send a packet to A" then, > as we all know, it is possible with any cone through the use of STUN. > The trick to wildcard-ing is in C sending a packet to A without talking > to anyone first; and that I claim is not possible. > > If you define wildcard-ing as "A receives C's intent to communicate > without knowing about C", then, as I have maintained, both Full Cone and > Restricted Cone are equivalent. The "intent to communicate" in the Full > Cone case would be C's initial UDP packet while that in the Restricted > Cone case would be B's signal to A that C wants to talk. In either case, > A doesn't need to know about C before C wants to talk to A -- and > therefore C is a wildcard regardless of the type of NAT. > > Now if you mandate that NATs MUST be port-preserving, then the story > changes. But as long as port-preservation is not a MUST, Full Cone is > equivalent to Restricted Cone. Ofcourse, port-preservation cannot be a > MUST since NATs by definition support multiple internal hosts and any > number of them can use the same port simultaneously. > > Can someone come up with an existing application that doesn't work with > NATs today and list each "application friendly" change that needs to be > made so it works with Full Cone NATs? > [suresh] Saikat - It seems, you misunderstood what I said. Please see my explanation of wildcarding earlier. As for how one supports a DNS server behind a NAT, one coudl do this by simply configuring/adding a static inbound port map on N:53 to map to A:53. The benefit of Full Cone NAT behavior over other types of Cone NAT behaviors is apparant in Peer-to-peer application scenario. So, say A (internal host) initiated an outbound session to an external Rendezvous server (and, say, N:n is A's external endpoint representation). With Full Cone NAT,any external host (B or C) will be able to initiate UDP sessions with A, without A having to explicitly initiate them internally. Yes, as you said, this wouldnt be possible without the assistance of the third party Rendezvous server. cheers, suresh > -- > Saikat > From srisuresh@yahoo.com Fri, 3 Jun 2005 08:37:56 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 3 Jun 2005 08:37:56 -0700 (PDT) Subject: Re: [Ietf-behave] TCP through NATs (was Re: How should NATs reject TCP packets?) In-Reply-To: Message-ID: <20050603153756.95913.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > On 5/30/05 12:03 PM, "Pyda Srisuresh" wrote: > > > Cullen, > > > > Reset handling is also done in firewalls. That is not to say, Reset > handling > > is > > a firewall issue. I disgaree with your remark that reet handling is a > firewall > > only issue. > > That's a fair comment - I did not mean to imply that we say nothing about > RST. What do you think we have to say about RST to make STUNT reliably work? > Are you in agreement with the conclusions that came up in last WG meeting? > [suresh] Sure, I agree with the conclusions. We also had discussion on the list about whether to silently drop the packets or generate RST/ICMP-reject for TCP. Initially, we agreed that the NAT device SHOULD send ICMP destination unreachable message, with a code of 10. This is what the ford-behave-gen draft reflects currently in REQ-9. Later, we agreed to drop the packets silently. We will revise the text in the next rev of behave-gen draft. As for RST processing, below is what the sivakumar-behave-nat-tcp draft says. I donot see anything in this that impacts STUNT. RST attack is another well known DoS attack. An attacker could simply forge a number of RST packets for a variety of Established TCP connections and cause the NAT sessions to be reset and freed. One technique to defend against this type of attack is to validate the RST packet and not let the packet through unless the sequence number used in the RST packet is within the expected TCP window size of the TCP Session. cheers, suresh From jon.peterson@neustar.biz Fri, 3 Jun 2005 12:35:58 -0700 (PDT) From: "Peterson, Jon" Date: Fri, 3 Jun 2005 12:35:58 -0700 (PDT) Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59701502F0D@stntexch03.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain > One more reason, why I believe, we need to treat behave-gen and behave-udp as > two different drafts with different scopes and NOT combine them into one > within > the UDP draft. Any comments? I do have one further comment on this. It has become increasingly clear to me that treating these as separate drafts, with separate authors and terminology and ideas, is unlikely to be a path towards consensus. At best, I think it would sweep certain differences under the rug. I think it is preferable, and possible, to come to WG consensus about those differences. That should be done in the context of a single document. Jon Peterson NeuStar, Inc. > cheers, > suresh From marc@let.de Fri, 3 Jun 2005 12:43:35 -0700 (PDT) From: Marc Manthey Date: Fri, 3 Jun 2005 12:43:35 -0700 (PDT) Subject: [Ietf-behave] opencuseeme In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD59701502F0D@stntexch03.cis.neustar.com> Message-ID: <5D161508-F03F-43C7-960A-B6B9C2353B6F@let.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit hello experts, sorry for my offtopic post due to the massive influence from tycoon firms, apple for example during the miss use of vlanhacks and the ongoing software patents disscussion in europe and the pressure from the http://www.mpaa.org/ on bittorrent users i think there is a strong need for Opencuseeme a free peer2peer multiconferencing tool. please join regards www.cuseeme.de Attachment: smime.p7s --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="p7s00002.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7s00002.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHHzCCA0kw ggKyoAMCAQICDgpqAAEAAntSGyw2RRVxMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQ MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50 ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIu ZGUwHhcNMDUwNTA5MTQzMjQ4WhcNMDYwNTA5MTQzMjQ4WjBAMQswCQYDVQQGEwJERTEVMBMGA1UE AxMMTWFyYyBNYW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAvwCjxxISYuhol4fmTuqlvYN3JOLxcceKV3T8OzmBqQVkbKvmkqh+d5ue O+Dz4ZD9sYKbvbAcQmfLqra94of91kM20oPlAalNcSNe8HUEDEVb4GHdqPVwmaVK9jJ5BUPDMheq W5TR5X/ATEfQU7oCZSI/7+h9Ww3anbUXIZeCCOMCAwEAAaOByDCBxTAMBgNVHRMBAf8EAjAAMA4G A1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9n dWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0cHM6Ly93d3cu dHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzBBNkEwMDAxMDAwMjdCNTIxQjJD MzY0NTE1NzE/MA0GCSqGSIb3DQEBBAUAA4GBAE94N6LMW8iv8HvV9RC77acqqCw4JyLYB6pcgTK9 bpEYxkdggTJRUnCMzz8TOOzVvfA2mzEmwoKDnMYUFugAxdLbFPuxsw4aJ9vMZPdppz28nBDdx1jt lmoJvm3fogTLCGfhWyrd68/tqneYNf540iiXPkp9bwVs8qvQFyEUa8Y8MIIDzjCCAzegAwIBAgIP AJn2AAAAAtbxQYHMGpdhMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMH SGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNl Y3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwHhcNMDUw MjA0MTY0ODQ3WhcNMDYwMjA0MTY0ODQ3WjBAMQswCQYDVQQGEwJERTEVMBMGA1UEAxMMTWFyYyBN YW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANL2cTdJD0oNKje7z4466yUIRX8DJbmjCZBMLtnmHiEqMrpK2rQps8Gcmp3ueB+d o7lGwU7YH3m676a5XhyvcaYwmu1C2gLfBiOzbijbZLP95vP0Aowf9HyuO6iTS42el73q+6MKCY8h O1px1R1blj9cxFeGfFXiG8Oz2QOi7sfJHB+Vp9WVU8ZI1I8NibF/wAN8HzZSdbKkEArGarBCYZ8J Em9C7UZpxc3fx61PePP/z5j4GeQVt+iI5FzBMlg0T7W5X16D0yQuLQb2ajeYJhstFC0KrbO+v9eV WnOsXzOYo+PkPH4O6tOKyX14GFITKYWTwyU6It03XrO/lAvn80kCAwEAAaOByDCBxTAMBgNVHRMB Af8EAjAAMA4GA1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNl bnRlci5kZS9ndWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0 cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzk5RjYwMDAwMDAw MkQ2RjE0MTgxQ0MxQTk3NjE/MA0GCSqGSIb3DQEBBAUAA4GBAF3ZoITTnsH5RDnrDWReZJPv9WUF yGPjjKIUHQlGeEg+JY4T5b8SrHJGkyxyoc2dj3E5G7iJ173mz5IK42YizLRNCcw3gZcSJQl8SqiL L7VN/xdOZfbZKFhDStraQXghJ9tvoD5CNzFKblW71W0iv2f1R7GPwR+lKB9S5ZejZj+CMYIDoTCC A50CAQEwgc8wgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1i dXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3Jr cyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkB FhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIOCmoAAQACe1IbLDZFFXEwCQYFKw4DAhoFAKCC AicwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNjAzMTk0MzM1 WjAjBgkqhkiG9w0BCQQxFgQUBR7v9Zqkns8ZePp4mPe4Qt8rtL0wgeEGCSsGAQQBgjcQBDGB0zCB 0DCBvDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4 BgNVBAoTMVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgx IjAgBgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRp ZmljYXRlQHRydXN0Y2VudGVyLmRlAg8AmfYAAAAC1vFBgcwal2EwgeMGCyqGSIb3DQEJEAILMYHT oIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6 MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21i SDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2Vy dGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTANBgkqhkiG9w0BAQEFAASB gAfonVjbEq0zUYmnnE+0iRj375nd8io8Q37UrNhUZvhEeEERSFE/UcFTznsTG01MCmk1oYhkYkUL vFvsURXs/yJRx0IfBEjz6nqSqUqu5dmP1/Z+ozL2HZ85uJoV5Xs6eaPnk0I/+u5WbWDa6L1wQK0u qsyTF3RiGgekDW2F9WsbAAAAAAAA --Boundary..27398.1163630134.multipart/signed-- From srisuresh@yahoo.com Sat, 4 Jun 2005 10:33:48 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 4 Jun 2005 10:33:48 -0700 (PDT) Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD59701502F0D@stntexch03.cis.neustar.com> Message-ID: <20050604173347.29656.qmail@web40428.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- "Peterson, Jon" wrote: > > > One more reason, why I believe, we need to treat behave-gen and behave-udp > as > > two different drafts with different scopes and NOT combine them into one > within > > the UDP draft. Any comments? > > I do have one further comment on this. It has become increasingly clear to me > that treating these as separate drafts, with separate authors and terminology > and ideas, is unlikely to be a path towards consensus. At best, I think it > would sweep certain differences under the rug. I think it is preferable, and > possible, to come to WG consensus about those differences. That should be > done in the context of a single document. > [suresh] It is interesting that you come to a different conclusion than I did. I agree there shoudl be consensus on the terminology used across the drafts. But, I dont see why there cannot be seperate drafts with seperate authors, using the same terminology. What are the differences you think will be swept under the carpet? FWIW, Bi-directional NATs effect the TCP apps just as they do the UDP apps. The Bindings (Address and/or Port Bindings) are bi-directional in a Bi-Directional NAT. As a result, Bi-Directional NAT is P2P friendly for both TCP and UDP apps. So, going by your argument, why continue with a seperate draft for TCP? Why not combine all three drafts (behave-gen, behave-udp & behave-tcp) into one? While on the subject, let me also point out that a NAT device may not be a pure Cone NAT or a pure Bi-Directional NAT. The address maps configured on a NAT device may be such that certain Bindings are uni-directional and some are Bi-directional so that the NAT device provides security in some cases and added application friendliness in other cases. The key here is configurability and directionality of the Bindings on the NAT device. Not mentioning the term Binding in a Behave draft would be "brushing under the rug". There are several items in the behave-gen draft that effects TCP apps. ICMP Error packet handling, rejection of IP packets not permitted by NAT, honoring the DF bit, Port Block reservaton, Hairpin support in a Multi-level NAT, fragment processing, and DHCP configured NAT processing - to name a few. Depending upon your point of view one could argue for them all being combined into a single draft along with the TCP and UDP requirements or into 3 different drafts. We agreed on this list that there is a need for transport-independent general NAT requirements, UDP-specific NAT requirements and TCP-specific NAT requirements. The WG milestones calls for producing BCP drafts for a) unicast UDP requirements, b) TCP requirements, and c) ICMP requirements. Given these, I would think, the natural conclusion would be one of (i) generate three behave drafts - one each for transport-independent general NAT requirements, UDP-specific NAT requirements and TCP-specific NAT requiremens. (or) (ii) Combine all three requirements into a single draft. I donot understand how one could draw the conclusion to have two drafts - One to cover transport-independent general requirements and UDP-specific requirements; and another to cover TCP-specific requirements. Please explain. Thanks. cheers, suresh > Jon Peterson > NeuStar, Inc. > > > cheers, > > suresh > From rohan.mahy@gmail.com Sun, 5 Jun 2005 08:43:18 -0700 (PDT) From: Rohan Mahy Date: Sun, 5 Jun 2005 08:43:18 -0700 (PDT) Subject: Re: [Ietf-behave] New TCP requirements draft In-Reply-To: Message-ID: <953beacc0506050843242f62a0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Hi Paul, First of all, I think the length of this document is refreshing. I think Requirements 2 through 5 are clear and the right level of detail for your average NAT developer. Requirement 1 was not immediately obvious to me. I was thoroughly confused after reading the motivation, but understood the requirement as long as I didn't try to think about the motivation. I don't think it is obvious to a new reader what the motivation is. I think most developers think of this behavior as an accidental side-effect of some implementation decision and will need a bit more explanation to understand that it is a Feature instead of a bug. I think a packet flow diagram would be very helpful here. The statement beginning "Normal TCP stacks..." Is downright confusing. On a purely editorial note, I think it is confusing to have requirements numbered from 1 that start in section 2. I would make a Section 2: Requirements, and put the existing requirements under that. thanks, -rohan On 6/1/05, Paul Hoffman wrote: > Greetings again. Now that looks like the UDP requirements document is > going to be organized more along the "general NAT requirements first, > UDP-specific requirements second" model, I thought it would be good > to take a stab at a draft that had *only* TCP-specific requirements. > Please see > , > which gets its definitions from the UDP requirements document. > > This document is purposely quite short. The goal of this WG is to > create documents that are easily understood by all NAT developers, > not just the most technical ones (and not just the ones who like > reading standards documents). To reach that goal, we need to limit > the rationale descriptions to just enough for a developer to believe > we have some reason for our requirements. > > If I missed any TCP-specific requirements, I'm happy to revise the document. > > --Paul Hoffman, Director > --Cybersecurity Association > --www.cybersecurity.org > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From sg266@cornell.edu Mon, 6 Jun 2005 16:11:58 -0700 (PDT) From: Saikat Guha Date: Mon, 6 Jun 2005 16:11:58 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <20050602141455.11095.qmail@web40422.mail.yahoo.com> Message-ID: <1118099516.5377.40.camel@dcl-craig.dcml.docomolabs-usa.com> MIME-Version: 1.0 Content-Type: text/plain On Thu, 2005-06-02 at 07:14 -0700, Pyda Srisuresh wrote: > As for how one supports a DNS server behind > a NAT, one coudl do this by simply configuring/adding a static inbound port > map > on N:53 to map to A:53. I agree -- "true"/transparent UDP semantics can only be achieved by the use of static mappings. That, however, is not practical giving rise to the need for NAT traversal techniques in the first place. Static mappings aside, the question is -- Is EF=I more 'app friendly' or more 'udp wildcard' friendly than EF=A (or EF=ADP). Reading through the thread I think we agree that that EF=I is no more 'app friendly' than the others (both require similar changes to the application protocol). As for 'wildcard' behavior > With Full Cone NAT,any external host (B or C) will be able to initiate > UDP sessions with A, without A having to explicitly initiate them > internally. Yes, as you said, this wouldnt be possible without the > assistance of the third party Rendezvous server. IMHO, the requirement that B or C "initiate" the UDP session and A not have to "explicitly initiate" it is somewhat arbitrary. It is equivalent (i.e. no loss of 'wildcard' behavior) for B/C to indicate that it wants to establish a UDP session before sending the UDP packet. The equivalence is perhaps more clear with a real life analogy. B and C initiating the UDP session with A is analogous to some stranger knocking on your door. A can process the request (open the door) or drop the UDP packet (ignore the knock). In the second case, the stranger can ring the buzzer on the ground floor of the apartment complex (analogous to B or C indicating their intent to communicate through the rendezvous). A can then buzz them in (send STUN packet through NAT) or ignore them (not send STUN packet). Either way, any stranger can visit A -- so the 'wildcard' behavior is identical. The difference between EF=A and EF=I, I believe, is not in app friendliness or wildcard behavior, but rather in the security properties. And if that is the only difference, I see no reason to not recommend the one that offers better security. -- Saikat From yutaka_takeda@playstation.sony.com Mon, 6 Jun 2005 18:28:11 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Mon, 6 Jun 2005 18:28:11 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <20050530184255.21293.qmail@web40425.mail.yahoo.com> Message-ID: <42A4F828.4080708@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain I am not advocating Full-cone to be the default behavior here but it has some advantages. Consider host A behind a NAT has sessions from a local UDP port to 100 remote hosts. If the NAT is restrictive, host A needs to send keep-alive packets within the NAT binding lifetime to the 100 destinations to maintain all the NAT bindings. If the NAT is Full-cone, only one keep-alive packet per binding lifetime to a host (typically a STUN server) is needed. > 4. C MUST inform A (through B) that it wishes to query A I do not agree with this. One of the advantages of having Full-cone(EF=I) is that C does not have to talk to A through B (proxy) to send packet from C to A. The problem is how host A advertises its external port on the NAT to everyone else. There may be many ways to accomplish this. One familiar example is to use DNS SRV records where host A may dynamically update the record with the current external address and port. (Well, in this case it is assumed that the host A operates an other UDP service than DNS, and the remote hosts can locate the service with FQDN using SRV record resolver.) In general, if there is a DNS-like service where a remote host can resolve a transport address of host A's external port on the NAT by an application specific service identifier, host C can reach host A without sending a signal to A. The real issue here is that there is no guarantee that the NAT that host A is behind is always EF=I. However, consider a situation where there are many hosts that have ability to provide the same service, some of which may find that they are behind a NAT with EF=I. Those hosts may register their external transport address on their NATs to the DNS-like proxy server so that overall traffic load on a 'media relay' can be reduced. Christian pointed out earlier that there is almost no way for an application to ascertain that it is actually behind an EF=I NAT. I agree with this to some extent considering some NATs today do port overloading and/or preservation that may break primary behavior of NAT. I think it is still possible but it may introduce more complexity to host A to ensure the detected behavior, especially during the transition to full deployment of behave compliant NAT. Any thoughts? - Yutaka Saikat Guha wrote: Just so we are on the same page, I define 'wildcard' as follows. Any host can send a packet to the UDP service endpoint without first communicating with some other host. For example, once a root DNS server is up and running *any* host on the internet can query it and receive a response without first communicating with any other host. On Mon, 2005-05-30 at 11:42 -0700, Pyda Srisuresh wrote: The next important thing is to make NATs application friendly, without violating the fundamental NAT behabior. [...] Cone NAT behavior varies with UDP sessions because even though the binding is unirectional, UDP sessions are not like TCP and can have wildcards on the destination address and port. Wildcard on the destination port alone makes it an Address restricted Cone NAT, where as wildcard on address & port makes it a Full Cone NAT. Indeed 'wildcard'-ing is essential for UDP, but Full Cone does NOT support it. Full Cone is no more application friendly than Restricted Cone. Consider a UDP NAT wildcard scenario -- one wants to deploy a root DNS server ... behind a NAT. Futher assume that the NAT is Full Cone. Even so, you cannot do it. No matter what, there is NO way for a new host to send a packet to the DNS server without interacting with some other host first. Even if the NAT is Full Cone. Let me illustrate the point. Host A --------- NAT N --------- Internet ---------- C | +--------------- B - DNS server runs on A (UDP port 53). Case 1 ====== - C sends a DNS query to N at port 53. Packet is dropped. Case 2 ====== - A (somehow) sends a packet to B from port 53 (N maps A:53 <=> N:1424) - C sends a packet to N at port 53. Packet is dropped Ofcourse C needs to talk to someone to learn that the DNS server is externally at port 1424. Even if N is Full Cone, C cannot just show up and talk to A straight away. Here is what needs to be changed in the DNS server and resolver such that A can host the root DNS for C: 1. A MUST send an initial packet to B 2. C MUST query B (directly or indirectly) to get A's mapping ^ | +------- unavoidable no matter what kind of Cone it is 3. A MUST send keep-alives (to keep mapping open; irrelevant point mentioned for completeness) No matter what, C _cannot_ send a packet to A without communicating with someone A has sent a packet to. Ergo, no more wildcard-ing even for Full Cone. With a Restricted Cone NAT, one needs to make one additional change: 4. C MUST inform A (through B) that it wishes to query A If you define wildcard-ing as "C can somehow send a packet to A" then, as we all know, it is possible with any cone through the use of STUN. The trick to wildcard-ing is in C sending a packet to A without talking to anyone first; and that I claim is not possible. If you define wildcard-ing as "A receives C's intent to communicate without knowing about C", then, as I have maintained, both Full Cone and Restricted Cone are equivalent. The "intent to communicate" in the Full Cone case would be C's initial UDP packet while that in the Restricted Cone case would be B's signal to A that C wants to talk. In either case, A doesn't need to know about C before C wants to talk to A -- and therefore C is a wildcard regardless of the type of NAT. Now if you mandate that NATs MUST be port-preserving, then the story changes. But as long as port-preservation is not a MUST, Full Cone is equivalent to Restricted Cone. Ofcourse, port-preservation cannot be a MUST since NATs by definition support multiple internal hosts and any number of them can use the same port simultaneously. Can someone come up with an existing application that doesn't work with NATs today and list each "application friendly" change that needs to be made so it works with Full Cone NATs? ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From sg266@cornell.edu Mon, 6 Jun 2005 19:49:09 -0700 (PDT) From: Saikat Guha Date: Mon, 6 Jun 2005 19:49:09 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <20050530184255.21293.qmail@web40425.mail.yahoo.com> Message-ID: <1118112545.5377.106.camel@dcl-craig.dcml.docomolabs-usa.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-06-06 at 18:28 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: > Consider host A behind a NAT has sessions from a local UDP port to 100 > remote hosts. If the NAT is restrictive, host A needs to send keep-alive > packets within the NAT binding lifetime to the 100 destinations to > maintain all the NAT bindings. In that case the NAT violates REQ-6b: REQ-6b The NAT mapping Refresh Direction MUST have a "NAT refresh method behavior" of "Per mapping" (i.e. refresh all sessions active on a particular mapping). (The requirement holds for any kind of cone behavior) > The problem is how host A advertises its > external port on the NAT to everyone else. There may be many ways to > accomplish this. One familiar example is to use DNS SRV records where > host A may dynamically update the record with the current external > address and port. True. Another way to accomplish this is for A to use something like SIP -- where C's INVITE (more or less equivalent to C's DNS query) is routed to A. A then responds with its external IP:port over SIP and opens a hole at the NAT. It may sound like SIP here is an overhead compared to DNS, but consider that to update the SRV record securely A needs to exchange DNSsec keys with the DNS provider and therefore must have a relationship with that DNS provider. The provider in this case will likely be either the company that sold the application, or A's IT-department, or a 3rd party. In any event, that provider can just as well run a SIP server that A can use. > The real issue here is that there is no guarantee that the NAT that host > A is behind is always EF=I. Agreed. In addition, market forces will almost certainly rule out a future where most NATs are EF=I (linksys et al.). On the other hand, the same forces can ensure that most NATs are EF=A (a compromise that many vendors already make). Therefore, if we can guarantee that the NAT is always EF=A, then much of the application complexity can be reduced. > However, consider a situation where there > are many hosts that have ability to provide the same service, some of > which may find that they are behind a NAT with EF=I. Those hosts may > register their external transport address on their NATs to the DNS-like > proxy server so that overall traffic load on a 'media relay' can be reduced. I did not understand this. > I think it > is still possible but it may introduce more complexity to host A to > ensure the detected behavior, especially during the transition to full > deployment of behave compliant NAT. If we go with the dual recommendation (EF=I and EF=A), then even with full compliance A will either need to detect NAT behavior or assume the worst case EF=A. With a single recommendation of EF=A, the complexity at A is lowered at the cost of opportunistic optimization (where the opportunity is rare in the first place given what the top vendors think about EF=I). -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00032.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00032.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3BRc2duRmx0cWk2OTEvb1JBbW1BQUo0b1d1OFN2c3IzbGxkSDczM0pL d1laL3BjbVVBQ2RHdWF6ClRIdGJISUs0eDUySGRneDhnTGh5YXRFPQo9UVRnSQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From yutaka_takeda@playstation.sony.com Tue, 7 Jun 2005 10:20:53 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Tue, 7 Jun 2005 10:20:53 -0700 (PDT) Subject: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 In-Reply-To: <20050530184255.21293.qmail@web40425.mail.yahoo.com> Message-ID: <42A5D770.4000507@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain I have some comments on REQ-6. REQ-6 The NAT mapping Refresh Direction MUST have a "NAT Outbound refresh behavior" of "True". a) The NAT mapping Refresh Direction MAY have a "NAT Inbound refresh behavior" of "True". b) The NAT mapping Refresh Direction MUST have a "NAT refresh method behavior" of "Per mapping" (i.e. refresh all sessions active on a particular mapping). There's a typo in 6b: "Refresh Direction" -> "Refresh Scope" Somewhat I missed what 6b exactly meant when I read it before, I assumed that the definition of "mapping" for EF=A was a tuple of local IP address, local port, protocol and destination IP (4-tuple). To me, requiring "per mapping" refresh for EF=A is problematic. Say, there is a host behind a EF=A NAT communicating with many remote hosts from the same local port. If one or more sessions are always active for a long time, the number of destination IP addresses stored in the memory in the NAT for filtering will accumulate. When it hits the maximum number of the destination address the NAT can remember, the design must need to consider overwriting the existing destination address table but there is no criteria for which one can be overwritten without a timer per session. In another word, it cannot be assumed in NAT design that communications would be made to limited number of destinations during the lifetime of the mapping. So, I think 6b should be removed. From the security point of view, the sessions that are no longer in use should preferably be closed. Similarly, I feel 6a can be "NOT RECOMMENDED" to prevent from an attacker maintain a session that is no longer in use by an application. - Yutaka From yutaka_takeda@playstation.sony.com Tue, 7 Jun 2005 11:36:20 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Tue, 7 Jun 2005 11:36:20 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <20050530184255.21293.qmail@web40425.mail.yahoo.com> Message-ID: <42A5E91D.3000804@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain Hi Saikat, My comments inline.. Saikat Guha wrote: On Mon, 2005-06-06 at 18:28 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: Consider host A behind a NAT has sessions from a local UDP port to 100 remote hosts. If the NAT is restrictive, host A needs to send keep-alive packets within the NAT binding lifetime to the 100 destinations to maintain all the NAT bindings. In that case the NAT violates REQ-6b: REQ-6b The NAT mapping Refresh Direction MUST have a "NAT refresh method behavior" of "Per mapping" (i.e. refresh all sessions active on a particular mapping). (The requirement holds for any kind of cone behavior) Thanks for pointing it out. I put this in another thread. However, consider a situation where there are many hosts that have ability to provide the same service, some of which may find that they are behind a NAT with EF=I. Those hosts may register their external transport address on their NATs to the DNS-like proxy server so that overall traffic load on a 'media relay' can be reduced. I did not understand this. I apologize my lack of words. I was thinking about something along the line of what Bryan mentioned earlier: http://list.sipfoundry.org/archive/ietf-behave/msg00673.html It would not be a bad idea to make use of EF=I behavior to promote a peer behind a NAT to be an globally accessible node, as a rely node for example, to increase scalability of a decentralized system. If we go with the dual recommendation (EF=I and EF=A), then even with full compliance A will either need to detect NAT behavior or assume the worst case EF=A. Yes. I am in totally agreement. In fact, A must assume EF=APD anyways unless it says "MUST NOT be EF=APD". With a single recommendation of EF=A, the complexity at A is lowered at the cost of opportunistic optimization (where the opportunity is rare in the first place given what the top vendors think about EF=I). An application may not make use of EF=I behavior. An application may make use of EF=I behavior as I mentioned earlier. The decision should be made by an application developer, not by behave WG. If "the dual recommendation" is a matter, I am ok with something like "EF=APD is NOT RECOMMENDED" considering the issues mentioned in REQ-7 justification. - Yutaka From sg266@cornell.edu Tue, 7 Jun 2005 15:40:03 -0700 (PDT) From: Saikat Guha Date: Tue, 7 Jun 2005 15:40:03 -0700 (PDT) Subject: [Ietf-behave] P2P Filesharing over UDP Message-ID: <1118183998.7074.68.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, FYI, I ran into an interesting (and disturbing) P2P filesharing app (Rodi) that seems to use UDP and traverses NATs. http://larytet.sourceforge.net/btRat.shtml It has an interesting approach to UDP NAT Hole-punching that doesn't use a _public_ STUN-like server per say. The first Rodi client opens a UDP hole in the NAT. It does so by initiating a UDP port-scan to some destination from a fixed local port. It waits for one response packet. (at present finding the response packet is manual; but can easily be automated). To keep the UDP hole open, it keeps sending UDP packets at a low rate to the remote port that responded. Subsequent Rodi clients perform a port scan on a remote address as before. If the address is a NAT'ed Rodi client (that has already performed step 1 above), then one of the port-scan packets make it through to the other end. This is assuming the NAT is Full Cone for UDP. The other end replies back with the external IP:port mapping, just as STUN would. Basically, the approach trades off a public STUN server in exchange for a port-scan and full-cone support. As a side note, its main mandate is to transfer files while being indistinguishable from other traffic (Rodi packets can be made to look like DNS, RTP etc). The default transport protocol of choice is UDP. :-/ It seems to implement its own "Rate Limiter (RL)" to provide congestion control, but I can't seem to find how the RL works or how TCP-friendly it is. Just an FYI. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00033.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00033.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3BpSTluRmx0cWk2OTEvb1JBcG84QUo5MHVoK0tFMnVVKzdHUitWZzdT bTlwZG5tRkJBQ2ZWRGNlCjA0b3NOMGJYalhMWFN4SmlGZ0wwUXdBPQo9RnBINQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Tue, 7 Jun 2005 22:26:16 -0700 (PDT) From: Saikat Guha Date: Tue, 7 Jun 2005 22:26:16 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <20050530184255.21293.qmail@web40425.mail.yahoo.com> Message-ID: <1118208371.5348.12.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-06-07 at 11:36 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: > I was thinking about something along the > line of what Bryan mentioned earlier: > http://list.sipfoundry.org/archive/ietf-behave/msg00673.html > It would not be a bad idea to make use of EF=I behavior to promote a > peer behind a NAT to be an globally accessible node, as a rely node for > example, to increase scalability of a decentralized system. Interesting. Infact I just came across an example of this -- Rodi (in another thread). > In fact, A must assume EF=APD anyways > unless it says "MUST NOT be EF=APD". That is true. > If "the dual > recommendation" is a matter, I am ok with something like "EF=APD is NOT > RECOMMENDED" considering the issues mentioned in REQ-7 justification. In my mind that is still a dual recommendation -- since vendors are equally encouraged to build EF=I and EF=A NATs. What do you think of: -------------------- REQ-7: It is RECOMMENDED that a NAT have an "Endpoint Address dependent filtering" behavior. A NAT MAY support Endpoint Independent Filtering, as an option configurable by the administrator. -------------------- -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00034.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00034.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3BvRnpuRmx0cWk2OTEvb1JBdE15QUpzR08yc05waEE5a0tuNTcvcTNt V0hZbTF0L3h3Q2ZmSWdqCmhtSnlEMnVjWXdpYnFua1h6VThUSVlvPQo9b0NvVQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From baford@mit.edu Wed, 8 Jun 2005 08:02:12 -0700 (PDT) From: Bryan Ford Date: Wed, 8 Jun 2005 08:02:12 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: Message-ID: <200506081102.08315.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Trying to catch up on this discussion after being sick for a week... On Sunday 29 May 2005 03:28, Saikat Guha wrote: > Taking a step back, the whole idea of EF=I is it is supposedly more > 'application-friendly' and EF=A and EF=ADP are less so. I disagree. I > believe both are equally app friendly (or unfriendly). Consider what > needs to be done to setup UDP (assuming NAT is NB=I which is > uncontested): > +---+ > > | S | > > +---+ > +---+ +---+ | +---+ +---+ > > | A |--| N |---+---| M |--| B | > > +---+ +---+ +---+ +---+ > > A wants to set up UDP with B. N and M are NATs. S is a STUN-like server. The validity of your example as an argument for why "both are equally app friendly" is already gone with your assumption that "S is a STUN-like server" - i.e., that you _have_ this server S. Think about your assumptions about S for this to work: S must either not be behind a NAT, or its NAT must have EF=I filtering behavior. In other words, in order for hole punching to work for EF=A nodes, there must be _other_ EF=I nodes present to facilitate that hole punching. In other words, the presence of EF=I nodes is vital to the ability to hole punch: EF=A nodes are only "second-class citizens" and have no useful first-class Internet presence without the help of other EF=I nodes. It is therefore crucial to the long-term goal of maintaining robust "any-to-any" connectivity on the Internet that we do anything we can to ensure that EF=I nodes remain easy to come by, even if (for security reasons) many nodes must be behind EF=A NATs. See my earlier messages about supernode-based protocols, etc. In short, I strongly disagree with your assessment that EF=A and EF=I are equally "application-friendly." Bryan > EF=I > ---- > 1. A sends packet to S to learn binding > 2. B sends packet to S (so it can learn A's address) > 3. S sends A's binding to B > 4. B sends packet to A's binding > 5. A sends packet to B's binding (src of pkt #4) > > Here packets 1-3 are unavoidable. A needs to reserve a binding and B > needs to learn of it. Now consider the case with EF=A > > EF=A > ---- > 1. A sends packet to S to learn binding > 2. B sends packet to S (so it can learn A's address) > 3. S sends A's binding to B > 4. S sends B's binding to A > 5. B sends packet to A's binding (dropped) > 6. A sends packet to B's binding > 7. B sends packet to A's binding > > The only change is that A explicitly learns B's binding from S and not > from the packet B sent. You may say #7 is an extra packet ... but think > of it as a retry that would have to be implemented for the previous case > in the event that pkt #4 is dropped due to congestion. The only > difference is handling that one extra packet from S to A. FWIW, it even > _simplifies_ the application's state machine since the connection setup > becomes identical on either side ... and agnostic to the EF type of the > NATs. > > The first reaction is that if it were EF=I, then a new NAT'ed host C > wouldn't go through this long process. Not true. If you repeat the > analysis above, you'll find that, as before, only one extra packet (from > S to A) is needed. Furthermore, the "complexity" of the application is > the maximum complexity at A, B, C and not the complexity of one branch > of some if-statement. > > In the long term, what does EF=I taken in conjunction with the other > recommendations buy us over EF=A? > - Better p2p connectivity? NO! Anywhere where EF=I works, EF=A works. > - Simpler application? NO! See above. > - A warm mushy feeling that we didn't tackle security in the NAT > document? Yes. > > In contrast, EF=A enhances security (think buffer overflows) and the > icky feeling that the NAT document proposed *what the NAT vendors will > end up doing anyway*. I'd say it makes the apps simpler even. > > If I were to be so bold as to invite a flame war, I would make the > following suggestion: > ++++++++++++++++++ > REQ-7: > It is RECOMMENDED that a NAT have an "Endpoint Address dependent > filtering" behavior. > ++++++++++++++++++ > > Before you hit reply ... consider what happens in the long run. > > 1) NAT behavior becomes more consistent > 2) Connection setup becomes NAT-agnostic -- simplifies application > (the complexity in apps is not the extra packet/logic but rather > deciding what to do dynamically based on the type of NAT) > 3) Given the two evils, we recommend the one that enhances security > rather than pretend that security has no place in the NAT rfc. > > (Note EF=I is still RFC compliant ... just not recommended) From marc@let.de Wed, 8 Jun 2005 08:50:43 -0700 (PDT) From: Marc Manthey Date: Wed, 8 Jun 2005 08:50:43 -0700 (PDT) Subject: Re: [Ietf-behave] P2P Filesharing over UDP In-Reply-To: <1118183998.7074.68.camel@localhost.localdomain> Message-ID: <63F952A8-F5CB-40D9-AB1F-33062933FBB5@let.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Jun 8, 2005, at 12:39 AM, Saikat Guha wrote: As a side note, its main mandate is to transfer files while being indistinguishable from other traffic (Rodi packets can be made to look like DNS, RTP etc). hello saikat, great information thank you very much i am looking for connection mechanism for open cuseeme. as far as i see the method looks very similar . provide congestion control can you tell me more about this ? regards marc www.cuseeme.de ******************************************************** opencuseeme / peer2peer multiparty conferencing ******************************************************** Attachment: smime.p7s --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="p7s00003.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7s00003.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHHzCCA0kw ggKyoAMCAQICDgpqAAEAAntSGyw2RRVxMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQ MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50 ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIu ZGUwHhcNMDUwNTA5MTQzMjQ4WhcNMDYwNTA5MTQzMjQ4WjBAMQswCQYDVQQGEwJERTEVMBMGA1UE AxMMTWFyYyBNYW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAvwCjxxISYuhol4fmTuqlvYN3JOLxcceKV3T8OzmBqQVkbKvmkqh+d5ue O+Dz4ZD9sYKbvbAcQmfLqra94of91kM20oPlAalNcSNe8HUEDEVb4GHdqPVwmaVK9jJ5BUPDMheq W5TR5X/ATEfQU7oCZSI/7+h9Ww3anbUXIZeCCOMCAwEAAaOByDCBxTAMBgNVHRMBAf8EAjAAMA4G A1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9n dWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0cHM6Ly93d3cu dHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzBBNkEwMDAxMDAwMjdCNTIxQjJD MzY0NTE1NzE/MA0GCSqGSIb3DQEBBAUAA4GBAE94N6LMW8iv8HvV9RC77acqqCw4JyLYB6pcgTK9 bpEYxkdggTJRUnCMzz8TOOzVvfA2mzEmwoKDnMYUFugAxdLbFPuxsw4aJ9vMZPdppz28nBDdx1jt lmoJvm3fogTLCGfhWyrd68/tqneYNf540iiXPkp9bwVs8qvQFyEUa8Y8MIIDzjCCAzegAwIBAgIP AJn2AAAAAtbxQYHMGpdhMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMH SGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNl Y3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwHhcNMDUw MjA0MTY0ODQ3WhcNMDYwMjA0MTY0ODQ3WjBAMQswCQYDVQQGEwJERTEVMBMGA1UEAxMMTWFyYyBN YW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANL2cTdJD0oNKje7z4466yUIRX8DJbmjCZBMLtnmHiEqMrpK2rQps8Gcmp3ueB+d o7lGwU7YH3m676a5XhyvcaYwmu1C2gLfBiOzbijbZLP95vP0Aowf9HyuO6iTS42el73q+6MKCY8h O1px1R1blj9cxFeGfFXiG8Oz2QOi7sfJHB+Vp9WVU8ZI1I8NibF/wAN8HzZSdbKkEArGarBCYZ8J Em9C7UZpxc3fx61PePP/z5j4GeQVt+iI5FzBMlg0T7W5X16D0yQuLQb2ajeYJhstFC0KrbO+v9eV WnOsXzOYo+PkPH4O6tOKyX14GFITKYWTwyU6It03XrO/lAvn80kCAwEAAaOByDCBxTAMBgNVHRMB Af8EAjAAMA4GA1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNl bnRlci5kZS9ndWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0 cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzk5RjYwMDAwMDAw MkQ2RjE0MTgxQ0MxQTk3NjE/MA0GCSqGSIb3DQEBBAUAA4GBAF3ZoITTnsH5RDnrDWReZJPv9WUF yGPjjKIUHQlGeEg+JY4T5b8SrHJGkyxyoc2dj3E5G7iJ173mz5IK42YizLRNCcw3gZcSJQl8SqiL L7VN/xdOZfbZKFhDStraQXghJ9tvoD5CNzFKblW71W0iv2f1R7GPwR+lKB9S5ZejZj+CMYIDoTCC A50CAQEwgc8wgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1i dXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3Jr cyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkB FhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIOCmoAAQACe1IbLDZFFXEwCQYFKw4DAhoFAKCC AicwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNjA4MTU1MDQx WjAjBgkqhkiG9w0BCQQxFgQUHqkLF5SPO9MP7cialrA411t1RiQwgeEGCSsGAQQBgjcQBDGB0zCB 0DCBvDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4 BgNVBAoTMVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgx IjAgBgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRp ZmljYXRlQHRydXN0Y2VudGVyLmRlAg8AmfYAAAAC1vFBgcwal2EwgeMGCyqGSIb3DQEJEAILMYHT oIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6 MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21i SDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2Vy dGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTANBgkqhkiG9w0BAQEFAASB gGakDLiibxDpyriTdXT1TajL5E30JkW7mSkmQ6sHMyQnuR3TUMUpzZR9vMIFNdJf+bDkKN4I6XE2 GAXjF4eGTWFbdrWZCDFrBZ+AjWjPDrOpUUZ60hio/QMCMkyQrzZjW5b/8h9KLQ+gceJyf7Nm6QiB 9IMLrx1yyNv0lAeRsoA1AAAAAAAA --Boundary..27398.1163630134.multipart/signed-- From baford@mit.edu Wed, 8 Jun 2005 09:01:56 -0700 (PDT) From: Bryan Ford Date: Wed, 8 Jun 2005 09:01:56 -0700 (PDT) Subject: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P Message-ID: <200506081201.53635.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain I'm forwarding this message with the permission of the author, David Barrett, who is not on the BEHAVE list but makes some good points on the filtering behavior issue. Bryan -----Original Message----- From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] Sent: Thursday, May 19, 2005 6:06 PM To: 'Peer-to-peer development.'; 'ietf-behave@xxxxxxxxxxxxxxxxxxx' Subject: RE: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P Hi Bryan, I think your work in this area is simply the best, and I entirely agree with your judgment here. I'm a P2P developer working in the VoIP space, and I can't stress enough the annoyance of address-restricted NATs. Were I working in a "closed" space (ala Skype) it'd be merely a nuisance. However, due to the limitations of open standards (notably SIP and RTP), working in the presence of NATs is quite challenging. I would enthusiastically welcome more standardized behavior in terms of how to "punch holes" and how long I can count on these holes remaining open. Let me explain by way of example: First, as you well know, before anyone can hope to contact me behind a NAT, I must first figure out what the global (NAT'd) address is for each of my local ports. I do this with the help of some central server, such as with STUN. Once the hole has been "punched" I have no idea how long it will stay open, so I need to send a "keep-alive" to my central server. The net result is that there is a very high cost to open even one UDP port behind a NAT, and an ongoing cost to keep it open. So even with a full-cone NAT, there is an up-front and ongoing cost to opening a UDP port on which I intend to receive data. However, with a full-cone NAT, the cost is purely spent by my client -- I needn't involve anyone else (excepting the central server) in preparing to receive data than my own instance of my own application. In the case of an address-restricted NAT, however, not only must I pay the cost of being behind a NAT (and pay not once, but again for each client who communicates with me), everyone else who wishes to communicate with me must pay as well. For the full-cone NAT, once I know my global (NAT'd) IP/port, I can use that as my own -- anybody can contact me via that address, without special behavior to account for me being behind a NAT. This means NAT-ignorant protocols (such as RTP, for example) can be received from behind NATs, without any special programming on the part of the sender. However, for address-restricted NATs, this is not the case. Imagine you want to send me an RTP stream, and I am behind a NAT. With a full-cone NAT, I could send you my global IP/port (via SIP and SDP), and you could open an RTP stream direct back to me. But with an address-restricted NAT, this is not enough. The reason is a bit involved, but please bear with me. First you need to send me the SIP INVITE via my proxy server. SIP allows the proxy server to either redirect you to contact me directly, or forward on my request. If I'm behind a full-cone NAT, either works fine. If I'm behind an address-restricted NAT, I can only hope that the proxy forwards your request on to me, because I have no way of punching a hole to receive your direct SIP request. Furthermore, I have no way of indicating to the SIP proxy that I need it to forward to me. So right off the bat, receiving SIP INVITE requests behind an address-restricted NAT is more complicated than from behind a full-cone NAT. Assuming I'm lucky and the SIP proxy forwards the request to me (via the hole I've already punched for it), I can receive and respond to the INVITE request indicating the port to which you should broadcast your RTP. However, I have a complication that shared by all NATs, and that is getting a port that complies with RTP. The RTP standard indicates RTP ports should be even-numbered, and the next port (odd-numbered) is implied to be open to receive RTCP. Unfortunately, I as a client have absolutely no control over which ports my NAT assigns me, so it's very difficult for me to receive RTP in a fully compliant fashion. So for all NATs I must put in extra effort to communicate the real RTP/RTCP ports I wish to receive on, possibly by bending the RTP spec. But a further complication of address-restricted NATs is that I also need to somehow figure out the exact address you intend to broadcast from, even though I would otherwise not care. This means I must bend the SIP/RTP framework even more (or dig into the details more than I might otherwise) just to support address-restricted NATs. In the meantime, while I am playing these extra games to punch holes to receive your data, you have already begun to broadcast. For full-cone NATs, this is fine and expected. But for address-restricted NATs, I can't receive data despite having told you the correct IP/port to which you should broadcast, because I haven't punched a hole for you. While I'm playing games trying to punch the hole, you're broadcasting data that I'm not receiving. Depending on the codec, that might be very important header data. Naturally UDP is an unreliable transport mechanism and thus there are fallbacks if the occasional packet is lost, but there's a big difference between "some packets might be lost" and "an unknown number of initial packets *will* be lost". More work must be put into supporting the address-restricted case, and more deviation from the "mainstream" SIP/RTP best practices. Furthermore, just punching the holes themselves involve violating standards, hopefully in benign fashion. In the case of unidirectional RTP, there is nowhere in the standard that I as a listener should send to your RTP broadcast port -- thus there is no fully-compliant way to punch a hole to receive your data. (Yes I can send to your RTCP port, but that's a separate port.) The best I can do is send a malformed packet your way and hope it doesn't cause you harm. With full-cone NATs, I have no such problem. And finally, every hole I punch requires some maintenance. The less holes, the better. Generally, with full-cone, the number of holes I need punch is proportional to the number of services I wish to offer (and the same holes are used for all users). But with address-restricted, it's proportional to the product of the number of services, and the number of simultaneous users. This means I have a much higher overhead to working with address-restricted NATs. But more importantly, I have so many more things that can go wrong. This breeds the absolute worst kind of "partial failure" bug such as: - Why can I hear Bob, but not Alice? - Why can I hear Bob, but he can't hear me? - Why can I receive Bob's RTP, but not Bob's RTCP? - And so on... And if I walk across the room and pick a different wi-fi hub, thus changing IP addresses, with active sessions? Oye, it's a ton of work to re-establish all of these crazy holes and sessions in a bidirectional manner. A ton of work that I needn't do with full-cone NATs. So, to make a long story short, NAT traversal is a hard problem, and it's made especially hard by address-restricted NATs. If I could count on full-cone NAT behavior, my life as a programmer would be easier, and the applications I produce would function better, faster, and more reliably. In other words, I fully endorse Bryan's recommendation, and hope to see it included in the final draft. -david From sg266@cornell.edu Wed, 8 Jun 2005 11:05:51 -0700 (PDT) From: Saikat Guha Date: Wed, 8 Jun 2005 11:05:51 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: Message-ID: <1118253947.5511.25.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-06-08 at 11:02 -0400, Bryan Ford wrote: > The validity of your example as an argument for why "both are equally app > friendly" is already gone with your assumption that "S is a STUN-like server" > - i.e., that you _have_ this server S. Think about your assumptions about S > for this to work: S must either not be behind a NAT, or its NAT must have > EF=I filtering behavior.implement or S is behind any type of NAT with a static mapping set by the server administrator > EF=A nodes are only "second-class citizens" and have > no useful first-class Internet presence without the help of other EF=I nodes. As are EF=I NATs without the help of a non NAT'ed host. Consider a world with only EF=I NATs (no non NAT'ed host). Barring a port-scan, no connections can be established since the external port cannot be predicted (NATs are not port-preserving as per the draft). Nevertheless, IMHO, it is reasonable to assume a public STUN-like service in the long run because: 1. It is a common service for P2P apps (kind of like DNS if you will) 2. As part of the Internet infrastructure, STUN-servers can be given public addresses or be put behind NATs with static mappings > In short, I strongly disagree with your assessment that EF=A and EF=I are > equally "application-friendly." I suspect you are pointing out that applications currently assume EF=I and don't bother to support other kinds since it requires the application to implement the proxy (that C uses to inform A it wants to initiate STUN). Indeed it is more code; but once written a) the app works through more NATs, b) the app doesn't need to detect the type of NAT dynamically anymore, making it simpler. As for the public proxy services, many exist -- the SIP infrastructure, OpenDHT, IM networks even etc. So it's only a matter of app developers making the extra effort to use them. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00035.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00035.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3B6TjZuRmx0cWk2OTEvb1JBcGJPQUowVFpHOGJsbVlxenJxN3BlTE1y THg4SHpYQjZRQ2VQNnJnCmhvN0RBdnM0Z3JXK0dVN2JTNWhuVXJZPQo9NkhJMQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From yutaka_takeda@playstation.sony.com Wed, 8 Jun 2005 11:08:01 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Wed, 8 Jun 2005 11:08:01 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <20050530184255.21293.qmail@web40425.mail.yahoo.com> Message-ID: <42A733FB.7010108@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain >>If "the dual >>recommendation" is a matter, I am ok with something like "EF=APD is NOT >>RECOMMENDED" considering the issues mentioned in REQ-7 justification. > In my mind that is still a dual recommendation Not really. Let's consider the keywords ("MUST", "SHOULD", "MAY", etc.) as different strength of "constraints". Reading RFC 2119, I feel "RECOMMENDED", or "SHOULD", has very strong constraint, while an item not mentioned with the keyword has no constraint. An implementation that ignores an item that is recommended can be view as "not-fully-compliant". Probably this is why dual recommendation is perceived as a bit odd, because when one is chosen, the other recommended item is always ignored. > -------------------- > REQ-7: > It is RECOMMENDED that a NAT have an "Endpoint Address dependent > filtering" behavior. A NAT MAY support Endpoint Independent > Filtering, as an option configurable by the administrator. > -------------------- This will kill applications like Rodi. Choosing one way or the other is obviously a trade-off between security versus application transparency, which, I believe, should not be behave's matter. Can't we let the market decide it and let us focus on avoidance of non-deterministic behavior of NAT. I also would like to see as many fully behave-compliant NATs in the market, as soon as possible. - Yutaka Saikat Guha wrote: On Tue, 2005-06-07 at 11:36 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: I was thinking about something along the line of what Bryan mentioned earlier: http://list.sipfoundry.org/archive/ietf-behave/msg00673.html It would not be a bad idea to make use of EF=I behavior to promote a peer behind a NAT to be an globally accessible node, as a rely node for example, to increase scalability of a decentralized system. Interesting. Infact I just came across an example of this -- Rodi (in another thread). In fact, A must assume EF=APD anyways unless it says "MUST NOT be EF=APD". That is true. If "the dual recommendation" is a matter, I am ok with something like "EF=APD is NOT RECOMMENDED" considering the issues mentioned in REQ-7 justification. In my mind that is still a dual recommendation -- since vendors are equally encouraged to build EF=I and EF=A NATs. What do you think of: -------------------- REQ-7: It is RECOMMENDED that a NAT have an "Endpoint Address dependent filtering" behavior. A NAT MAY support Endpoint Independent Filtering, as an option configurable by the administrator. -------------------- From sg266@cornell.edu Thu, 9 Jun 2005 12:28:31 -0700 (PDT) From: Saikat Guha Date: Thu, 9 Jun 2005 12:28:31 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <200506081201.53635.baford@mit.edu> Message-ID: <1118345308.20932.47.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-06-08 at 09:01 -0700, Bryan Ford wrote: > -----Original Message----- > From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] Hi David, > So, to make a long story short, NAT traversal is a hard problem, and it's > made especially hard by address-restricted NATs. > If I could count on > full-cone NAT behavior, my life as a programmer would be easier Consider that NAT vendors have blatantly said that they _refuse_ to implement full cone; mainly because of the importance of security in Internet devices and market forces. IMHO, unless the draft absolutely forbids non-full cone behavior, vendors that value security (as a principle or as marketing hype) will continue to developing non-full cone NATs. Regardless of the recommendations, developers will need to support non-full cone behavior if they want to maximize connectivity; there are ways to do this without adding all the complexity you mentioned but thats a separate topic. The big difference between full and non-full cone, I find, is less and more security respectively and not in p2p connectivity or application support. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00036.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00036.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3FKaGNuRmx0cWk2OTEvb1JBZ01OQUo0b3BDdUZ6SVp3ZWF1eHVqM1dq UzJNSW9JRGZ3Q2VPTk16CnhWbHBJZno4SmxUd2R2MTJCV1dmK3pJPQo9anBmegotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From audet@nortel.com Thu, 9 Jun 2005 13:43:58 -0700 (PDT) From: "Francois Audet" Date: Thu, 9 Jun 2005 13:43:58 -0700 (PDT) Subject: RE: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behaviorrecomm endations for NATrelevant to P2P Message-ID: <1ECE0EB50388174790F9694F77522CCF02AF06B3@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behaviorrecommendations for NATrelevant to P2P Bingo. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Thursday, June 09, 2005 12:28 > To: dbarrett@xxxxxxxxxxxx > Cc: p2p-hackers@xxxxxxx; 'Behave' > Subject: Re: [Ietf-behave] Fwd: [p2p-hackers] Official IETF > behaviorrecommendations for NATrelevant to P2P > > > On Wed, 2005-06-08 at 09:01 -0700, Bryan Ford wrote: > > -----Original Message----- > > From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] > > Hi David, > > > So, to make a long story short, NAT traversal is a hard > problem, and > > it's made especially hard by address-restricted NATs. If I > could count > > on full-cone NAT behavior, my life as a programmer would be easier > > Consider that NAT vendors have blatantly said that they > _refuse_ to implement full cone; mainly because of the > importance of security in Internet devices and market forces. > IMHO, unless the draft absolutely forbids non-full cone > behavior, vendors that value security (as a principle or as > marketing hype) will continue to developing non-full cone > NATs. Regardless of the recommendations, developers will need > to support non-full cone behavior if they want to maximize > connectivity; there are ways to do this without adding all > the complexity you mentioned but thats a separate topic. The > big difference between full and non-full cone, I find, is > less and more security respectively and not in p2p > connectivity or application support. > > -- > Saikat > > > > > From dbarrett@quinthar.com Thu, 9 Jun 2005 14:50:35 -0700 (PDT) From: David Barrett Date: Thu, 9 Jun 2005 14:50:35 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <200506081201.53635.baford@mit.edu> Message-ID: <42A8B9A6.6020303@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Saikat Guha wrote: From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] So, to make a long story short, NAT traversal is a hard problem, and it's made especially hard by address-restricted NATs. If I could count on full-cone NAT behavior, my life as a programmer would be easier IMHO, unless the draft absolutely forbids non-full cone behavior, vendors that value security (as a principle or as marketing hype) will continue to developing non-full cone NATs. Unfortunately I agree, but this can be said about any of the NAT variables. Each has its own pros/cons, and the problem as a developer isn't dealing with misconfigured or broken NATs, it's dealing with the wide variety of differently-configured NATS. Reading through your IETF charter, I see: "Given the current near-universal deployment of NATs (Network Address Translators) in the public Internet, **the lack of standards for NAT behavior has given rise to a crisis**." [emphasis added] I'm not sure if this statement is referring to standards in terms of NAT *implementation* or NAT *deployment*, and there's a very big difference. If you are concerned with standardizing the implementation of NATs, but do nothing to standardize the deployment of NATs, you won't have done much to mitigate the current crisis. Indeed, it seems rather academic to completely define anything but the lowest-common denominator, because as a developer, that's all that matters. At the moment, the lowest common denominator is punching holes through address-restricted NATS, maintaining said holes with high-frequency keepalives, and avoiding fragmentation using very small MTUs. So long as you allow this configuration, I'm forced to develop towards it, and anything less restrictive or easier might as well not exist. Granted, I'd welcome a better definition of "high frequency keepalives" and "small MTUs". But I'd welcome even more an absence of address-restricted NATs. Personally, I believe NATs are not firewalls, and shouldn't be in the business of blocking traffic with the goal of enhancing security. Firewalls are much more capable in this respect, and have much less "collateral damage". But so long as NAT vendors are encouraged to market NATs as poor-man's firewalls (ie, so long as the IETF does nothing to counter this trend), I need to build with that in mind. -david From audet@nortel.com Thu, 9 Jun 2005 15:17:46 -0700 (PDT) From: "Francois Audet" Date: Thu, 9 Jun 2005 15:17:46 -0700 (PDT) Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Message-ID: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 All right guys, I'm back from Hawaii. Beats worrying about NATs... Anyways, do we have an agreement for this text below. This is what I can see as the best compromise, after reading the gazillions of postings on this. ----------------------------------------------------------------------- REQ-7: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address dependent filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. ----------------------------------------------------------------------- And can we please avoid huge threads on this topic. Please only express an opinion if you really have a problem with this text. We've beaten this to death, and then beaten it some more. Cullen? Bryan? From audet@nortel.com Thu, 9 Jun 2005 15:49:46 -0700 (PDT) From: "Francois Audet" Date: Thu, 9 Jun 2005 15:49:46 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 Message-ID: <1ECE0EB50388174790F9694F77522CCF02AF08A0@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 OK for the comment about s/Direction/Scope. I will make the fix. As for the comments on 6b, I'm not sure I share your concern. It just means that as long as the inside endpoint is using the port (regardless of how any endpoints are sending to it from the outside), it will remain opened. The "cleanup" of the sessions is only going to happened when the inside endpoint stops sending packets (to anywhere). But I don't really care either way. As for 6a, the idea was for unidirectional sessions (see Justification). I have no problem removing 6a however or making it NOT RECOMMENDED. Any comments from others? ---------------------------------------------- 6a- Opinions on 6a: i) Keep it as is ii) Remove it completely ii) Replace MAY by NOT RECOMMENDED 6b- Opinions on 6b: i) Keep as is ii) Remove it completely ---------------------------------------------- > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > Sent: Tuesday, June 07, 2005 10:21 > To: 'Behave' > Subject: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > I have some comments on REQ-6. > > REQ-6 The NAT mapping Refresh Direction MUST have a "NAT Outbound > refresh behavior" of "True". > a) The NAT mapping Refresh Direction MAY have a > "NAT Inbound > refresh behavior" of "True". > b) The NAT mapping Refresh Direction MUST have a > "NAT refresh > method behavior" of "Per mapping" (i.e. refresh all > sessions active on a particular mapping). > > There's a typo in 6b: "Refresh Direction" -> "Refresh Scope" > Somewhat I missed what 6b exactly meant when I read it > before, I assumed > that the definition of "mapping" for EF=A was a tuple of local IP > address, local port, protocol and destination IP (4-tuple). > > To me, requiring "per mapping" refresh for EF=A is problematic. Say, > there is a host behind a EF=A NAT communicating with many > remote hosts > from the same local port. If one or more sessions are always > active for > a long time, the number of destination IP addresses stored in > the memory > in the NAT for filtering will accumulate. When it hits the maximum > number of the destination address the NAT can remember, the > design must > need to consider overwriting the existing destination address > table but > there is no criteria for which one can be overwritten without a timer > per session. In another word, it cannot be assumed in NAT design that > communications would be made to limited number of destinations during > the lifetime of the mapping. So, I think 6b should be removed. > > From the security point of view, the sessions that are no > longer in use > should preferably be closed. Similarly, I feel 6a can be "NOT > RECOMMENDED" to prevent from an attacker maintain a session > that is no > longer in use by an application. > > > - Yutaka > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From yutaka_takeda@playstation.sony.com Thu, 9 Jun 2005 17:28:57 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Thu, 9 Jun 2005 17:28:57 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF08A0@zrc2hxm0.corp.nortel.com> Message-ID: <42A8DEC0.3090006@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain > The "cleanup" of the sessions is only going to happened > when the inside endpoint stops sending packets (to anywhere). This is the point I am concerned about. What if the inside endpoint does not stop sending to some remote hosts for a long time? Let me explain again with an example: Consider host S is behind EF=A/NB=I NAT, providing video streaming service, for example, from the same local port to *anyone*, like forever... Accumulative number of connections could be thousands or millions over time if instantaneous number of connections happens to be one or more whole time. Since the NAT is EF=A, it has to remember all the remote host's addresses for the endpoint filtering until the binding is destroyed. I do not believe that a NAT can store millions of addresses in memory practically. Then a design might be determined to have a limit like 256 addresses at maximum for a binding, but is 256 enough? It is hard tell. The MUST in 6b imposes above problem to implementors. 6b is sure attractive, but I cannot help anticipating that this may cause another non-dereministic behavior of NAT. Considering the essential reason to choose EF=A over EF=I, the sessions no longer in use should be closed. Actually, an application cannot assume that the NAT it is behind a behave compliant NAT, 6b is not so useful anyways.. - Yutaka Francois Audet wrote: OK for the comment about s/Direction/Scope. I will make the fix. As for the comments on 6b, I'm not sure I share your concern. It just means that as long as the inside endpoint is using the port (regardless of how any endpoints are sending to it from the outside), it will remain opened. The "cleanup" of the sessions is only going to happened when the inside endpoint stops sending packets (to anywhere). But I don't really care either way. As for 6a, the idea was for unidirectional sessions (see Justification). I have no problem removing 6a however or making it NOT RECOMMENDED. Any comments from others? ---------------------------------------------- 6a- Opinions on 6a: i) Keep it as is ii) Remove it completely ii) Replace MAY by NOT RECOMMENDED 6b- Opinions on 6b: i) Keep as is ii) Remove it completely ---------------------------------------------- > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > Sent: Tuesday, June 07, 2005 10:21 > To: 'Behave' > Subject: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > I have some comments on REQ-6. > > REQ-6 The NAT mapping Refresh Direction MUST have a "NAT Outbound > refresh behavior" of "True". > a) The NAT mapping Refresh Direction MAY have a > "NAT Inbound > refresh behavior" of "True". > b) The NAT mapping Refresh Direction MUST have a > "NAT refresh > method behavior" of "Per mapping" (i.e. refresh all > sessions active on a particular mapping). > > There's a typo in 6b: "Refresh Direction" -> "Refresh Scope" > Somewhat I missed what 6b exactly meant when I read it > before, I assumed > that the definition of "mapping" for EF=A was a tuple of local IP > address, local port, protocol and destination IP (4-tuple). > > To me, requiring "per mapping" refresh for EF=A is problematic. Say, > there is a host behind a EF=A NAT communicating with many > remote hosts > from the same local port. If one or more sessions are always > active for > a long time, the number of destination IP addresses stored in > the memory > in the NAT for filtering will accumulate. When it hits the maximum > number of the destination address the NAT can remember, the > design must > need to consider overwriting the existing destination address > table but > there is no criteria for which one can be overwritten without a timer > per session. In another word, it cannot be assumed in NAT design that > communications would be made to limited number of destinations during > the lifetime of the mapping. So, I think 6b should be removed. > > From the security point of view, the sessions that are no > longer in use > should preferably be closed. Similarly, I feel 6a can be "NOT > RECOMMENDED" to prevent from an attacker maintain a session > that is no > longer in use by an application. > > > - Yutaka > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortel.com Thu, 9 Jun 2005 17:47:59 -0700 (PDT) From: "Francois Audet" Date: Thu, 9 Jun 2005 17:47:59 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 Message-ID: <1ECE0EB50388174790F9694F77522CCF02B49BE1@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 I think you have a good point in favor of eliminating 6b. It does mean that applications will have to keep all sessions alive, but you may be right that it's the price to pay. Anybody objects to removing 6b in light of this? > -----Original Message----- > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] > Sent: Thursday, June 09, 2005 17:29 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > > > The "cleanup" of the sessions is only going to happened > > when the inside endpoint stops sending packets (to anywhere). > > This is the point I am concerned about. What if the inside > endpoint does > not stop sending to some remote hosts for a long time? > > Let me explain again with an example: > > Consider host S is behind EF=A/NB=I NAT, providing video streaming > service, for example, from the same local port to *anyone*, like > forever... Accumulative number of connections could be thousands or > millions over time if instantaneous number of connections > happens to be > one or more whole time. Since the NAT is EF=A, it has to remember all > the remote host's addresses for the endpoint filtering until > the binding > is destroyed. I do not believe that a NAT can store millions of > addresses in memory practically. Then a design might be determined to > have a limit like 256 addresses at maximum for a binding, but is 256 > enough? It is hard tell. > > The MUST in 6b imposes above problem to implementors. 6b is sure > attractive, but I cannot help anticipating that this may > cause another > non-dereministic behavior of NAT. Considering the essential reason to > choose EF=A over EF=I, the sessions no longer in use should > be closed. > Actually, an application cannot assume that the NAT it is behind a > behave compliant NAT, 6b is not so useful anyways.. > > - Yutaka > > > Francois Audet wrote: > > OK for the comment about s/Direction/Scope. I will make the fix. > > > > As for the comments on 6b, I'm not sure I share your > concern. It just > > means that as long as the inside endpoint is using the port > > (regardless of how any endpoints are sending to it from the > outside), > > it will remain opened. The "cleanup" of the sessions is > only going to > > happened when the inside endpoint > > stops sending packets (to anywhere). But I don't really > care either way. > > > > As for 6a, the idea was for unidirectional sessions (see > > Justification). I have no problem removing 6a however or > making it NOT > > RECOMMENDED. > > > > Any comments from others? > > > > ---------------------------------------------- > > 6a- Opinions on 6a: > > i) Keep it as is > > ii) Remove it completely > > ii) Replace MAY by NOT RECOMMENDED > > > > 6b- Opinions on 6b: > > i) Keep as is > > ii) Remove it completely > > ---------------------------------------------- > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > > > Sent: Tuesday, June 07, 2005 10:21 > > > To: 'Behave' > > > Subject: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > > > > > I have some comments on REQ-6. > > > > > > REQ-6 The NAT mapping Refresh Direction MUST have a > "NAT Outbound > > > refresh behavior" of "True". > > > a) The NAT mapping Refresh Direction MAY have a > > > "NAT Inbound > > > refresh behavior" of "True". > > > b) The NAT mapping Refresh Direction MUST have a > > > "NAT refresh > > > method behavior" of "Per mapping" (i.e. refresh all > > > sessions active on a particular mapping). > > > > > > There's a typo in 6b: "Refresh Direction" -> "Refresh Scope" > > > Somewhat I missed what 6b exactly meant when I read it > > > before, I assumed > > > that the definition of "mapping" for EF=A was a tuple of local IP > > > address, local port, protocol and destination IP (4-tuple). > > > > > > To me, requiring "per mapping" refresh for EF=A is > problematic. Say, > > > there is a host behind a EF=A NAT communicating with many > > > remote hosts > > > from the same local port. If one or more sessions are always > > > active for > > > a long time, the number of destination IP addresses stored in > > > the memory > > > in the NAT for filtering will accumulate. When it hits > the maximum > > > number of the destination address the NAT can remember, the > > > design must > > > need to consider overwriting the existing destination address > > > table but > > > there is no criteria for which one can be overwritten > without a timer > > > per session. In another word, it cannot be assumed in > NAT design that > > > communications would be made to limited number of > destinations during > > > the lifetime of the mapping. So, I think 6b should be removed. > > > > > > From the security point of view, the sessions that are no > > > longer in use > > > should preferably be closed. Similarly, I feel 6a can be "NOT > > > RECOMMENDED" to prevent from an attacker maintain a session > > > that is no > > > longer in use by an application. > > > > > > > > > - Yutaka > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > From sg266@cornell.edu Mon, 13 Jun 2005 08:24:38 -0700 (PDT) From: Saikat Guha Date: Mon, 13 Jun 2005 08:24:38 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02B49BE1@zrc2hxm0.corp.nortel.com> Message-ID: <1118676276.6005.0.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-06-09 at 20:47 -0400, Francois Audet wrote: > Anybody objects to removing 6b in light of this? Yes. I messed up. :-p I pointed Yutaka-san to the wrong requirement; the document addresses his concerns in section 5.2, not 4.3. 4.3 is fine as is. 5.2 needs changing in light of his concerns. (section 4.3) > NAT mapping timeout implementations vary but include the timer's > value and the way the mapping timer is refreshed to keep the mapping > alive. (section 5.2) > 5.2 NAT Filter Refresh > > The time for which a NAT filter is valid can be refreshed based on > packets that are inbound, outbound, or going either direction. As far as I understand, "mappings" for a NB=I NAT are determined based only on the internal source address and port. Even if a internal endpoint (X:x) sends packets to hundreds of destinations, the NAT has exactly _one_ mapping (X:x => X1:x1). The NAT "filter" however depends on both the internal and external endpoint. If the NAT is EF=A, and the host (X:x) connects to 100 external addresses (Yn:yn), then the NAT needs to remember 100 "filter" tuples of the form (X:x, Y1), (X:x, Y2), ... (X:x, Y100) so it can enforce the filtering policy. This filter state is different from the mapping state. It is this filtering state that Yutaka is concerned about: On Thu, 2005-06-09 at 17:28 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > Since the NAT is EF=A, it has to remember all > the remote host's addresses for the endpoint filtering Concerning this, UDP draft in its present form says in section 5.2 that: > In the case of "External Filtering" of "Address dependent" or "Address > and port dependent" NATs, the scope of the refresh could include the > filters for just the particular port and destination or for all the > ports and destinations sharing the same external address and port on > the NAT. I believe what Yutaka-san is suggesting is to add the recommendation: REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh Scope" behavior of "Per Session". In fact changing REQ-6b in section 4.3 to "per session" is a null operation. It has no effect because of the NB=I requirement. If you expire the "mapping" for an inactive session (X:x => X1:x1), then the NAT cannot reclaim the mapping as long as there are other sessions that are active that also use the (X:x => X1:x1) mapping. -- Saikat (who is stranded in LA) Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00037.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00037.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3JhVTBuRmx0cWk2OTEvb1JBbm55QUo5K2ZUSjA1Y1dIUHpnZlhKb2NJ YWNBR1VNckF3Q2ZUSDQrCnpSeVMzTzJVT1d3NXE5ZkhjQ0U0NURZPQo9ZHZzcQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Mon, 13 Jun 2005 08:26:19 -0700 (PDT) From: Saikat Guha Date: Mon, 13 Jun 2005 08:26:19 -0700 (PDT) Subject: [Ietf-behave] UDP draft review Message-ID: <1118676376.6005.1.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Bunch of comments on the UDP draft below. This is based on the draft current as of Thursday; so there may be some differences compared to the ID. ------------- (sec 4.1) > Address and Port Dependent Mapping: > The NAT reuses the port mapping for subsequent sessions > initiated from the same internal IP address and port (X:x) only > for sessions to the same external and port. Specifically, > X1':x1' equals X2':x2' if, and only if, Y2:y2 equals Y1:y1. #1. Ambiguity: What is meant by "subsequent sessions"? If you mean UDP packets with the same src and dst IP and port ... aren't they part of the same "session" as defined earlier? Do you mean "subsequent sessions" as in a UDP packet sent long after the last packet of a previous session. If you mean the former, may I suggest something along the lines of "the NAT does not reuse the port mapping" for different sessions. If you mean the latter, then this terminology does cannot adequately define existing behavior -- some existing NATs pick different mappings for X:x->Y:y at different times of the day based on mappings in use at the moment. -------- #2. Suggestion: In all these NB=x cases, perhaps an exception should be made to accommodate NATs that avoid port-collisions. Something along the lines of "unless that NAT mapping is already in use" should suffice. I am concerned about a NAT implementation that computes the mapping based on a deterministic function F(X,x) => X1':x1'. By definition this function has to be many-to-one. It satisfies the requirements for NB=I. But a correct implementation needs to ensure that X1':x1' isn't already allocated (to avoid port overloading); therefore fundamentally F cannot always be deterministic. When classifying NATs, we should explicitly allow for the tiny non-determinism required for port- collision/overloading-resolution; thats what my suggestion ties to capture. --------- (sec 4.2.1, sec 12) > REQ-3: IA NAT MUST NOT have a "Port assignment" behavior of "Port #3. Typo: IA -> A (both in section 4.2.1 and 12) --------- (sec 4.2.1) > However, it should be understood > that a NAT that when a port is randomly assigned, it may just > randomly happen to be assigned the same port. #4. Typo: "that a NAT that when"? --------- (section 4.2.2) > Some NATs preserve the parity of the UDP port, i.e., an even port > will be mapped to an even port, and an odd port will be mapped to an > odd port. This behavior respects the RFC 3550 [8] rule that RTP use > even ports, and RTCP use odd ports. Some NATs preserve the parity of > the UDP port, i.e., an even port will be mapped to an even port, and > an odd port will be mapped to an odd port. This behavior respects > the RFC 3550 rule that RTP use even ports and RTCP use odd ports when > the application takes a single port number as a parameter and derives > the RTP and RTCP port pair from that number. #5. Typo: The first two sentences are redundant. Or perhaps the last two. ------------- (section 4.3) > NAT mapping timeout implementations vary but include the timer's > value and the way the mapping timer is refreshed to keep the mapping > alive. #6. Suggestion In light of Yutaka's recent suggestion to require per-session filter scope (see other thread), should this timeout be increased? One mitigating circumstance is that this holds only for idle sessions. With the existing values, 120 clients on a RTP or VoIP server (with silence suppression) will govern a 1 packet per second overhead. Any estimates on the typical number of clients (tens, hundreds, thousands) and the acceptable overhead for such applications? -------------------- (section 5.2) #7. Suggestion Add REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh Scope" behavior of "Per Session". (see other thread for details) -------------------- (section 7) > a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow > the user to enable or disable each ALG separately. #8. Ambiguity There was some talk about defining "user". Perhaps it should be changed to "NAT administrator" here. -------------------- (section 8) > Any NAT that changes the NAT mapping or the External Filtering at any > point in time under any particular conditions is referred to as a > "non-deterministic" NAT. #9. Ambiguity ... unless it is response to a configuration change by the NAT administrator (REQ-7a) -------------------- (section 9) > a) The ICMP timeout SHOULD be greater than 2 seconds. #10. Ambuguity ICMP timeout has not been defined in this context. I don't even have a good guess as to what it could mean. If you mean that an ICMP received more than 2 seconds after the outgoing UDP packet that triggered the ICMP need not be translated, then I point out that the RFC recommended MSL is 2 minutes. In any case, such a timeout seems redundant since it doesn't affect security. If you mean timeout in the sense that no ICMP packets should be generated or translated within 2 seconds of an ICMP that is processed, then it prevents an one or more endpoint from doing parallel MTU discovery to different hosts. -------------------- Cheers. -- Saikat (Note to self: Next time when I get stranded for 8 hours, I must have some other reading material on me than just the UDP draft) Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00038.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00038.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3JhV1luRmx0cWk2OTEvb1JBcGNjQUp3TzhFQ0xmL3NGNzhub1piVGRZ S3BtWG9yUW5BQ2ZjbDRhCjdGN3lxdWx6YWhnTEgreHduMzZ0cTBrPQo9R2tSMQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From audet@nortel.com Mon, 13 Jun 2005 18:14:20 -0700 (PDT) From: "Francois Audet" Date: Mon, 13 Jun 2005 18:14:20 -0700 (PDT) Subject: [Ietf-behave] RE: UDP draft review Message-ID: <1ECE0EB50388174790F9694F77522CCF02BF4283@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: UDP draft review Thanks. Lots of good comments in there. See additional clarifications below. > -----Original Message----- > From: Saikat Guha [mailto:saikat@xxxxxxxxxxxxxx] > Sent: Monday, June 13, 2005 07:53 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: UDP draft review > > > Bunch of comments on the UDP draft below. This is based on > the draft current as of Thursday; so there may be some > differences compared to the ID. > > ------------- > > (sec 4.1) > > Address and Port Dependent Mapping: > > The NAT reuses the port mapping for subsequent sessions > > initiated from the same internal IP address and port > (X:x) only > > for sessions to the same external and port. Specifically, > > X1':x1' equals X2':x2' if, and only if, Y2:y2 equals Y1:y1. > > #1. Ambiguity: > What is meant by "subsequent sessions"? If you mean UDP > packets with the same src and dst IP and port ... aren't they > part of the same "session" as defined earlier? Do you mean > "subsequent sessions" as in a UDP packet sent long after the > last packet of a previous session. > > If you mean the former, may I suggest something along the > lines of "the NAT does not reuse the port mapping" for > different sessions. If you mean the latter, then this > terminology does cannot adequately define existing behavior > -- some existing NATs pick different mappings for X:x->Y:y at > different times of the day based on mappings in use at the moment. > I guess you are right that they wouldn't be "sessions". It should really say something like this: Endpoint Independent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to any external IP address and port. Specifically, X1':x1' equals X2':x2' for all values of Y2:y2. Address Dependent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address, regardless of the external port. Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals Y1. Address and Port Dependent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external and port. Specifically, X1':x1' equals X2':x2' if, and only if, Y2:y2 equals Y1:y1. > -------- > > #2. Suggestion: > In all these NB=x cases, perhaps an exception should be made > to accommodate NATs that avoid port-collisions. Something > along the lines of "unless that NAT mapping is already in > use" should suffice. I am concerned about a NAT > implementation that computes the mapping based on a > deterministic function F(X,x) => X1':x1'. By definition this > function has to be many-to-one. It satisfies the requirements > for NB=I. But a correct implementation needs to ensure that > X1':x1' isn't already allocated (to avoid port overloading); > therefore fundamentally F cannot always be deterministic. > When classifying NATs, we should explicitly allow for the > tiny non-determinism required for port- > collision/overloading-resolution; thats what my suggestion > ties to capture. Isn't this already covered at great length in section 4.2.1 on port overloading? > --------- > > (sec 4.2.1, sec 12) > > REQ-3: IA NAT MUST NOT have a "Port assignment" behavior of "Port > > #3. Typo: > IA -> A (both in section 4.2.1 and 12) OK. I will correct. > (sec 4.2.1) > > However, it should be understood > > that a NAT that when a port is randomly assigned, it may > just randomly > > happen to be assigned the same port. > > #4. Typo: > "that a NAT that when"? Yes, I will remove "a NAT that". > --------- > > (section 4.2.2) > > Some NATs preserve the parity of the UDP port, i.e., an > even port will > > be mapped to an even port, and an odd port will be mapped to an odd > > port. This behavior respects the RFC 3550 [8] rule that > RTP use even > > ports, and RTCP use odd ports. Some NATs preserve the > parity of the > > UDP port, i.e., an even port will be mapped to an even port, and an > > odd port will be mapped to an odd port. This behavior respects the > > RFC 3550 rule that RTP use even ports and RTCP use odd > ports when the > > application takes a single port number as a parameter and > derives the > > RTP and RTCP port pair from that number. > > #5. Typo: > The first two sentences are redundant. Or perhaps the last two. Yeah, the second pair will be deleted. > ------------- > > (section 4.3) > > NAT mapping timeout implementations vary but include the > timer's value > > and the way the mapping timer is refreshed to keep the > mapping alive. > > > #6. Suggestion > In light of Yutaka's recent suggestion to require per-session filter > scope (see other thread), should this timeout be increased? One > mitigating circumstance is that this holds only for idle > sessions. With > the existing values, 120 clients on a RTP or VoIP server (with silence > suppression) will govern a 1 packet per second overhead. Any estimates > on the typical number of clients (tens, hundreds, thousands) and the > acceptable overhead for such applications? Not sure about this. The values we put in there seemed to be acceptable to most people. > -------------------- > > (section 5.2) > > #7. Suggestion > Add > > REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh Scope" > behavior of "Per Session". > > (see other thread for details) > -------------------- > > (section 7) > > a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow > > the user to enable or disable each ALG separately. > > #8. Ambiguity > There was some talk about defining "user". Perhaps it should > be changed > to "NAT administrator" here. I agree. > -------------------- > > (section 8) > > Any NAT that changes the NAT mapping or the External > Filtering at any > > point in time under any particular conditions is referred to as a > > "non-deterministic" NAT. > > #9. Ambiguity > ... unless it is response to a configuration change by the NAT > administrator (REQ-7a) Yeah, it should say: Any NAT that changes the NAT mapping or the External Filtering without configuration changes, at any point in time under any particular conditions is referred to as a "non-deterministic" NAT. NATs that don't are called "deterministic". > -------------------- > > (section 9) > > a) The ICMP timeout SHOULD be greater than 2 seconds. > > #10. Ambuguity > ICMP timeout has not been defined in this context. I don't even have a > good guess as to what it could mean. If you mean that an ICMP received > more than 2 seconds after the outgoing UDP packet that triggered the > ICMP need not be translated, then I point out that the RFC recommended > MSL is 2 minutes. In any case, such a timeout seems redundant > since it > doesn't affect security. If you mean timeout in the sense > that no ICMP > packets should be generated or translated within 2 seconds of an ICMP > that is processed, then it prevents an one or more endpoint > from doing > parallel MTU discovery to different hosts. Cullen, can you clarify? I'm not sure what we meant here... > -------------------- > > Cheers. > > -- > Saikat > (Note to self: Next time when I get stranded for 8 hours, I must have > some other reading material on me than just the UDP draft) > > From audet@nortel.com Mon, 13 Jun 2005 18:20:41 -0700 (PDT) From: "Francois Audet" Date: Mon, 13 Jun 2005 18:20:41 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 Message-ID: <1ECE0EB50388174790F9694F77522CCF02BF4288@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 Yutaka, Would Saikat's proposal below for a new requirement address your concern? > -----Original Message----- > From: Saikat Guha [mailto:saikat@xxxxxxxxxxxxxx] > Sent: Monday, June 13, 2005 07:53 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'yutaka_takeda@xxxxxxxxxxxxxxxxxxxx'; 'Behave' > Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > On Thu, 2005-06-09 at 20:47 -0400, Francois Audet wrote: > > Anybody objects to removing 6b in light of this? > > Yes. I messed up. :-p I pointed Yutaka-san to the wrong > requirement; the document addresses his concerns in section > 5.2, not 4.3. 4.3 is fine as is. 5.2 needs changing in light > of his concerns. > > (section 4.3) > > NAT mapping timeout implementations vary but include the > timer's value > > and the way the mapping timer is refreshed to keep the > mapping alive. > > (section 5.2) > > 5.2 NAT Filter Refresh > > > > The time for which a NAT filter is valid can be refreshed based on > > packets that are inbound, outbound, or going either direction. > > As far as I understand, "mappings" for a NB=I NAT are > determined based only on the internal source address and > port. Even if a internal endpoint (X:x) sends packets to > hundreds of destinations, the NAT has exactly _one_ mapping > (X:x => X1:x1). > > The NAT "filter" however depends on both the internal and > external endpoint. If the NAT is EF=A, and the host (X:x) > connects to 100 external addresses (Yn:yn), then the NAT > needs to remember 100 "filter" tuples of the form (X:x, Y1), > (X:x, Y2), ... (X:x, Y100) so it can enforce the filtering > policy. This filter state is different from the mapping > state. It is this filtering state that Yutaka is concerned > about: > > On Thu, 2005-06-09 at 17:28 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > > Since the NAT is EF=A, it has to remember all > > the remote host's addresses for the endpoint filtering > > Concerning this, UDP draft in its present form says in > section 5.2 that: > > In the case of "External Filtering" of "Address dependent" > or "Address > > and port dependent" NATs, the scope of the refresh could > include the > > filters for just the particular port and destination or for all the > > ports and destinations sharing the same external address > and port on > > the NAT. > > I believe what Yutaka-san is suggesting is to add the recommendation: > > REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh > Scope" behavior of "Per Session". > > In fact changing REQ-6b in section 4.3 to "per session" is a > null operation. It has no effect because of the NB=I > requirement. If you expire the "mapping" for an inactive > session (X:x => X1:x1), then the NAT cannot reclaim the > mapping as long as there are other sessions that are active > that also use the (X:x => X1:x1) mapping. > > -- > Saikat > (who is stranded in LA) > From yutaka_takeda@playstation.sony.com Mon, 13 Jun 2005 20:07:32 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Mon, 13 Jun 2005 20:07:32 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02BF4288@zrc2hxm0.corp.nortel.com> Message-ID: <42AE49F1.5070901@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain Saikat caught my concerns correctly. > REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh > Scope" behavior of "Per Session". Do I agree with this... Not exactly, because of the definition of "session" in this document refers to RFC 2663, that says: "TCP/UDP sessions are uniquely identified by the tuple of (source IP address, source TCP/UDP port, target IP address, target TCP/UDP port)." As Saikat himself realizes, "Per session" means nothing to EF=I. Similarly, EF=AD only cares target IP addresses, not exactly a "session". The term "Per session" only makes sense if it is EF=APD. Specifically speaking, there are three possible scopes: (RS: Refresh scope) RS=Any: refresh is done by interaction with any remote hosts (equivalent to the current "Per mapping") RS=A : refresh is done by interaction with remote hosts at specific addresses) RS=AP : refresh is done by interaction with remote hosts at specific sets of address and port ("sessions") Now, we have following chart to discuss further: | RS=Any | RS=A | RS=AP | -------+--------+--------+--------+ EF=I |x or n/a| n/a | n/a | -------+--------+--------+--------+ EF=AD | Bad | x | n/a | -------+--------+--------+--------+ EF=APD | Bad | Bad | x | -------+--------+--------+--------+ In the combinations marked with "n/a", enforcing the refresh means nothing. The combinations with "Bad" are the cases that I am concerned about. The combinations with "x" are the most reasonable and natural behaviors to be implemented. Thought about introducing above new refresh scopes in 4.4 and recommending combinations with "x" with the details (why "Bad" is bad, etc) in 12.1, however, this might be overspecifying. Just removing 6b is fine by me. 4.4 and 5.2 need to be taken care of though... Any thoughts? Thanks, - Yutaka Francois Audet wrote: Yutaka, Would Saikat's proposal below for a new requirement address your concern? > -----Original Message----- > From: Saikat Guha [mailto:saikat@xxxxxxxxxxxxxx] > Sent: Monday, June 13, 2005 07:53 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'yutaka_takeda@xxxxxxxxxxxxxxxxxxxx'; 'Behave' > Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > On Thu, 2005-06-09 at 20:47 -0400, Francois Audet wrote: > > Anybody objects to removing 6b in light of this? > > Yes. I messed up. :-p I pointed Yutaka-san to the wrong > requirement; the document addresses his concerns in section > 5.2, not 4.3. 4.3 is fine as is. 5.2 needs changing in light > of his concerns. > > (section 4.3) > > NAT mapping timeout implementations vary but include the > timer's value > > and the way the mapping timer is refreshed to keep the > mapping alive. > > (section 5.2) > > 5.2 NAT Filter Refresh > > > > The time for which a NAT filter is valid can be refreshed based on > > packets that are inbound, outbound, or going either direction. > > As far as I understand, "mappings" for a NB=I NAT are > determined based only on the internal source address and > port. Even if a internal endpoint (X:x) sends packets to > hundreds of destinations, the NAT has exactly _one_ mapping > (X:x => X1:x1). > > The NAT "filter" however depends on both the internal and > external endpoint. If the NAT is EF=A, and the host (X:x) > connects to 100 external addresses (Yn:yn), then the NAT > needs to remember 100 "filter" tuples of the form (X:x, Y1), > (X:x, Y2), ... (X:x, Y100) so it can enforce the filtering > policy. This filter state is different from the mapping > state. It is this filtering state that Yutaka is concerned > about: > > On Thu, 2005-06-09 at 17:28 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > > Since the NAT is EF=A, it has to remember all > > the remote host's addresses for the endpoint filtering > > Concerning this, UDP draft in its present form says in > section 5.2 that: > > In the case of "External Filtering" of "Address dependent" > or "Address > > and port dependent" NATs, the scope of the refresh could > include the > > filters for just the particular port and destination or for all the > > ports and destinations sharing the same external address > and port on > > the NAT. > > I believe what Yutaka-san is suggesting is to add the recommendation: > > REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh > Scope" behavior of "Per Session". > > In fact changing REQ-6b in section 4.3 to "per session" is a > null operation. It has no effect because of the NB=I > requirement. If you expire the "mapping" for an inactive > session (X:x => X1:x1), then the NAT cannot reclaim the > mapping as long as there are other sessions that are active > that also use the (X:x => X1:x1) mapping. > > -- > Saikat > (who is stranded in LA) > From audet@nortel.com Tue, 14 Jun 2005 10:37:14 -0700 (PDT) From: "Francois Audet" Date: Tue, 14 Jun 2005 10:37:14 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 Message-ID: <1ECE0EB50388174790F9694F77522CCF02C5A9E8@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 This whole thing is confusing because what we mean is "Endpoint session" as opposed to "NAT session". Backing off a little, perhaps we should just not talk about the "Refresh scope" at all. It seems to me that people are doubting the usefulness of having a "Refresh scope" that is different from the Mapping. We could simply delete 4.4 (and 6b) altogether. And also, we could remove the last phrase of 5.2 (after the comma) on the scope of the refresh. The consequence would be that Applications would need one refresh per "endpoint session" all the time. It would be something for the application document. The rationale is that we need to implement this for support Address and Port Dependent Filtering. So, here is the question: Do people agree with deleting 4.4, Requirement 6b, and the last phrase of 5.2 (everything after the comma). > -----Original Message----- > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] > Sent: Monday, June 13, 2005 20:07 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Saikat Guha'; 'Behave' > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > Saikat caught my concerns correctly. > > > REQ-x: It is RECOMMENDED that a NAT have "NAT filter > Refresh > Scope" behavior of "Per Session". > > Do I agree with this... Not exactly, because of the definition of > "session" in this document refers to RFC 2663, that says: > > "TCP/UDP sessions are uniquely identified by the tuple of (source IP > address, source TCP/UDP port, target IP address, target > TCP/UDP port)." > > As Saikat himself realizes, "Per session" means nothing to EF=I. > Similarly, EF=AD only cares target IP addresses, not exactly a > "session". The term "Per session" only makes sense if it is EF=APD. > > Specifically speaking, there are three possible scopes: > (RS: Refresh scope) > > RS=Any: refresh is done by interaction with any remote > hosts (equivalent to the current "Per mapping") > RS=A : refresh is done by interaction with remote hosts > at specific addresses) > RS=AP : refresh is done by interaction with remote hosts > at specific sets of address and port ("sessions") > > Now, we have following chart to discuss further: > > | RS=Any | RS=A | RS=AP | > -------+--------+--------+--------+ > EF=I |x or n/a| n/a | n/a | > -------+--------+--------+--------+ > EF=AD | Bad | x | n/a | > -------+--------+--------+--------+ > EF=APD | Bad | Bad | x | > -------+--------+--------+--------+ > > In the combinations marked with "n/a", enforcing the refresh means > nothing. The combinations with "Bad" are the cases that I am > concerned > about. The combinations with "x" are the most reasonable and natural > behaviors to be implemented. > > Thought about introducing above new refresh scopes in 4.4 and > recommending combinations with "x" with the details (why > "Bad" is bad, > etc) in 12.1, however, this might be overspecifying. Just > removing 6b is > fine by me. 4.4 and 5.2 need to be taken care of though... > Any thoughts? > > > Thanks, > - Yutaka > > > > Francois Audet wrote: > > Yutaka, > > > > Would Saikat's proposal below for a new requirement address your > > concern? > > > > > -----Original Message----- > > > From: Saikat Guha [mailto:saikat@xxxxxxxxxxxxxx] > > > Sent: Monday, June 13, 2005 07:53 > > > To: Audet, Francois [SC100:9T51:EXCH] > > > Cc: 'yutaka_takeda@xxxxxxxxxxxxxxxxxxxx'; 'Behave' > > > Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > > > > > On Thu, 2005-06-09 at 20:47 -0400, Francois Audet wrote: > > > > Anybody objects to removing 6b in light of this? > > > > > > Yes. I messed up. :-p I pointed Yutaka-san to the wrong > > > requirement; the document addresses his concerns in section > > > 5.2, not 4.3. 4.3 is fine as is. 5.2 needs changing in light > > > of his concerns. > > > > > > (section 4.3) > > > > NAT mapping timeout implementations vary but include the > > > timer's value > > > > and the way the mapping timer is refreshed to keep the > > > mapping alive. > > > > > > (section 5.2) > > > > 5.2 NAT Filter Refresh > > > > > > > > The time for which a NAT filter is valid can be > refreshed based on > > > > packets that are inbound, outbound, or going either > direction. > > > > > > As far as I understand, "mappings" for a NB=I NAT are > > > determined based only on the internal source address and > > > port. Even if a internal endpoint (X:x) sends packets to > > > hundreds of destinations, the NAT has exactly _one_ mapping > > > (X:x => X1:x1). > > > > > > The NAT "filter" however depends on both the internal and > > > external endpoint. If the NAT is EF=A, and the host (X:x) > > > connects to 100 external addresses (Yn:yn), then the NAT > > > needs to remember 100 "filter" tuples of the form (X:x, Y1), > > > (X:x, Y2), ... (X:x, Y100) so it can enforce the filtering > > > policy. This filter state is different from the mapping > > > state. It is this filtering state that Yutaka is concerned > > > about: > > > > > > On Thu, 2005-06-09 at 17:28 -0700, > yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > > > > Since the NAT is EF=A, it has to remember all > > > > the remote host's addresses for the endpoint filtering > > > > > > Concerning this, UDP draft in its present form says in > > > section 5.2 that: > > > > In the case of "External Filtering" of "Address dependent" > > > or "Address > > > > and port dependent" NATs, the scope of the refresh could > > > include the > > > > filters for just the particular port and destination > or for all the > > > > ports and destinations sharing the same external address > > > and port on > > > > the NAT. > > > > > > I believe what Yutaka-san is suggesting is to add the > recommendation: > > > > > > REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh > > > Scope" behavior of "Per Session". > > > > > > In fact changing REQ-6b in section 4.3 to "per session" is a > > > null operation. It has no effect because of the NB=I > > > requirement. If you expire the "mapping" for an inactive > > > session (X:x => X1:x1), then the NAT cannot reclaim the > > > mapping as long as there are other sessions that are active > > > that also use the (X:x => X1:x1) mapping. > > > > > > -- > > > Saikat > > > (who is stranded in LA) > > > > > > > From sg266@cornell.edu Tue, 14 Jun 2005 12:30:26 -0700 (PDT) From: Saikat Guha Date: Tue, 14 Jun 2005 12:30:26 -0700 (PDT) Subject: Re: [Ietf-behave] RE: UDP draft review In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02BF4283@zrc2hxm0.corp.nortel.com> Message-ID: <1118777423.5099.43.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-06-13 at 21:13 -0400, Francois Audet wrote: > > #2. Suggestion: > > "unless that NAT mapping is already in > > use" > > Isn't this already covered at great length in section 4.2.1 on > port overloading? It is, but in the changes you proposed "subsequent packets" is not defined to exclude packets send after a mapping expires ... which are still 'subsequent packets' as far as the English language is concerned but need not be allocated the old mapping for the NAT to be classified such. > > #6. Suggestion > > In light of Yutaka's recent suggestion to require per-session > > filter > > scope (see other thread), should this timeout be increased? > Not sure about this. The values we put in there seemed to be > acceptable to most people. When it was discussed before, was it under the assumption that all endpoint-sessions would need a keep-alive (NAT filter refresh scope of per session or equivalent) or just one keep-alive would refresh all endpoint-sessions (scope of per-mapping). If it was the first case, then my question is merely for clarification; if not, then the keep-alive traffic is now significantly more than when it was last discussed. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00039.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00039.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3J6QlBuRmx0cWk2OTEvb1JBa2oxQUo5MnBRbG95Y0JTMnRBeVdOVCtt VU4wcyt4YlZRQ2ZVOHU5CnoxcXFjRnY2YWEzNUlwa21VWUMwSUdVPQo9NVRIMAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From audet@nortel.com Tue, 14 Jun 2005 17:13:18 -0700 (PDT) From: "Francois Audet" Date: Tue, 14 Jun 2005 17:13:18 -0700 (PDT) Subject: RE: [Ietf-behave] RE: UDP draft review Message-ID: <1ECE0EB50388174790F9694F77522CCF02C5B143@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] RE: UDP draft review > On Mon, 2005-06-13 at 21:13 -0400, Francois Audet wrote: > > > #2. Suggestion: > > > "unless that NAT mapping is already in > > > use" > > > > Isn't this already covered at great length in section 4.2.1 on > > port overloading? > > It is, but in the changes you proposed "subsequent packets" > is not defined to exclude packets send after a mapping > expires ... which are still 'subsequent packets' as far as > the English language is concerned but need not be allocated > the old mapping for the NAT to be classified such. OK. I'll clarify. > > > #6. Suggestion > > > In light of Yutaka's recent suggestion to require per-session > > > filter > > > scope (see other thread), should this timeout be increased? > > > Not sure about this. The values we put in there seemed to be > > acceptable to most people. > > When it was discussed before, was it under the assumption > that all endpoint-sessions would need a keep-alive (NAT > filter refresh scope of per session or equivalent) or just > one keep-alive would refresh all endpoint-sessions (scope of > per-mapping). If it was the first case, then my question is > merely for clarification; if not, then the keep-alive traffic > is now significantly more than when it was last discussed. Yes. It we now expect multiple keep-alives, then indeed the traffic is increased (which is why the draft tried to avoid the need for multiple keep-alives). From srisuresh@yahoo.com Thu, 16 Jun 2005 09:39:27 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 16 Jun 2005 09:39:27 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 In-Reply-To: <1118676276.6005.0.camel@localhost.localdomain> Message-ID: <20050616163927.82798.qmail@web40428.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Sorry, I am a bit late on this thread. Just catching up after a long hiatus. I havent necessarily read all the e-mails on this thread. Just a cautionary note :-) My comments below inline. cheers, suresh --- Saikat Guha wrote: <... stuff deleted> > > 5.2 NAT Filter Refresh > > > > The time for which a NAT filter is valid can be refreshed based on > > packets that are inbound, outbound, or going either direction. > > As far as I understand, "mappings" for a NB=I NAT are determined based > only on the internal source address and port. Even if a internal endpoint > (X:x) > sends packets to hundreds of destinations, the NAT has exactly _one_ > mapping (X:x => X1:x1). > > The NAT "filter" however depends on both the internal and external > endpoint. If the NAT is EF=A, and the host (X:x) connects to 100 > external addresses (Yn:yn), then the NAT needs to remember 100 "filter" > tuples of the form (X:x, Y1), (X:x, Y2), ... (X:x, Y100) so > it can enforce the filtering policy. This filter state is different from > the mapping state. It is this filtering state that Yutaka is concerned > about: > [suresh] Right. The difference between EF=A and EF=I is that the number of NAT sessions. The term "NAT Session" is explained in ford-behave-gen-01 draft, section 2.3. Essentially, as Saikat explains above, The EF=A case results in 100 NAT Sessions, whereas the EF=I case results in a a single NAT Session. > On Thu, 2005-06-09 at 17:28 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > > Since the NAT is EF=A, it has to remember all > > the remote host's addresses for the endpoint filtering > [suresh] Right. > Concerning this, UDP draft in its present form says in section 5.2 that: > > In the case of "External Filtering" of "Address dependent" or "Address > > and port dependent" NATs, the scope of the refresh could include the > > filters for just the particular port and destination or for all the > > ports and destinations sharing the same external address and port on > > the NAT. > > I believe what Yutaka-san is suggesting is to add the recommendation: > > REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh Scope" > behavior of "Per Session". > [suresh] I suggest rewording this as below using the terminology of "NAT Sessions". I suspect, this is what Yutaka intended as well. I might also add this is a fairly basic aspect of how NATs operate, as described in section 2 of the ford-behave-gen-01 draft. Lastly, the requirement is transport independent and pertains to both the TCP and UDP NAT Sessions. REQ-x: It is RECOMMENDED that a NAT device monitor the idle-time on all NAT Sessions. > In fact changing REQ-6b in section 4.3 to "per session" is a null > operation. It has no effect because of the NB=I requirement. If you > expire the "mapping" for an inactive session (X:x => X1:x1), then the > NAT cannot reclaim the mapping as long as there are other sessions that > are active that also use the (X:x => X1:x1) mapping. > [suresh] yes. cheers, suresh > -- > Saikat > (who is stranded in LA) > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Thu, 16 Jun 2005 10:12:13 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 16 Jun 2005 10:12:13 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 In-Reply-To: <42AE49F1.5070901@playstation.sony.com> Message-ID: <20050616171213.24532.qmail@web40422.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Yutaka, I agree with your comment about the semantics of the term "Session" being inconsistent with RFC 2663. I believe, the term "NAT Session" is the appropriate term to use here. Also, I believe, the following req captures what you say. REQ-x: It is RECOMMENDED that a NAT device monitor the idle-time on all NAT Sessions. my comments inline. cheers, suresh --- yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: > Saikat caught my concerns correctly. > > > REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh > > Scope" behavior of "Per Session". > > Do I agree with this... Not exactly, because of the definition of > "session" in this document refers to RFC 2663, that says: > > "TCP/UDP sessions are uniquely identified by the tuple of (source IP > address, source TCP/UDP port, target IP address, target TCP/UDP port)." > [suresh] Right. I believe, the intended term here is "NAT Session". > As Saikat himself realizes, "Per session" means nothing to EF=I. > Similarly, EF=AD only cares target IP addresses, not exactly a > "session". The term "Per session" only makes sense if it is EF=APD. > [suresh] Right. The NAT Session parameters differ between EF=A and EF=I in the way the NAT Session uses wild card for external UDP-port vs External IP Address & External UDP-Port. A NAT Session can be as fine grained as a NAT device chooses (EF=AP, EF=A or EF=I). When it comes to idletime monitoring, a NAt device does this on a NAT Session basis. All UDP packets that match a NAT Session will reset the idletime of the NAT Sesson. I.e., refresh the liveness of the NAT Session. > Specifically speaking, there are three possible scopes: > (RS: Refresh scope) > > RS=Any: refresh is done by interaction with any remote > hosts (equivalent to the current "Per mapping") > RS=A : refresh is done by interaction with remote hosts > at specific addresses) > RS=AP : refresh is done by interaction with remote hosts > at specific sets of address and port ("sessions") > > Now, we have following chart to discuss further: > > | RS=Any | RS=A | RS=AP | > -------+--------+--------+--------+ > EF=I |x or n/a| n/a | n/a | > -------+--------+--------+--------+ > EF=AD | Bad | x | n/a | > -------+--------+--------+--------+ > EF=APD | Bad | Bad | x | > -------+--------+--------+--------+ > > In the combinations marked with "n/a", enforcing the refresh means > nothing. The combinations with "Bad" are the cases that I am concerned > about. The combinations with "x" are the most reasonable and natural > behaviors to be implemented. > [suresh] Right. It Seems, the refresh scope loosely refers to idletime monitoring of a NAT Session. cheers, suresh > Thought about introducing above new refresh scopes in 4.4 and > recommending combinations with "x" with the details (why "Bad" is bad, > etc) in 12.1, however, this might be overspecifying. Just removing 6b is > fine by me. 4.4 and 5.2 need to be taken care of though... Any thoughts? > > > Thanks, > - Yutaka > > > > Francois Audet wrote: > > Yutaka, > > > > Would Saikat's proposal below for a new requirement address your concern? > > > > > -----Original Message----- > > > From: Saikat Guha [mailto:saikat@xxxxxxxxxxxxxx] > > > Sent: Monday, June 13, 2005 07:53 > > > To: Audet, Francois [SC100:9T51:EXCH] > > > Cc: 'yutaka_takeda@xxxxxxxxxxxxxxxxxxxx'; 'Behave' > > > Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > > > > > > > On Thu, 2005-06-09 at 20:47 -0400, Francois Audet wrote: > > > > Anybody objects to removing 6b in light of this? > > > > > > Yes. I messed up. :-p I pointed Yutaka-san to the wrong > > > requirement; the document addresses his concerns in section > > > 5.2, not 4.3. 4.3 is fine as is. 5.2 needs changing in light > > > of his concerns. > > > > > > (section 4.3) > > > > NAT mapping timeout implementations vary but include the > > > timer's value > > > > and the way the mapping timer is refreshed to keep the > > > mapping alive. > > > > > > (section 5.2) > > > > 5.2 NAT Filter Refresh > > > > > > > > The time for which a NAT filter is valid can be refreshed based on > > > > packets that are inbound, outbound, or going either direction. > > > > > > As far as I understand, "mappings" for a NB=I NAT are > > > determined based only on the internal source address and > > > port. Even if a internal endpoint (X:x) sends packets to > > > hundreds of destinations, the NAT has exactly _one_ mapping > > > (X:x => X1:x1). > > > > > > The NAT "filter" however depends on both the internal and > > > external endpoint. If the NAT is EF=A, and the host (X:x) > > > connects to 100 external addresses (Yn:yn), then the NAT > > > needs to remember 100 "filter" tuples of the form (X:x, Y1), > > > (X:x, Y2), ... (X:x, Y100) so it can enforce the filtering > > > policy. This filter state is different from the mapping > > > state. It is this filtering state that Yutaka is concerned > > > about: > > > > > > On Thu, 2005-06-09 at 17:28 -0700, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > > > > Since the NAT is EF=A, it has to remember all > > > > the remote host's addresses for the endpoint filtering > > > > > > Concerning this, UDP draft in its present form says in > > > section 5.2 that: > > > > In the case of "External Filtering" of "Address dependent" > > > or "Address > > > > and port dependent" NATs, the scope of the refresh could > > > include the > > > > filters for just the particular port and destination or for all the > > > > ports and destinations sharing the same external address > > > and port on > > > > the NAT. > > > > > > I believe what Yutaka-san is suggesting is to add the recommendation: > > > > > > REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh > > > Scope" behavior of "Per Session". > > > > > > In fact changing REQ-6b in section 4.3 to "per session" is a > > > null operation. It has no effect because of the NB=I > > > requirement. If you expire the "mapping" for an inactive > > > session (X:x => X1:x1), then the NAT cannot reclaim the > > > mapping as long as there are other sessions that are active > > > that also use the (X:x => X1:x1) mapping. > > > > > > -- > > > Saikat > > > (who is stranded in LA) > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Fri, 17 Jun 2005 09:42:31 -0700 (PDT) From: Cullen Jennings Date: Fri, 17 Jun 2005 09:42:31 -0700 (PDT) Subject: [Ietf-behave] FW: Approval to Post Version -00 Internet-Drafts for the 63rd IETF Meeting in Paris, France In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain If we are going to have a WG version of TCP by Paris, we need to sort out how we are doing that before July 5th. Similarly if anyone else wants to submit 00 WG documents before Paris, please talk to Jiri and I soon. Cullen ------ Forwarded Message From: Internet-Drafts Administrator Date: Fri, 17 Jun 2005 00:00:02 -0400 To: Working Group Chairs Subject: Approval to Post Version -00 Internet-Drafts for the 63rd IETF Meeting in Paris, France Dear IETF Working Group Chairs: In order to expedite the processing of the many version -00 I-Ds that the Secretariat receives before an IETF meeting, we ask that you please notify the Secretariat prior to the initial submission cutoff date of all version -00 I-Ds that you expect to approve for posting as WG documents. Please send the filenames of your approved -00 I-Ds to internet-drafts@xxxxxxxxx We would appreciate receiving your list of approved drafts four (4) business days prior to the cutoff date for -00 submissions, or by Tuesday, July 5th at 9:00 AM ET for the 63rd IETF Meeting. Please include the word "Approved I-Ds" in the "Subject" field. This procedure will help to ensure that version -00 I-Ds are posted in a timely manner, allowing more time for review by the public. Thank you for your cooperation in this matter. The Internet-Drafts Administrator FYI: The Internet-Draft cutoff dates as well as other significant dates for the 63rd IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_63.html. ------ End of Forwarded Message From petithug@acm.org Sun, 19 Jun 2005 00:38:04 -0700 (PDT) From: Marc Petit-Huguenin Date: Sun, 19 Jun 2005 00:38:04 -0700 (PDT) Subject: [Ietf-behave] Username in rfc3489bis Message-ID: <42B520C6.10906@acm.org> MIME-Version: 1.0 Content-Type: text/plain Section 8.2 in rfc3489bis-01: "...rounded-time is the current time modulo 20 minutes..." I think it should be "...rounded-time is the result of the integer division of the current time by 20 minutes..." -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx From srisuresh@yahoo.com Sun, 19 Jun 2005 15:04:46 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 19 Jun 2005 15:04:46 -0700 (PDT) Subject: Re: [Ietf-behave] P2P Filesharing over UDP In-Reply-To: <1118183998.7074.68.camel@localhost.localdomain> Message-ID: <20050619220446.64115.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > Hi, > > FYI, I ran into an interesting (and disturbing) P2P filesharing app > (Rodi) that seems to use UDP and traverses NATs. > http://larytet.sourceforge.net/btRat.shtml > [suresh] This sounds interesting. I will give this a read. > It has an interesting approach to UDP NAT Hole-punching that doesn't use > a _public_ STUN-like server per say. > > The first Rodi client opens a UDP hole in the NAT. It does so by > initiating a UDP port-scan to some destination from a fixed local port. > It waits for one response packet. (at present finding the response > packet is manual; but can easily be automated). To keep the UDP hole > open, it keeps sending UDP packets at a low rate to the remote port that > responded. > > Subsequent Rodi clients perform a port scan on a remote address as > before. If the address is a NAT'ed Rodi client (that has already > performed step 1 above), then one of the port-scan packets make it > through to the other end. This is assuming the NAT is Full Cone for UDP. [suresh] I am not sure, I understand you correctly in your above comment about assuming Full-Cone NAT. Is the following what you meant? It seems, if the rodi clients (i.e., file-xfering subscrbers) are all behind NAT device, then the NAT device just needs to be an Address restricted Cone NAT. However, if the destination address (i..e, file-providing publishers) happen to be behind a NAT, then the algorithm would only work if the NAT were a full cone NAT. Right? > The other end replies back with the external IP:port mapping, just as > STUN would. > > Basically, the approach trades off a public STUN server in exchange for > a port-scan and full-cone support. > [suresh] Right. If I understood what you said correctly, You dont need an external public server to get a list of file sharers behind NAT devices, when the NAT devices exhibit full-Cone NAT behavior. > As a side note, its main mandate is to transfer files while being > indistinguishable from other traffic (Rodi packets can be made to look > like DNS, RTP etc). The default transport protocol of choice is UDP. :-/ > It seems to implement its own "Rate Limiter (RL)" to provide congestion > control, but I can't seem to find how the RL works or how TCP-friendly > it is. > > Just an FYI. > [suresh] Cool. This seems to add yet another voice to full-Cone NAT deployment in providing flexibility from a P2P application vantage. I.e., this is also pointing to bi-directional NAT behavior beng preferable to traditional NAT behavior from a P2P application vantage. cheers, suresh > -- > Saikat > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Sun, 19 Jun 2005 15:35:31 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 19 Jun 2005 15:35:31 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <42A8B9A6.6020303@quinthar.com> Message-ID: <20050619223531.21432.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain My apologies for being a bit late on this thread. First off, much thanks to David for taking the time and sharing his thoughts with the list. We could do with more people like you, David, to give us real feedback from an applicaion developers' perspective. I would really appreciate your continued feedback and involvement on this list. Thanks again. Please see my comments inline below. cheers, suresh --- David Barrett wrote: > Saikat Guha wrote: > >>From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] > >>So, to make a long story short, NAT traversal is a hard problem, and it's > >>made especially hard by address-restricted NATs. > >>If I could count on > >>full-cone NAT behavior, my life as a programmer would be easier > > > > IMHO, unless the draft absolutely > > forbids non-full cone behavior, vendors that value security (as a > > principle or as marketing hype) will continue to developing non-full > > cone NATs. > > Unfortunately I agree, but this can be said about any of the NAT > variables. Each has its own pros/cons, and the problem as a developer > isn't dealing with misconfigured or broken NATs, it's dealing with the > wide variety of differently-configured NATS. Reading through your IETF > charter, I see: > > "Given the current near-universal deployment of NATs (Network Address > Translators) in the public Internet, **the lack of standards for NAT > behavior has given rise to a crisis**." > > [emphasis added] > > I'm not sure if this statement is referring to standards in terms of NAT > *implementation* or NAT *deployment*, and there's a very big difference. > [suresh] Indeed. > If you are concerned with standardizing the implementation of NATs, but > do nothing to standardize the deployment of NATs, you won't have done > much to mitigate the current crisis. Indeed, it seems rather academic > to completely define anything but the lowest-common denominator, because > as a developer, that's all that matters. > > At the moment, the lowest common denominator is punching holes through > address-restricted NATS, maintaining said holes with high-frequency > keepalives, and avoiding fragmentation using very small MTUs. > > So long as you allow this configuration, I'm forced to develop towards > it, and anything less restrictive or easier might as well not exist. > [suresh] I agree with all your comments. Ideally, if the demand for initial deployment was simply bi-diectional NATs, P2P application deployment would have been a cake walk by now. Bi-Directional NATs would make the port bindings Bi-diectional and would exhibit Full Cone NAT behavior for both TCP & UDP applications. Unfortunately, the predominant use-case of NATs during early deployment was client-server apps and people were concerned mainly about hosts running the client apps from behind NAT. P2P apps were not as prevalent. Security was a big concern. So, given the history and mindset of the NAT vendors from the past, I am sure you understand the reason behind the hesitation on this list. However, I agree with both you and Bryan and believe that we should recommend deploying bi-directional NATs going forward. I believe, the phenomenon of this being UDP specific is also just the current mindset. I can foresee the same discussion coming up one more time when TCP based apps become more prevalent. Bi-directionality requirement is not a UDP only rquirement for P2P apps. The issue of security with Traditional NATs (which includes NAPT) is one of illusion and can be really shattered only when app developers (both client-server and P2P application developers) come forward and indicate that their apps work just as well behind a bi-directioanl NAT as behind a Traditional NAT. So long as there are applications that depend upon Address restricted Cone NAT behavior, it gives the NAT vendors an opportunity to say things like, my NAT (a traditional NAT) can provide better DOS protection than the competetion's (which may be Bi-Directional NAT). > Granted, I'd welcome a better definition of "high frequency keepalives" > and "small MTUs". But I'd welcome even more an absence of > address-restricted NATs. > > Personally, I believe NATs are not firewalls, and shouldn't be in the > business of blocking traffic with the goal of enhancing security. > Firewalls are much more capable in this respect, and have much less > "collateral damage". > > But so long as NAT vendors are encouraged to market NATs as poor-man's > firewalls (ie, so long as the IETF does nothing to counter this trend), > I need to build with that in mind. > [suresh] I agree NATs are not firewalls. The blocking provided by the Iraditional NATs was adequate for a number of deployments. I donot have a problem with that. cheers, suresh > -david > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From dbarrett@quinthar.com Sun, 19 Jun 2005 16:42:37 -0700 (PDT) From: David Barrett Date: Sun, 19 Jun 2005 16:42:37 -0700 (PDT) Subject: Re: [Ietf-behave] P2P Filesharing over UDP In-Reply-To: <20050619220446.64115.qmail@web40427.mail.yahoo.com> Message-ID: <42B602EB.2000806@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Pyda Srisuresh wrote: --- Saikat Guha wrote: Subsequent Rodi clients perform a port scan on a remote address as before. If the address is a NAT'ed Rodi client (that has already performed step 1 above), then one of the port-scan packets make it through to the other end. This is assuming the NAT is Full Cone for UDP. Just curious, how "broad" is this port scan? Does it do a total portscan (ie, of the complete range of possible UDP ports), or pick a subset that it somehow knows will work? It'd seem that firewalls and routers would quickly identify this type of traffic as malicious, and then block the scan from completing. Does Rodi do anything to somehow evade being flagged and blocked as such (maybe random delays or non-sequential scanning)? Regardless, thanks for the great Rodi overview. I agree this is further evidence that full-cone is the most P2P friendly, address-restricted less so, and symmetric even less than that. The closer we can get to a total full-cone world (or even just a non-symmetric world), the better. -david From dbarrett@quinthar.com Sun, 19 Jun 2005 17:08:00 -0700 (PDT) From: David Barrett Date: Sun, 19 Jun 2005 17:08:00 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <20050619223531.21432.qmail@web40426.mail.yahoo.com> Message-ID: <42B608D5.4090606@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Pyda Srisuresh wrote: First off, much thanks to David for taking the time and sharing his thoughts with the list. We could do with more people like you, David, to give us real feedback from an applicaion developers' perspective. I would really appreciate your continued feedback and involvement on this list. Thanks again. Ah, you're entirely welcome. I'm glad the IETF-BEHAVE group is working on this topic. And I think I was being snippy last time I wrote and suggested anything less than a total full-cone world was meaningless. This is anything but the case. Granted, as a P2P developer, a standardized full-cone Internet with fixed keepalives and so forth would be the ideal. But there's a big range between where we are today and that ideal, and any progress along this road is most welcome. Unfortunately, the predominant use-case of NATs during early deployment was client-server apps and people were concerned mainly about hosts running the client apps from behind NAT. P2P apps were not as prevalent. Security was a big concern. So, given the history and mindset of the NAT vendors from the past, I am sure you understand the reason behind the hesitation on this list. Yes, I accept entirely the historical reasons why we are where we are today. But it's frustrating from a development perspective nonetheless. And security should always be a major concern. It's just unfortunate when it comes at the expense of functionality. Personally, I believe full-cone NATs provide the lion's share of the benefits with the fewest detriments (blocking external traffic to internal applications not anticipating it). But address restricted and symmetric NATs offer few incremental security benefits, while many incremental detriments. I believe full-cone NATs offer a excellent balance of "untargeted security" and functionality, and that administrators seeking more targeted security should purposely configure a firewall. But I recognize that there is a diversity of opinion on the topic. -david From marc@let.de Mon, 20 Jun 2005 01:05:31 -0700 (PDT) From: Marc Manthey Date: Mon, 20 Jun 2005 01:05:31 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit So, to make a long story short, NAT traversal is a hard problem, and it's made especially hard by address-restricted NATs. If I could count on full-cone NAT behavior, my life as a programmer would be easier IMHO, unless the draft absolutely forbids non-full cone behavior, vendors that value security (as a principle or as marketing hype) will continue to developing non-full cone NATs. Unfortunately I agree, but this can be said about any of the NAT variables. Each has its own pros/cons, and the problem as a developer isn't dealing with misconfigured or broken NATs, it's dealing with the wide variety of differently-configured NATS. Reading through your IETF charter, I see: "Given the current near-universal deployment of NATs (Network Address Translators) in the public Internet, **the lack of standards for NAT behavior has given rise to a crisis**." [emphasis added] I'm not sure if this statement is referring to standards in terms of NAT *implementation* or NAT *deployment*, and there's a very big difference. [suresh] Indeed. morning all, i found some stuff that might be interesting http://files.dns-sd.org/draft-cheshire-nat-pmp.txt This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. If you are concerned with standardizing the implementation of NATs, but do nothing to standardize the deployment of NATs, you won't have done much to mitigate the current crisis. Indeed, it seems rather academic to completely define anything but the lowest-common denominator, because as a developer, that's all that matters. amen:-) At the moment, the lowest common denominator is punching holes through address-restricted NATS, maintaining said holes with high-frequency keepalives, and avoiding fragmentation using very small MTUs. So long as you allow this configuration, I'm forced to develop towards it, and anything less restrictive or easier might as well not exist. [suresh] I agree with all your comments. Ideally, if the demand for initial deployment was simply bi-diectional NATs, P2P application deployment would have been a cake walk by now. Bi-Directional NATs would make the port bindings Bi-diectional and would exhibit Full Cone NAT behavior for both TCP & UDP applications. Unfortunately, the predominant use-case of NATs during early deployment was client-server apps and people were concerned mainly about hosts running the client apps from behind NAT. P2P apps were not as prevalent. Security was a big concern. i found out that this called spoofing could be eliminated with a simple proxy. Bi-directionality requirement is not a UDP only rquirement for P2P apps. exactly The issue of security with Traditional NATs (which includes NAPT) is one of illusion and can be really shattered only when app developers (both client-server and P2P application developers) come forward and indicate that their apps work just as well behind a bi-directioanl NAT as behind a Traditional NAT. So long as there are applications that depend upon Address restricted Cone NAT behavior, it gives the NAT vendors an opportunity to say things like, my NAT (a traditional NAT) can provide better DOS protection than the competetion's (which may be Bi-Directional NAT). Granted, I'd welcome a better definition of "high frequency keepalives" and "small MTUs". But I'd welcome even more an absence of address-restricted NATs. Personally, I believe NATs are not firewalls, and shouldn't be in the business of blocking traffic with the goal of enhancing security. Firewalls are much more capable in this respect, and have much less "collateral damage". agree But so long as NAT vendors are encouraged to market NATs as poor- man's firewalls (ie, so long as the IETF does nothing to counter this trend), I need to build with that in mind. [suresh] I agree NATs are not firewalls. The blocking provided by the Iraditional NATs was adequate for a number of deployments. I donot have a problem with that. cheers, suresh -david cusoon marc -- " The reasonable man adapts himself to the world the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw" http://brain.let.de cuseeme:// cuseeme.dyndns.tv Attachment: smime.p7s --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="p7s00004.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7s00004.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHHzCCA0kw ggKyoAMCAQICDgpqAAEAAntSGyw2RRVxMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQ MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50 ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIu ZGUwHhcNMDUwNTA5MTQzMjQ4WhcNMDYwNTA5MTQzMjQ4WjBAMQswCQYDVQQGEwJERTEVMBMGA1UE AxMMTWFyYyBNYW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAvwCjxxISYuhol4fmTuqlvYN3JOLxcceKV3T8OzmBqQVkbKvmkqh+d5ue O+Dz4ZD9sYKbvbAcQmfLqra94of91kM20oPlAalNcSNe8HUEDEVb4GHdqPVwmaVK9jJ5BUPDMheq W5TR5X/ATEfQU7oCZSI/7+h9Ww3anbUXIZeCCOMCAwEAAaOByDCBxTAMBgNVHRMBAf8EAjAAMA4G A1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9n dWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0cHM6Ly93d3cu dHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzBBNkEwMDAxMDAwMjdCNTIxQjJD MzY0NTE1NzE/MA0GCSqGSIb3DQEBBAUAA4GBAE94N6LMW8iv8HvV9RC77acqqCw4JyLYB6pcgTK9 bpEYxkdggTJRUnCMzz8TOOzVvfA2mzEmwoKDnMYUFugAxdLbFPuxsw4aJ9vMZPdppz28nBDdx1jt lmoJvm3fogTLCGfhWyrd68/tqneYNf540iiXPkp9bwVs8qvQFyEUa8Y8MIIDzjCCAzegAwIBAgIP AJn2AAAAAtbxQYHMGpdhMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMH SGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNl Y3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwHhcNMDUw MjA0MTY0ODQ3WhcNMDYwMjA0MTY0ODQ3WjBAMQswCQYDVQQGEwJERTEVMBMGA1UEAxMMTWFyYyBN YW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANL2cTdJD0oNKje7z4466yUIRX8DJbmjCZBMLtnmHiEqMrpK2rQps8Gcmp3ueB+d o7lGwU7YH3m676a5XhyvcaYwmu1C2gLfBiOzbijbZLP95vP0Aowf9HyuO6iTS42el73q+6MKCY8h O1px1R1blj9cxFeGfFXiG8Oz2QOi7sfJHB+Vp9WVU8ZI1I8NibF/wAN8HzZSdbKkEArGarBCYZ8J Em9C7UZpxc3fx61PePP/z5j4GeQVt+iI5FzBMlg0T7W5X16D0yQuLQb2ajeYJhstFC0KrbO+v9eV WnOsXzOYo+PkPH4O6tOKyX14GFITKYWTwyU6It03XrO/lAvn80kCAwEAAaOByDCBxTAMBgNVHRMB Af8EAjAAMA4GA1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNl bnRlci5kZS9ndWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0 cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzk5RjYwMDAwMDAw MkQ2RjE0MTgxQ0MxQTk3NjE/MA0GCSqGSIb3DQEBBAUAA4GBAF3ZoITTnsH5RDnrDWReZJPv9WUF yGPjjKIUHQlGeEg+JY4T5b8SrHJGkyxyoc2dj3E5G7iJ173mz5IK42YizLRNCcw3gZcSJQl8SqiL L7VN/xdOZfbZKFhDStraQXghJ9tvoD5CNzFKblW71W0iv2f1R7GPwR+lKB9S5ZejZj+CMYIDoTCC A50CAQEwgc8wgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1i dXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3Jr cyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkB FhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIOCmoAAQACe1IbLDZFFXEwCQYFKw4DAhoFAKCC AicwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNjIwMDgwNTI2 WjAjBgkqhkiG9w0BCQQxFgQU/U2/12+TdEv8IZeUpYIHpjHYAWEwgeEGCSsGAQQBgjcQBDGB0zCB 0DCBvDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4 BgNVBAoTMVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgx IjAgBgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRp ZmljYXRlQHRydXN0Y2VudGVyLmRlAg8AmfYAAAAC1vFBgcwal2EwgeMGCyqGSIb3DQEJEAILMYHT oIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6 MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21i SDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2Vy dGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTANBgkqhkiG9w0BAQEFAASB gCeKLULsM5nWTWJiOs7T8ZfMDrYbTgo+Of/XRtqhZTbf/M7CXCBIZjUN+hOCRFLRVO40k59qB1zL 6QhCTqOxJ379CzRLlREOvTDamb6b+5yMqAMY6FO8AGuzE/gswCT1lhy3vvlz5GDJWmIx2O0nED8p I+uC9GEpKc2TsAsT2OTwAAAAAAAA --Boundary..27398.1163630134.multipart/signed-- From srisuresh@yahoo.com Mon, 20 Jun 2005 07:41:49 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 20 Jun 2005 07:41:49 -0700 (PDT) Subject: Re: [Ietf-behave] FW: Approval to Post Version -00 Internet-Drafts for the 63rd IETF Meeting in Paris, France In-Reply-To: Message-ID: <20050620144148.8222.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen & Jiri, We would like draft-sivakumar-behave-nat-tcp-req-01 to be adapted as WG document for TCP. In addition, we would also like draft-ford-behave-gen-01 to be adapted as WG document for common stuff (i.e., transport independent stuff, including ICMP). regards, suresh --- Cullen Jennings wrote: > > If we are going to have a WG version of TCP by Paris, we need to sort out > how we are doing that before July 5th. Similarly if anyone else wants to > submit 00 WG documents before Paris, please talk to Jiri and I soon. > > Cullen > > > ------ Forwarded Message > From: Internet-Drafts Administrator > Date: Fri, 17 Jun 2005 00:00:02 -0400 > To: Working Group Chairs > Subject: Approval to Post Version -00 Internet-Drafts for the 63rd IETF > Meeting in Paris, France > > > Dear IETF Working Group Chairs: > > In order to expedite the processing of the many version -00 I-Ds that > the Secretariat receives before an IETF meeting, we ask that you > please notify the Secretariat prior to the initial submission cutoff > date of all version -00 I-Ds that you expect to approve for posting as > WG documents. Please send the filenames of your approved -00 I-Ds to > internet-drafts@xxxxxxxxx We would appreciate receiving your list of > approved drafts four (4) business days prior to the cutoff date for -00 > submissions, or by Tuesday, July 5th at 9:00 AM ET for the 63rd IETF > Meeting. Please include the word "Approved I-Ds" in the "Subject" > field. This procedure will help to ensure that version -00 I-Ds are > posted in a timely manner, allowing more time for review by the public. > > Thank you for your cooperation in this matter. > > The Internet-Drafts Administrator > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 63rd IETF Meeting can be found at > http://www.ietf.org/meetings/cutoff_dates_63.html. > > ------ End of Forwarded Message > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From paul.hoffman@cybersecurity.org Mon, 20 Jun 2005 09:21:31 -0700 (PDT) From: Paul Hoffman Date: Mon, 20 Jun 2005 09:21:31 -0700 (PDT) Subject: Re: [Ietf-behave] FW: Approval to Post Version -00 Internet-Drafts for the 63rd IETF Meeting in Paris, France In-Reply-To: <20050620144148.8222.qmail@web40426.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I read Cullen's message as them wanting to hear offline, so I did it that way, but now that folks are asking in public: I would like to have draft-hoffman-behave-tcp-00.txt considered as the WG document for TCP NAT behavior. --Paul Hoffman, Director --Cybersecurity Association --www.cybersecurity.org From baford@mit.edu Tue, 21 Jun 2005 06:59:24 -0700 (PDT) From: Bryan Ford Date: Tue, 21 Jun 2005 06:59:24 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <200506210959.14185.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Trying to catch up again... On Thursday 09 June 2005 16:17, Francois Audet wrote: > Anyways, do we have an agreement for this text below. This is what I can > see as the best compromise, after reading the gazillions of postings on > this. > > ----------------------------------------------------------------------- > REQ-7: If application transparency is most important, it is > RECOMMENDED that a NAT have an "Endpoint independent filtering" > behavior. If a more stringent filtering behavior is most > important, it is RECOMMENDED that a NAT have an "Address > dependent filtering" behavior. > > a) The filtering behavior MAY be an option configurable by the > administrator of the NAT. > ----------------------------------------------------------------------- I'm OK with the first paragraph. I still feel strongly that the MAY should be a SHOULD in the second. I don't recall hearing any objections from Cullen or anyone else after my earlier suggestion that we keep the SHOULD but change "user configurable" to "configurable by the administrator of the NAT". Thanks, Bryan From baford@mit.edu Tue, 21 Jun 2005 07:20:19 -0700 (PDT) From: Bryan Ford Date: Tue, 21 Jun 2005 07:20:19 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF08A0@zrc2hxm0.corp.nortel.com> Message-ID: <200506211020.17458.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On the REQ-6b issue, I fully agree with Yukata's concerns and support the ongoing discussion to resolve it. As a side note, though, I just wanted to point out that this presents us with yet another reason we should encourage EF=I NATs as much as possible, and strongly recommend that NATs at least be configurable to EF=I by the administrator whatever their default configuration. Since as a practical matter any EF=A NAT must have per-session keepalive timers (or at any rate finer than per-binding granularity), applications behind EF=A NATs have to send per-session keepalives. For applications with a lot of neighbors (e.g., apps running distributed hash table algorithms and the like), that can amount to a LOT of keepalive traffic. Applications behind EF=I NATs, in contrast, besides being "first-class citizens" that can help other nodes punch holes, also only have to send keepalives on one session to maintain all their mappings, thereby substantially reducing their "background" traffic load on the Net. Of course this still doesn't make applications simpler, since we know in practice applications have to support both EF=A and EF=I NATs. But in situations where the app is smart enough to detect and take advantage of EF=I behavior anyway (e.g., in order to become a supernode on a P2P network), it can easily leverage this knowledge further by reducing the keepalive traffic it generates to a single session. Less useless keepalive traffic is good for users and for the Internet. EF=I is good for users and for the Internet. Nuff said. Bryan On Thursday 09 June 2005 18:28, yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: > > The "cleanup" of the sessions is only going to happened > > when the inside endpoint stops sending packets (to anywhere). > > This is the point I am concerned about. What if the inside endpoint does > not stop sending to some remote hosts for a long time? > > Let me explain again with an example: > > Consider host S is behind EF=A/NB=I NAT, providing video streaming > service, for example, from the same local port to *anyone*, like > forever... Accumulative number of connections could be thousands or > millions over time if instantaneous number of connections happens to be > one or more whole time. Since the NAT is EF=A, it has to remember all > the remote host's addresses for the endpoint filtering until the binding > is destroyed. I do not believe that a NAT can store millions of > addresses in memory practically. Then a design might be determined to > have a limit like 256 addresses at maximum for a binding, but is 256 > enough? It is hard tell. > > The MUST in 6b imposes above problem to implementors. 6b is sure > attractive, but I cannot help anticipating that this may cause another > non-dereministic behavior of NAT. Considering the essential reason to > choose EF=A over EF=I, the sessions no longer in use should be closed. > Actually, an application cannot assume that the NAT it is behind a > behave compliant NAT, 6b is not so useful anyways.. > > - Yutaka From sg266@cornell.edu Tue, 21 Jun 2005 11:14:05 -0700 (PDT) From: Saikat Guha Date: Tue, 21 Jun 2005 11:14:05 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <1119373669.5075.11.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-06-21 at 09:59 -0600, Bryan Ford wrote: > On Thursday 09 June 2005 16:17, Francois Audet wrote: > > a) The filtering behavior MAY be an option configurable by the > I still feel strongly that the MAY should be > a SHOULD in the second. I don't recall hearing any objections from Cullen or > anyone else after my earlier suggestion that we keep the SHOULD but change > "user configurable" to "configurable by the administrator of the NAT". I agree with Cullen (below) that changing the MAY to should doesn't change any interoperability issues. Even if "user configurable" is changed to "configurable by the administrator", all of Cullen's objections still hold. Changing it to SHOULD/RECOMMENDED in REQ-7a introduces a hidden recommendation that a NAT SHOULD implement both filtering behaviors (so it can have an option configurable by the admin) ... which is not what REQ-7 says. I support "MAY" in REQ-7a. On Wed, 2005-06-01 at 09:25 -0400, Cullen Jennings wrote: > > a) The filtering behavior SHOULD be a user configurable option. > > I could deal with this if we change to MAY but strongly object to the > SHOULD. There are going to be devices where this is difficult. There are > going to be devices that only support one type. In many case the > administrator of the NAT is very different from the user of it. There is no > reason why the WG should tell vendors how to build this. Having it as MAY or > SHOULD does not change any interoperability issues between devices. Any > standards body should focus on things that it needs to specify to ensure > interoperability. Once vendors start down the slipper slope of not being > fully compliant, pain and suffering will ensue - I'd rather avoid that. It's > about as useful for the draft to say that all NAT user manuals SHOULD be in > gender neutral language. It has no effect on interoperability. I can not see > any good come it and I can see harm caused by it when key vendors that are > not fully complaint start justifying why it is not useful to be fully > complaint with BEHAVE. I know it sounds weird to care about this, but I > would like to have a chance of getting the largest vendor of residential and > corporate NATs to do this and this is not going to help. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00040.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00040.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3VFbGxuRmx0cWk2OTEvb1JBc3Q2QUo5S0lIaTRPTnJwTWdTRTQzUWh6 V2dFWERZOHVBQ2VMcXRtClJLQXg5b2kyYlJMYnQ4NGw4Q0hjUjRjPQo9Q0NVaAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Tue, 21 Jun 2005 11:23:06 -0700 (PDT) From: Saikat Guha Date: Tue, 21 Jun 2005 11:23:06 -0700 (PDT) Subject: Re: [Ietf-behave] P2P Filesharing over UDP In-Reply-To: <20050619220446.64115.qmail@web40427.mail.yahoo.com> Message-ID: <1119378177.5134.36.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-06-19 at 16:42 -0700, David Barrett wrote: > Pyda Srisuresh wrote: > > --- Saikat Guha wrote: > >>Subsequent Rodi clients perform a port scan on a remote address as > >>before. If the address is a NAT'ed Rodi client (that has already > >>performed step 1 above), then one of the port-scan packets make it > >>through to the other end. This is assuming the NAT is Full Cone for UDP. > > Just curious, how "broad" is this port scan? Does it do a total > portscan (ie, of the complete range of possible UDP ports), or pick a > subset that it somehow knows will work? Last I looked into it, it asked the user to specify the range. For it to work with existing NATs, this would be 1024--65536. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00041.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00041.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3VGc0JuRmx0cWk2OTEvb1JBdW9mQUo5a2pJNG1aR0t1dmFieUdaSHIv S2FEWFBEcnhRQ2ZmTjZ1CmRMbnZaRjliaUp6WldNbzVqeDhVc1BzPQo9bDNvUwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Tue, 21 Jun 2005 11:38:59 -0700 (PDT) From: Saikat Guha Date: Tue, 21 Jun 2005 11:38:59 -0700 (PDT) Subject: Re: [Ietf-behave] P2P Filesharing over UDP In-Reply-To: <20050619220446.64115.qmail@web40427.mail.yahoo.com> Message-ID: <1119379130.5134.51.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-06-19 at 15:04 -0700, Pyda Srisuresh wrote: > [suresh] I am not sure, I understand you correctly in your above comment about > assuming Full-Cone NAT. Is the following what you meant? If both the publisher and subscriber know of each other, then any kind of NAT works (the algorithm basically degenerates to STUN with port- scanning to traverse symmetric NATs). If the publisher is unaware of the subscriber then, as far as I understand, the publisher needs to be behind a full cone since the application does not implement any sort of out-of-band signaling to get the publisher to punch a hole for that specific subscriber in his NAT. Not sure if I answered your question. > > Basically, the approach trades off a public STUN server in exchange for > > a port-scan and full-cone support. > > > [suresh] Right. If I understood what you said correctly, You dont need an > external public server to get a list of file sharers behind NAT devices, when > the NAT devices exhibit full-Cone NAT behavior. I do not know how peers discover each other and find the file sharers. You are correct in that Rodi does not have a central rendezvous server (perhaps it has some gossip based discovery like gnutella, or the user points it to the file server like in Bittorrent). What I was getting at was that it doesn't use a public STUN server to discover its own mapping. > [suresh] Cool. This seems to add yet another voice to full-Cone NAT deployment > in providing flexibility from a P2P application vantage. True, but the only thing that supports full-cone is the port-scan. If instead of the port-scan it implements a port-and-address scan then it would work with restricted cone as well. That said, as Christopher and David pointed out, port-scans are rarely welcomed by users and administrators. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00042.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00042.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3VGNjZuRmx0cWk2OTEvb1JBZ1JzQUo0eElKN21GdE9kVFZFekJydFJy WEpDZm92Y3JBQ2ZTdSs4CkJUajhrTXN0VmxjOWV0RUcvd2FmYzlRPQo9QlhhNQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From baford@mit.edu Tue, 21 Jun 2005 12:21:59 -0700 (PDT) From: Bryan Ford Date: Tue, 21 Jun 2005 12:21:59 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <200506212121.56318.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 21 June 2005 19:07, Saikat Guha wrote: > On Tue, 2005-06-21 at 09:59 -0600, Bryan Ford wrote: > > On Thursday 09 June 2005 16:17, Francois Audet wrote: > > > a) The filtering behavior MAY be an option configurable by the > > > > I still feel strongly that the MAY should be > > a SHOULD in the second. I don't recall hearing any objections from > > Cullen or anyone else after my earlier suggestion that we keep the SHOULD > > but change "user configurable" to "configurable by the administrator of > > the NAT". > > I agree with Cullen (below) that changing the MAY to should doesn't > change any interoperability issues. Even if "user configurable" is > changed to "configurable by the administrator", all of Cullen's > objections still hold. In what way do they still hold? As far as I can tell, Cullen's objections were primarily based on his comment that "In many case[s] the administrator of the NAT is very different from the user of it" and therefore it was unreasonable to expect a NAT's behavior to be "user-configurable". That statement I agree with. It is entirely reasonable, however, to expect a NAT's behavior to be "administrator-configurable". Every NAT on the planet is already "administrator-configurable" - even locked-down NATs supplied by ISPs, which are configured by the ISP's administrator (perhaps before they are even shipped to the user). The problem was merely a minor semantic confusion caused by the distinction between "user" and "administrator". I always meant "administrator-configurable"; it just accidentally came out "user-configurable" at some point because I wasn't thinking carefully about that distinction at the time. > Changing it to SHOULD/RECOMMENDED in REQ-7a > introduces a hidden recommendation that a NAT SHOULD implement both > filtering behaviors (so it can have an option configurable by the > admin) ... which is not what REQ-7 says. I support "MAY" in REQ-7a. That hidden recommendation that a NAT SHOULD implement both filtering behaviors is precisely the point. I feel that if a NAT implements EF=A filtering (which is a problematic but reasonable security feature), then it SHOULD also provide a way for the NAT's administrator to turn that filtering feature off. Since an EF=A NAT minus filtering effectively becomes an EF=I NAT, what we have is a NAT that is configurable for either EF=I or EF=A. This will take an absurdly small amount of implementation effort by the NAT implementor - every NAT on the planet has a zillion configuration options already; this is just one more, and all it does is turn off a particular security feature that sometimes gets in the way of application connectivity. Can you explain why it is unreasonable or undesirable for NAT vendors to be expected to provide this small but potentially important bit of configurability? Bryan > On Wed, 2005-06-01 at 09:25 -0400, Cullen Jennings wrote: > > > a) The filtering behavior SHOULD be a user configurable option. > > > > I could deal with this if we change to MAY but strongly object to the > > SHOULD. There are going to be devices where this is difficult. There are > > going to be devices that only support one type. In many case the > > administrator of the NAT is very different from the user of it. There is > > no reason why the WG should tell vendors how to build this. Having it as > > MAY or SHOULD does not change any interoperability issues between > > devices. Any standards body should focus on things that it needs to > > specify to ensure interoperability. Once vendors start down the slipper > > slope of not being fully compliant, pain and suffering will ensue - I'd > > rather avoid that. It's about as useful for the draft to say that all NAT > > user manuals SHOULD be in gender neutral language. It has no effect on > > interoperability. I can not see any good come it and I can see harm > > caused by it when key vendors that are not fully complaint start > > justifying why it is not useful to be fully complaint with BEHAVE. I know > > it sounds weird to care about this, but I would like to have a chance of > > getting the largest vendor of residential and corporate NATs to do this > > and this is not going to help. From sg266@cornell.edu Tue, 21 Jun 2005 14:34:35 -0700 (PDT) From: Saikat Guha Date: Tue, 21 Jun 2005 14:34:35 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <1119389664.5134.89.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-06-21 at 21:21 +0200, Bryan Ford wrote: > That hidden recommendation that a NAT SHOULD implement both filtering > behaviors is precisely the point. I wasn't aware this was the intention -- Francois? Cullen? > Can you explain why it is unreasonable or undesirable for NAT vendors to be > expected to provide this small but potentially important bit of > configurability? They MAY provide it and I'd be happy if they did, but requiring the config option for full compliance with the RFC's mandatory and recommended specifications is overkill. The document defines the standards for interoperability and, as I see it, the user- interface/config-option is not one of them. Nevertheless, I am glad it is mentioned as OPTIONAL to nudge vendors in the right direction. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00043.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00043.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3VJZmduRmx0cWk2OTEvb1JBdUFJQUo5UXlmZ3NibkJqQlBySFRlb3BZ eXNYWkxqK1VRQ2RHLzVDCkpKejN3L0VydExOcS8wc2o0MjRJNkl3PQo9UHYxTwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Tue, 21 Jun 2005 15:07:32 -0700 (PDT) From: Saikat Guha Date: Tue, 21 Jun 2005 15:07:32 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <1119391642.5134.121.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-06-21 at 21:21 +0200, Bryan Ford wrote: > In what way do they still hold? I think you misunderstood what Cullen was objecting to. > > On Wed, 2005-06-01 at 09:25 -0400, Cullen Jennings wrote: > > > I could deal with this if we change to MAY but strongly object to the > > > SHOULD. There are going to be devices where this is difficult. There are > > > going to be devices that only support one type. Yep. If the NAT supports only one type (EF=I or EF=A), it would be difficult to have the config option regardless of whether it is the end- user or the NAT administrator who is configuring it. -- Saikat (who has started seeing glimpses of behave udp emails in his nightmares and wants to make it stop) Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00044.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00044.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3VJK2FuRmx0cWk2OTEvb1JBdUJOQUo5QXBkZnJ0bDdDS1JHSm1ON0tG RzFtYzBqOG5nQ2ZTRi9pCmxwMXFhaXVMZ2szOUNrV0RhQWRYY0kwPQo9Tk5ZbgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From dbarrett@quinthar.com Tue, 21 Jun 2005 16:10:11 -0700 (PDT) From: David Barrett Date: Tue, 21 Jun 2005 16:10:11 -0700 (PDT) Subject: Re: [Ietf-behave] P2P Filesharing over UDP In-Reply-To: <20050619220446.64115.qmail@web40427.mail.yahoo.com> Message-ID: <1119395387.3BDC71@bf12.dngr.org> MIME-Version: 1.0 Content-Type: text/plain On Tue, 21 Jun 2005 11:33 am, Saikat Guha wrote: Last I looked into it, it asked the user to specify the range. For it to work with existing NATs, this would be 1024--65536. Huh. I assumed a total portscan would raise all sorts of alarms and get blocked. Interesting. -david From audet@nortel.com Tue, 21 Jun 2005 17:04:20 -0700 (PDT) From: "Francois Audet" Date: Tue, 21 Jun 2005 17:04:20 -0700 (PDT) Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Message-ID: <1ECE0EB50388174790F9694F77522CCF02E69441@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 My understanding too. Let's wait for Cullen to clarify. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Tuesday, June 21, 2005 15:07 > To: Bryan Ford > Cc: 'Behave' > Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 > > > On Tue, 2005-06-21 at 21:21 +0200, Bryan Ford wrote: > > In what way do they still hold? > > I think you misunderstood what Cullen was objecting to. > > > > On Wed, 2005-06-01 at 09:25 -0400, Cullen Jennings wrote: > > > > I could deal with this if we change to MAY but strongly > object to > > > > the SHOULD. There are going to be devices where this is > difficult. > > > > There are going to be devices that only support one type. > > Yep. If the NAT supports only one type (EF=I or EF=A), it > would be difficult to have the config option regardless of > whether it is the end- user or the NAT administrator who is > configuring it. > > -- > Saikat > (who has started seeing glimpses of behave udp emails in his > nightmares and wants to make it stop) > From audet@nortel.com Tue, 21 Jun 2005 17:45:27 -0700 (PDT) From: "Francois Audet" Date: Tue, 21 Jun 2005 17:45:27 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 Message-ID: <1ECE0EB50388174790F9694F77522CCF02E69490@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 Hi Brian, Can you clarify what you mean by you agree with the "ongoing discussion" to resolve it? I was proposing the following: Do people agree with deleting 4.4, Requirement 6b, and the last phrase of 5.2 (everything after the comma). Is this what you are agreeing with? As for the rest of your notes below, I'm assuming that you are not proposing actual new text for the document, and that the comments were targetted at the mailing list, right? > -----Original Message----- > From: Bryan Ford [mailto:baford@xxxxxxx] > Sent: Tuesday, June 21, 2005 09:20 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Cc: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx; Audet, Francois > [SC100:9T51:EXCH] > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > On the REQ-6b issue, I fully agree with Yukata's concerns and > support the > ongoing discussion to resolve it. As a side note, though, I > just wanted to > point out that this presents us with yet another reason we > should encourage > EF=I NATs as much as possible, and strongly recommend that > NATs at least be > configurable to EF=I by the administrator whatever their default > configuration. Since as a practical matter any EF=A NAT must have > per-session keepalive timers (or at any rate finer than per-binding > granularity), applications behind EF=A NATs have to send per-session > keepalives. For applications with a lot of neighbors (e.g., > apps running > distributed hash table algorithms and the like), that can > amount to a LOT of > keepalive traffic. Applications behind EF=I NATs, in > contrast, besides being > "first-class citizens" that can help other nodes punch holes, > also only have > to send keepalives on one session to maintain all their > mappings, thereby > substantially reducing their "background" traffic load on the Net. > > Of course this still doesn't make applications simpler, since > we know in > practice applications have to support both EF=A and EF=I > NATs. But in > situations where the app is smart enough to detect and take > advantage of EF=I > behavior anyway (e.g., in order to become a supernode on a > P2P network), it > can easily leverage this knowledge further by reducing the > keepalive traffic > it generates to a single session. Less useless keepalive > traffic is good for > users and for the Internet. EF=I is good for users and for > the Internet. > Nuff said. > > Bryan > > On Thursday 09 June 2005 18:28, > yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: > > > The "cleanup" of the sessions is only going to happened > > > when the inside endpoint stops sending packets (to anywhere). > > > > This is the point I am concerned about. What if the inside endpoint > > does not stop sending to some remote hosts for a long time? > > > > Let me explain again with an example: > > > > Consider host S is behind EF=A/NB=I NAT, providing video streaming > > service, for example, from the same local port to *anyone*, like > > forever... Accumulative number of connections could be thousands or > > millions over time if instantaneous number of connections > happens to > > be one or more whole time. Since the NAT is EF=A, it has to > remember > > all the remote host's addresses for the endpoint filtering > until the > > binding is destroyed. I do not believe that a NAT can store > millions > > of addresses in memory practically. Then a design might be > determined > > to have a limit like 256 addresses at maximum for a binding, but is > > 256 enough? It is hard tell. > > > > The MUST in 6b imposes above problem to implementors. 6b is sure > > attractive, but I cannot help anticipating that this may > cause another > > non-dereministic behavior of NAT. Considering the essential > reason to > > choose EF=A over EF=I, the sessions no longer in use should > be closed. > > Actually, an application cannot assume that the NAT it is behind a > > behave compliant NAT, 6b is not so useful anyways.. > > > > - Yutaka > > From baford@mit.edu Wed, 22 Jun 2005 00:25:41 -0700 (PDT) From: Bryan Ford Date: Wed, 22 Jun 2005 00:25:41 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <200506220925.38809.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 22 June 2005 00:07, Saikat Guha wrote: > On Tue, 2005-06-21 at 21:21 +0200, Bryan Ford wrote: > > In what way do they still hold? > > I think you misunderstood what Cullen was objecting to. If that's the case, I think I'll let Cullen clarify what exactly he was objecting to. Bryan > > > On Wed, 2005-06-01 at 09:25 -0400, Cullen Jennings wrote: > > > > I could deal with this if we change to MAY but strongly object to the > > > > SHOULD. There are going to be devices where this is difficult. There > > > > are going to be devices that only support one type. > > Yep. If the NAT supports only one type (EF=I or EF=A), it would be > difficult to have the config option regardless of whether it is the end- > user or the NAT administrator who is configuring it. So the NAT should support both types. Doing so is trivial from an implementation perspective, and does not make the NAT any less powerful or less secure. So what exactly is your beef with this proposal? Bryan From sg266@cornell.edu Wed, 22 Jun 2005 01:29:03 -0700 (PDT) From: Saikat Guha Date: Wed, 22 Jun 2005 01:29:03 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <1119428933.5375.39.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-06-22 at 09:25 +0200, Bryan Ford wrote: > If that's the case, I think I'll let Cullen clarify what exactly he was > objecting to. Peace. It is possible I interpreted Cullen's objections incorrectly. We should let him clarify. In the mean time, let's try to keep this discussion constructive. > So the NAT should support both types. Doing so is trivial from an > implementation perspective, and does not make the NAT any less powerful or > less secure. So what exactly is your beef with this proposal? Can you please rephrase the question? -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00045.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00045.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3VTRkZuRmx0cWk2OTEvb1JBcjUwQUpvRE9pd0d6N3ZDbEJIWWx0ckJk V1E4VHBiTnZnQ2ZWd0tICnZjZmZpSDNqdnNTV0MzQVJNWGs1QkEwPQo9NjRqcgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From baford@mit.edu Wed, 22 Jun 2005 08:25:08 -0700 (PDT) From: Bryan Ford Date: Wed, 22 Jun 2005 08:25:08 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <200506221724.38176.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 22 June 2005 10:28, Saikat Guha wrote: > > So the NAT should support both types. Doing so is trivial from an > > implementation perspective, and does not make the NAT any less powerful > > or less secure. So what exactly is your beef with this proposal? > > Can you please rephrase the question? OK - I wasn't trying to be rude; I really just don't understand what your objection is. What exactly is it that makes you think NAT vendors will be resistant to providing both EF=I and EF=A filtering, as an option configurable by the NAT administrator? To reiterate the point (once again): Implementing EF=I as an option on a NAT that already supports EF=A is trivial. The vendor still gets to decide which behavior should be the default, based on the security/compatibility tradeoff we point out in the draft. We are already asking NAT vendors to do other substantially more difficult-to-implement things in the UDP draft, such as requiring Cone NAT in the first place (which requires implementing bindings if the vendor hasn't already), and supporting hairpin translation (which very few vendors have done so far). So what makes you think NAT vendors will resist or ignore this recommendation while accepting all the technically much more difficult ones we've already agreed on? Bryan From sg266@cornell.edu Wed, 22 Jun 2005 13:17:07 -0700 (PDT) From: Saikat Guha Date: Wed, 22 Jun 2005 13:17:07 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <1119471385.5179.77.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-06-22 at 17:24 +0200, Bryan Ford wrote: > Implementing EF=I as an option on a NAT > that already supports EF=A is trivial. - Implementing EF=A as an option on a NAT that already supports EF=I is not trivial. - Even for an EF=A NAT, I don't presume to know how trivial EF=I is; it will require extra code, introduce more bugs, increase complexity and add to the testing/QA overhead. I suppose a NAT vendor is in a better position to comment on how hard/easy it is to put into a product than either of us. - Even if they do implement it, the configuration option may or may not be convenient. Windows, Linux and BSD currently do not allow the admin to change any NAT behavior (binding, timer, fragment handling etc). A lot of "Zero-configuration" VoIP devices (http://www.siphardware.com/) come bundled with very rudimentary NATs whose sole purpose in life is to shunt VoIP traffic to the device and send everything else down another interface. But most importantly, - The document specifies interoperability standards; not how to implement it. The config option would be nice, but there is no compelling justification for it -- if security is important do EF=A, if transparency is do EF=I, Why both? 'It doesn't change anything or is trivial' is not a compelling. If vendors cannot stay "fully compliant" without implementing this one item with a wishy-washy justification, they might as well balk and stop following any of the RECOMMENDED parts since they cannot be fully compliant anyway; which would be a complete disaster. -- Saikat (who found an interesting, and provocative, article linked off of Slashdot -- http://www.securityfocus.com/columnists/334. Standard Disclaimer: this does not necessarily reflect the views of the poster or this mailing list etc. etc.) Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00046.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00046.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3VjY1puRmx0cWk2OTEvb1JBdW53QUo5Y1g4Y2Radmg4QXpIdWp3cm5P aThkRlJ1ZWpnQ2RIaEV5CnRGeFFlZCtWKzhpQ2orc0JMcjlodk5nPQo9eTZyVQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From srisuresh@yahoo.com Wed, 22 Jun 2005 18:10:53 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 22 Jun 2005 18:10:53 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1119471385.5179.77.camel@localhost.localdomain> Message-ID: <20050623011053.59837.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Wed, 2005-06-22 at 17:24 +0200, Bryan Ford wrote: > > Implementing EF=I as an option on a NAT > > that already supports EF=A is trivial. > > - Implementing EF=A as an option on a NAT that already supports EF=I is > not trivial. > - Even for an EF=A NAT, I don't presume to know how trivial EF=I is; it > will require extra code, introduce more bugs, increase complexity and > add to the testing/QA overhead. I suppose a NAT vendor is in a better > position to comment on how hard/easy it is to put into a product than > either of us. [suresh] Saikat - I worked on implementing NAT devices. It is pretty straight forward and trivial to do these options, especially when one of them is already implemented. Obviously, I cannot speak for all NAT vendors out there. This is one opinion of a NAT vendor. As for new bugs, this can happen while incorporating any of the recommendations. This specific one being no exception. However, the upside of incorporating the changes is presumably better interoperability and deployment experience in the end. So, comptent coding and testing is the price one has to pay for that. It is not reasonable to drop requirements because doing so could add bugs, IMHO. cheers, suresh From audet@nortel.com Wed, 22 Jun 2005 18:31:43 -0700 (PDT) From: "Francois Audet" Date: Wed, 22 Jun 2005 18:31:43 -0700 (PDT) Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Message-ID: <1ECE0EB50388174790F9694F77522CCF02ECDE0B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Thanks. Good feedback. Your last point is actually very important. I fully agree with it, and I think it is why this group keeps on getting into rat-holes. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Wednesday, June 22, 2005 13:16 > To: Bryan Ford > Cc: 'Behave' > Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 > > > On Wed, 2005-06-22 at 17:24 +0200, Bryan Ford wrote: > > Implementing EF=I as an option on a NAT > > that already supports EF=A is trivial. > > - Implementing EF=A as an option on a NAT that already > supports EF=I is > not trivial. > - Even for an EF=A NAT, I don't presume to know how trivial > EF=I is; it > will require extra code, introduce more bugs, increase > complexity and > add to the testing/QA overhead. I suppose a NAT vendor is > in a better > position to comment on how hard/easy it is to put into a > product than > either of us. > - Even if they do implement it, the configuration option may > or may not > be convenient. Windows, Linux and BSD currently do not > allow the admin > to change any NAT behavior (binding, timer, fragment > handling etc). A > lot of "Zero-configuration" VoIP devices > (http://www.siphardware.com/) > come bundled with very rudimentary NATs whose sole purpose > in life is > to shunt VoIP traffic to the device and send everything else down > another interface. > > But most importantly, > > - The document specifies interoperability standards; not how to > implement it. The config option would be nice, but there is no > compelling justification for it -- if security is important > do EF=A, > if transparency is do EF=I, Why both? 'It doesn't change anything or > is trivial' is not a compelling. If vendors cannot stay "fully > compliant" without implementing this one item with a wishy-washy > justification, they might as well balk and stop following any of the > RECOMMENDED parts since they cannot be fully compliant anyway; which > would be a complete disaster. > > -- > Saikat > (who found an interesting, and provocative, article linked > off of Slashdot -- > http://www.securityfocus.com/columnists/334. Standard > Disclaimer: this does not necessarily reflect the views of > the poster or this mailing list etc. etc.) > From baford@mit.edu Thu, 23 Jun 2005 00:07:47 -0700 (PDT) From: Bryan Ford Date: Thu, 23 Jun 2005 00:07:47 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02E69490@zrc2hxm0.corp.nortel.com> Message-ID: <200506230907.17769.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 22 June 2005 02:45, Francois Audet wrote: > Hi Brian, > > Can you clarify what you mean by you agree with the "ongoing > discussion" to resolve it? > > I was proposing the following: > Do people agree with deleting 4.4, Requirement 6b, and the last > phrase of 5.2 (everything after the comma). > > Is this what you are agreeing with? Seems reasonable to me, although deleting just the last phrase of 5.2 seems to leave a meaningless sentence fragment ("In the case of ... NATS"). Maybe I'm looking at a different version of the text than you are referring to... The time for which a NAT filter is valid can be refreshed based on packets that are inbound, outbound, or going either direction. In the case of "External Filtering" of "Address dependent" or "Address and port dependent" NATs, the scope of the refresh could include the filters for just the particular port and destination or for all the ports and destinations sharing the same external address and port on the NAT. Did you mean to just delete the whole second sentence? At any rate, I don't have a strong opinion as to how exactly this issue is resolved, as long as it doesn't leave NAT vendors between a rock and a hard place like it does at the moment. > As for the rest of your notes below, I'm assuming that you are not > proposing actual new text for the document, and that the comments > were targetted at the mailing list, right? Correct. Thanks, Bryan > > -----Original Message----- > > From: Bryan Ford [mailto:baford@xxxxxxx] > > Sent: Tuesday, June 21, 2005 09:20 > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Cc: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx; Audet, Francois > > [SC100:9T51:EXCH] > > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > > > > On the REQ-6b issue, I fully agree with Yukata's concerns and > > support the > > ongoing discussion to resolve it. As a side note, though, I > > just wanted to > > point out that this presents us with yet another reason we > > should encourage > > EF=I NATs as much as possible, and strongly recommend that > > NATs at least be > > configurable to EF=I by the administrator whatever their default > > configuration. Since as a practical matter any EF=A NAT must have > > per-session keepalive timers (or at any rate finer than per-binding > > granularity), applications behind EF=A NATs have to send per-session > > keepalives. For applications with a lot of neighbors (e.g., > > apps running > > distributed hash table algorithms and the like), that can > > amount to a LOT of > > keepalive traffic. Applications behind EF=I NATs, in > > contrast, besides being > > "first-class citizens" that can help other nodes punch holes, > > also only have > > to send keepalives on one session to maintain all their > > mappings, thereby > > substantially reducing their "background" traffic load on the Net. > > > > Of course this still doesn't make applications simpler, since > > we know in > > practice applications have to support both EF=A and EF=I > > NATs. But in > > situations where the app is smart enough to detect and take > > advantage of EF=I > > behavior anyway (e.g., in order to become a supernode on a > > P2P network), it > > can easily leverage this knowledge further by reducing the > > keepalive traffic > > it generates to a single session. Less useless keepalive > > traffic is good for > > users and for the Internet. EF=I is good for users and for > > the Internet. > > Nuff said. > > > > Bryan > > From baford@mit.edu Thu, 23 Jun 2005 00:20:19 -0700 (PDT) From: Bryan Ford Date: Thu, 23 Jun 2005 00:20:19 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <200506230919.52291.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 22 June 2005 22:16, Saikat Guha wrote: > On Wed, 2005-06-22 at 17:24 +0200, Bryan Ford wrote: > > Implementing EF=I as an option on a NAT > > that already supports EF=A is trivial. > > - Implementing EF=A as an option on a NAT that already supports EF=I is > not trivial. >[...] See Suresh's response. > But most importantly, > > - The document specifies interoperability standards; not how to > implement it. In what way does recommending that a particular be configurable amount to telling NAT vendors "how to implement" NATs? Many IETF standards of all kinds routinely recommend that various behaviors be configurable by an administrator; there is nothing new about recommending configurability, and this is the first time I've ever heard anyone claim that recommending a behavior be administrator-configurable amounts to "telling the vendor how to implement it." Configurability is an *external*, user-visible (or at least administrator-visible) functionality, not just an internal implementation detail. Furthermore, as we've already established, this issue DOES affect interoperability in at least one concrete way, as Francois's proposed text for the draft already points out. An EF=I NAT is more interoperable with legacy symmetric NATs than an EF=A NAT is, because you can hole punch between an EF=I NAT and a symmetric NAT with no problem, whereas you can't hole punch between an EF=A NAT and a symmetric NAT without port number prediction. > The config option would be nice, but there is no > compelling justification for it -- if security is important do EF=A, > if transparency is do EF=I, Why both? Because it's not the VENDOR that should decide whether security or transparency is most important! It's the customer who buys, configures, and actually deploys the NAT who should be able to decide this. (See for example Jon Peterson's comment on this topic many weeks ago.) Bryan From sg266@cornell.edu Thu, 23 Jun 2005 01:10:05 -0700 (PDT) From: Saikat Guha Date: Thu, 23 Jun 2005 01:10:05 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <1119514180.5383.19.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-06-23 at 09:19 +0200, Bryan Ford wrote: > you can't hole punch > between an EF=A NAT and a symmetric NAT without port number prediction. Are you sure you mean EF=A and not EF=ADP; since you _can_ hole punch between a legacy symmetric NAT without port number prediction and a proposed NB=I EF=A (address restricted cone) NAT. S A --- N --+-- M ---- B N is NB=I EF=A, M is legacy symmetric. S is STUN server for hole punching 1. B sends STUN packet from (X:x) to S; mapping is X1:x1 2. B tells A, it is reachable at X1:x1 <-- no prediction here 3. A sends STUN packet from (Y:y) to S; mapping is Y1:y1 4. A tells B, it is reachable at Y1:y1 <-- N is cone; no port pred reqd. 5. B sends packet from (X:x) to Y1:y1; legacy symmetric mapping is X1:x2 (different from X1:x1), packet is dropped by N (since X1 != S) 6. A sends packet from (Y:y) to X1:x1; mapping is Y1:y1 (N is cone) packet is dropped by M (mapping X1:x1 was for S not Y1:y1) hole is punched at N for (Y:y = Y1:y1) -> X1 ... N is EF=A 7. B re-tries packet #5 (X:x) to Y1:y1; mapping is X1:x2 as before packet is accepted by N (through the hole in 6) 8. A receives B's packet (#7) It is with an EF=ADP NAT that a legacy symmetric NAT cannot hole punch without port prediction ... because the hole in packet #6 would be for X1:x1 and packet #7 would be from X1:x2. For EF=A, the hole in #6 is for X1 and #7 is from X1 as well; so all's good. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00047.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00047.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3VtNUNuRmx0cWk2OTEvb1JBc3drQUo5YjlFSEFZNmVHSnEyQVFGcnFV bklwZ1ZENkpBQ2NDZWpYCmJ4WUZXM2xROFNpTkJ5bTUxTlVzQ2NrPQo9ZEE3SAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From baford@mit.edu Thu, 23 Jun 2005 04:23:18 -0700 (PDT) From: Bryan Ford Date: Thu, 23 Jun 2005 04:23:18 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <200506231323.14983.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 23 June 2005 10:09, Saikat Guha wrote: > On Thu, 2005-06-23 at 09:19 +0200, Bryan Ford wrote: > > you can't hole punch > > between an EF=A NAT and a symmetric NAT without port number prediction. > > Are you sure you mean EF=A and not EF=ADP; since you _can_ hole punch > between a legacy symmetric NAT without port number prediction and a > proposed NB=I EF=A (address restricted cone) NAT. That only works if the symmetric NAT uses only one public IP address, or always maps multiple sessions from a single internal IP address to the same public IP address. Granted, this will be the case for small home NATs, but large ISP-deployed or corporate NATs are much less likely to have this property. So you're right that the interoperability issue is less serious for EF=A than for EF=ADP, but it's still there. Plus there are still the issues of network efficiency and scalability for self-organizing protocols that I've hashed out at length several times already (which you seem to be dismissing based on a vague information-theoretic argument that completely ignores the practical realities of self-organizing P2P application protocols). Bryan > > S > A --- N --+-- M ---- B > > N is NB=I EF=A, M is legacy symmetric. S is STUN server for hole > punching > > 1. B sends STUN packet from (X:x) to S; mapping is X1:x1 > 2. B tells A, it is reachable at X1:x1 <-- no prediction here > 3. A sends STUN packet from (Y:y) to S; mapping is Y1:y1 > 4. A tells B, it is reachable at Y1:y1 <-- N is cone; no port pred reqd. > 5. B sends packet from (X:x) to Y1:y1; > legacy symmetric mapping is X1:x2 (different from X1:x1), > packet is dropped by N (since X1 != S) > 6. A sends packet from (Y:y) to X1:x1; mapping is Y1:y1 (N is cone) > packet is dropped by M (mapping X1:x1 was for S not Y1:y1) > hole is punched at N for (Y:y = Y1:y1) -> X1 ... N is EF=A > 7. B re-tries packet #5 (X:x) to Y1:y1; > mapping is X1:x2 as before > packet is accepted by N (through the hole in 6) > 8. A receives B's packet (#7) > > It is with an EF=ADP NAT that a legacy symmetric NAT cannot hole punch > without port prediction ... because the hole in packet #6 would be for > X1:x1 and packet #7 would be from X1:x2. For EF=A, the hole in #6 is for > X1 and #7 is from X1 as well; so all's good. From sg266@cornell.edu Thu, 23 Jun 2005 12:24:38 -0700 (PDT) From: Saikat Guha Date: Thu, 23 Jun 2005 12:24:38 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <1119554665.5816.48.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-06-23 at 13:23 +0200, Bryan Ford wrote: > Plus there are still the issues of network efficiency and scalability Correct. EF=A NATs may necessitate more complex applications that require more packets and accounting than what developers are currently accustomed to writing. Developers adapt, definitions of efficiency and scalability changes with bandwidth and processing power. What matters in the long run is what is fundamentally doable and what is not. It seems to me you are objecting to REQ-7 not REQ-7a. It is my understanding that you would like to recommend a vendor SHOULD implement *both* EF=I and EF=A in REQ-7. Using SHOULD in REQ-7a to introduce a hidden requirement is just sneaky :-p. Propose new text for REQ-7 if you wish, but I am far from convinced it is justifiable. Before I rest my case, I have always maintained that EF=I does not enable more connectivity than EF=A, it is merely an optimization that requires fewer packets. Security is the only essential difference. We can agree to disagree on this issue; as Franois mentioned, we have beaten REQ-7 to death several times over already. Ultimately someone (Cullen? Franois?) will need to put their foot down and just pick one. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00048.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00048.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDREQlFCQ3V3eG9uRmx0cWk2OTEvb1JBcEFXQUpVZFUzK3cwNWt0TnQybjg1N2NH bm53TWtTdkFKOXFSdnJLCjYxZXJPWm5palVQdGxKYUNVVnNrQWc9PQo9alZ2VAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From audet@nortel.com Thu, 23 Jun 2005 13:29:15 -0700 (PDT) From: "Francois Audet" Date: Thu, 23 Jun 2005 13:29:15 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 Message-ID: <1ECE0EB50388174790F9694F77522CCF02ECE7F9@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 Yes. The whole sentence. All right, looks like we nailed REQ-6. > -----Original Message----- > From: Bryan Ford [mailto:baford@xxxxxxx] > Sent: Thursday, June 23, 2005 00:07 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'; > 'yutaka_takeda@xxxxxxxxxxxxxxxxxxxx' > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > On Wednesday 22 June 2005 02:45, Francois Audet wrote: > > Hi Brian, > > > > Can you clarify what you mean by you agree with the "ongoing > > discussion" to resolve it? > > > > I was proposing the following: > > Do people agree with deleting 4.4, Requirement 6b, and the last > > phrase of 5.2 (everything after the comma). > > > > Is this what you are agreeing with? > > Seems reasonable to me, although deleting just the last > phrase of 5.2 seems to > leave a meaningless sentence fragment ("In the case of ... > NATS"). Maybe I'm > looking at a different version of the text than you are > referring to... > > The time for which a NAT filter is valid can be refreshed based on > packets that are inbound, outbound, or going either direction. In > the case of "External Filtering" of "Address dependent" or "Address > and port dependent" NATs, the scope of the refresh could > include the > filters for just the particular port and destination or for all the > ports and destinations sharing the same external address > and port on > the NAT. > > Did you mean to just delete the whole second sentence? > > At any rate, I don't have a strong opinion as to how exactly > this issue is > resolved, as long as it doesn't leave NAT vendors between a > rock and a hard > place like it does at the moment. > > > As for the rest of your notes below, I'm assuming that you are not > > proposing actual new text for the document, and that the > comments were > > targetted at the mailing list, right? > > Correct. > > Thanks, > Bryan > > > > -----Original Message----- > > > From: Bryan Ford [mailto:baford@xxxxxxx] > > > Sent: Tuesday, June 21, 2005 09:20 > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Cc: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx; Audet, Francois > > > [SC100:9T51:EXCH] > > > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-udp-01, REQ-6 > > > > > > > > > On the REQ-6b issue, I fully agree with Yukata's concerns and > > > support the ongoing discussion to resolve it. As a side note, > > > though, I just wanted to > > > point out that this presents us with yet another reason we > > > should encourage > > > EF=I NATs as much as possible, and strongly recommend that > > > NATs at least be > > > configurable to EF=I by the administrator whatever their default > > > configuration. Since as a practical matter any EF=A NAT must have > > > per-session keepalive timers (or at any rate finer than > per-binding > > > granularity), applications behind EF=A NATs have to send > per-session > > > keepalives. For applications with a lot of neighbors (e.g., > > > apps running > > > distributed hash table algorithms and the like), that can > > > amount to a LOT of > > > keepalive traffic. Applications behind EF=I NATs, in > > > contrast, besides being > > > "first-class citizens" that can help other nodes punch holes, > > > also only have > > > to send keepalives on one session to maintain all their > > > mappings, thereby > > > substantially reducing their "background" traffic load on the Net. > > > > > > Of course this still doesn't make applications simpler, since we > > > know in practice applications have to support both EF=A and EF=I > > > NATs. But in > > > situations where the app is smart enough to detect and take > > > advantage of EF=I > > > behavior anyway (e.g., in order to become a supernode on a > > > P2P network), it > > > can easily leverage this knowledge further by reducing the > > > keepalive traffic > > > it generates to a single session. Less useless keepalive > > > traffic is good for > > > users and for the Internet. EF=I is good for users and for > > > the Internet. > > > Nuff said. > > > > > > Bryan > > > > > From dbarrett@quinthar.com Thu, 23 Jun 2005 13:56:59 -0700 (PDT) From: David Barrett Date: Thu, 23 Jun 2005 13:56:59 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <42BB2217.7060407@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Saikat Guha wrote: On Thu, 2005-06-23 at 13:23 +0200, Bryan Ford wrote: Plus there are still the issues of network efficiency and scalability Correct. EF=A NATs may necessitate more complex applications that require more packets and accounting than what developers are currently accustomed to writing. Developers adapt, definitions of efficiency and scalability changes with bandwidth and processing power. What matters in the long run is what is fundamentally doable and what is not. Hi, I've been lurking a bit on this issue as it is of particular relevance to me. Please excuse my ignorance as the discussion is a bit hard to follow (is there a wiki for this draft anywhere?), but by "EF=A" do you mean "External filtering is endpoint address dependent", as described by section 5.1 of "draft-ietf-behave-nat-udp-01.txt"? If so, I think you are understating the severity of the problem. This isn't merely a matter of inconveniencing programmers. This is not a matter of conserving bandwidth or CPU. This is a matter of fundamentally preventing the deployment of certain algorithms that have proven enormously powerful in the P2P space. For example, imagine we are neighbors in a neighborhood, and we both have the EF=I security system (by which I take to mean "External filtering is endpoint independent"). This means "You control when you open your door, but once you do so, anybody can visit." This allows me to declare myself the "welcome committee" and publish my address in a global directory, and then open my door for anyone new to contact me. When you move into town, you look up my address, and you can walk up and introduce yourself, even if I'm not expecting you. But EF=A means "You must separately open your door for each visitor." There is simply no way for me to publish my address in the global "welcome wagon" directory, as even if you had it, you couldn't come over and visit. We'd need some other approach, probably involving a central call center where you can make a reservation to come see me. Given that the "welcome wagon" is a volunteer organization, this might be of prohibitive expense and inconvenience, and simply worsen your move-in experience -- all for some form of "security" that it's unclear we actually wanted in the first place. This "directory-based rendezvous algorithm", which makes up the heart of many of our most powerful P2P systems (most notably Skype), simply cannot work in a world with only EF=A NATs. And this has absolutely nothing to do with the amount of bandwidth or CPU available; more of each has no effect on the problem. Thus the incentive for maximizing the possibility for EF=I deployment is not just to please lazy programmers. It's to enable decentralized architectures to work. Without this ability, we need to centralize certain types of functionality forcing us to not only offer different features, but support them with entirely different business models. This issue goes far beyond technology to impact the entire product. I recognize that for security reasons, some administrators will likely want to deploy EF=A and purchase their NAT with this in mind. But I find it equally likely that administrators simply won't be aware of the difference. Because the issue is so esoteric, and the consequences so nonlinear, it behooves *us* to make decisions that favor the future of the Internet, and not just pass the buck down the pipeline. For example, if tomorrow we started to sell only EF=A NATs, then Skype would still work. Every day it would work worse, but there is no immediacy to the issue. There is no apparent cause/effect between some fine print in my NAT brochure and my P2P VoIP application. Rather, in a year Skype needs to start charging because their decentralized algorithms have degraded in efficiency to the point they no longer work effectively. In two years, there are no more major P2P applications, and only a few programmers understand why. Granted, this is an extreme example. But it highlights the subtlety of the issue -- even in its most extreme form, its effect is nebulous and deferred. In reality the consequences will be even harder to quantify and even more deferred, though no less undermining the long-term efficiency of today's most popular P2P applications. Personally, I believe EF=I should be the default. And if it were, I would see no argument against making EF=A a recommended option. Thus I'm simply befuddled at the strength of opposition now that the tables are turned. It would seem that the amount of discussion on this topic alone would be proof enough that the issue is not settled -- that there are compelling arguments from both side. And given the only voice I've heard from an actual NAT vendor seems to indicate the option is in fact trivial, it seems like a simple compromise to recommend that compliant NATs SHOULD support the option. -david From audet@nortel.com Thu, 23 Jun 2005 14:04:00 -0700 (PDT) From: "Francois Audet" Date: Thu, 23 Jun 2005 14:04:00 -0700 (PDT) Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Message-ID: <1ECE0EB50388174790F9694F77522CCF02ECE8C3@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 I think it is time for closure on REQ-7a. I have opted for the MAY in 7a because it doesn't look like we can get consensus for the SHOULD. However, I did add a sentence at the end of the justification section touting the merit of having a configuration option. I think this is the best compromise we can achieve, and I would like the group to achieve "rough consensus" on this requirement. ---------------------------------------------------------------- REQ-7: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address dependent filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. Justification for REQ-7: The recommendation to use Endpoint Independent Filtering is aimed at maximizing application transparency, in particular for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: an unauthorized packet could get a specific port while the port was kept open if it was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could in reality be two endpoints behind another NAT, where one of the two endpoints is an attacker): however, such a policy could interfere with applications that expect to receive UDP packets on more than one UDP port. Using Endpoint Independent Filtering or Address Dependent Filetering instead of Address and Port Dependent Filtering on a NAT (say NAT-A) also has benefits when the other enpoint is behind a non-BEHAVE compliant NAT (say NAT-B) which doesn't support REQ-1. When the endpoints use ICE, if NAT-A uses Address and Port Dependent Filtering, connectivity will require a Media Relay. However, if NAT-A uses Endpoint Indepent Filtering or Address Dependent Filtering, ICE will ultimately find connectivity without requiring a Media Relay. Having the filtering behavior being an option configurable by the administrator of the NAT ensures that a NAT can be used in the widest variety of deployment scenarios. From sg266@cornell.edu Thu, 23 Jun 2005 14:30:56 -0700 (PDT) From: Saikat Guha Date: Thu, 23 Jun 2005 14:30:56 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02AF0854@zrc2hxm0.corp.nortel.com> Message-ID: <1119562246.5816.52.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-06-23 at 13:56 -0700, David Barrett wrote: > Hi, I've been lurking a bit on this issue as it is of particular > relevance to me. Discussion continued offline. Email me if anyone else wants to be CC'ed. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00049.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00049.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3V5b0duRmx0cWk2OTEvb1JBZ2crQUo5bElYQnlYaFE4NEg3OWhjZWhD YjJWNTVjdER3Q2RFcmV4Cm1EWjdkZHR1OFZ6QjV5TG5IMmh4ZHNjPQo9ZWJKZwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From srisuresh@yahoo.com Fri, 24 Jun 2005 10:59:17 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 24 Jun 2005 10:59:17 -0700 (PDT) Subject: Is Full-Cone NAT more appl friendly than Address-restricted Cone NAT (WAS:: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7) In-Reply-To: <1119554665.5816.48.camel@localhost.localdomain> Message-ID: <20050624175916.99658.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Thu, 2005-06-23 at 13:23 +0200, Bryan Ford wrote: > > Plus there are still the issues of network efficiency and scalability > > Correct. EF=A NATs may necessitate more complex applications that > require more packets and accounting than what developers are currently > accustomed to writing. Developers adapt, definitions of efficiency and > scalability changes with bandwidth and processing power. What matters in > the long run is what is fundamentally doable and what is not. > > It seems to me you are objecting to REQ-7 not REQ-7a. It is my > understanding that you would like to recommend a vendor SHOULD implement > *both* EF=I and EF=A in REQ-7. Using SHOULD in REQ-7a to introduce a > hidden requirement is just sneaky :-p. Propose new text for REQ-7 if you > wish, but I am far from convinced it is justifiable. > > Before I rest my case, I have always maintained that EF=I does not > enable more connectivity than EF=A, it is merely an optimization that > requires fewer packets. Security is the only essential difference. We > can agree to disagree on this issue; as Franois mentioned, we have > beaten REQ-7 to death several times over already. Ultimately someone > (Cullen? Franois?) will need to put their foot down and just pick one. > [suresh] Saikat - I disagree with your notion that EF=I does not enable more connectivity than EF=A. Your argument seems fundamentally disingenuous. In a world without NATs, the conectivity provided by every router is one of EF=I for both TCP and UDP sessions. Peer-to-peer application connectivity is unhindered. Such a world with routers (and no NATs) would be considered P2P application friendly by most people. Now, as we ran into adress depletion problems with IPv4, we brought in Traditional NATs into deployment. Traditional NATs have solved the problem of address depletion, but created a new world of client-server connectivity. We have islands of domains (behind NATs) from which you can access services outside, but unable to offer services to the outside. File sharing and other P2P applications hurt in this paradigm because they fundamentally require every node in the mesh to act both as client and server. By making the Bindings bi-directional (for both TCP and UDP) or enforcing a Full Cone NAT behavior (for UDP alone), you give extra ammunition to the nodes behind NAT to take part in P2P applications. By restricting session traffic for these applications to be uni-directional (say, Address restricted Cone NAT), you are not providing security, you are hindering a number of P2P applications from beign able to function. Address-restrictd Cone NATs are a hindrane to a number of P2p aplications. By requiring the NATs to enforce bi-directional Bindings or use NAT Sessions that will exhibit Full-Cone NAT behavior (for UDP), we come a step closer to making the NATs application friendly. Nodes behind NATs are able to take part in P2P apps as first-class citizens. The security you are refering to can be obtained as an adjunct to NATs. It would be ideal if NAT devices could reserve a block of ports (or addresses) to be P2P application friendly and enforce Address-restricted Cone NAT behavior for the remaining ports (or addresses). For the block of ports (or addresses) that are application friendly, Bindings (port or address Bindings) could simly be set to be bi-diectional. Just a thought. cheers, suresh > -- > Saikat > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From sg266@cornell.edu Fri, 24 Jun 2005 12:55:11 -0700 (PDT) From: Saikat Guha Date: Fri, 24 Jun 2005 12:55:11 -0700 (PDT) Subject: Re: Is Full-Cone NAT more appl friendly than Address-restricted Cone NAT (WAS:: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7) In-Reply-To: <20050624175916.99658.qmail@web40429.mail.yahoo.com> Message-ID: <1119638774.5828.11.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-06-24 at 10:59 -0700, Pyda Srisuresh wrote: > I disagree with your notion that EF=I does not enable more > connectivity than EF=A. David's email essentially asked the same question so I'll forward my response to him to the list. If there are lingering issues or if it doesn't answer some of your concerns, I'd be glad to answer them offline unless you feel pursuing this discussion on the list is still valuable. -------- Forwarded Message -------- From: Saikat Guha To: David Barrett Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Date: Thu, 23 Jun 2005 15:02:14 -0700 On Thu, 2005-06-23 at 13:56 -0700, David Barrett wrote: > publish my address in a > global directory Correct. EF=I allows you to publish to a passive directory like DNS. EF=A requires an active directory like SIP. As long as the directory can inform you when someone looks you up, you can prepare the NAT for them. There is nothing in EF=A that fundamentally prevents you from talking to someone you wish to talk to; it just requires signaling which is always possible. If you are averse to using SIP, which has some sort of centralized connotation just like DNS; the problem is still solvable in a distributed fashion. For EF=I, the newcomer (B) will engage in some gossip to find out the address and port of the guy behind the EF=I NAT (A). Initially, A is the only person who knows his own external IP address and port; it tells that to A_1, who tells it to A_2 and so on until A_n learns of it and tells B. B can then send a direct packet to A at that address since the NAT is EF=I By the same logic, if the NAT is EF=A, then B cannot send a packet directly to A, but it can send it indirectly by sending it to A_n who sends it to he previous guy and so on until it reaches A_1 who sends it to A. The route B's signal takes to A is the reverse of the route A's IP and port data took to reach B and must necessarily be accepted by even the most stringent of filtering rules (even EF=ADP). Once B's signal reaches A, A can open the door for B. What is crucial to understand is that, essentially, EF=I is an optimization that allows one to short-circuit this reserve path. Practically speaking, it requires more packets and bookkeeping to maintain this reverse path -- but that is an engineering issue and not a fundamental limitation; and p2p developers never cease to amaze in producing efficient solutions to problems that are solvable. The main takeaway here is -- signaling is important and sometimes necessary. It can be proved that with any kind of a NAT, an out-of-band 2-way signaling path must exist. With signaling, any cone NAT can be traversed 100% of the time. There are public commercial infrastructures for signaling (SIP), academic ones (OpenDHT, i3), proprietary ones (Skype), modules that can be incorporated into an app (TURN, ICE) and even services that weren't meant for signaling but can be used if desperately necessary (IRC, ICQ, etc). Sure, it requires more work that publishing the IP on a DNS-like directory but it is necessary for the least common denominator of NATs and firewalls out there anyway. Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00050.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00050.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3ZGVDJuRmx0cWk2OTEvb1JBdHVLQUo5dmNVK21Fc2x1bnJqb3JXVm5x Qmk4Mm1RMXRnQ2ZSWGlGCjlZUkpORS9tU29OejI3MXBFTDJOdWJBPQo9SmUydgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From dbarrett@quinthar.com Fri, 24 Jun 2005 15:08:59 -0700 (PDT) From: David Barrett Date: Fri, 24 Jun 2005 15:08:59 -0700 (PDT) Subject: Re: Is Full-Cone NAT more appl friendly than Address-restricted Cone NAT (WAS:: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7) In-Reply-To: <20050624175916.99658.qmail@web40429.mail.yahoo.com> Message-ID: <42BC8479.8000900@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Saikat Guha wrote: On Fri, 2005-06-24 at 10:59 -0700, Pyda Srisuresh wrote: David's email essentially asked the same question so I'll forward my response to him to the list. If there are lingering issues or if it doesn't answer some of your concerns, I'd be glad to answer them offline unless you feel pursuing this discussion on the list is still valuable. To which I replied: -------- Original Message -------- Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Date: Thu, 23 Jun 2005 15:39:28 -0700 From: David Barrett To: Saikat Guha Saikat Guha wrote: > EF=I allows you to publish to a passive directory like DNS. > EF=A requires an active directory like SIP. This is an excellent summary of the competing options. > What is crucial to understand is that, essentially, EF=I is an > optimization that allows one to short-circuit this reserve path. > Practically speaking, it requires more packets and bookkeeping to > maintain this reverse path -- but that is an engineering issue and not a > fundamental limitation; and p2p developers never cease to amaze in > producing efficient solutions to problems that are solvable. Ah, this is a really interesting way to put it. From a theoretical perspective, I agree with you. There is no "functionality cost" to using an EF=A NAT. But in that same theoretical universe, there's no "security benefit" to using one either. In theory, because hackers can circumvent the filtering process (directly, by hacking the protocol, or indirectly, by spoofing UDP or just exploiting flaws in the application itself), there's no security benefit from EF=A filtering. I think where we disagree is in the practical, real world. In reality, spoofing, hacking, and exploiting are harder than they seem, and thus EF=A offers real security advantages. But also in reality, signalling is harder than it seems, and thus EF=I offers real functionality advantages. And just as developers are incredibly innovative (and thus the downside of EF=A is lessened), malicious hackers are possibly even moreso (and thus the upside of EF=A is lessened). At the end of the day, I think we can at least agree that there is no "right" answer. The world will continue to spin either way. So what it ultimately comes down to is whether to err on the side of functionality or security. From an application developer perspective, EF=I makes it easier to make my customers happy, and thus that's where I place my chips. -david From dbarrett@quinthar.com Fri, 24 Jun 2005 22:05:58 -0700 (PDT) From: David Barrett Date: Fri, 24 Jun 2005 22:05:58 -0700 (PDT) Subject: [Ietf-behave] Port scan to and from symmetric NAT'd peers Message-ID: <42BCE634.5090905@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain So I'm about to embark on implementing my symmetric NAT piercing tech, and I'm having trouble learning about how port scans and NATs combine both today, as well as under the IETF BEHAVE recommendations. Can you help me to understand: 1) If a symmetric NAT assigns different external ports to each outgoing UDP request in round-robin fashion, what happens if there aren't enough ports to go around? How does it pick which mappings to override? For example, I am behind a symmetric NAT, and I contact 65537 external nodes, there simply aren't enough port mappings to accomodate all sessions. If it uses a simple "least recently used" approach, would I in effect deny service to every other node behind my NAT (by remapping their ports to me)? Or is there some kind of hard limit on the number of ports that will be assigned to a given endpoint? 2) Do symmetric (or any) NATs use the full range (0-65535) of extenal port mappings, or do they avoid certain "special" ranges (such as 0-1023)? Thus if I'm trying to scan a symmetric NAT to find any nodes behind it, need I (in the worst case) scan the entire range (0-65535) or can I target my scan better? 3) Given the fuzzy line between NATs and firewalls, do NATs typically perform any sort of "attack detection" and thus block activities such as port scanning, whether inbound or outbound? Naturally, this would depend on the implementation, but I'm curious if you are aware of implementations that do this today, or if the BEHAVE draft makes any recommendations around this type of functionality. 4) Do you have any advice for me regarding how to effectively pierce symmetric NATs while remaining a "good citizen" of the Internet? Naturally, port-scanning is a horrible solution to the problem of piercing symmetric NATs, but it's the only one of which I'm aware. Can you offer me any advice on how to target my scan most effectively, structure my scan to avoid setting off any alarms, or do away with the scan altogether? Thanks for your help! -david From sg266@cornell.edu Sat, 25 Jun 2005 00:52:09 -0700 (PDT) From: Saikat Guha Date: Sat, 25 Jun 2005 00:52:09 -0700 (PDT) Subject: Re: [Ietf-behave] Port scan to and from symmetric NAT'd peers In-Reply-To: <42BCE634.5090905@quinthar.com> Message-ID: <1119685917.5342.55.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-06-24 at 22:05 -0700, David Barrett wrote: > how port scans and NATs combine > both today I have some numbers: http://www.guha.cc/saikat/stunt-results.php?sort=-9 but this is for TCP and some of it is from only 13 NATs in the lab. I do not have data for UDP and do not know if there is a correlation between TCP/UDP, but hopefully it'll provide some insights. > 1) If a symmetric NAT assigns different external ports to each outgoing > UDP request in round-robin fashion, what happens if there aren't enough > ports to go around? How does it pick which mappings to override? In my tests, the new TCP connection being attempted after all ports had been exhausted would timeout; that new SYN would be dropped by the NAT without any ICMP. > For example, I am behind a symmetric NAT, and I contact 65537 external > nodes, there simply aren't enough port mappings to accomodate all > sessions. While all symmetric NATs with one external IP would choke after 65535 unique external endpoints; I observed some (Netgear, Allied Telesyn) that choke at ~1000 unique endpoints (see the 'Max Flows' column). This is for TCP of course. I've heard reports of some old Linksys, D-Link and Netgerar NATs choking at 255 sessions on various forums. Btw, on the STUNT result page above, I did not test more than 1020 sessions due to compiled in per-process kernel limits. So it is possible some of those NATs run out of ports long before 65K. > 2) Do symmetric (or any) NATs use the full range (0-65535) of extenal > port mappings, or do they avoid certain "special" ranges (such as > 0-1023)? I see all possible behavior in this respect. Look under the "Preserves" columns. LOW is defined as <=1023, HIGH as >=1024 and DYNAMIC as >=49152. I saw NATs that only use DYNAMIC. I saw NATs that preserve the port number and therefore use LOW as well. I saw NATs that don't preserve the port number but still use LOW (freaky). Saying anything conclusive about what a NAT _does not_ use is tricky since a 'no' in the table could just be because the NAT wasn't desperate enough to use that port. But I can say that there are NATs that use all port ranges. > 3) Given the fuzzy line between NATs and firewalls, do NATs typically > perform any sort of "attack detection" and thus block activities such as > port scanning, whether inbound or outbound? Naturally, this would > depend on the implementation, but I'm curious if you are aware of > implementations that do this today I am not aware of any active 'intrusion detection' type of counter measures on home NATs, but I know of firewalls that will dynamically block (or rate limit) suspected 'intrusions'. And I have heard of ISP's that will lodge a complaint if they detect targeted scans -- but they might have mellowed since, thanks to worms and viruses :-p > or if the BEHAVE draft makes any > recommendations around this type of functionality. The UDP draft doesn't say anything about scans or max-flows. It recommends the use of HIGH ports I believe, and the use of LOW ports is optional. > Naturally, port-scanning is a horrible solution to the problem of > piercing symmetric NATs, but it's the only one of which I'm aware. There certainly are better solutions! Port prediction is a very efficient one. Yutaka-san had a draft at some point where he found that most subsequent ports are 1 or 2 higher than the previous one. Symmetric NAT Traversal using STUN: http://cnscenter.future.co.kr/resource/ietf/ind-draft/draft-takeda- symmetric-nat-traversal-00.txt His draft pertains directly to your question since he tested UDP. From my TCP testing, all but 1 or 2 of the symmetric NATs I encountered were traversable with port prediction. Results are on the STUNT result page under the 'Delta' and 'Predicted' columns. Another solution, proposed by Biggadike et al., is to use the birthday paradox to cut down the port-scan from 65K to a smaller number. It is less efficient than port prediction since it still is a scan of sorts but it is more efficient than a full port-scan, and it can handle symmetric NATs that allocate ports randomly and are thus immune to port prediction. See http://sparrow.ece.cmu.edu/~adrian/projects/natblaster.pdf for details. Hope this helps. Cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00051.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00051.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3ZRMGNuRmx0cWk2OTEvb1JBbHFIQUo0eFkySXVjeFVuNTcrU05ON2VR b2lvSVlPZTB3Q2ZYa0d3ClJvVU42eHl6VHRQMGxXWjNMd01NdUxNPQo9NStxNAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From dbarrett@quinthar.com Sat, 25 Jun 2005 12:54:46 -0700 (PDT) From: David Barrett Date: Sat, 25 Jun 2005 12:54:46 -0700 (PDT) Subject: Re: [Ietf-behave] Port scan to and from symmetric NAT'd peers In-Reply-To: <42BCE634.5090905@quinthar.com> Message-ID: <42BDB685.9060009@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Saikat Guha wrote: In my tests, the new TCP connection being attempted after all ports had been exhausted would timeout; that new SYN would be dropped by the NAT without any ICMP. Ah, I hadn't considered that possibility. But, I guess it's better than allowing any node to DoS everyone else behind the NAT. What does BEHAVE recommend in this scenario? While all symmetric NATs with one external IP would choke after 65535 unique external endpoints; I observed some (Netgear, Allied Telesyn) that choke at ~1000 unique endpoints (see the 'Max Flows' column). This is for TCP of course. I've heard reports of some old Linksys, D-Link and Netgerar NATs choking at 255 sessions on various forums. Wow, I had no idea they were that limited. Does BEHAVE recommend a minimum 'Max Flows'? Incidentally, are there NATs with multiple external IPs? I'd never even considered this possibility, nor its ramifications. Naturally, port-scanning is a horrible solution to the problem of piercing symmetric NATs, but it's the only one of which I'm aware. There certainly are better solutions! Port prediction is a very efficient one. Ah, I'm sorry, I wasn't being clear -- I was categorizing "port prediction" as a high-precision subtype of "port scanning". The Takeda draft (which is an excellent resource -- thank you for the link!) suggests "Multiple port prediction" (effectively a very narrow scan) as one of several strategies for improving port prediction success. In my case the time elapsed between the STUN and NAT-traversal operations can grow to be quite large, and thus I might need to rely more heavily on this type of scanning that might otherwise be necessary. (Or I need to rearchitect to have a smaller window, which is probably more likely, but I'm investigating all options.) Another solution, proposed by Biggadike et al., is to use the birthday paradox to cut down the port-scan from 65K to a smaller number. It is less efficient than port prediction since it still is a scan of sorts but it is more efficient than a full port-scan, and it can handle symmetric NATs that allocate ports randomly and are thus immune to port prediction. See http://sparrow.ece.cmu.edu/~adrian/projects/natblaster.pdf for details. So I've read through what I believe are the relevant portions of this paper, and I still don't "get" it. Can you try to summarize this for me? Hope this helps. It does enormously. Thanks! -david From sg266@cornell.edu Sun, 26 Jun 2005 01:49:07 -0700 (PDT) From: Saikat Guha Date: Sun, 26 Jun 2005 01:49:07 -0700 (PDT) Subject: Re: [Ietf-behave] Port scan to and from symmetric NAT'd peers In-Reply-To: <42BCE634.5090905@quinthar.com> Message-ID: <1119760200.5060.41.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2005-06-25 at 12:54 -0700, David Barrett wrote: > Saikat Guha wrote: > > the new TCP connection being attempted after all ports had > > been exhausted would timeout > > What does BEHAVE recommend in this scenario? > > Does BEHAVE recommend a minimum 'Max Flows'? I don't think the UDP draft has any recommendations that address these issues. Franois? > Incidentally, are there NATs with multiple external IPs? Mainly corporate NATs, as far as I know. > > Another solution, proposed by Biggadike et al., is to use the birthday > > paradox to cut down the port-scan from 65K to a smaller number. > > Can you try to summarize this for me? The birthday paradox is that if there are 23 people in a room then there is a slightly more than 50:50 chance that at least two of them will have the same birthday (from Wikipedia). For 60 or more people, the probability is greater than 99%. The argument can be generalized to say that if two hosts randomly pick ~450 ports, then there is a 95% chance that they'll pick the same port -- result from the Biggadike paper. Intuitively, A sends out 450 packets to B's IP address but to different ports so that 450 random holes are punched in A's symmetric NAT. B sends 450 packets addressed to A's IP address but to a random port. With 95% probability, one of B's packets (sent to a random port) will coincide with one of the (random) mappings allocated to A. So with ~900 packets, you can find a working port mapping 95% of the time. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00052.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00052.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3ZpOUhuRmx0cWk2OTEvb1JBcGp3QUo0eGdiS3hBUjdYcEtzV3lROWxw d3I0czJEQk1RQ2ZTSzRYCnBNU2hGd3ZaUFBTZEdnUGFWQ1V2eUEwPQo9ZnNBdAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From srisuresh@yahoo.com Sun, 26 Jun 2005 14:20:27 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 26 Jun 2005 14:20:27 -0700 (PDT) Subject: Re: Is Full-Cone NAT more appl friendly than Address-restricted Cone NAT (WAS:: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7) In-Reply-To: <42BC8479.8000900@quinthar.com> Message-ID: <20050626212027.27985.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Right, I agree. The basic Internet paradigm (i.e., one without NATs) is one of free interconnection between any nodes, without requiring devious signalling. This model is application friendly. Any security concerns are addressed as an adjunt on top of this basic deployment model. Bi-directional NATs come close to the above model. Semantically, Full-Cone NAT comes close to Bi-directional NATs for UDP sessions. Address Restricted Cone NAT mandates additional signalling. So, it is either less application friendly or more secure. It depends on your view point, I guess. Bottom line, as David says, is that there is no "right" answer on how to characterize the two NAT behaviors. "More secure for Address Restricted Cone NAT" vs. "More application friendly for Full Cone NAT". Here is what I believe. Traditional NATs fundamentally mandate uni-directional Bindings (Address and/or Port Bindings). So, recommending Address Restricted Cone NAT behavior for UDP would be the right thing to do in the context of Traditional NATs. However, given a choice between Traditional and Bi-Directional NATs, I believe, we should recommend deploying Bi-directional NATs over Traditional NATs. The key difference being that Bindings are Bi-directional in Bi-Directional NAT and Uni-directional in Traditional NAT. Any security concerns should be addressed as an adjunt on top of the NAT deployment, just as how it is done in the world without NATs, IMHO. regards, suresh --- David Barrett wrote: > Saikat Guha wrote: > > On Fri, 2005-06-24 at 10:59 -0700, Pyda Srisuresh wrote: > > David's email essentially asked the same question so I'll forward my > > response to him to the list. If there are lingering issues or if it > > doesn't answer some of your concerns, I'd be glad to answer them offline > > unless you feel pursuing this discussion on the list is still valuable. > > To which I replied: > > -------- Original Message -------- > Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 > Date: Thu, 23 Jun 2005 15:39:28 -0700 > From: David Barrett > To: Saikat Guha > > Saikat Guha wrote: > > EF=I allows you to publish to a passive directory like DNS. > > EF=A requires an active directory like SIP. > > This is an excellent summary of the competing options. > > > > What is crucial to understand is that, essentially, EF=I is an > > optimization that allows one to short-circuit this reserve path. > > Practically speaking, it requires more packets and bookkeeping to > > maintain this reverse path -- but that is an engineering issue and not a > > fundamental limitation; and p2p developers never cease to amaze in > > producing efficient solutions to problems that are solvable. > > Ah, this is a really interesting way to put it. From a theoretical > perspective, I agree with you. There is no "functionality cost" to > using an EF=A NAT. > > But in that same theoretical universe, there's no "security benefit" to > using one either. In theory, because hackers can circumvent the > filtering process (directly, by hacking the protocol, or indirectly, by > spoofing UDP or just exploiting flaws in the application itself), > there's no security benefit from EF=A filtering. > > I think where we disagree is in the practical, real world. In reality, > spoofing, hacking, and exploiting are harder than they seem, and thus > EF=A offers real security advantages. But also in reality, signalling > is harder than it seems, and thus EF=I offers real functionality advantages. > > And just as developers are incredibly innovative (and thus the downside > of EF=A is lessened), malicious hackers are possibly even moreso (and > thus the upside of EF=A is lessened). > > At the end of the day, I think we can at least agree that there is no > "right" answer. The world will continue to spin either way. So what it > ultimately comes down to is whether to err on the side of functionality > or security. From an application developer perspective, EF=I makes it > easier to make my customers happy, and thus that's where I place my chips. > > -david > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From baford@mit.edu Sun, 26 Jun 2005 15:03:46 -0700 (PDT) From: Bryan Ford Date: Sun, 26 Jun 2005 15:03:46 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02ECE8C3@zrc2hxm0.corp.nortel.com> Message-ID: <200506270003.43899.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Thursday 23 June 2005 23:03, Francois Audet wrote: > I think it is time for closure on REQ-7a. > > I have opted for the MAY in 7a because it doesn't look like we > can get consensus for the SHOULD. I still don't see any consensus on the MAY version either. I am not the only one who has spoken for promoting EF=I filtering or configurability. With MAY, that item says absolutely nothing and is useless. Absolutely anything MAY be configurable; no one needs to be told that. I continue to have STRONG OBJECTIONS to the publication of a BEHAVE document that further legitimizes the existing trend toward NATs having "hard-coded" EF=A filtering behavior and which seriously reducing Internet connectivity for all users, regardless of whether they or their NAT administrator feels the functionality/security tradeoff is justified. While the existence of EF=A filtering may be unavoidable for the moment, hard-coding it into NATs is by no means necessary, and doing so runs counter to the basic connectivity principles the Internet was built on and which this working group was intended to promote. The ONLY objections I have heard to my proposal are based on arguments that NAT implementors will find the proposed SHOULD recommendation seriously troublesome, and that they would use that one "troublesome" recommendation as an excuse not to adopt the BEHAVE specification at all. Yet the _ONLY_ NAT vendor who has actually spoken up on this topic on the list (Suresh) confirmed my claim that making filtering behavior configurable, as proposed, should be easy for any NAT that has already implemented EF=A filtering. If a NAT vendor actually exists who will vehemently resist making filtering behavior configurable, then please get them on this list and let's hear their objections. Otherwise, I'm frankly tired of listening to and refuting long arguments about what objections some other people _not_ participating on this list _might_ have and what they _might_ do. So please write the configurability recommendation as a SHOULD for now, and let's see if any NAT vendor actually resists. Thanks, Bryan From dbarrett@quinthar.com Sun, 26 Jun 2005 16:10:33 -0700 (PDT) From: David Barrett Date: Sun, 26 Jun 2005 16:10:33 -0700 (PDT) Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02ECE8C3@zrc2hxm0.corp.nortel.com> Message-ID: <42BF35E5.5070803@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Bryan Ford wrote: > So please write the configurability recommendation as a SHOULD for > now, and let's see if any NAT vendor actually resists. Here here. From dbarrett@quinthar.com Sun, 26 Jun 2005 16:27:27 -0700 (PDT) From: David Barrett Date: Sun, 26 Jun 2005 16:27:27 -0700 (PDT) Subject: Re: Is Full-Cone NAT more appl friendly than Address-restricted Cone NAT (WAS:: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7) In-Reply-To: <20050626212027.27985.qmail@web40425.mail.yahoo.com> Message-ID: <42BF39DD.9050709@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Pyda Srisuresh wrote: The basic Internet paradigm (i.e., one without NATs) is one of free interconnection between any nodes, without requiring devious signalling. ... Any security concerns should be addressed as an > adjunt on top of the NAT deployment, just as how it is done in the > world without NATs, IMHO. I totally agree with the first. The original Internet was designed without NATs and with firewalls for a reason. NATs were introduced as a band-aid for Internet shortcomings. So from a philosophical point of view, I totally support moving back to the original Internet roots of open connectivity with targeted firewalls. However, on the second, the reality is people use NATs for security today, and thus from a practical standpoint we can't abandon them. Therefore I also support the option for address-restricted NATs. Each has a valid use. But the issue is so esoteric I'd warrant few outside this list fully grasp the implications of each. Thus I wholeheartedly support recommending that this be a configurable option, so as to save people from being shoehorned into one or the other option unintentionally, and having no easy way to correct the mistake. The only reason I could see not to provide this option would be if: 1) People overwhelmingly supported one option over the other 2) The cost of providing the option was prohibitive Criterion (1) clearly hasn't been satisfied. And the only evidence we have on the topic of (2) clearly contradicts it. Given this, it seems like an option that is both feasible and desirable, and thus I endorse its recommendation. -david From srisuresh@yahoo.com Mon, 27 Jun 2005 08:39:07 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 27 Jun 2005 08:39:07 -0700 (PDT) Subject: Re: Is Full-Cone NAT more appl friendly than Address-restricted Cone NAT (WAS:: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7) In-Reply-To: <42BF39DD.9050709@quinthar.com> Message-ID: <20050627153906.97776.qmail@web40422.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain I can go with that. cheers, suresh --- David Barrett wrote: > Pyda Srisuresh wrote: > > The basic Internet paradigm (i.e., one without NATs) is one of free > > interconnection between any nodes, without requiring devious > > signalling. ... Any security concerns should be addressed as an > > adjunt on top of the NAT deployment, just as how it is done in the > > world without NATs, IMHO. > > I totally agree with the first. The original Internet was designed > without NATs and with firewalls for a reason. NATs were introduced as a > band-aid for Internet shortcomings. So from a philosophical point of > view, I totally support moving back to the original Internet roots of > open connectivity with targeted firewalls. > > However, on the second, the reality is people use NATs for security > today, and thus from a practical standpoint we can't abandon them. > Therefore I also support the option for address-restricted NATs. > > Each has a valid use. But the issue is so esoteric I'd warrant few > outside this list fully grasp the implications of each. Thus I > wholeheartedly support recommending that this be a configurable option, > so as to save people from being shoehorned into one or the other option > unintentionally, and having no easy way to correct the mistake. > > The only reason I could see not to provide this option would be if: > 1) People overwhelmingly supported one option over the other > 2) The cost of providing the option was prohibitive > > Criterion (1) clearly hasn't been satisfied. And the only evidence we > have on the topic of (2) clearly contradicts it. > > Given this, it seems like an option that is both feasible and desirable, > and thus I endorse its recommendation. > > -david > From audet@nortel.com Mon, 27 Jun 2005 10:36:35 -0700 (PDT) From: "Francois Audet" Date: Mon, 27 Jun 2005 10:36:35 -0700 (PDT) Subject: RE: [Ietf-behave] Port scan to and from symmetric NAT'd peers Message-ID: <1ECE0EB50388174790F9694F77522CCF02FCC7A7@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Port scan to and from symmetric NAT'd peers > On Sat, 2005-06-25 at 12:54 -0700, David Barrett wrote: > > Saikat Guha wrote: > > > the new TCP connection being attempted after all ports had been > > > exhausted would timeout > > > > What does BEHAVE recommend in this scenario? > > > > Does BEHAVE recommend a minimum 'Max Flows'? > > I don't think the UDP draft has any recommendations that > address these issues. Franois? No, UDP draft doesn't. I don't think it should either. Obviously, the maxflow would be dependent of the NAT deployment. A large Enterprise NAT would have a much different requirement from a residential NAT. > > Incidentally, are there NATs with multiple external IPs? > > Mainly corporate NATs, as far as I know. Yes, even SOHO NATs. Sometime this is called "IP address pooling". From audet@nortel.com Mon, 27 Jun 2005 10:57:55 -0700 (PDT) From: "Francois Audet" Date: Mon, 27 Jun 2005 10:57:55 -0700 (PDT) Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Message-ID: <1ECE0EB50388174790F9694F77522CCF02FCC830@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 I'm sorry Bryan, but after seeing the arguments over and over again, it seems to me that we have more people in favour of the MAY versus the SHOULD. There is not much I can do about it. We did have one NAT vendor resist STRONGLY the SHOULD. We did NOT have NAT vendors resist the MAY. I will leave it as a MAY, and mark it as an Open issue for now. Cheers. > -----Original Message----- > From: Bryan Ford [mailto:baford@xxxxxxx] > Sent: Sunday, June 26, 2005 15:04 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Saikat Guha'; 'Behave' > Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 > > > On Thursday 23 June 2005 23:03, Francois Audet wrote: > > I think it is time for closure on REQ-7a. > > > > I have opted for the MAY in 7a because it doesn't look like > we can get > > consensus for the SHOULD. > > I still don't see any consensus on the MAY version either. I > am not the only > one who has spoken for promoting EF=I filtering or > configurability. With > MAY, that item says absolutely nothing and is useless. > Absolutely anything > MAY be configurable; no one needs to be told that. > > I continue to have STRONG OBJECTIONS to the publication of a > BEHAVE document > that further legitimizes the existing trend toward NATs > having "hard-coded" > EF=A filtering behavior and which seriously reducing Internet > connectivity > for all users, regardless of whether they or their NAT > administrator feels > the functionality/security tradeoff is justified. While the > existence of > EF=A filtering may be unavoidable for the moment, hard-coding > it into NATs is > by no means necessary, and doing so runs counter to the basic > connectivity > principles the Internet was built on and which this working group was > intended to promote. > > The ONLY objections I have heard to my proposal are based on > arguments that > NAT implementors will find the proposed SHOULD recommendation > seriously > troublesome, and that they would use that one "troublesome" > recommendation as > an excuse not to adopt the BEHAVE specification at all. Yet > the _ONLY_ NAT > vendor who has actually spoken up on this topic on the list (Suresh) > confirmed my claim that making filtering behavior > configurable, as proposed, > should be easy for any NAT that has already implemented EF=A > filtering. > > If a NAT vendor actually exists who will vehemently resist > making filtering > behavior configurable, then please get them on this list and > let's hear their > objections. Otherwise, I'm frankly tired of listening to and > refuting long > arguments about what objections some other people _not_ > participating on this > list _might_ have and what they _might_ do. So please write the > configurability recommendation as a SHOULD for now, and let's > see if any NAT > vendor actually resists. > > Thanks, > Bryan > > From sg266@cornell.edu Tue, 28 Jun 2005 16:22:49 -0700 (PDT) From: Saikat Guha Date: Tue, 28 Jun 2005 16:22:49 -0700 (PDT) Subject: Re: [Ietf-behave] FW: Approval to Post Version -00 Internet-Drafts for the 63rd IETF Meeting in Paris, France In-Reply-To: Message-ID: <1120000955.9613.4.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-06-17 at 09:42 -0700, Cullen Jennings wrote: > If we are going to have a WG version of TCP by Paris, we need to sort out > how we are doing that before July 5th. After going through the active TCP drafts and taking into consideration the UDP draft that is nearing consensus, my vote is to consider: draft-hoffman-behave-tcp-00.txt as the WG document for TCP behavior. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00053.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00053.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3dkdTduRmx0cWk2OTEvb1JBdkNkQUo5QVBBNUNkNEtBVmM5NE5VSGgx em01RkRNN1hBQ2VObC9uCnR5bk9PbjdaVStIVExaVVFtREpOelVjPQo9UzhENgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From audet@nortel.com Wed, 29 Jun 2005 10:33:05 -0700 (PDT) From: "Francois Audet" Date: Wed, 29 Jun 2005 10:33:05 -0700 (PDT) Subject: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF03099DAC@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt I want to draw the attention of the group to the new issue of the UDP draft. > -----Original Message----- > From: Internet-Drafts@xxxxxxxx [mailto:Internet-Drafts@xxxxxxxx] > Sent: Wednesday, June 29, 2005 09:39 > To: Audet, Francois [SC100:9T51:EXCH] > Subject: I-D ACTION:draft-ietf-behave-nat-udp-02.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. > > Title : NAT Behavioral Requirements for Unicast UDP > Author(s) : F. Audet, C. Jennings > Filename : draft-ietf-behave-nat-udp-02.txt > Pages : 25 > Date : 2005-6-28 > > This document defines basic terminology for describing different > types of NAT behavior when handling Unicast UDP, and > defines a set of > requirements that would allow many applications, such as > multimedia > communications or on-line gaming, to work consistently. > Developing > NATs that meet this set of requirements will greatly increase the > likelihood that these applications will function properly. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-02.txt > > To remove yourself from the I-D Announcement list, send a > message to i-d-announce-request@xxxxxxxx with the word > unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-behave-nat-udp-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@xxxxxxxxx > In the body type: > "FILE /internet-drafts/draft-ietf-behave-nat-udp-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > > > [The following attachment must be fetched by mail. Command-click the > URL below and send the resulting message to get the > attachment.] > [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ I-D-Announce mailing list I-D-Announce@xxxxxxxx https://www1.ietf.org/mailman/listinfo/i-d-announce From dbarrett@quinthar.com Wed, 29 Jun 2005 14:12:42 -0700 (PDT) From: David Barrett Date: Wed, 29 Jun 2005 14:12:42 -0700 (PDT) Subject: Re: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF03099DAC@zrc2hxm0.corp.nortel.com> Message-ID: <42C30EC8.4090009@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Can you explain to me the relation between the BEHAVE draft and this one? There seems to be a very high degree of overlap, and some direct conflicts. Which one speaks "for the IETF"? For example I couldn't help but note the first requirement: REQ-1: A NAT MUST have an "External NAT mapping is endpoint independent" behavior. This is taking a *much* stronger position than BEHAVE draft. Whether one agrees or disagrees with this individual requirement, I think we can all agree that it's best to have one set of NAT requirements rather than fragmenting into different drafts. -david Francois Audet wrote: I want to draw the attention of the group to the new issue of the UDP draft. > -----Original Message----- > From: Internet-Drafts@xxxxxxxx [mailto:Internet-Drafts@xxxxxxxx] > Sent: Wednesday, June 29, 2005 09:39 > To: Audet, Francois [SC100:9T51:EXCH] > Subject: I-D ACTION:draft-ietf-behave-nat-udp-02.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. > > Title : NAT Behavioral Requirements for Unicast UDP > Author(s) : F. Audet, C. Jennings > Filename : draft-ietf-behave-nat-udp-02.txt > Pages : 25 > Date : 2005-6-28 > > This document defines basic terminology for describing different > types of NAT behavior when handling Unicast UDP, and > defines a set of > requirements that would allow many applications, such as > multimedia > communications or on-line gaming, to work consistently. > Developing > NATs that meet this set of requirements will greatly increase the > likelihood that these applications will function properly. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-02.txt > > To remove yourself from the I-D Announcement list, send a > message to i-d-announce-request@xxxxxxxx with the word > unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-behave-nat-udp-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@xxxxxxxxx > In the body type: > "FILE /internet-drafts/draft-ietf-behave-nat-udp-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > > > [The following attachment must be fetched by mail. Command-click the > URL below and send the resulting message to get the > attachment.] > [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ I-D-Announce mailing list I-D-Announce@xxxxxxxx https://www1.ietf.org/mailman/listinfo/i-d-announce ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Wed, 29 Jun 2005 14:43:15 -0700 (PDT) From: "Francois Audet" Date: Wed, 29 Jun 2005 14:43:15 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF0309A2F2@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt This IS the Behave UDP draft. It's the update to draft-ietf-behave-nat-udp-01 based on the list discussion. The requirement you quote has NOT changed from draft-ietf-behave-nat-udp-01. In fact, it hasn't changed from draft-ietf-behave-nat-udp-00 in IETF 62. It hasn't even changed from draft-ietf-behave-nat-00 in IETF 61. It hasn't even changed from the very first individual draft presesent in IETGF 60, draft-audet-nat-behave-00. So I'm not sure what you are talking about. > -----Original Message----- > From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] > Sent: Wednesday, June 29, 2005 14:13 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Re: [Ietf-behave] FW: I-D > ACTION:draft-ietf-behave-nat-udp-02.txt > > > Can you explain to me the relation between the BEHAVE draft and this > one? There seems to be a very high degree of overlap, and > some direct > conflicts. Which one speaks "for the IETF"? For example I couldn't > help but note the first requirement: > > > REQ-1: A NAT MUST have an "External NAT mapping is endpoint > > independent" behavior. > > This is taking a *much* stronger position than BEHAVE draft. Whether > one agrees or disagrees with this individual requirement, I > think we can > all agree that it's best to have one set of NAT requirements > rather than > fragmenting into different drafts. > > -david > > Francois Audet wrote: > > I want to draw the attention of the group to the > > new issue of the UDP draft. > > > > > -----Original Message----- > > > From: Internet-Drafts@xxxxxxxx > [mailto:Internet-Drafts@xxxxxxxx] > > > Sent: Wednesday, June 29, 2005 09:39 > To: Audet, Francois > > [SC100:9T51:EXCH] > Subject: I-D > > ACTION:draft-ietf-behave-nat-udp-02.txt > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. This draft is a work item of the > > > Behavior Engineering for Hindrance > Avoidance Working > Group of the > > IETF. > > > > Title : NAT Behavioral Requirements for > Unicast UDP > > > Author(s) : F. Audet, C. Jennings > > > Filename : draft-ietf-behave-nat-udp-02.txt > > > Pages : 25 > > > Date : 2005-6-28 > > > > > > This document defines basic terminology for describing different > > > types of NAT behavior when handling Unicast UDP, and > > > defines a set of > > > requirements that would allow many applications, such as > > > multimedia > > > communications or on-line gaming, to work consistently. > > > Developing > > > NATs that meet this set of requirements will greatly > increase the > > > likelihood that these applications will function properly. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-02.txt > > > > > > To remove yourself from the I-D Announcement list, send a > > > message to i-d-announce-request@xxxxxxxx with the word > > > unsubscribe in the body > > > of the message. > > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > with the username "anonymous" and a password of your e-mail > > > address. After logging in, type "cd internet-drafts" and then > > > "get draft-ietf-behave-nat-udp-02.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@xxxxxxxxx > > > In the body type: > > > "FILE /internet-drafts/draft-ietf-behave-nat-udp-02.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. > To use this > > > feature, insert the command "ENCODING mime" before > the "FILE" > > > command. To decode the response(s), you will need > "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant > > > mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which > have been split > > > up into multiple messages), so check your local > documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail > > > reader implementation to automatically retrieve the ASCII > > > version of the Internet-Draft. > > > > > > > > > [The following attachment must be fetched by mail. > Command-click the > > > URL below and send the resulting message to get the > > > attachment.] > > > > ternet-drafts/draft-ietf-behave-nat-udp-02.txt> > > [The following attachment must be fetched by ftp. Command-click the > > URL below to ask your ftp client to fetch it.] > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From dbarrett@quinthar.com Wed, 29 Jun 2005 15:01:26 -0700 (PDT) From: David Barrett Date: Wed, 29 Jun 2005 15:01:26 -0700 (PDT) Subject: Re: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0309A2F2@zrc2hxm0.corp.nortel.com> Message-ID: <42C31A30.5060608@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain OOPS! My mistake. I'm sorry, I was thinking this was some alternate draft. *blush* Nevermind. Francois Audet wrote: This IS the Behave UDP draft. It's the update to draft-ietf-behave-nat-udp-01 based on the list discussion. The requirement you quote has NOT changed from draft-ietf-behave-nat-udp-01. In fact, it hasn't changed from draft-ietf-behave-nat-udp-00 in IETF 62. It hasn't even changed from draft-ietf-behave-nat-00 in IETF 61. It hasn't even changed from the very first individual draft presesent in IETGF 60, draft-audet-nat-behave-00. So I'm not sure what you are talking about. > -----Original Message----- > From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] > Sent: Wednesday, June 29, 2005 14:13 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Re: [Ietf-behave] FW: I-D > ACTION:draft-ietf-behave-nat-udp-02.txt > > > Can you explain to me the relation between the BEHAVE draft and this > one? There seems to be a very high degree of overlap, and > some direct > conflicts. Which one speaks "for the IETF"? For example I couldn't > help but note the first requirement: > > > REQ-1: A NAT MUST have an "External NAT mapping is endpoint > > independent" behavior. > > This is taking a *much* stronger position than BEHAVE draft. Whether > one agrees or disagrees with this individual requirement, I > think we can > all agree that it's best to have one set of NAT requirements > rather than > fragmenting into different drafts. > > -david > > Francois Audet wrote: > > I want to draw the attention of the group to the > > new issue of the UDP draft. > > > > > -----Original Message----- > > > From: Internet-Drafts@xxxxxxxx > [mailto:Internet-Drafts@xxxxxxxx] > > > Sent: Wednesday, June 29, 2005 09:39 > To: Audet, Francois > > [SC100:9T51:EXCH] > Subject: I-D > > ACTION:draft-ietf-behave-nat-udp-02.txt > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. This draft is a work item of the > > > Behavior Engineering for Hindrance > Avoidance Working > Group of the > > IETF. > > > > Title : NAT Behavioral Requirements for > Unicast UDP > > > Author(s) : F. Audet, C. Jennings > > > Filename : draft-ietf-behave-nat-udp-02.txt > > > Pages : 25 > > > Date : 2005-6-28 > > > > > > This document defines basic terminology for describing different > > > types of NAT behavior when handling Unicast UDP, and > > > defines a set of > > > requirements that would allow many applications, such as > > > multimedia > > > communications or on-line gaming, to work consistently. > > > Developing > > > NATs that meet this set of requirements will greatly > increase the > > > likelihood that these applications will function properly. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-02.txt > > > > > > To remove yourself from the I-D Announcement list, send a > > > message to i-d-announce-request@xxxxxxxx with the word > > > unsubscribe in the body > > > of the message. > > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > with the username "anonymous" and a password of your e-mail > > > address. After logging in, type "cd internet-drafts" and then > > > "get draft-ietf-behave-nat-udp-02.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@xxxxxxxxx > > > In the body type: > > > "FILE /internet-drafts/draft-ietf-behave-nat-udp-02.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. > To use this > > > feature, insert the command "ENCODING mime" before > the "FILE" > > > command. To decode the response(s), you will need > "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant > > > mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which > have been split > > > up into multiple messages), so check your local > documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail > > > reader implementation to automatically retrieve the ASCII > > > version of the Internet-Draft. > > > > > > > > > [The following attachment must be fetched by mail. > Command-click the > > > URL below and send the resulting message to get the > > > attachment.] > > > > ternet-drafts/draft-ietf-behave-nat-udp-02.txt> > > [The following attachment must be fetched by ftp. Command-click the > > URL below to ask your ftp client to fetch it.] > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From ssenthil@cisco.com Wed, 29 Jun 2005 16:12:40 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Wed, 29 Jun 2005 16:12:40 -0700 (PDT) Subject: RE: [Ietf-behave] Port scan to and from symmetric NAT'd peers Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB47F81B@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > David Barrett > Sent: Friday, June 24, 2005 10:06 PM > To: 'Behave' > Subject: [Ietf-behave] Port scan to and from symmetric NAT'd peers > > So I'm about to embark on implementing my symmetric NAT > piercing tech, and I'm having trouble learning about how port > scans and NATs combine both today, as well as under the IETF > BEHAVE recommendations. Can you help me to understand: > > 1) If a symmetric NAT assigns different external ports to > each outgoing UDP request in round-robin fashion, what > happens if there aren't enough ports to go around? How does > it pick which mappings to override? > > For example, I am behind a symmetric NAT, and I contact 65537 > external nodes, there simply aren't enough port mappings to > accomodate all sessions. If it uses a simple "least recently > used" approach, would I in effect deny service to every other > node behind my NAT (by remapping their ports to me)? Or is > there some kind of hard limit on the number of ports that > will be assigned to a given endpoint? There are NAT implementations that could limit sessions per host/user. Typically the LRU is driven by a configurable timer which the draft-sivakumar-behave-nat-tcp-req-01.txt specifies. Even though the exact timers values cannot be specified in some cases a guideline should be issued by behave. Senthil > > > 2) Do symmetric (or any) NATs use the full range (0-65535) of > extenal port mappings, or do they avoid certain "special" > ranges (such as 0-1023)? Thus if I'm trying to scan a > symmetric NAT to find any nodes behind it, need I (in the > worst case) scan the entire range (0-65535) or can I target > my scan better? > The implementations differ. Some use the high range of ports and after exhaustion they move to the next address and use the higher range if available or try to use the low range of ports. I think there is a lot of inconsistency in behavior and hence behave should provide some guidelines. UDP draft provides some guidelines in this context. > > 3) Given the fuzzy line between NATs and firewalls, do NATs > typically perform any sort of "attack detection" and thus > block activities such as port scanning, whether inbound or > outbound? Naturally, this would depend on the > implementation, but I'm curious if you are aware of > implementations that do this today, or if the BEHAVE draft > makes any recommendations around this type of functionality. > > > 4) Do you have any advice for me regarding how to effectively > pierce symmetric NATs while remaining a "good citizen" of the > Internet? > Naturally, port-scanning is a horrible solution to the > problem of piercing symmetric NATs, but it's the only one of > which I'm aware. Can you offer me any advice on how to > target my scan most effectively, structure my scan to avoid > setting off any alarms, or do away with the scan altogether? > > > Thanks for your help! > > -david > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From baford@mit.edu Thu, 30 Jun 2005 00:01:40 -0700 (PDT) From: Bryan Ford Date: Thu, 30 Jun 2005 00:01:40 -0700 (PDT) Subject: [Ietf-behave] Vote on REQ-7 (was Re: draft-ietf-behave-nat-udp-01, REQ-7) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02FCC830@zrc2hxm0.corp.nortel.com> Message-ID: <200506300901.18551.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Monday 27 June 2005 19:57, Francois Audet wrote: > I'm sorry Bryan, but after seeing the arguments over and over again, it > seems to me that we have more people in favour of the MAY versus the > SHOULD. There is not much I can do about it. How did you figure that? If we're counting votes, then from the recent discussion on this thread here's how it looks to me: SHOULD: 3 - me, David, Suresh MAY: 2 - you (presumably), Saikat Cullen objected to the earlier "user-configurable" language, but hasn't said a peep since we changed the language to "administrator-configurable" specifically to address that concern. At any rate, at the moment I see no clear majority in favor off MAY. So let's see what the situation actually is - if you're right, then I'll shut up and we can all have blessed peace (or a different battle :)). So I'm calling a vote on REQ-7(a). Everyone who has an opinion on this and isn't already in the tally above (or who I may have mis-tallied), please express it - all your message needs to have is the above subject line and an obvious "MAY" or "SHOULD" in the body. To review: MAY := "a) The filtering behavior MAY be an option configurable by the administrator of the NAT." SHOULD := "a) The filtering behavior SHOULD be an option configurable by the administrator of the NAT." I propose giving a week - say through July 6 - for the votes to trickle in. > We did have one NAT vendor resist STRONGLY the SHOULD. We did NOT have NAT > vendors resist the MAY. I don't remember any such statement by a NAT vendor here - can you point me to the relevant message on the list? Thanks, Bryan From baford@mit.edu Thu, 30 Jun 2005 00:04:05 -0700 (PDT) From: Bryan Ford Date: Thu, 30 Jun 2005 00:04:05 -0700 (PDT) Subject: Re: [Ietf-behave] FW: Approval to Post Version -00 =?utf-8?q?Internet-Drafts=09for_the_63rd_IETF_Meeting_in?= Paris, France In-Reply-To: Message-ID: <200506300904.03479.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Fri, 2005-06-17 at 09:42 -0700, Cullen Jennings wrote: > If we are going to have a WG version of TCP by Paris, we need to sort out > how we are doing that before July 5th. I vote for adopting: draft-ford-behave-gen-01.txt, and draft-sivakumar-behave-nat-tcp-01.txt as working group drafts. Bryan From dbarrett@quinthar.com Thu, 30 Jun 2005 01:09:19 -0700 (PDT) From: David Barrett Date: Thu, 30 Jun 2005 01:09:19 -0700 (PDT) Subject: Re: [Ietf-behave] Vote on REQ-7 (was Re: draft-ietf-behave-nat-udp-01, REQ-7) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02FCC830@zrc2hxm0.corp.nortel.com> Message-ID: <42C3A8A8.20108@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Bryan Ford wrote: MAY := "a) The filtering behavior MAY be an option configurable by the administrator of the NAT." SHOULD := "a) The filtering behavior SHOULD be an option configurable by the administrator of the NAT." Bryan tallied my vote correctly, but just so there's no confusion: I vote "SHOULD". From ssenthil@cisco.com Thu, 30 Jun 2005 06:49:44 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Thu, 30 Jun 2005 06:49:44 -0700 (PDT) Subject: RE: [Ietf-behave] Port scan to and from symmetric NAT'd peers Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB47F89A@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > David Barrett > Sent: Friday, June 24, 2005 10:06 PM > To: 'Behave' > Subject: [Ietf-behave] Port scan to and from symmetric NAT'd peers > > So I'm about to embark on implementing my symmetric NAT > piercing tech, and I'm having trouble learning about how port > scans and NATs combine both today, as well as under the IETF > BEHAVE recommendations. Can you help me to understand: > > 1) If a symmetric NAT assigns different external ports to > each outgoing UDP request in round-robin fashion, what > happens if there aren't enough ports to go around? How does > it pick which mappings to override? > > For example, I am behind a symmetric NAT, and I contact 65537 > external nodes, there simply aren't enough port mappings to > accomodate all sessions. If it uses a simple "least recently > used" approach, would I in effect deny service to every other > node behind my NAT (by remapping their ports to me)? Or is > there some kind of hard limit on the number of ports that > will be assigned to a given endpoint? There are NAT implementations that could limit sessions per host/user. Typically the LRU is driven by a configurable timer which the draft-sivakumar-behave-nat-tcp-req-01.txt specifies. Even though the exact timers values cannot be specified in some cases a guideline should be issued by behave. Senthil > > > 2) Do symmetric (or any) NATs use the full range (0-65535) of > extenal port mappings, or do they avoid certain "special" > ranges (such as 0-1023)? Thus if I'm trying to scan a > symmetric NAT to find any nodes behind it, need I (in the > worst case) scan the entire range (0-65535) or can I target > my scan better? > The implementations differ. Some use the high range of ports and after exhaustion they move to the next address and use the higher range if available or try to use the low range of ports. I think there is a lot of inconsistency in behavior and hence behave should provide some guidelines. UDP draft provides some guidelines in this context. > > 3) Given the fuzzy line between NATs and firewalls, do NATs > typically perform any sort of "attack detection" and thus > block activities such as port scanning, whether inbound or > outbound? Naturally, this would depend on the > implementation, but I'm curious if you are aware of > implementations that do this today, or if the BEHAVE draft > makes any recommendations around this type of functionality. > > > 4) Do you have any advice for me regarding how to effectively > pierce symmetric NATs while remaining a "good citizen" of the > Internet? > Naturally, port-scanning is a horrible solution to the > problem of piercing symmetric NATs, but it's the only one of > which I'm aware. Can you offer me any advice on how to > target my scan most effectively, structure my scan to avoid > setting off any alarms, or do away with the scan altogether? > > > Thanks for your help! > > -david > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From sg266@cornell.edu Thu, 30 Jun 2005 15:20:37 -0700 (PDT) From: Saikat Guha Date: Thu, 30 Jun 2005 15:20:37 -0700 (PDT) Subject: Re: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF03099DAC@zrc2hxm0.corp.nortel.com> Message-ID: <1120169833.10321.10.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-06-29 at 13:32 -0400, Francois Audet wrote: > I want to draw the attention of the group to the > new issue of the UDP draft. Few notes ... some from dangling threads and some new (so there is one place to look up the issues) 1) (old) -- REQ7a. 'nuff said. 2) (old) -- Clarification: The ICMP timeout in REQ-11a is still unclear to me. I realize Cullen is on vacation. Just a reminder. 3) (new) -- Confusing terminology: > REQ-11: It is RECOMMENDED that a NAT support ICMP Destination > Unreachable. At first glance, I seems this just asks the NAT to support ICMP Type=3 (Type=3 is Destination Unreachable). As defined earlier, however, "Support Destination Unreachable" actually means "A NAT which performs the functions described in [section 9]" which includes "Receipt of *any* sort of ICMP message MUST NOT destroy the NAT mapping." (emphasis mine). It seems unclear if REQ-11 is for all ICMPs or just Destination unreachable. In any case, changing the terminology to "Support ICMP Translations" or "Support ICMP Processing" etc would avoid this confusing. Also, if you really meant just ICMP Destination Unreachable in REQ-11, then the other requirements from the paragraph should also be summarized: REQ-11: Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping. a) The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address. b) It is RECOMMENDED that a NAT support ICMP Destination Unreachable messages. c) The ICMP timeout SHOULD be greater than 2 seconds. or more concisely as, REQ-11: It is RECOMMENDED that a NAT support ICMP Processing. a) The ICMP timeout SHOULD be greater than 2 seconds. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00054.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00054.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3hHOW9uRmx0cWk2OTEvb1JBcWhlQUo0b2xJckNzak1xTkR5MnlwUWpP VHdnTjJJRTJnQ2ZWaGlZCkJPQzU1QVE3N09IYWp0eWV3RjYvTDhJPQo9RVA0YgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From audet@nortel.com Thu, 30 Jun 2005 17:12:46 -0700 (PDT) From: "Francois Audet" Date: Thu, 30 Jun 2005 17:12:46 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF030F769A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I am OK with your proposed clarification for REQ-11, which is basically to change the term "support ICMP Destination Unreachable" terminology with "support ICMP processing". I'm also OK with your alternative with the explicit sub-bullets. Dan, you wrote this. Are you OK with the suggestion? > -----Original Message----- > From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] > Sent: Thursday, June 30, 2005 15:17 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Re: [Ietf-behave] FW: I-D > ACTION:draft-ietf-behave-nat-udp-02.txt > > > On Wed, 2005-06-29 at 13:32 -0400, Francois Audet wrote: > > I want to draw the attention of the group to the > > new issue of the UDP draft. > > Few notes ... some from dangling threads and some new > (so there is one place to look up the issues) > > 1) (old) -- REQ7a. > 'nuff said. > > > 2) (old) -- Clarification: > The ICMP timeout in REQ-11a is still unclear to me. I realize > Cullen is on vacation. Just a reminder. > > > 3) (new) -- Confusing terminology: > > REQ-11: It is RECOMMENDED that a NAT support ICMP Destination > > Unreachable. > > At first glance, I seems this just asks the NAT to support > ICMP Type=3 (Type=3 is Destination Unreachable). > > As defined earlier, however, "Support Destination > Unreachable" actually means "A NAT which performs the > functions described in [section 9]" which includes "Receipt > of *any* sort of ICMP message MUST NOT destroy the NAT > mapping." (emphasis mine). It seems unclear if REQ-11 is for > all ICMPs or just Destination unreachable. > > In any case, changing the terminology to "Support ICMP > Translations" or "Support ICMP Processing" etc would avoid > this confusing. Also, if you really meant just ICMP > Destination Unreachable in REQ-11, then the other > requirements from the paragraph should also be summarized: > > REQ-11: Receipt of any sort of ICMP message MUST NOT destroy the NAT > mapping. > a) The NAT's default configuration SHOULD NOT filter ICMP messages > based on their source IP address. > b) It is RECOMMENDED that a NAT support ICMP Destination > Unreachable messages. > c) The ICMP timeout SHOULD be greater than 2 seconds. > > or more concisely as, > > REQ-11: It is RECOMMENDED that a NAT support ICMP Processing. > a) The ICMP timeout SHOULD be greater than 2 seconds. > > > -- > Saikat > From ssenthil@cisco.com Sun, 3 Jul 2005 10:58:42 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Sun, 3 Jul 2005 10:58:42 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB517E27@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > REQ-11: It is RECOMMENDED that a NAT support ICMP Processing. > a) The ICMP timeout SHOULD be greater than 2 seconds. > The above is vague, it does not specify exactly what the requirement is. IMO, the requirement is that NAT should not delete any mapping as a result of seeing Destination unreachable. BTW, how was the timeout of 2 secs derived? Senthil > > -- > Saikat > From sg266@cornell.edu Sun, 3 Jul 2005 14:13:34 -0700 (PDT) From: Saikat Guha Date: Sun, 3 Jul 2005 14:13:34 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB517E27@xmb-sjc-236.amer.cisco.com> Message-ID: <1120425195.5293.17.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-07-03 at 10:58 -0700, Senthil Sivakumar (ssenthil) wrote: > > REQ-11: It is RECOMMENDED that a NAT support ICMP Processing. > > a) The ICMP timeout SHOULD be greater than 2 seconds. > > The above is vague, it does not specify exactly what the requirement is. > IMO, the requirement is that NAT should not delete any mapping as a > result of seeing Destination unreachable. The requirement actually is much stronger -- the NAT shouldn't delete the mapping as a result of any ICMP packet; the details being in section 9. But I agree with you and would prefer something similar to the long form with the explicit sub-bullets. > BTW, how was the timeout of 2 > secs derived? *shrug* What's the timeout for, even? -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00055.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00055.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3lGVHFuRmx0cWk2OTEvb1JBaklXQUo0MUM4bTJSaEV5TUZpY0JBZVB2 WlNaWWUwckpRQ2FBd3N3CjkralJ0SFQ1YzZEV0htbW9IZDBrcGE0PQo9MXgragotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From ssenthil@cisco.com Mon, 4 Jul 2005 08:06:25 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Mon, 4 Jul 2005 08:06:25 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB517E43@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] > Sent: Sunday, July 03, 2005 5:13 PM > To: Senthil Sivakumar (ssenthil) > Cc: Francois Audet; Behave > Subject: RE: [Ietf-behave] FW: I-D > ACTION:draft-ietf-behave-nat-udp-02.txt > > On Sun, 2005-07-03 at 10:58 -0700, Senthil Sivakumar (ssenthil) wrote: > > > REQ-11: It is RECOMMENDED that a NAT support ICMP Processing. > > > a) The ICMP timeout SHOULD be greater than 2 seconds. > > > > The above is vague, it does not specify exactly what the > requirement is. > > IMO, the requirement is that NAT should not delete any mapping as a > > result of seeing Destination unreachable. > > The requirement actually is much stronger -- the NAT > shouldn't delete the mapping as a result of any ICMP packet; > the details being in section 9. But I agree with you and > would prefer something similar to the long form with the > explicit sub-bullets. Me too. > > > BTW, how was the timeout of 2 > > secs derived? > > *shrug* What's the timeout for, even? > I was just curious to understand if the 2 secs was based on some data/testing. Timeouts are definitely needed otherwise you would be consuming the resources of the box. The question is what is a reasonable timeout for ICMP.. Two seconds seem awfully low to me. Senthil > -- > Saikat > From paul.hoffman@cybersecurity.org Mon, 4 Jul 2005 15:02:38 -0700 (PDT) From: Paul Hoffman Date: Mon, 4 Jul 2005 15:02:38 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB517E43@xmb-sjc-236.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 8:06 AM -0700 7/4/05, Senthil Sivakumar (ssenthil) wrote: Timeouts are definitely needed otherwise you would be consuming the resources of the box. Fully disagree. Timeouts are completely unnecessary on a system that watches its resources and, when a resource gets close to full, starts to discard based on a sensible algorithm (which could be "oldest" in almost all cases). Trying to guess what a good/reasonable time for a timer without a lot of research is not engineering. --Paul Hoffman, Director --Cybersecurity Association --www.cybersecurity.org From ssenthil@cisco.com Mon, 4 Jul 2005 16:07:02 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Mon, 4 Jul 2005 16:07:02 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB517E53@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Paul Hoffman > Sent: Monday, July 04, 2005 6:03 PM > To: Behave > Subject: RE: [Ietf-behave] FW: I-D > ACTION:draft-ietf-behave-nat-udp-02.txt > > At 8:06 AM -0700 7/4/05, Senthil Sivakumar (ssenthil) wrote: > >Timeouts are definitely needed otherwise you would be consuming the > >resources of the box. > > Fully disagree. Timeouts are completely unnecessary on a > system that watches its resources and, when a resource gets > close to full, starts to discard based on a sensible > algorithm (which could be "oldest" in almost all cases). > Disagree as well. Using the resources for longer than necessary is not good engineering either. In this case we are talking about ICMP mappings and you are going to let the ICMP mappings stay and consume the resources of the box until the box runs "close to full"? We have defined timeouts through out the behave drafts - basically those are all unnecessary? Can you point me to a NAT implementation that does it the way you have mentioned? > Trying to guess what a good/reasonable time for a timer > without a lot of research is not engineering. That is the reason for question of 2 seconds. > > --Paul Hoffman, Director > --Cybersecurity Association > --www.cybersecurity.org > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From paul.hoffman@cybersecurity.org Mon, 4 Jul 2005 16:33:21 -0700 (PDT) From: Paul Hoffman Date: Mon, 4 Jul 2005 16:33:21 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB517E53@xmb-sjc-236.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 4:07 PM -0700 7/4/05, Senthil Sivakumar (ssenthil) wrote: Disagree as well. Using the resources for longer than necessary is not good engineering either. We agree there. However, no one has defined "longer than necessary". Picking a length of time without any backing from either the RFCs or experimentation can't answer that. In this case we are talking about ICMP mappings and you are going to let the ICMP mappings stay and consume the resources of the box until the box runs "close to full"? No, that's now what I said. I explicitly said "when a resource gets close to full". You don't toss all the resources into one memory heap: different mappings have different buffers, and when you put something into a buffer, you check if that buffer is getting close to full. This is a completely common programming technique used by nearly every network device vendor. We have defined timeouts through out the behave drafts I'm not sure who you mean by "we". See section 4 of draft-hoffman-behave-tcp-00.txt for a counter-example. - basically those are all unnecessary? Correct, unless they match a timer in the RFC that defines the protocol in question, or they are taken from some research that people agree is complete and well-founded. --Paul Hoffman, Director --Cybersecurity Association --www.cybersecurity.org From ssenthil@cisco.com Mon, 4 Jul 2005 17:05:15 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Mon, 4 Jul 2005 17:05:15 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB517E55@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Paul Hoffman > Sent: Monday, July 04, 2005 7:33 PM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] FW: I-D > ACTION:draft-ietf-behave-nat-udp-02.txt > > At 4:07 PM -0700 7/4/05, Senthil Sivakumar (ssenthil) wrote: > >Disagree as well. Using the resources for longer than > necessary is not > >good engineering either. > > We agree there. However, no one has defined "longer than necessary". > Picking a length of time without any backing from either the > RFCs or experimentation can't answer that. > > >In this case we are talking about ICMP mappings and you are going to > >let the ICMP mappings stay and consume the resources of the > box until > >the box runs "close to full"? > > No, that's now what I said. I explicitly said "when a > resource gets close to full". You don't toss all the > resources into one memory > heap: different mappings have different buffers, and when you > put something into a buffer, you check if that buffer is > getting close to full. This is a completely common > programming technique used by nearly every network device vendor. Really? I have worked on two implementations neither of them use a different buffer for each protocol. > > >We have defined > >timeouts through out the behave drafts > > I'm not sure who you mean by "we". See section 4 of > draft-hoffman-behave-tcp-00.txt for a counter-example. > The draft here in question defines timeouts for udp mappings. The draft-sivakumar-behave-nat-tcp-req-01.txt has recommendations for tcp mappings. Another reason why I believe the above draft you mentioned is not detailed enough for TCP behavior. Senthil > >- basically those are all > >unnecessary? > > Correct, unless they match a timer in the RFC that defines > the protocol in question, or they are taken from some > research that people agree is complete and well-founded. > > --Paul Hoffman, Director > --Cybersecurity Association > --www.cybersecurity.org > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Tue, 5 Jul 2005 01:25:11 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 5 Jul 2005 01:25:11 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB517E43@xmb-sjc-236.amer.cisco.com> Message-ID: <20050705082510.88074.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Francois, What is the timeout you are refering to in this requirement (Req#11)? Why do you need to time anything when forwardign an ICMP error message? Also, the text in section 9 refers to "UDP mapping" and labels the NAT that forwards ICMP error messages as "UDP Support Destination Unreachable". Why do you believe, this is a UDP-only support characteristic? Is this not applicable to both TCP and UDP? Further, do you believe, a NAT is considered to support ICMP Destination unreachable messages if it simply forwarded error messages between domains? Shouldnt a NAT be capable of generating ICMP error messages as well? cheers, suresh --- "Senthil Sivakumar (ssenthil)" wrote: > > > > -----Original Message----- > > From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] > > Sent: Sunday, July 03, 2005 5:13 PM > > To: Senthil Sivakumar (ssenthil) > > Cc: Francois Audet; Behave > > Subject: RE: [Ietf-behave] FW: I-D > > ACTION:draft-ietf-behave-nat-udp-02.txt > > > > On Sun, 2005-07-03 at 10:58 -0700, Senthil Sivakumar (ssenthil) wrote: > > > > REQ-11: It is RECOMMENDED that a NAT support ICMP Processing. > > > > a) The ICMP timeout SHOULD be greater than 2 seconds. > > > > > > The above is vague, it does not specify exactly what the > > requirement is. > > > IMO, the requirement is that NAT should not delete any mapping as a > > > result of seeing Destination unreachable. > > > > The requirement actually is much stronger -- the NAT > > shouldn't delete the mapping as a result of any ICMP packet; > > the details being in section 9. But I agree with you and > > would prefer something similar to the long form with the > > explicit sub-bullets. > > Me too. > > > > > > BTW, how was the timeout of 2 > > > secs derived? > > > > *shrug* What's the timeout for, even? > > > > I was just curious to understand if the 2 secs was based on some > data/testing. Timeouts are definitely needed otherwise you would be > consuming the resources of the box. The question is what is a reasonable > timeout for ICMP.. Two seconds seem awfully low to me. > > Senthil > > > -- > > Saikat > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Tue, 5 Jul 2005 01:40:16 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 5 Jul 2005 01:40:16 -0700 (PDT) Subject: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050705082510.88074.qmail@web40429.mail.yahoo.com> Message-ID: <20050705084015.4338.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Francois, You have section 4.3 refering to "Mapping Refresh" behavior and a req-6 that follows it. And, section 5.2 refering to "Filter refresh" with no requirement that follows it. Why does section 5.2 have no requirement associated with it? Also, w.r.t. req-6, why is the refresh required only on the outbound? cheers, suresh From srisuresh@yahoo.com Tue, 5 Jul 2005 02:00:42 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 5 Jul 2005 02:00:42 -0700 (PDT) Subject: [Ietf-behave] Fragment ation support (Req-13 & Req-12) In-Reply-To: <20050705084015.4338.qmail@web40427.mail.yahoo.com> Message-ID: <20050705090042.91236.qmail@web40428.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Francois, Req-13 (A NAt must support receiving in-order fragments) is not the WG consensus, AFAIK. Fragement processign is not limited to in-order fragments. As for Req-12, why is NAT support of fragmentation restricted to link MTU criteria? Are you referign to immediate link MTU? The discussion we had on outbound fragmentation addressed much more than you mention here. Also, what is the "ICMP section" you refer to in section 10.2? cheers, suresh From audet@nortel.com Wed, 6 Jul 2005 15:48:27 -0700 (PDT) From: "Francois Audet" Date: Wed, 6 Jul 2005 15:48:27 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF031E7470@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Did we agree on the following for REQ-11? REQ-11: Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping. a) The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address. b) It is RECOMMENDED that a NAT support ICMP Destination Unreachable messages. c) The ICMP timeout SHOULD be greater than 2 seconds. Or are people still questioning c), and if so what would be the proposal. From audet@nortel.com Wed, 6 Jul 2005 15:50:17 -0700 (PDT) From: "Francois Audet" Date: Wed, 6 Jul 2005 15:50:17 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <1ECE0EB50388174790F9694F77522CCF031E7478@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain > Francois, > > You have section 4.3 refering to "Mapping Refresh" behavior > and a req-6 that follows it. And, section 5.2 refering to > "Filter refresh" with no requirement that follows it. Please go read the archive for why we don't have a requirement for Filter refresh. > Why does section 5.2 have no requirement associated with it? Because people don't think we need one. > Also, w.r.t. req-6, why is the refresh required only on the outbound? Please go read the archives. We discussed this before. From audet@nortel.com Wed, 6 Jul 2005 16:11:16 -0700 (PDT) From: "Francois Audet" Date: Wed, 6 Jul 2005 16:11:16 -0700 (PDT) Subject: RE: [Ietf-behave] Fragment ation support (Req-13 & Req-12) Message-ID: <1ECE0EB50388174790F9694F77522CCF031E74C5@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pyda Srisuresh > Sent: Tuesday, July 05, 2005 02:01 > To: Behave > Subject: [Ietf-behave] Fragment ation support (Req-13 & Req-12) > > > Francois, > > Req-13 (A NAt must support receiving in-order fragments) is > not the WG consensus, AFAIK. Fragement processign is not > limited to in-order fragments. AFAIK, it is the consensus of the group. If you feel it is not, please substantiate, AND provide an alternative for which you will have gathered concensus from the group. > As for Req-12, why is NAT support of fragmentation restricted > to link MTU criteria? Are you referign to immediate link MTU? > The discussion we had on outbound fragmentation addressed > much more than you mention here. Feel free to propose alternative text for which you will have gathered consensus from the group. > Also, what is the "ICMP > section" you refer to in section 10.2? That would be section 9, entitled "ICMP Destination Unreachable Behavior" (which seems quite obvious to me, but I'll spell it out). From paul.hoffman@cybersecurity.org Wed, 6 Jul 2005 16:28:07 -0700 (PDT) From: Paul Hoffman Date: Wed, 6 Jul 2005 16:28:07 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF031E7470@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 5:48 PM -0500 7/6/05, Francois Audet wrote: c) The ICMP timeout SHOULD be greater than 2 seconds. Or are people still questioning c), and if so what would be the proposal. I disagree with such a short timeout. Why not 2 minutes (or shorter, only if the NAT's ICMP message buffer is running out of space)? If the ICMP responder is busy doing something else, and waits 2.1 seconds, and the sender has thrown away the state, this would cause unexpected behavior. If the 2 seconds is specified in the ICMP spec, that's fine; otherwise, we should stretch out as far as we can. --Paul Hoffman, Director --Cybersecurity Association --www.cybersecurity.org From sg266@cornell.edu Wed, 6 Jul 2005 16:39:10 -0700 (PDT) From: Saikat Guha Date: Wed, 6 Jul 2005 16:39:10 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF031E7470@zrc2hxm0.corp.nortel.com> Message-ID: <1120693128.5126.38.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-07-06 at 17:48 -0500, Francois Audet wrote: > c) The ICMP timeout SHOULD be greater than 2 seconds. > > Or are people still questioning c), and if so what would be the > proposal. Perhaps I am just being obtuse, but I really don't understand requirement c). See my point #10 in http://list.sipfoundry.org/archive/ietf-behave/msg00759.html In any event, I agree with Paul that there should be no timer unless an RFC for the ICMP protocol defines one for the particular case ... and I do not know what the particular timer is for so I cannot say either yay or nay. Some timers that might be relevant based on intent: Intent #1: Handling an inbound ICMP packet in response to an outbound TCP/UDP packet -- The maximum time an in-flight packet is considered alive is 2 minutes (RFC 1122). So it may take at most 4 minutes for can ICMP to come back. ... But the encapsulated IP packet inside the ICMP will have all the data needed to route the packet (as long as the mapping is alive) ... so there is no point specifying the timeout if this is the intent. Intent #2: Preventing packet storms; ICMP rate-limiting -- RFC 2521 says ICMP's should be rate limited but the timer is "left to the implementor's discretion". If this is the intent, I'd suggest not specifying a timer value. Intent #3: Handling inbound ICMP's that do not have an encapsulated IP packet to help routing, such as ICMP Echo Response -- If this is the intent, it needs to be made clear. Also, by the same logic as #1, RFC 1122 would say that an ICMP Echo Response may be received within at most 4 minutes; so that should be the recommended value of the timer. That said, reiterating Paul's point -- unless the NAT is low on available "ICMP mappings", it should not expire any ICMP mapping. If it is low, then it should expire ICMP mappings that have been open for more than 4 minutes. If that doesn't free up any mappings, then it should reject the new ICMP packet -- to prevent an insider from DoS'ing the NAT. I think Intent #3 makes most sense logically; and if we are going to have a separate ICMP draft (as per the charter), thats where this issue should go. But if we are not, then the intent should be made more clear. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00056.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00056.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3pHdUluRmx0cWk2OTEvb1JBbFdpQUo5Rkhxem9qbm14WWNmeHV2VTFC SFc1OWtqN1F3Q2VOMjdjCjJiNGE2VTYxZDJKcVQrSWJ3S3Q5SWZrPQo9WlhYNAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From audet@nortel.com Wed, 6 Jul 2005 17:13:36 -0700 (PDT) From: "Francois Audet" Date: Wed, 6 Jul 2005 17:13:36 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF031E7551@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain OK, I don't understand the 2s timer either. I'm hearing a bunch of votes for removing requirement c, and I don't have objections. Dan/Cullen, I think this requirement came from you. Objections to removing it from the UDP draft? (Presumable some ICMP document would clarify further any timers requirement for this, as per Saikat's suggestion below). > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Wednesday, July 06, 2005 16:39 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] FW: I-D > ACTION:draft-ietf-behave-nat-udp-02.txt > > > On Wed, 2005-07-06 at 17:48 -0500, Francois Audet wrote: > > c) The ICMP timeout SHOULD be greater than 2 seconds. > > > > Or are people still questioning c), and if so what would be the > > proposal. > > Perhaps I am just being obtuse, but I really don't understand > requirement c). See my point #10 in > http://list.sipfoundry.org/archive/ietf-behave/msg00759.html > > In any event, I agree with Paul that there should be no timer > unless an RFC for the ICMP protocol defines one for the > particular case ... and I do not know what the particular > timer is for so I cannot say either yay or nay. > > Some timers that might be relevant based on intent: > > Intent #1: Handling an inbound ICMP packet in response to an > outbound TCP/UDP packet -- The maximum time an in-flight > packet is considered alive is 2 minutes (RFC 1122). So it may > take at most 4 minutes for can ICMP to come back. ... But the > encapsulated IP packet inside the ICMP will have all the data > needed to route the packet (as long as the mapping is alive) > ... so there is no point specifying the timeout if this is the intent. > > Intent #2: Preventing packet storms; ICMP rate-limiting -- > RFC 2521 says ICMP's should be rate limited but the timer is > "left to the implementor's discretion". If this is the > intent, I'd suggest not specifying a timer value. > > Intent #3: Handling inbound ICMP's that do not have an > encapsulated IP packet to help routing, such as ICMP Echo > Response -- If this is the intent, it needs to be made clear. > Also, by the same logic as #1, RFC 1122 would say that an > ICMP Echo Response may be received within at most 4 minutes; > so that should be the recommended value of the timer. That > said, reiterating Paul's point -- unless the NAT is low on > available "ICMP mappings", it should not expire any ICMP > mapping. If it is low, then it should expire ICMP mappings > that have been open for more than 4 minutes. If that doesn't > free up any mappings, then it should reject the new ICMP > packet -- to prevent an insider from DoS'ing the NAT. > > I think Intent #3 makes most sense logically; and if we are > going to have a separate ICMP draft (as per the charter), > thats where this issue should go. But if we are not, then the > intent should be made more clear. > > -- > Saikat > From srisuresh@yahoo.com Thu, 7 Jul 2005 05:24:03 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 7 Jul 2005 05:24:03 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF031E7470@zrc2hxm0.corp.nortel.com> Message-ID: <20050707122330.38153.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain You need to go read your draft. Below is what your draft says. REQ-11: It is RECOMMENDED that a NAT support ICMP Destination Unreachable. a) The ICMP timeout SHOULD be greater than 2 seconds. I propose moving the coverage on ICMP processing to the ICMP draft (or) adapt the text in section 3.8 of the ford-behave-gen-01.txt. cheers, suresh --- Francois Audet wrote: > Did we agree on the following for REQ-11? > > REQ-11: Receipt of any sort of ICMP message MUST NOT destroy the NAT > mapping. > a) The NAT's default configuration SHOULD NOT filter ICMP messages > based on their source IP address. > b) It is RECOMMENDED that a NAT support ICMP Destination > Unreachable messages. > c) The ICMP timeout SHOULD be greater than 2 seconds. > > Or are people still questioning c), and if so what would be the > proposal. > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Thu, 7 Jul 2005 05:49:39 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 7 Jul 2005 05:49:39 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1ECE0EB50388174790F9694F77522CCF031E7478@zrc2hxm0.corp.nortel.com> Message-ID: <20050707124921.77096.qmail@web40424.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Basically, it makes no sense to discuss refreshing a filter in the context of NATs. Here is why. You donot refresh an entity you donot have. NATs donot have filters. Filtering is a behavior you observe on certain types of NATs (most notably, Traditinal NATs), not all NAT types. The filtering behavior is a direct result of the Address map configuration and the Bindings. So, it makes no sense to discuss refreshing a filter in the context of NAT. The term "Address and Port mapping" that you use in your document loosely refers to "NAT Session" (as defined in RFC 4008), which is a NAT resource. So, it does make sense to discuss refreshing a NAT Session. Another resource that NATs do manage as a resource is "Address/Port Binding" (also defined in RFC 4008). NATs do refresh the Bindings. Your document makes no mention of this. There is a more fundamental problem in that the behave-udp draft does not use the right terminology. cheers, suresh --- Francois Audet wrote: > > > > Francois, > > > > You have section 4.3 refering to "Mapping Refresh" behavior > > and a req-6 that follows it. And, section 5.2 refering to > > "Filter refresh" with no requirement that follows it. > > Please go read the archive for why we don't have a requirement > for Filter refresh. > > > > Why does section 5.2 have no requirement associated with it? > > Because people don't think we need one. > > > Also, w.r.t. req-6, why is the refresh required only on the outbound? > > Please go read the archives. We discussed this before. > From srisuresh@yahoo.com Thu, 7 Jul 2005 06:29:10 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 7 Jul 2005 06:29:10 -0700 (PDT) Subject: RE: [Ietf-behave] Fragment ation support (Req-13 & Req-12) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF031E74C5@zrc2hxm0.corp.nortel.com> Message-ID: <20050707132845.59730.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Francois Audet wrote: > > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Pyda Srisuresh > > Sent: Tuesday, July 05, 2005 02:01 > > To: Behave > > Subject: [Ietf-behave] Fragment ation support (Req-13 & Req-12) > > > > > > Francois, > > > > Req-13 (A NAt must support receiving in-order fragments) is > > not the WG consensus, AFAIK. Fragement processign is not > > limited to in-order fragments. > > AFAIK, it is the consensus of the group. > > If you feel it is not, please substantiate, AND provide an > alternative for which you will have gathered concensus from the > group. > [suresh] Check out the followig from the archives. This was the lsst e-mail on supporting incoming fragments. http://list.sipfoundry.org/archive/ietf-behave/msg00588.html, > > As for Req-12, why is NAT support of fragmentation restricted > > to link MTU criteria? Are you referign to immediate link MTU? > > The discussion we had on outbound fragmentation addressed > > much more than you mention here. > > Feel free to propose alternative text for which you will have gathered > consensus from the group. > [suresh] Refer sections 3.3 & 3.4 in ford-behave-gen-01.txt. Suggest adapting the text from these sections. > > > Also, what is the "ICMP > > section" you refer to in section 10.2? > > That would be section 9, entitled "ICMP Destination Unreachable > Behavior" (which seems quite obvious to me, but I'll spell it out). > [suresh] OK. The section titles did not match. So, I assumed, you were refering to a section that had wider covrage on ICMP than setion 9. Anyways, the requirement (REQ-12) text seems lame at the end after all the discussion on DF-bit processing. In contrast, refer section 3.4 & 3.7 of the ford-behave-gen-01.txt. Specifically, on the subject of DF-bit processing, below is what the behave-gen draft says in section 3.7. I suggest adapting this text. REQ-7: If DF bit is set on an inbound IP packet and the NAT device cannot forward the packet without fragmentation, the NAT device MUST send a destination unreachable ICMP message (ICMP type 3, Code 4) with a suggested MTU back to the sender prior to dropping the IP packet. cheers, suresh From audet@nortel.com Thu, 7 Jul 2005 09:03:12 -0700 (PDT) From: "Francois Audet" Date: Thu, 7 Jul 2005 09:03:12 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <1ECE0EB50388174790F9694F77522CCF0324CECF@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Should we remove 5.2 altogether? > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > Sent: Thursday, July 07, 2005 05:49 > To: Audet, Francois [SC100:9T51:EXCH]; Behave > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > > > Basically, it makes no sense to discuss refreshing a filter > in the context of NATs. Here is why. > > You donot refresh an entity you donot have. NATs donot have > filters. Filtering is a behavior you observe on certain types > of NATs (most notably, Traditinal NATs), not all NAT types. > The filtering behavior is a direct result of the Address map > configuration and the Bindings. So, it makes no sense to > discuss refreshing a filter in the context of NAT. > > The term "Address and Port mapping" that you use in your > document loosely refers to "NAT Session" (as defined in RFC > 4008), which is a NAT resource. So, it does make sense to > discuss refreshing a NAT Session. > > Another resource that NATs do manage as a resource is > "Address/Port Binding" (also defined in RFC 4008). NATs do > refresh the Bindings. Your document makes no mention of this. > > There is a more fundamental problem in that the behave-udp > draft does not use the right terminology. > > cheers, > suresh > --- Francois Audet wrote: > > > > > > > > Francois, > > > > > > You have section 4.3 refering to "Mapping Refresh" behavior > > > and a req-6 that follows it. And, section 5.2 refering to > > > "Filter refresh" with no requirement that follows it. > > > > Please go read the archive for why we don't have a requirement for > > Filter refresh. > > > > > > > Why does section 5.2 have no requirement associated with it? > > > > Because people don't think we need one. > > > > > Also, w.r.t. req-6, why is the refresh required only on the > > > outbound? > > > > Please go read the archives. We discussed this before. > > > > > > > From fluffy@cisco.com Fri, 8 Jul 2005 05:46:58 -0700 (PDT) From: Cullen Jennings Date: Fri, 8 Jul 2005 05:46:58 -0700 (PDT) Subject: Re: [Ietf-behave] FW: Approval to Post Version -00 Internet-Drafts for the 63rd IETF Meeting in Paris, France In-Reply-To: <20050620144148.8222.qmail@web40426.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Jiri and I talked on the phone and I would like to comment on the TCP drafts - all of them actually... The chairs don't see widespread opinions or consensus about how to move from the multiple TCP drafts forward to one WG documents - We plan to have discussion of this in the WG meeting at the next IETF then take the results of that discussion to the list and try to decide how to move forward. Cullen On 6/20/05 7:41 AM, "Pyda Srisuresh" wrote: > Cullen & Jiri, > > We would like draft-sivakumar-behave-nat-tcp-req-01 to be adapted as WG > document for TCP. In addition, we would also like draft-ford-behave-gen-01 > to > be adapted as WG document for common stuff (i.e., transport independent stuff, > including ICMP). > > regards, > suresh > > --- Cullen Jennings wrote: > >> >> If we are going to have a WG version of TCP by Paris, we need to sort out >> how we are doing that before July 5th. Similarly if anyone else wants to >> submit 00 WG documents before Paris, please talk to Jiri and I soon. >> >> Cullen >> >> >> ------ Forwarded Message >> From: Internet-Drafts Administrator >> Date: Fri, 17 Jun 2005 00:00:02 -0400 >> To: Working Group Chairs >> Subject: Approval to Post Version -00 Internet-Drafts for the 63rd IETF >> Meeting in Paris, France >> >> >> Dear IETF Working Group Chairs: >> >> In order to expedite the processing of the many version -00 I-Ds that >> the Secretariat receives before an IETF meeting, we ask that you >> please notify the Secretariat prior to the initial submission cutoff >> date of all version -00 I-Ds that you expect to approve for posting as >> WG documents. Please send the filenames of your approved -00 I-Ds to >> internet-drafts@xxxxxxxxx We would appreciate receiving your list of >> approved drafts four (4) business days prior to the cutoff date for -00 >> submissions, or by Tuesday, July 5th at 9:00 AM ET for the 63rd IETF >> Meeting. Please include the word "Approved I-Ds" in the "Subject" >> field. This procedure will help to ensure that version -00 I-Ds are >> posted in a timely manner, allowing more time for review by the public. >> >> Thank you for your cooperation in this matter. >> >> The Internet-Drafts Administrator >> >> FYI: The Internet-Draft cutoff dates as well as other significant dates >> for the 63rd IETF Meeting can be found at >> http://www.ietf.org/meetings/cutoff_dates_63.html. >> >> ------ End of Forwarded Message >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> > From srisuresh@yahoo.com Fri, 8 Jul 2005 07:02:35 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 8 Jul 2005 07:02:35 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0324CECF@zrc2hxm0.corp.nortel.com> Message-ID: <20050708140235.41800.qmail@web40423.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain 1. Yes, remove 5.2 altogether. 2. As for section 4.3, Req-6, the refresh (i.e., liveness) should not be tied to traffic in one direction over the other. The NAT Session should be refreshed (i.e., considered live) when associated packets traverse the NAT in either direction. Further, the refresh process is transport independent, i.e., not UDP specific. This requirement is currently buried under the same section (section 4.3) that discusses UDP specific timeouts (REQ-5). 3. Lastly, the document is missing a key requirement on Bindings. A dynamically created Binding (Address and/or Port Binding) MUST be refreshed, when there is is at least one live NAT Session using the Binding. Alternately, once a Binding is created in relation to an endpoint and a NAT Session, subsequent NAT Sessions associated with the endpoint MUST reuse the same Binding. A dynamically created NAT Binding may expire when there is no live NAT session associated with it. A NAT may choose to use an expiry time largen than 0 secs for the Bindings. cheers, suresh --- Francois Audet wrote: > Should we remove 5.2 altogether? > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > Sent: Thursday, July 07, 2005 05:49 > > To: Audet, Francois [SC100:9T51:EXCH]; Behave > > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > > > > > > > Basically, it makes no sense to discuss refreshing a filter > > in the context of NATs. Here is why. > > > > You donot refresh an entity you donot have. NATs donot have > > filters. Filtering is a behavior you observe on certain types > > of NATs (most notably, Traditinal NATs), not all NAT types. > > The filtering behavior is a direct result of the Address map > > configuration and the Bindings. So, it makes no sense to > > discuss refreshing a filter in the context of NAT. > > > > The term "Address and Port mapping" that you use in your > > document loosely refers to "NAT Session" (as defined in RFC > > 4008), which is a NAT resource. So, it does make sense to > > discuss refreshing a NAT Session. > > > > Another resource that NATs do manage as a resource is > > "Address/Port Binding" (also defined in RFC 4008). NATs do > > refresh the Bindings. Your document makes no mention of this. > > > > There is a more fundamental problem in that the behave-udp > > draft does not use the right terminology. > > > > cheers, > > suresh > > --- Francois Audet wrote: > > > > > > > > > > > > Francois, > > > > > > > > You have section 4.3 refering to "Mapping Refresh" behavior > > > > and a req-6 that follows it. And, section 5.2 refering to > > > > "Filter refresh" with no requirement that follows it. > > > > > > Please go read the archive for why we don't have a requirement for > > > Filter refresh. > > > > > > > > > > Why does section 5.2 have no requirement associated with it? > > > > > > Because people don't think we need one. > > > > > > > Also, w.r.t. req-6, why is the refresh required only on the > > > > outbound? > > > > > > Please go read the archives. We discussed this before. > > > > > > > > > > > > > > From srisuresh@yahoo.com Fri, 8 Jul 2005 07:24:25 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 8 Jul 2005 07:24:25 -0700 (PDT) Subject: [Ietf-behave] Applicability statement in the UDP draft In-Reply-To: <20050708140235.41800.qmail@web40423.mail.yahoo.com> Message-ID: <20050708142425.14008.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Francois, In section 1, titled "applicability Statement", you state the following. The requirements of this specification apply generally to all NAT variations, including the ones described in RFC 2663 [3] (Traditional NAT, Basic NAT, NAPT, Bi-directional NAT, Twice NAT, and Multihomed NATs). However, it is not within the scope of this specification to address all issues specific to all possible NAT variations. Yet, in section 3, you state: In this specification, the term "NAT" refers to both "Basic NAT" and "Network Address/Port Translator (NAPT)". For the reminder of the document, you use the above definition for NAT in deriving the Behave requirements. If the scope of applicability is beyond Traditional NATs, then the requirements do not do justice to that, as they assume traditional NAT. You will need to spell out which of the requirements are generic and which are specific to Basic NAT and/or NAPT. cheers, suresh From ssenthil@cisco.com Fri, 8 Jul 2005 08:50:42 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Fri, 8 Jul 2005 08:50:42 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB518848@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Wednesday, July 06, 2005 7:39 PM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] FW: I-D > ACTION:draft-ietf-behave-nat-udp-02.txt > > On Wed, 2005-07-06 at 17:48 -0500, Francois Audet wrote: > > c) The ICMP timeout SHOULD be greater than 2 seconds. > > > > Or are people still questioning c), and if so what would be the > > proposal. > > Perhaps I am just being obtuse, but I really don't understand > requirement c). See my point #10 in > http://list.sipfoundry.org/archive/ietf-behave/msg00759.html > > In any event, I agree with Paul that there should be no timer > unless an RFC for the ICMP protocol defines one for the > particular case ... and I do not know what the particular > timer is for so I cannot say either yay or nay. > > Some timers that might be relevant based on intent: > > Intent #1: Handling an inbound ICMP packet in response to an > outbound TCP/UDP packet -- The maximum time an in-flight > packet is considered alive is 2 minutes (RFC 1122). So it may > take at most 4 minutes for can ICMP to come back. ... But the > encapsulated IP packet inside the ICMP will have all the data > needed to route the packet (as long as the mapping is alive) > ... so there is no point specifying the timeout if this is the intent. > > Intent #2: Preventing packet storms; ICMP rate-limiting -- > RFC 2521 says ICMP's should be rate limited but the timer is > "left to the implementor's discretion". If this is the > intent, I'd suggest not specifying a timer value. > > Intent #3: Handling inbound ICMP's that do not have an > encapsulated IP packet to help routing, such as ICMP Echo > Response -- If this is the intent, it needs to be made clear. > Also, by the same logic as #1, RFC > 1122 would say that an ICMP Echo Response may be received > within at most > 4 minutes; so that should be the recommended value of the > timer. That said, reiterating Paul's point -- unless the NAT > is low on available "ICMP mappings", it should not expire any > ICMP mapping. If it is low, then it should expire ICMP > mappings that have been open for more than 4 minutes. If that > doesn't free up any mappings, then it should reject the new > ICMP packet -- to prevent an insider from DoS'ing the NAT. > Your opinion of not having a timer just for this particular case or in general? In any case, I think you are suggesting how this should be implemented rather than just stating the requirements. The reason why I say that is you seem to have implied above that NAT boxes should have a protocol specific mapping space that it should manage. I thought the intention of this WG is to specify the behavior of NAT so that it is consistent. With this suggestion of removing mappings based on resource usage per protocol, I see that different vendors could allocate different size mapping space for each protocol based on the available memory in their boxes. This cause inconsistent behavior. Now if I am a NAT vendor and if I don't have an implementation of per protocol mapping space any considerable changes to the implementation simply won't happen. As you have rightly pointed out in an earlier thread, "If vendors cannot stay "fully compliant" without implementing this one item with a wishy-washy justification, they might as well balk and stop following any of the RECOMMENDED parts since they cannot be fully compliant anyway; which would be a complete disaster." The above discussion on not having timeout based mechanisms fit right in the above category. Senthil > I think Intent #3 makes most sense logically; and if we are > going to have a separate ICMP draft (as per the charter), > thats where this issue should go. But if we are not, then the > intent should be made more clear. > > -- > Saikat > From sg266@cornell.edu Fri, 8 Jul 2005 14:01:37 -0700 (PDT) From: Saikat Guha Date: Fri, 8 Jul 2005 14:01:37 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050708140235.41800.qmail@web40423.mail.yahoo.com> Message-ID: <1120848135.7323.20.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-07-08 at 07:02 -0700, Pyda Srisuresh wrote: > 2. As for section 4.3, Req-6, the refresh (i.e., liveness) should not be tied > to traffic in one direction over the other. The NAT Session should be > refreshed > (i.e., considered live) when associated packets traverse the NAT in either > direction. I think someone (Yutaka?) made the case that if "Inbound" is true then an external attacker can keep a mapping alive without the consent of the internal app by just sending packets. If a different application is later started that binds to the same local port on the internal host then the attacker now has an attack vector that the internal app cannot close. > 3. Lastly, the document is missing a key requirement on Bindings. Just so I understand, this refers to the global IP address to internal host IP relation, correct? And therefore is stronger than cone in that all mappings from the same internal host get the same global IP address, which ofcourse would only affect NATs with multiple external IP addresses? If that is the case, I am not sure what benefits that provides. If an internal application opens two ports locally and talks to a remote host ... under the above requirement, it would need to tell the remote host of its two mapped ports and only one mapped IP. Without that, it would need to provide both the IPs. Since the internal application needs to find both its external port mappings (STUN etc), it automatically finds both its external IPs as well ... so as I see it, it seems that all this saves is sending over 4 extra bytes. Alternatively, the remote endpoint could be using the IP address as some security key ... to allow the second port from accessing something without any authentication; that in any case is horribly broken since even with the above requirement two hosts could get the same IP. Am I missing something? -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00057.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00057.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3pza0duRmx0cWk2OTEvb1JBa2hlQUo5SlJoMWtwb0xLdEtBNld0LzRq SjZNL3AwNnZRQ2ZYbW1DCm9Ock9zOXh3dy94M1R1K08zOFdjWjdNPQo9WE5yZgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Fri, 8 Jul 2005 14:01:52 -0700 (PDT) From: Saikat Guha Date: Fri, 8 Jul 2005 14:01:52 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB518848@xmb-sjc-236.amer.cisco.com> Message-ID: <1120849813.7323.47.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-07-08 at 08:50 -0700, Senthil Sivakumar (ssenthil) wrote: > Your opinion of not having a timer just for this particular case or in > general? In general, if the RFCs specify the timer then mention it; if they don't then not make one up unless it avoids something important. In my book, DoS is important, long-term resource depletion is important, short-term resource depletion is not. In particular, I'd say something like: REQ-11 c) A NAT SHOULD translate and forward ICMP responses received within 4 minutes of sending the ICMP request to the internal host that sent the request. since RFC 1122 gives timer values. But since no RFC mentions any sort of UDP keepalive, I'd like to say: REQ-5: A NAT UDP mapping MUST NOT be reclaimed unless the NAT is unable to allocate a mapping for a new session. a) A NAT UDP mapping MUST NOT be reclaimed within 2 minutes of a packet traversing the NAT associated with that mapping. Perhaps with fewer negatives, but the main requirement here is that mappings stay active as long as possible. Reclaim only to avoid long- term depletion, not short-term. The 2 minute is something we add for DoS protection (2 based on consensus on the last version). The additional 5 minutes recommendation was arbitrary anyway. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00058.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00058.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQ3pzK1ZuRmx0cWk2OTEvb1JBaXVlQUo5c0VDeVhrcyt2cHBwNmxCa1E4 R2xiY3BkMUNnQ2NETHZ2CnljUkhWTktrdHNtLzh6RlExN21mUklRPQo9ZjJsagotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From dbarrett@quinthar.com Fri, 8 Jul 2005 18:35:30 -0700 (PDT) From: David Barrett Date: Fri, 8 Jul 2005 18:35:30 -0700 (PDT) Subject: [Ietf-behave] Determining the precise behavior of a given NAT model Message-ID: <42CF29E1.2020200@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain What is and will be the process for determining the specific behavior of a given NAT? Is there, or will there be, a formally-standardized set of terminology and characteristics that fully describe a NAT's behavior? A major goal of the BEHAVE draft is reduce the diversity of NATs deployed to a more manageable set. However, there will still be a diversity, even if every NAT device is fully compliant. Thus if we fast-forward to a post-BEHAVE world, what will the process be to determine what kind of NAT I have? Does BEHAVE make any recommendations on terminology, and how to publicize a given NAT's behavior? To give a specific example, I'm testing with a Zyxel NAT, and it appears to have a very small NAT-refresh window with address-restricted filtering. However, I can't find any clear description in the Zyxel product literature detailing whether this is true or not, nor is it clear what specifically I should be looking for (mapping timeouts? refresh period? full cone? restricted cone? endpoint filtering?) What would be helpful is a clear set of variables that completely describe the BEHAVE-regulated NAT criteria, with well-defined possible answers. In this way a NAT can say "100% BEHAVE Compliant!" and then completely describe its behavior (Endpoint filtering: address restricted. NAT mapping lease duration: 20s. ...etc...). It would seem to fit the charter of the BEHAVE draft to recommend that compliant devices SHOULD report their behavior in a standardized fashion to enable reliable comparisions. Take, for example, the endpoint filtering debate. If we don't require that devices implement both in a configurable fashion, and if we don't require that devices clearly say which they are, how can a customer reasonably be expected to make an intelligent choice about which to buy? Does BEHAVE already do this? Should it? -david From audet@nortel.com Fri, 8 Jul 2005 19:17:34 -0700 (PDT) From: "Francois Audet" Date: Fri, 8 Jul 2005 19:17:34 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NAT model Message-ID: <1ECE0EB50388174790F9694F77522CCF032B17BC@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Right, Both the TCP and UDP drafts (and potentially others) will define terminology and Requirements. We also have on the Charter as an item of "Produce a BCP document that describes the usage of protocols like STUN for performing black-box testing and characterizing NAT behavior". We haven't received any submission on this last topic so far, but it would be quite appreciated. It would help validate the other drafts in the real world. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > David Barrett > Sent: Friday, July 08, 2005 18:35 > To: 'Behave' > Subject: [Ietf-behave] Determining the precise behavior of a > given NAT model > > > What is and will be the process for determining the specific > behavior of > a given NAT? Is there, or will there be, a > formally-standardized set of > terminology and characteristics that fully describe a NAT's behavior? > > > A major goal of the BEHAVE draft is reduce the diversity of NATs > deployed to a more manageable set. However, there will still be a > diversity, even if every NAT device is fully compliant. Thus if we > fast-forward to a post-BEHAVE world, what will the process be to > determine what kind of NAT I have? Does BEHAVE make any > recommendations > on terminology, and how to publicize a given NAT's behavior? > > To give a specific example, I'm testing with a Zyxel NAT, and > it appears > to have a very small NAT-refresh window with address-restricted > filtering. However, I can't find any clear description in the Zyxel > product literature detailing whether this is true or not, nor is it > clear what specifically I should be looking for (mapping timeouts? > refresh period? full cone? restricted cone? endpoint filtering?) > > What would be helpful is a clear set of variables that completely > describe the BEHAVE-regulated NAT criteria, with well-defined > possible > answers. In this way a NAT can say "100% BEHAVE Compliant!" and then > completely describe its behavior (Endpoint filtering: address > restricted. NAT mapping lease duration: 20s. ...etc...). It would > seem to fit the charter of the BEHAVE draft to recommend that > compliant > devices SHOULD report their behavior in a standardized > fashion to enable > reliable comparisions. > > Take, for example, the endpoint filtering debate. If we > don't require > that devices implement both in a configurable fashion, and if > we don't > require that devices clearly say which they are, how can a customer > reasonably be expected to make an intelligent choice about > which to buy? > > Does BEHAVE already do this? Should it? > > -david > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortel.com Fri, 8 Jul 2005 19:25:10 -0700 (PDT) From: "Francois Audet" Date: Fri, 8 Jul 2005 19:25:10 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <1ECE0EB50388174790F9694F77522CCF032B17BD@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain > 1. Yes, remove 5.2 altogether. I agree with this suggestion. Any dissenters? If I hear none, I will remove it. > 2. As for section 4.3, Req-6, the refresh (i.e., liveness) > should not be tied to traffic in one direction over the > other. The NAT Session should be refreshed (i.e., considered > live) when associated packets traverse the NAT in either direction. This was discussed ad nauseam, and the document reflects the consensus. I don't want to change it unless there is a clear indication that magically, everbody changed their mind. > Further, the refresh process is transport independent, i.e., > not UDP specific. > This requirement is currently buried under the same section > (section 4.3) that discusses UDP specific timeouts (REQ-5). This whole document is only on UDP, so I don't see your point. > 3. Lastly, the document is missing a key requirement on > Bindings. A dynamically created Binding (Address and/or Port > Binding) MUST be refreshed, when there is is at least one > live NAT Session using the Binding. Alternately, once a > Binding is created in relation to an endpoint and a NAT > Session, subsequent NAT Sessions associated with the endpoint > MUST reuse the same Binding. A dynamically created NAT > Binding may expire when there is no live NAT session > associated with it. A NAT may choose to use an expiry time > largen than 0 secs for the Bindings. I believe this is covered in section 4.3. We are not using the "binding" terminology, which makes the explanation a lot simpler than your paragraph above. > cheers, > suresh > > --- Francois Audet wrote: > > > Should we remove 5.2 altogether? > > > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > Sent: Thursday, July 07, 2005 05:49 > > > To: Audet, Francois [SC100:9T51:EXCH]; Behave > > > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT > filter refresh > > > > > > > > > > > > Basically, it makes no sense to discuss refreshing a filter > > > in the context of NATs. Here is why. > > > > > > You donot refresh an entity you donot have. NATs donot have > > > filters. Filtering is a behavior you observe on certain types > > > of NATs (most notably, Traditinal NATs), not all NAT types. > > > The filtering behavior is a direct result of the Address map > > > configuration and the Bindings. So, it makes no sense to > > > discuss refreshing a filter in the context of NAT. > > > > > > The term "Address and Port mapping" that you use in your > > > document loosely refers to "NAT Session" (as defined in RFC > > > 4008), which is a NAT resource. So, it does make sense to > > > discuss refreshing a NAT Session. > > > > > > Another resource that NATs do manage as a resource is > > > "Address/Port Binding" (also defined in RFC 4008). NATs do > > > refresh the Bindings. Your document makes no mention of this. > > > > > > There is a more fundamental problem in that the behave-udp > > > draft does not use the right terminology. > > > > > > cheers, > > > suresh > > > --- Francois Audet wrote: > > > > > > > > > > > > > > > > Francois, > > > > > > > > > > You have section 4.3 refering to "Mapping Refresh" > behavior and > > > > > a req-6 that follows it. And, section 5.2 refering to "Filter > > > > > refresh" with no requirement that follows it. > > > > > > > > Please go read the archive for why we don't have a > requirement for > > > > Filter refresh. > > > > > > > > > > > > > Why does section 5.2 have no requirement associated with it? > > > > > > > > Because people don't think we need one. > > > > > > > > > Also, w.r.t. req-6, why is the refresh required only on the > > > > > outbound? > > > > > > > > Please go read the archives. We discussed this before. > > > > > > > > > > > > > > > > > > > > > > > > > > From audet@nortel.com Fri, 8 Jul 2005 19:30:55 -0700 (PDT) From: "Francois Audet" Date: Fri, 8 Jul 2005 19:30:55 -0700 (PDT) Subject: RE: [Ietf-behave] Applicability statement in the UDP draft Message-ID: <1ECE0EB50388174790F9694F77522CCF032B17C0@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pyda Srisuresh > Sent: Friday, July 08, 2005 07:24 > To: Behave > Subject: [Ietf-behave] Applicability statement in the UDP draft > > > Francois, > > In section 1, titled "applicability Statement", you state the > following. > > The requirements of this specification apply generally to all NAT > variations, including the ones described in RFC 2663 [3] > (Traditional > NAT, Basic NAT, NAPT, Bi-directional NAT, Twice NAT, and Multihomed > NATs). However, it is not within the scope of this > specification to > address all issues specific to all possible NAT variations. > > Yet, in section 3, you state: > > In this specification, the term "NAT" refers > to both "Basic NAT" and "Network Address/Port Translator (NAPT)". > > For the reminder of the document, you use the above > definition for NAT in deriving the Behave requirements. > > If the scope of applicability is beyond Traditional NATs, > then the requirements do not do justice to that, as they > assume traditional NAT. You are correct. We are looking at Traditional NAT only. That section 1 comment will be modified. > You will need to spell out which of > the requirements are generic and which are specific to Basic > NAT and/or NAPT. > cheers, > suresh > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From dbarrett@quinthar.com Fri, 8 Jul 2005 19:35:28 -0700 (PDT) From: David Barrett Date: Fri, 8 Jul 2005 19:35:28 -0700 (PDT) Subject: Re: [Ietf-behave] Determining the precise behavior of a given NAT model In-Reply-To: <1ECE0EB50388174790F9694F77522CCF032B17BC@zrc2hxm0.corp.nortel.com> Message-ID: <42CF37EC.7060300@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Francois Audet wrote: Both the TCP and UDP drafts (and potentially others) will define terminology and Requirements. Good. But is there any requirement or recommendation that NAT vendors document their NAT's behaviors using this terminology? For example, I'm sure Zyxel could sit down and write in BEHAVE-compliant terminology precisely how their NATs are supposed to... well, behave. However, it doesn't appear that they have done so yet, and I'm curious if the BEHAVE draft will recommend to NAT vendors -- like Zyxel -- that in order to claim BEHAVE compliance they need to document how their NATs behave? We also have on the Charter as an item of "Produce a BCP document that describes the usage of protocols like STUN for performing black-box testing and characterizing NAT behavior". Ah, now this would be great. I'm sure the STUNT tool that has been discussed here before would be a great help here. -david From audet@nortel.com Sat, 9 Jul 2005 11:07:57 -0700 (PDT) From: "Francois Audet" Date: Sat, 9 Jul 2005 11:07:57 -0700 (PDT) Subject: [Ietf-behave] ICMP Message-ID: <1ECE0EB50388174790F9694F77522CCF032B1867@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain What do people think about removing from the UDP spec COMPLETLY any discussion of ICMP (i.e., remove section 9)? We have the following item on the Charter: Nov 05 Produce a BCP that defines basic ICMP behavioral requirements for NATs I certainly don't have a problem with removing it from the UDP spec. From audet@nortel.com Sat, 9 Jul 2005 11:09:04 -0700 (PDT) From: "Francois Audet" Date: Sat, 9 Jul 2005 11:09:04 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF032B1868@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain > REQ-5: A NAT UDP mapping MUST NOT be reclaimed unless the NAT > is unable > to allocate a mapping for a new session. > a) A NAT UDP mapping MUST NOT be reclaimed within 2 minutes of a > packet traversing the NAT associated with that mapping. I think this is too stringent for most people. I'd leave REQ-5 as it is. From audet@nortel.com Sat, 9 Jul 2005 11:14:14 -0700 (PDT) From: "Francois Audet" Date: Sat, 9 Jul 2005 11:14:14 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel Message-ID: <1ECE0EB50388174790F9694F77522CCF032B186A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain > Good. But is there any requirement or recommendation that > NAT vendors > document their NAT's behaviors using this terminology? No. I don't see how it would be enforceable. I'd be very happy to see boxes with "IETF RFC XXXX, YYYY, ...." compliant (where XXX, YYYY are behave RFCs). Soon. Not three years from now when everybody is still laughing at why VoIP never made it because the IETF could put out an RFC saying "Don't do a symmetric NAT". > For example, I'm sure Zyxel could sit down and write in > BEHAVE-compliant > terminology precisely how their NATs are supposed to... well, behave. > However, it doesn't appear that they have done so yet, and > I'm curious > if the BEHAVE draft will recommend to NAT vendors -- like > Zyxel -- that > in order to claim BEHAVE compliance they need to document how > their NATs > behave? I can assure you that NAT manufacturers would very much like to have a set of BEHAVE RFCs guiding them. It's not like they are trying to do the wrong thing on purpose. > > > We also have on the Charter as an item of "Produce a BCP > document that > > describes the usage of protocols like STUN for performing black-box > > testing and characterizing NAT behavior". > > Ah, now this would be great. I'm sure the STUNT tool that has been > discussed here before would be a great help here. Yes, exactly, but STUNT and STUN, which would benefit from behing updated with diagnostics matching the various BEHAVE documents. From srisuresh@yahoo.com Sat, 9 Jul 2005 23:50:04 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 9 Jul 2005 23:50:04 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1120848135.7323.20.camel@localhost.localdomain> Message-ID: <20050710065003.82458.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Fri, 2005-07-08 at 07:02 -0700, Pyda Srisuresh wrote: > > 2. As for section 4.3, Req-6, the refresh (i.e., liveness) should not be > tied > > to traffic in one direction over the other. The NAT Session should be > refreshed > > (i.e., considered live) when associated packets traverse the NAT in either > > direction. > > I think someone (Yutaka?) made the case that if "Inbound" is true then > an external attacker can keep a mapping alive without the consent of the > internal app by just sending packets. [suresh] I see. Interesting. This of course makes the assumption that the attacker is on the outside. Note, address spoofing attacks can occur the inside as well. Anyways, assuming the attacker is on the outside ony, this is likely a bigger issue with Address Binding than Port Binding, because IP addresses are more scarce than the port numbers. I will also add, this requirement has the caveat that applications that involve long periods of inbound-only traffic can be problematic to traverse through NATs. This can be particulraly concerning for these applications, as the traffic path includes slow links. In any case, I believe, the rationale for the recommendation should be in the draft. Without that, the recommendation seems arbitrary. > If a different application is > later started that binds to the same local port on the internal host > then the attacker now has an attack vector that the internal app cannot > close. > [suresh] So long as the NAT Session is alive for an application-x, the port binding would stay alive. SO, there is no chance of another application-y reusing the same external port while NAT Session from application-x is kept alive. The worst thing that could happen is that the internal host closed application-x on its local port, but the associated port binding stays alive on the NAT. But, I agree, the damage can be more when the Binding is address based (not port based). > > 3. Lastly, the document is missing a key requirement on Bindings. > > Just so I understand, this refers to the global IP address to internal > host IP relation, correct? And therefore is stronger than cone in that > all mappings from the same internal host get the same global IP address, > which ofcourse would only affect NATs with multiple external IP > addresses? > [suresh] No. It would be Port Binding in case of NAPT; And, Address Binding in case of Basic NAT. > If that is the case, I am not sure what benefits that provides. If an > internal application opens two ports locally and talks to a remote > host ... under the above requirement, it would need to tell the remote > host of its two mapped ports and only one mapped IP. Without that, it > would need to provide both the IPs. Since the internal application needs > to find both its external port mappings (STUN etc), it automatically > finds both its external IPs as well ... so as I see it, it seems that > all this saves is sending over 4 extra bytes. Alternatively, the remote > endpoint could be using the IP address as some security key ... to allow > the second port from accessing something without any authentication; > that in any case is horribly broken since even with the above > requirement two hosts could get the same IP. Am I missing something? > [suresh] Sounds like you completely misunderstood what I said. frankly, I do not even follow your logic. Req-1 reads as follows REQ-1: A NAT MUST have an "External NAT mapping is endpoint independent" behavior. The above requirement does not address the associated Port Binding (or) Address Binding (whichever maybe the case) as a NAT resource. Applications such as DNS-ALG (which is a recommended default ALG) would require the Binding to be unexpired for a period of time even when the Binding has no NAT Sessions asosciated with it. Same would be the case with several Peer-to-peer applications. That a NAT may choose to use an expiry time largen than 0 secs for the Bindings is reflected in the following requirement text. A dynamically created Binding (Address and/or Port Binding) MUST be refreshed, when there is at least one live NAT Session using the Binding. A NAT may choose to use an expiry time larger than 0 secs for a Bindings, when there is no live NAT session associated with the Binding. cheers, suresh > -- > Saikat > From srisuresh@yahoo.com Sun, 10 Jul 2005 00:28:04 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 10 Jul 2005 00:28:04 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1ECE0EB50388174790F9694F77522CCF032B17BD@zrc2hxm0.corp.nortel.com> Message-ID: <20050710072803.84978.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Francois Audet wrote: > > 1. Yes, remove 5.2 altogether. > > I agree with this suggestion. > > Any dissenters? If I hear none, I will remove it. > > > 2. As for section 4.3, Req-6, the refresh (i.e., liveness) > > should not be tied to traffic in one direction over the > > other. The NAT Session should be refreshed (i.e., considered > > live) when associated packets traverse the NAT in either direction. > > This was discussed ad nauseam, and the document reflects the consensus. > > I don't want to change it unless there is a clear indication that > magically, everbody changed their mind. > [suresh] Please see my comments on the same thread in my e-mail response to Saikat. The requirement seems rather arbitrary without proper rationale. The following current rationale at best makes one question the requirement. Justification for REQ-6: Outbound refresh is necessary for allowing the client to keep the mapping alive. a) Inbound refresh may be useful for applications where there is no outgoing UDP traffic. > > Further, the refresh process is transport independent, i.e., > > not UDP specific. > > This requirement is currently buried under the same section > > (section 4.3) that discusses UDP specific timeouts (REQ-5). > > This whole document is only on UDP, so I don't see your point. > [suresh] I believe, there was agreement on the list that we needed "general NAT terminology & requirements" first, followed by "UDP-specific requirements". I.e., I heard no dissent when Jon Peterson brought this up on the e-mail. However, there was no conclusion on where the former should be addressed - behave-gen draft or behave-udp draft. If you believe, behave-udp is only on UDP, then the general requirements should be covered in behave-gen. Else, the behave-udp should clearly state which of the requirement in the draft are generic and which are UDP specific. > > 3. Lastly, the document is missing a key requirement on > > Bindings. A dynamically created Binding (Address and/or Port > > Binding) MUST be refreshed, when there is is at least one > > live NAT Session using the Binding. Alternately, once a > > Binding is created in relation to an endpoint and a NAT > > Session, subsequent NAT Sessions associated with the endpoint > > MUST reuse the same Binding. A dynamically created NAT > > Binding may expire when there is no live NAT session > > associated with it. A NAT may choose to use an expiry time > > largen than 0 secs for the Bindings. > > I believe this is covered in section 4.3. We are not using the > "binding" terminology, which makes the explanation a lot simpler than > your paragraph above. > [suresh] Francois - Section 4.3 covers the refresh of a NAT Session. I am OK with this, so long as you include the right rationale/justification to go with it. However, this REQ does not cover the refresh of the "Binding". "NAT Session" and "Binding" are different terms and two different NAT resources. Please see my response to Saikat on this. The new requirement refers the refresh of the "Binding". cheers, suresh > > cheers, > > suresh > > > > --- Francois Audet wrote: > > > > > Should we remove 5.2 altogether? > > > > > > > -----Original Message----- > > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > > Sent: Thursday, July 07, 2005 05:49 > > > > To: Audet, Francois [SC100:9T51:EXCH]; Behave > > > > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT > > filter refresh > > > > > > > > > > > > > > > > Basically, it makes no sense to discuss refreshing a filter > > > > in the context of NATs. Here is why. > > > > > > > > You donot refresh an entity you donot have. NATs donot have > > > > filters. Filtering is a behavior you observe on certain types > > > > of NATs (most notably, Traditinal NATs), not all NAT types. > > > > The filtering behavior is a direct result of the Address map > > > > configuration and the Bindings. So, it makes no sense to > > > > discuss refreshing a filter in the context of NAT. > > > > > > > > The term "Address and Port mapping" that you use in your > > > > document loosely refers to "NAT Session" (as defined in RFC > > > > 4008), which is a NAT resource. So, it does make sense to > > > > discuss refreshing a NAT Session. > > > > > > > > Another resource that NATs do manage as a resource is > > > > "Address/Port Binding" (also defined in RFC 4008). NATs do > > > > refresh the Bindings. Your document makes no mention of this. > > > > > > > > There is a more fundamental problem in that the behave-udp > > > > draft does not use the right terminology. > > > > > > > > cheers, > > > > suresh > > > > --- Francois Audet wrote: > > > > > > > > > > > > > > > > > > > > Francois, > > > > > > > > > > > > You have section 4.3 refering to "Mapping Refresh" > > behavior and > > > > > > a req-6 that follows it. And, section 5.2 refering to "Filter > > > > > > refresh" with no requirement that follows it. > > > > > > > > > > Please go read the archive for why we don't have a > > requirement for > > > > > Filter refresh. > > > > > > > > > > > > > > > > Why does section 5.2 have no requirement associated with it? > > > > > > > > > > Because people don't think we need one. > > > > > > > > > > > Also, w.r.t. req-6, why is the refresh required only on the > > > > > > outbound? > > > > > > > > > > Please go read the archives. We discussed this before. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From srisuresh@yahoo.com Sun, 10 Jul 2005 01:25:10 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 10 Jul 2005 01:25:10 -0700 (PDT) Subject: Re: [Ietf-behave] Determining the precise behavior of a given NAT model In-Reply-To: <42CF29E1.2020200@quinthar.com> Message-ID: <20050710082510.45748.qmail@web40424.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- David Barrett wrote: > What is and will be the process for determining the specific behavior of > a given NAT? Is there, or will there be, a formally-standardized set of > terminology and characteristics that fully describe a NAT's behavior? > [suresh] Well, draft-ford-behave-gen-01.txt does just that - terminology and general characteristics to characterize a NAT's behavior, with the proviso that TCP/UDP specific drafts will reuse the terms from here to further characterize TCP/UDP specific behaviors. As it stands, this is not a WG draft yet. > > A major goal of the BEHAVE draft is reduce the diversity of NATs > deployed to a more manageable set. However, there will still be a > diversity, even if every NAT device is fully compliant. Thus if we > fast-forward to a post-BEHAVE world, what will the process be to > determine what kind of NAT I have? Does BEHAVE make any recommendations > on terminology, and how to publicize a given NAT's behavior? > [suresh] Agreed. This was the intent behind the terminology defined in draft-ford-behave-gen-01.txt. > To give a specific example, I'm testing with a Zyxel NAT, and it appears > to have a very small NAT-refresh window with address-restricted > filtering. However, I can't find any clear description in the Zyxel > product literature detailing whether this is true or not, nor is it > clear what specifically I should be looking for (mapping timeouts? > refresh period? full cone? restricted cone? endpoint filtering?) > [suresh] You make an excellent point. Fully agree with your concern. The ford-behave-gen draft refers "Address/Port Maps", "Bindings", "NAT Sessions" , "Cone/Symmetric NAT behaviors", "Hairpin NAT" and "Multi-Level NAT" to characterize a NAT behavior. "Hairpin NAT" and "Multi-level NAT" are new terms introduced for the first time in this draft. It adds clarification to Cone/Symmteric NAT behaviors originally defined in RFC 3489. The remaining terms are essentially reused from RFC 4008, which is NAT MIB. NAT MIB refers to Binding timeout and NAT Session timeout. So, do ford-behave-gen and sivakumar-behave-nat-tcp drafts. The intent was to ensure vendors do not use inconsistent terms from across different RFCs. > What would be helpful is a clear set of variables that completely > describe the BEHAVE-regulated NAT criteria, with well-defined possible > answers. In this way a NAT can say "100% BEHAVE Compliant!" and then > completely describe its behavior (Endpoint filtering: address > restricted. NAT mapping lease duration: 20s. ...etc...). It would > seem to fit the charter of the BEHAVE draft to recommend that compliant > devices SHOULD report their behavior in a standardized fashion to enable > reliable comparisions. > [suresh] Right. Couldnt agree more. > Take, for example, the endpoint filtering debate. If we don't require > that devices implement both in a configurable fashion, and if we don't > require that devices clearly say which they are, how can a customer > reasonably be expected to make an intelligent choice about which to buy? > > Does BEHAVE already do this? Should it? > [suresh] I believe, we should. ford-behave-gen draft was done with this purpose in mind. However, this is not a BEHAVE WG draft yet. cheers, suresh > -david > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Sun, 10 Jul 2005 01:46:25 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 10 Jul 2005 01:46:25 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel In-Reply-To: <1ECE0EB50388174790F9694F77522CCF032B186A@zrc2hxm0.corp.nortel.com> Message-ID: <20050710084625.96109.qmail@web40427.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Francois Audet wrote: > > Good. But is there any requirement or recommendation that > > NAT vendors > > document their NAT's behaviors using this terminology? > > No. I don't see how it would be enforceable. > I'd be very happy to see boxes with "IETF RFC XXXX, YYYY, ...." > compliant > (where XXX, YYYY are behave RFCs). [suresh] This is not adequate. I agree with David that there has to be a consistent terminology that vendors could use when describing their NAT devices and their config parameters. It is not enough to say their box is BEHAVE RFC compliant. The vendors will also refer other NAT RFCs and the terms they use should be consistent across all RFCs. Even within BEHAVE RFCs, there can be variation across vendors in how they implement the same RFC. Several of the requirements specify a threshold, not the absolute value.Ex: NAT Session tmeouts, Binding timeouts, Address-restricted Cone NAT behavior vs. Full Cone NAT behavior, Fragmentation constraints etc. cheers, suresh > Soon. Not three years from now > when everybody is still laughing at why VoIP never made it because > the IETF could put out an RFC saying "Don't do a symmetric NAT". > > > For example, I'm sure Zyxel could sit down and write in > > BEHAVE-compliant > > terminology precisely how their NATs are supposed to... well, behave. > > However, it doesn't appear that they have done so yet, and > > I'm curious > > if the BEHAVE draft will recommend to NAT vendors -- like > > Zyxel -- that > > in order to claim BEHAVE compliance they need to document how > > their NATs > > behave? > > I can assure you that NAT manufacturers would very much like to have a > set > of BEHAVE RFCs guiding them. It's not like they are trying to do the > wrong thing on purpose. > > > > > > We also have on the Charter as an item of "Produce a BCP > > document that > > > describes the usage of protocols like STUN for performing black-box > > > testing and characterizing NAT behavior". > > > > Ah, now this would be great. I'm sure the STUNT tool that has been > > discussed here before would be a great help here. > > Yes, exactly, but STUNT and STUN, which would benefit from behing > updated > with diagnostics matching the various BEHAVE documents. > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Sun, 10 Jul 2005 01:52:15 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 10 Jul 2005 01:52:15 -0700 (PDT) Subject: RE: [Ietf-behave] Applicability statement in the UDP draft In-Reply-To: <1ECE0EB50388174790F9694F77522CCF032B17C0@zrc2hxm0.corp.nortel.com> Message-ID: <20050710085215.80906.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Francois Audet wrote: > > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Pyda Srisuresh > > Sent: Friday, July 08, 2005 07:24 > > To: Behave > > Subject: [Ietf-behave] Applicability statement in the UDP draft > > > > > > Francois, > > > > In section 1, titled "applicability Statement", you state the > > following. > > > > The requirements of this specification apply generally to all NAT > > variations, including the ones described in RFC 2663 [3] > > (Traditional > > NAT, Basic NAT, NAPT, Bi-directional NAT, Twice NAT, and Multihomed > > NATs). However, it is not within the scope of this > > specification to > > address all issues specific to all possible NAT variations. > > > > Yet, in section 3, you state: > > > > In this specification, the term "NAT" refers > > to both "Basic NAT" and "Network Address/Port Translator (NAPT)". > > > > For the reminder of the document, you use the above > > definition for NAT in deriving the Behave requirements. > > > > If the scope of applicability is beyond Traditional NATs, > > then the requirements do not do justice to that, as they > > assume traditional NAT. > > You are correct. We are looking at Traditional NAT only. That section 1 > comment will be modified. > [suresh] Well, the WG charter refers to NATs in general and does not restrict to Traditional NATs. Perhaps, the WG chairs can make the call on what the scope of the drafts should be. cheers, suresh > > You will need to spell out which of > > the requirements are generic and which are specific to Basic > > NAT and/or NAPT. > > > > > cheers, > > suresh > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > From srisuresh@yahoo.com Sun, 10 Jul 2005 02:10:22 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 10 Jul 2005 02:10:22 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1120849813.7323.47.camel@localhost.localdomain> Message-ID: <20050710091022.83494.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Saikat, This is not what NAT devices do. NAT devices donot time latencies (as you seem to suggest in REQ-11 proposal). I would NOT support this proposal. NAT devices use idle timeouts to timeout TCP/UDP sessions and associated Bindings. Making the idle timeouts for UDP Sessions dynamic has serious ramificatiosn on the resource usage and availability, not to mention the delays in creating new NAT Sessions. I would NOT support your proposal for REQ-5. cheers, suresh --- Saikat Guha wrote: > On Fri, 2005-07-08 at 08:50 -0700, Senthil Sivakumar (ssenthil) wrote: > > Your opinion of not having a timer just for this particular case or in > > general? > > In general, if the RFCs specify the timer then mention it; if they don't > then not make one up unless it avoids something important. In my book, > DoS is important, long-term resource depletion is important, short-term > resource depletion is not. In particular, I'd say something like: > > REQ-11 c) A NAT SHOULD translate and forward ICMP responses received > within 4 minutes of sending the ICMP request to the internal host that > sent the request. > > since RFC 1122 gives timer values. But since no RFC mentions any sort of > UDP keepalive, I'd like to say: > > REQ-5: A NAT UDP mapping MUST NOT be reclaimed unless the NAT is unable > to allocate a mapping for a new session. > a) A NAT UDP mapping MUST NOT be reclaimed within 2 minutes of a > packet traversing the NAT associated with that mapping. > > Perhaps with fewer negatives, but the main requirement here is that > mappings stay active as long as possible. Reclaim only to avoid long- > term depletion, not short-term. The 2 minute is something we add for DoS > protection (2 based on consensus on the last version). The additional 5 > minutes recommendation was arbitrary anyway. > > -- > Saikat > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From dbarrett@quinthar.com Sun, 10 Jul 2005 02:11:45 -0700 (PDT) From: David Barrett Date: Sun, 10 Jul 2005 02:11:45 -0700 (PDT) Subject: Re: [Ietf-behave] Determining the precise behavior of a given NATmodel In-Reply-To: <20050710084625.96109.qmail@web40427.mail.yahoo.com> Message-ID: <42D0E64A.8010907@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Pyda Srisuresh wrote: Even within BEHAVE RFCs, there can be variation across vendors in how they implement the same RFC. Several of the requirements specify a threshold, not the absolute value.Ex: NAT Session tmeouts, Binding timeouts, Address-restricted Cone NAT behavior vs. Full Cone NAT behavior, Fragmentation constraints etc. Yes, this is precisely my concern. I would like to see BEHAVE recommend that NAT vendors produce a formalized definition of their NAT characteristics -- using the BEHAVE-standardized terminology in some clearly defined, regularlized format. Think nutritional-guides on cereal boxes; something that allows you to look at 10 boxes side-by-side and clearly understand the specific differences. -david From audet@nortel.com Sun, 10 Jul 2005 12:14:46 -0700 (PDT) From: "Francois Audet" Date: Sun, 10 Jul 2005 12:14:46 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <1ECE0EB50388174790F9694F77522CCF032B193D@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain > > I think someone (Yutaka?) made the case that if "Inbound" > is true then > > an external attacker can keep a mapping alive without the > consent of > > the internal app by just sending packets. > > [suresh] I see. Interesting. This of course makes the > assumption that the attacker is on the outside. Note, address > spoofing attacks can occur the inside as well. Anyways, > assuming the attacker is on the outside ony, this is likely a > bigger issue with Address Binding than Port Binding, because > IP addresses are more scarce than the port numbers. > > I will also add, this requirement has the caveat that > applications that involve long periods of inbound-only > traffic can be problematic to traverse through NATs. This can > be particulraly concerning for these applications, as the > traffic path includes slow links. > > In any case, I believe, the rationale for the recommendation > should be in the draft. Without that, the recommendation > seems arbitrary. Fair enought, I'll add it to the justification. Note that over time (assuming a NAT that doesn't restart), it could end-up opening all the ports on the NAT. From audet@nortel.com Sun, 10 Jul 2005 12:21:28 -0700 (PDT) From: "Francois Audet" Date: Sun, 10 Jul 2005 12:21:28 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel Message-ID: <1ECE0EB50388174790F9694F77522CCF032B1940@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I believe the UDP draft does exactly that. It describes very specific Requirements that have to be met by NAT vendors. This is exactly why we got rid of fuzzy terminology like Cone/Restricted and so forth that nobody agreed on the meaning. I don't see anything at this point that is not sufficiently clear for NAT vendors in the udp draft. If there is anything SPECIFIC that is not clear, let me know. > -----Original Message----- > From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] > Sent: Sunday, July 10, 2005 02:12 > To: Pyda Srisuresh > Cc: Audet, Francois [SC100:9T51:EXCH]; Behave > Subject: Re: [Ietf-behave] Determining the precise behavior > of a given NATmodel > > > Pyda Srisuresh wrote: > > Even within BEHAVE RFCs, there can be variation across > vendors in how > > they implement the same RFC. Several of the requirements specify a > > threshold, not the absolute value.Ex: NAT Session tmeouts, Binding > > timeouts, Address-restricted Cone NAT behavior vs. Full Cone NAT > > behavior, Fragmentation constraints etc. > > Yes, this is precisely my concern. I would like to see > BEHAVE recommend > that NAT vendors produce a formalized definition of their NAT > characteristics -- using the BEHAVE-standardized terminology in some > clearly defined, regularlized format. > > Think nutritional-guides on cereal boxes; something that > allows you to > look at 10 boxes side-by-side and clearly understand the specific > differences. > > -david > > From dbarrett@quinthar.com Sun, 10 Jul 2005 23:41:59 -0700 (PDT) From: David Barrett Date: Sun, 10 Jul 2005 23:41:59 -0700 (PDT) Subject: Re: [Ietf-behave] Determining the precise behavior of a given NATmodel In-Reply-To: <1ECE0EB50388174790F9694F77522CCF032B1940@zrc2hxm0.corp.nortel.com> Message-ID: <42D214B4.8040105@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Francois Audet wrote: I don't see anything at this point that is not sufficiently clear for NAT vendors in the udp draft. If there is anything SPECIFIC that is not clear, let me know. I agree, the BEHAVE draft defines a specific lexicon. However, having the language is only half the problem. Compelling NAT vendors to use it in a standardized fashion is the other half. For example, it wouldn't be enough for scientists to merely define a language for nutrition. Rather, it takes the FDA to mandate that labels must *use* the language in a standardized form in order for consumers to benefit from it. In our case, I'd like the IETF to recommend that NAT vendors label their products in a consistent fashion, using the BEHAVE terminology. BEHAVE defines the language; let's go the extra step and recommend that NAT vendors actually use it, so consumers can benefit from it. -david From srisuresh@yahoo.com Mon, 11 Jul 2005 06:24:58 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 11 Jul 2005 06:24:58 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel In-Reply-To: <1ECE0EB50388174790F9694F77522CCF032B1940@zrc2hxm0.corp.nortel.com> Message-ID: <20050711132458.45047.qmail@web40426.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain As David mentioned, I do believe, the BEHAVE drafts should use standard terminology in order for the vendors to be able to formalize the definition of their NAT characteristics. The terms should be standard across all the RFCs they refer (at a minimum, all NAT RFCs). The terminology used in the UDP draft conflicts with prior NAT terminology and is problematic in its current form. 1. The UDP draft defines the term "Address/Port Mapping" that contradicts prior definition of the same term in RFC 4008 (NAT MIB). RFC 4008 defines "Address/Port Map" as a configuration entry on a NAT device. NAT device looks up the configured map entries in determining translation parameters for new sessions. "Address/port map" entries stay mostly unchanged during the operation of a NAT device, as they are config entries. The UDP draft, on the other hand, defines "Address/Port Mapping" as assignment of a translation endpoint by the NAT device for an outgoing session and is created on the fly on a per-session basis. Unlike in RFC 4008, this is not a configuration entry. An associated "Mapping timer" is defined as the time a mapping will stay active without packets traversing the NAT. The equivalent of "Address/Port Mapping" and "Address/Port mapping timer" are "NAT Session" and "NAT Session idle timeout" in RFC 4008. 2. The UDP draft finds devious ways in which to work around the RFC 3489 definitions for Cone and Symmetric NATs. It does this by splitting NAT function into mapping and filtering behaviors. It defines Address/Port mapping behavior to be one of a) Endpoint independent, b) Address Dependent, c) Address and Port Dependent. And, defines filtering behavior of external packets to be one of a) Endpoint independent, b) Address Dependent, c) Address and Port Dependent. In reality, a NAT device has a single instrument called "NAT Session" that deals with both translation and packet filtering. Only packets pertaining to an existing "NAT Session" are permitted to traverse in either direction. For example, there is no case, where a NAT Session uses "Endpoint Indepenent mapping" and "Address dependent filtering" (or) "Address dependent mapping" and "Address and Port Dependent filtering". When an external packet comes inbound to a NAT assigned address/port endpoint and the exsting NAT Session does not match this packet, the NAT device has to make a fresh determinination on whether or not to make a new NAT Session based on the orientation of the "Address/Port Binding" in use. In case of NAPT, Port Bindings are outbound only and will not permit creating a new inbound NAT Session. The UDP draft does not use the term "Binding" or any associated terms in decribign the NAT behavior. NAT vendors ought to be able to use standard terminology such as "NAT Session", "NAt Session idle timeouts", "Binding", "Binding timeout" and so forth to describe the characteristics of their NAT device. cheers, suresh --- Francois Audet wrote: > I believe the UDP draft does exactly that. It describes very specific > Requirements > that have to be met by NAT vendors. > > This is exactly why we got rid of fuzzy terminology like Cone/Restricted > and so forth > that nobody agreed on the meaning. > > I don't see anything at this point that is not sufficiently clear for > NAT vendors in the > udp draft. > > If there is anything SPECIFIC that is not clear, let me know. > > > -----Original Message----- > > From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] > > Sent: Sunday, July 10, 2005 02:12 > > To: Pyda Srisuresh > > Cc: Audet, Francois [SC100:9T51:EXCH]; Behave > > Subject: Re: [Ietf-behave] Determining the precise behavior > > of a given NATmodel > > > > > > Pyda Srisuresh wrote: > > > Even within BEHAVE RFCs, there can be variation across > > vendors in how > > > they implement the same RFC. Several of the requirements specify a > > > threshold, not the absolute value.Ex: NAT Session tmeouts, Binding > > > timeouts, Address-restricted Cone NAT behavior vs. Full Cone NAT > > > behavior, Fragmentation constraints etc. > > > > Yes, this is precisely my concern. I would like to see > > BEHAVE recommend > > that NAT vendors produce a formalized definition of their NAT > > characteristics -- using the BEHAVE-standardized terminology in some > > clearly defined, regularlized format. > > > > Think nutritional-guides on cereal boxes; something that > > allows you to > > look at 10 boxes side-by-side and clearly understand the specific > > differences. > > > > -david > > > > > From audet@nortel.com Mon, 11 Jul 2005 09:41:07 -0700 (PDT) From: "Francois Audet" Date: Mon, 11 Jul 2005 09:41:07 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel Message-ID: <1ECE0EB50388174790F9694F77522CCF03329DE3@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Can you propose some text? Perhaps for section 1, or whatever section you feel is appropriate. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > David Barrett > Sent: Sunday, July 10, 2005 23:42 > To: 'Behave' > Subject: Re: [Ietf-behave] Determining the precise behavior > of a given NATmodel > > > Francois Audet wrote: > > I don't see anything at this point that is not sufficiently > clear for > > NAT vendors in the udp draft. > > > > If there is anything SPECIFIC that is not clear, let me know. > > I agree, the BEHAVE draft defines a specific lexicon. > However, having > the language is only half the problem. Compelling NAT > vendors to use it > in a standardized fashion is the other half. > > For example, it wouldn't be enough for scientists to merely define a > language for nutrition. Rather, it takes the FDA to mandate > that labels > must *use* the language in a standardized form in order for > consumers to > benefit from it. > > In our case, I'd like the IETF to recommend that NAT vendors > label their > products in a consistent fashion, using the BEHAVE > terminology. BEHAVE > defines the language; let's go the extra step and recommend that NAT > vendors actually use it, so consumers can benefit from it. > > -david > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortel.com Mon, 11 Jul 2005 09:58:02 -0700 (PDT) From: "Francois Audet" Date: Mon, 11 Jul 2005 09:58:02 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel Message-ID: <1ECE0EB50388174790F9694F77522CCF03329E30@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain We've been through this many times before, and people don't agree with your views on Binding vs. Mapping. It's as simple as that. Furthermore, since the very beginning of the group, it was agreed to NOT use the terminology Cone/Symmetric NAT because it is too confusing. Last meeting, in order to satisfy YOU, I added a section on relating the new terminology with the Cone/Symmetric terminoly. We spent the whole meeting arguing about what Symmetric really meant. The agreement of the last meeting was therefore to REMOVE completely the terminology Cone/Symmetric from both the Behave document and from the revised-RFC3489. The rationale is what we had claimed all along: that it is too confusing, and has too many grey areas. And this was based on a suggestion from the author of RFC 3489. This is settled. You can't ignore the decisions of the group like you keep on doing. Let's move on. > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > Sent: Monday, July 11, 2005 06:25 > To: Audet, Francois [SC100:9T51:EXCH]; David Barrett > Cc: Behave > Subject: RE: [Ietf-behave] Determining the precise behavior > of a given NATmodel > > > As David mentioned, I do believe, the BEHAVE drafts should > use standard terminology in order for the vendors to be able > to formalize the definition of their NAT characteristics. The > terms should be standard across all the RFCs they refer (at a > minimum, all NAT RFCs). The terminology used in the UDP draft > conflicts with prior NAT terminology and is problematic in > its current form. > > 1. The UDP draft defines the term "Address/Port Mapping" that > contradicts prior definition of the same term in RFC 4008 (NAT MIB). > > RFC 4008 defines "Address/Port Map" as a configuration entry > on a NAT device. NAT device looks up the configured map > entries in determining translation parameters for new > sessions. "Address/port map" entries stay mostly unchanged > during the operation of a NAT device, as they are config entries. > > The UDP draft, on the other hand, defines "Address/Port > Mapping" as assignment of a translation endpoint by the NAT > device for an outgoing session and is created on the fly on a > per-session basis. Unlike in RFC 4008, this is not a > configuration entry. An associated "Mapping timer" is defined > as the time a mapping will stay active without packets > traversing the NAT. The equivalent of "Address/Port Mapping" > and "Address/Port mapping timer" are "NAT Session" and "NAT > Session idle timeout" in RFC 4008. > > 2. The UDP draft finds devious ways in which to work around > the RFC 3489 definitions for Cone and Symmetric NATs. It does > this by splitting NAT function into mapping and filtering > behaviors. It defines Address/Port mapping behavior to be one > of a) Endpoint independent, b) Address Dependent, c) Address > and Port Dependent. And, defines filtering behavior of > external packets to be one of a) Endpoint independent, b) > Address Dependent, c) Address and Port Dependent. > > In reality, a NAT device has a single instrument called "NAT > Session" that deals with both translation and packet > filtering. Only packets pertaining to an existing "NAT > Session" are permitted to traverse in either direction. For > example, there is no case, where a NAT Session uses "Endpoint > Indepenent mapping" and "Address dependent filtering" (or) > "Address dependent mapping" and "Address and Port Dependent > filtering". > > When an external packet comes inbound to a NAT assigned > address/port endpoint and the exsting NAT Session does not > match this packet, the NAT device has to make a fresh > determinination on whether or not to make a new NAT Session > based on the orientation of the "Address/Port Binding" in > use. In case of NAPT, Port Bindings are outbound only and > will not permit creating a new inbound NAT Session. The UDP > draft does not use the term "Binding" or any associated terms > in decribign the NAT behavior. > > NAT vendors ought to be able to use standard terminology such > as "NAT Session", "NAt Session idle timeouts", "Binding", > "Binding timeout" and so forth to describe the > characteristics of their NAT device. > > cheers, > suresh > --- Francois Audet wrote: > > > I believe the UDP draft does exactly that. It describes > very specific > > Requirements that have to be met by NAT vendors. > > > > This is exactly why we got rid of fuzzy terminology like > > Cone/Restricted and so forth that nobody agreed on the meaning. > > > > I don't see anything at this point that is not sufficiently > clear for > > NAT vendors in the udp draft. > > > > If there is anything SPECIFIC that is not clear, let me know. > > > > > -----Original Message----- > > > From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] > > > Sent: Sunday, July 10, 2005 02:12 > > > To: Pyda Srisuresh > > > Cc: Audet, Francois [SC100:9T51:EXCH]; Behave > > > Subject: Re: [Ietf-behave] Determining the precise behavior > > > of a given NATmodel > > > > > > > > > Pyda Srisuresh wrote: > > > > Even within BEHAVE RFCs, there can be variation across > > > vendors in how > > > > they implement the same RFC. Several of the > requirements specify a > > > > threshold, not the absolute value.Ex: NAT Session > tmeouts, Binding > > > > timeouts, Address-restricted Cone NAT behavior vs. Full > Cone NAT > > > > behavior, Fragmentation constraints etc. > > > > > > Yes, this is precisely my concern. I would like to see > > > BEHAVE recommend > > > that NAT vendors produce a formalized definition of their NAT > > > characteristics -- using the BEHAVE-standardized > terminology in some > > > clearly defined, regularlized format. > > > > > > Think nutritional-guides on cereal boxes; something that > > > allows you to > > > look at 10 boxes side-by-side and clearly understand the specific > > > differences. > > > > > > -david > > > > > > > > > > > > > From sg266@cornell.edu Mon, 11 Jul 2005 11:32:05 -0700 (PDT) From: Saikat Guha Date: Mon, 11 Jul 2005 11:32:05 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050710065003.82458.qmail@web40427.mail.yahoo.com> Message-ID: <1121103606.5211.4.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2005-07-09 at 23:50 -0700, Pyda Srisuresh wrote: > [suresh] So long as the NAT Session is alive for an application-x, the port > binding would stay alive. SO, there is no chance of another application-y > reusing the same external port while NAT Session from application-x is kept > alive. The worst thing that could happen is that the internal host closed > application-x on its local port, but the associated port binding stays alive > on > the NAT. I am confused. Can you define "port binding" and "NAT session" in the context of your mail or point me to the RFC that defines them; since I suspect it differs from that in the UDP draft. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00059.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00059.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzBxNzJuRmx0cWk2OTEvb1JBb1RZQUpvQyt3NEh5MG1MRDlpRWYxZ253 WmthOXJhRStBQ2Zhakp2Clo4NktJS04wVHpQcXNsMWZic0JRQllZPQo9VWR2VQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Mon, 11 Jul 2005 11:32:12 -0700 (PDT) From: Saikat Guha Date: Mon, 11 Jul 2005 11:32:12 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <20050710091022.83494.qmail@web40429.mail.yahoo.com> Message-ID: <1121104856.5211.22.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-07-10 at 02:10 -0700, Pyda Srisuresh wrote: > NAT devices do not time latencies [...] NAT devices use idle timeouts "idle timeout" is not defined for protocols where only one packet is ever sent or received, as is the case with many ICMP requests. > Making the idle timeouts for UDP Sessions dynamic has serious > ramificatiosn on the resource usage and availability, I do not agree. If the NAT has space to allocate new mappings and yet expires existing ones prematurely based on some arbitrary timer in anticipation of new connections that may or may not arrive, then the NAT is _wasting_ resources. In the extreme case, there is not reason why a single host behind a NAT (no other internal hosts) running a single application (no other network activity) has to ever send a 'keep-alive'. I hate to use analogies, but what you propose is like having a coffee house throw someone out just because they have not been drinking coffee for 5 minutes even though the coffee house is empty. What I am suggesting is that they be thrown out only when the coffee house is full (or close to full) and there are customers waiting for a seat. > not to mention the delays > in creating new NAT Sessions. In the existing proposal, a NAT silently expires a mapping without sending any ICMP etc; expiry is immediate -- there is no proposed TIMED_WAIT for the port after the mapping is expired. The same behavior can be preserved where the NAT silently and instantaneously expires the mapping when it is low on resources (as opposed to when an idle timer expires). -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00060.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00060.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzByUFluRmx0cWk2OTEvb1JBdjY2QUo5ZWJ0SXlXTnpVRDFGRUhSeE1C Yi9MK3lDbG5BQ2ZUOWQ5CmRnTFRhWWpJY0ZsenQ1MStRZFZCNlZvPQo9RHUxagotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Mon, 11 Jul 2005 11:32:14 -0700 (PDT) From: Saikat Guha Date: Mon, 11 Jul 2005 11:32:14 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF032B1868@zrc2hxm0.corp.nortel.com> Message-ID: <1121105665.5211.31.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2005-07-09 at 13:08 -0500, Francois Audet wrote: > > REQ-5: A NAT UDP mapping MUST NOT be reclaimed unless the NAT > > is unable > > to allocate a mapping for a new session. > > a) A NAT UDP mapping MUST NOT be reclaimed within 2 minutes of a > > packet traversing the NAT associated with that mapping. > > I think this is too stringent for most people. I'd leave REQ-5 as it is. Sure :) -- I was just saying what I would like, not proposing anything. :-p Now, if there is someone to second me on this, then my proposal would be: c) For maximum application compatibility, a NAT MAY expire mappings only when it is unable to allocate new mappings. Any seconds? -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00061.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00061.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzByY0JuRmx0cWk2OTEvb1JBdndJQUo5eHFUZ1RxWTI1bTYycmsyei90 Q0Y4bE1jc2VnQ2ZWa2Y0CnhiZ0NiRHBlNms2RVFSamZueUVmU0lzPQo9eGxxZQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Mon, 11 Jul 2005 11:33:51 -0700 (PDT) From: Saikat Guha Date: Mon, 11 Jul 2005 11:33:51 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel In-Reply-To: <20050711132458.45047.qmail@web40426.mail.yahoo.com> Message-ID: <1121106806.6513.0.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-07-11 at 06:24 -0700, Pyda Srisuresh wrote: > For > example, there is no case, where a NAT Session uses "Endpoint Indepenent > mapping" and "Address dependent filtering" (or) "Address dependent mapping" > and > "Address and Port Dependent filtering". Not sure about UDP, but I do see such behavior for TCP. In particular I see: NB=I,EF=I 5% NB=I,EF=A 10% NB=I,EF=ADP 55% NB=ADP,EF=I 2% NB=ADP,EF=ADP 12% NB=P,EF=I 1% NB=P,EF=ADP 3% see the STUNT result page for more details. For TCP at least, "Symmetric" subsumes 5 or more different types of NAT and is therefore unable to distinguish between them. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00062.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00062.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzBydDJuRmx0cWk2OTEvb1JBakxHQUo5OTJIUnpScjZrWS84SXNaV0ZD RXRCd3l3d1lBQ2ZRenp2CkpIazFwcFJZN1c1SUFQNklGNUVlYU8wPQo9eUVBZAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From ssenthil@cisco.com Mon, 11 Jul 2005 11:57:15 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Mon, 11 Jul 2005 11:57:15 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB5ADCE3@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] > Sent: Monday, July 11, 2005 2:01 PM > To: Pyda Srisuresh > Cc: Senthil Sivakumar (ssenthil); ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] FW: I-D > ACTION:draft-ietf-behave-nat-udp-02.txt > > On Sun, 2005-07-10 at 02:10 -0700, Pyda Srisuresh wrote: > > NAT devices do not time latencies [...] NAT devices use > idle timeouts > > "idle timeout" is not defined for protocols where only one > packet is ever sent or received, as is the case with many > ICMP requests. > > > > Making the idle timeouts for UDP Sessions dynamic has serious > > ramificatiosn on the resource usage and availability, > > I do not agree. If the NAT has space to allocate new mappings > and yet expires existing ones prematurely based on some > arbitrary timer in anticipation of new connections that may > or may not arrive, then the NAT is _wasting_ resources. In > the extreme case, there is not reason why a single host > behind a NAT (no other internal hosts) running a single > application (no other network activity) has to ever send a > 'keep-alive'. The NAT box is not just a NAT box - it does a bunch of other things. Resources consumed by NAT cannot be held on by an infinite amount of time, because there are other applications/protocols need this resource for something else. It is just not acceptable to customers to fill up the memory as I have seen with my experience. IMO, any proposal in these lines will be ignored by the NAT vendors - atlest majority of them. I am yet to hear anybody in this list saying that they would implement them. I don't see how a timer here is an arbitrary timer and how the resource based removal of mappings provide a consistent behavior of NAT boxes. Also, I don't understand how you would implement the resource based mappings to provide consistent behavior. Let's say that within a minute all my ICMP mappings are taken. I would have to drop the new ICMP mappings until when? If I am using the LRU algorithm the one I am removing was last used just a minute ago(the first one that was created). I could potentially cause thrashing. I assume you would say now use the timer when you have to decide which one to remove first. What should be the duration of this timer? I believe this WG should not mandate the implementation but just the requirements. I think I have said enough on this topic, I rest my case with strongly opposing any proposal of resource availability based removal of mappings. Senthil > > > From srisuresh@yahoo.com Mon, 11 Jul 2005 12:38:15 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 11 Jul 2005 12:38:15 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel In-Reply-To: <1ECE0EB50388174790F9694F77522CCF03329E30@zrc2hxm0.corp.nortel.com> Message-ID: <20050711193805.99504.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Francois Audet wrote: > We've been through this many times before, and people don't agree with > your > views on Binding vs. Mapping. It's as simple as that. > [suresh] Bryan and I have had numerous e-mail conversations with you and Cullen way back in 2004 on the inconsistent use of terms in the UDP draft. That was really the genesis of the behave-gen draft. David's comments about lack of consistent terms to allow NAT vendors to characterize their NAT devices triggered me to draw this to the attention of the list. It is clear, you still dont see what I am saying. It is not one of "Binding" vs "Mapping". It is inconsistent use of the term "Address/port Map" and not using the terms "NAT Session" and "Binding". Anyways, I am done tryign to convince you. I posted my concerns to the list to hear if others care. > Furthermore, since the very beginning of the group, it was agreed to NOT > use > the terminology Cone/Symmetric NAT because it is too confusing. > > Last meeting, in order to satisfy YOU, I added a section on relating the > new terminology with the Cone/Symmetric terminoly. We spent the whole > meeting arguing about what Symmetric really meant. > [suresh] Hmm... as I recall from the last WG meeting, the explanation text you had for Cone/Symmetric NATs in the UDP draft was more confusing than the original definitions and you were rushing to issue a WG last call on the draft. Someone in the meeting said one could drive a huge vehile through the holes inthe logic. I dont recall who. Naturally, I, as with many others, in the meeting were opposed to the text you had. > The agreement of the last meeting was therefore to REMOVE completely the > > terminology Cone/Symmetric from both the Behave document and from the > revised-RFC3489. The rationale is what we had claimed all along: that it > is too confusing, and has too many grey areas. And this was based on a > suggestion from the author of RFC 3489. > > This is settled. You can't ignore the decisions of the group like you > keep on doing. > [suresh] We agreed not to use the Cone/Symmetric terminology. I am fine with that. But, we had no agreement on the replacement text you had put in. For example, you say the Address Map behavior can be one of a) external Address independent, b) Address dependent or c) Address and Port Dependent. That makes no sense. The address Map behavior always is external Address or Port independent, even in the case of a Symmteric NAT. What is different is the way a "NAT Session" is setup that exhibits the Symmetric NAT vs Cone NAT behaviors. The parameters of a NAT Session are setup using wild-card matches for Address restricted and Full-Cone NAT. This is what characterizes the changes in filtering across Cone vs Symmetric NAT behaviors. Symmetric NATs do not use "Bindings". Cone NATs do. Together, "NAT Session" and "Binding" are the key instruments in describing the NAT behavior, without ever refering the Cone/Symmetric NAT terminology. Instead, you chose to explain this with the use of "Address/Port Map" and "fltering" behaviors, with 3 different possibilites for each type. You even drew a matrix on the acceptable combinations (in rev 0). It was extremely confusing. It is a good thing that you later removed the matrix. You strated believing in these behavioral model so much that you even had text to refresh the filtering behavior. I am just saying the model you had put together using non-standard terminology is confusing to even yourself. Given that, how do you expect vendors to charactrize their NAT devices without standard terminology? cheers, suresh > Let's move on. > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > Sent: Monday, July 11, 2005 06:25 > > To: Audet, Francois [SC100:9T51:EXCH]; David Barrett > > Cc: Behave > > Subject: RE: [Ietf-behave] Determining the precise behavior > > of a given NATmodel > > > > > > As David mentioned, I do believe, the BEHAVE drafts should > > use standard terminology in order for the vendors to be able > > to formalize the definition of their NAT characteristics. The > > terms should be standard across all the RFCs they refer (at a > > minimum, all NAT RFCs). The terminology used in the UDP draft > > conflicts with prior NAT terminology and is problematic in > > its current form. > > > > 1. The UDP draft defines the term "Address/Port Mapping" that > > contradicts prior definition of the same term in RFC 4008 (NAT MIB). > > > > RFC 4008 defines "Address/Port Map" as a configuration entry > > on a NAT device. NAT device looks up the configured map > > entries in determining translation parameters for new > > sessions. "Address/port map" entries stay mostly unchanged > > during the operation of a NAT device, as they are config entries. > > > > The UDP draft, on the other hand, defines "Address/Port > > Mapping" as assignment of a translation endpoint by the NAT > > device for an outgoing session and is created on the fly on a > > per-session basis. Unlike in RFC 4008, this is not a > > configuration entry. An associated "Mapping timer" is defined > > as the time a mapping will stay active without packets > > traversing the NAT. The equivalent of "Address/Port Mapping" > > and "Address/Port mapping timer" are "NAT Session" and "NAT > > Session idle timeout" in RFC 4008. > > > > 2. The UDP draft finds devious ways in which to work around > > the RFC 3489 definitions for Cone and Symmetric NATs. It does > > this by splitting NAT function into mapping and filtering > > behaviors. It defines Address/Port mapping behavior to be one > > of a) Endpoint independent, b) Address Dependent, c) Address > > and Port Dependent. And, defines filtering behavior of > > external packets to be one of a) Endpoint independent, b) > > Address Dependent, c) Address and Port Dependent. > > > > In reality, a NAT device has a single instrument called "NAT > > Session" that deals with both translation and packet > > filtering. Only packets pertaining to an existing "NAT > > Session" are permitted to traverse in either direction. For > > example, there is no case, where a NAT Session uses "Endpoint > > Indepenent mapping" and "Address dependent filtering" (or) > > "Address dependent mapping" and "Address and Port Dependent > > filtering". > > > > When an external packet comes inbound to a NAT assigned > > address/port endpoint and the exsting NAT Session does not > > match this packet, the NAT device has to make a fresh > > determinination on whether or not to make a new NAT Session > > based on the orientation of the "Address/Port Binding" in > > use. In case of NAPT, Port Bindings are outbound only and > > will not permit creating a new inbound NAT Session. The UDP > > draft does not use the term "Binding" or any associated terms > > in decribign the NAT behavior. > > > > NAT vendors ought to be able to use standard terminology such > > as "NAT Session", "NAt Session idle timeouts", "Binding", > > "Binding timeout" and so forth to describe the > > characteristics of their NAT device. > > > > cheers, > > suresh > > --- Francois Audet wrote: > > > > > I believe the UDP draft does exactly that. It describes > > very specific > > > Requirements that have to be met by NAT vendors. > > > > > > This is exactly why we got rid of fuzzy terminology like > > > Cone/Restricted and so forth that nobody agreed on the meaning. > > > > > > I don't see anything at this point that is not sufficiently > > clear for > > > NAT vendors in the udp draft. > > > > > > If there is anything SPECIFIC that is not clear, let me know. > > > > > > > -----Original Message----- > > > > From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] > > > > Sent: Sunday, July 10, 2005 02:12 > > > > To: Pyda Srisuresh > > > > Cc: Audet, Francois [SC100:9T51:EXCH]; Behave > > > > Subject: Re: [Ietf-behave] Determining the precise behavior > > > > of a given NATmodel > > > > > > > > > > > > Pyda Srisuresh wrote: > > > > > Even within BEHAVE RFCs, there can be variation across > > > > vendors in how > > > > > they implement the same RFC. Several of the > > requirements specify a > > > > > threshold, not the absolute value.Ex: NAT Session > > tmeouts, Binding > > > > > timeouts, Address-restricted Cone NAT behavior vs. Full > > Cone NAT > > > > > behavior, Fragmentation constraints etc. > > > > > > > > Yes, this is precisely my concern. I would like to see > > > > BEHAVE recommend > > > > that NAT vendors produce a formalized definition of their NAT > > > > characteristics -- using the BEHAVE-standardized > > terminology in some > > > > clearly defined, regularlized format. > > > > > > > > Think nutritional-guides on cereal boxes; something that > > > > allows you to > > > > look at 10 boxes side-by-side and clearly understand the specific > > > > differences. > > > > > > > > -david > > > > > > > > > > > > > > > > > > > > > > From audet@nortel.com Mon, 11 Jul 2005 12:59:47 -0700 (PDT) From: "Francois Audet" Date: Mon, 11 Jul 2005 12:59:47 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a givenNATmodel Message-ID: <1ECE0EB50388174790F9694F77522CCF0332A273@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Does ADP mean Address and Port Dependent? > -----Original Message----- > From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] > Sent: Monday, July 11, 2005 11:33 > To: Pyda Srisuresh > Cc: Audet, Francois [SC100:9T51:EXCH]; David Barrett; Behave > Subject: RE: [Ietf-behave] Determining the precise behavior > of a givenNATmodel > > > On Mon, 2005-07-11 at 06:24 -0700, Pyda Srisuresh wrote: > > For > > example, there is no case, where a NAT Session uses "Endpoint > > Indepenent mapping" and "Address dependent filtering" (or) "Address > > dependent mapping" and "Address and Port Dependent filtering". > > Not sure about UDP, but I do see such behavior for TCP. In > particular I > see: > > NB=I,EF=I 5% > NB=I,EF=A 10% > NB=I,EF=ADP 55% > NB=ADP,EF=I 2% > NB=ADP,EF=ADP 12% > NB=P,EF=I 1% > NB=P,EF=ADP 3% > > see the STUNT result page for more details. For TCP at least, > "Symmetric" subsumes 5 or more different types of NAT and is > therefore unable to distinguish between them. > > -- > Saikat > From sg266@cornell.edu Mon, 11 Jul 2005 13:19:31 -0700 (PDT) From: Saikat Guha Date: Mon, 11 Jul 2005 13:19:31 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a givenNATmodel In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0332A273@zrc2hxm0.corp.nortel.com> Message-ID: <1121113146.6513.10.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-07-11 at 14:59 -0500, Francois Audet wrote: > Does ADP mean Address and Port Dependent? Yes. -- Saikat (who vaguely recalls the NB=x and EF=x terminology being in the draft somewhere; but might just be suffering the after-effects of the Nappa Valley Winery tour.) Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00063.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00063.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzB0UTZuRmx0cWk2OTEvb1JBb1U3QUo5VUFCYUZ5VVZlZVhhNHI1dit3 QWU0SEo2aml3Q2ZRYWwxCmFNdFhYdStkZ2pNVXpMSDk5S3FOd1lZPQo9OStKQwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From dbarrett@quinthar.com Mon, 11 Jul 2005 17:57:20 -0700 (PDT) From: David Barrett Date: Mon, 11 Jul 2005 17:57:20 -0700 (PDT) Subject: [Ietf-behave] Standard Disclosure In-Reply-To: <1ECE0EB50388174790F9694F77522CCF03329DE3@zrc2hxm0.corp.nortel.com> Message-ID: <42D3156F.2060903@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Francois Audet wrote: Can you propose some text? Perhaps for section 1, or whatever section you feel is appropriate. I'd be happy to try. Reviewing the UDP draft [1] I'd propose including the following text: [1] ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-02.txt ---- 12. Standard Disclosure To help consumers compare and choose between competing NAT products, for each NAT variation there SHOULD be made available a standard disclosure of the NAT's behavior in the following form: Address and port mapping behavior: "endpoint independent" | "address dependent" | "address and port dependent" IP address pooling behavior: "unsupported" | "arbitrary" | "paired" Port preservation: "yes" | "no" | "overloading" Port-range preservation: "none" | "registered" | "dynamic" | "registered and dynamic" Port-parity preservation: "yes" | "no" Port-contiguity preservation: "yes" | "no" Mapping refresh timer: | "configurable" Mapping outbound refresh: "yes" | "no" Mapping inbound refresh: "yes" | "no" Unsolicited packet filtering: "endpoint independent" | "address dependent" | "address and port dependent" Filter refresh timer: | "configurable" Filter outbound refresh: "yes" | "no" Filter inbound refresh: "yes" | "no" Hairpining behavior: "none" | "external source address and port" | "internal source address and port" Fixed application level gateways: | "none" Configurable application level gateways: | "none" Mapping and filtering determinism: "deterministic" | "non-deterministic" Supports ICMP destination unreachable: "yes" | "no" Supports fragmentation: "yes" | "no" Fragment receive ordering: "ordered" | "out of order" | "none" Maximum transmission unit (MTU): | "configurable" For example, the product datasheet for a given NAT device might include the following complete description of its NAT behavior: Address and port mapping behavior: endpoint independent IP address pooling behavior: paired Port preservation: yes Port-range preservation: registered and dynamic Port-parity preservation: yes Port-contiguity preservation: yes Mapping refresh timer: configurable Mapping outbound refresh: yes Mapping inbound refresh: yes Unsolicited packet filtering: endpoint independent Filter refresh timer: configurable Filter outbound refresh: yes Filter inbound refresh: yes Hairpining behavior: external source address and port Fixed application level gateways: DNS, FTP Configurable application level gateways: none Mapping and filtering determinism: deterministic Supports ICMP destination unreachable: yes Supports fragmentation: yes Fragment receive ordering: out of order Maximum transmission unit (MTU): configurable REQ-14: The product literature and documentation for a NAT SHOULD include a standard description of its behavior in the form detailed by this document. ---- Questions: 1) Are they called "external ports and addresses" or "public ports and addresses"? I'm using "external". 2) Should we use "yes/no" or "true/false"? I'm using "yes/no". 3) Where should this be put? I'm recommending a new section after all the definitions, but before the requirements. 4) How strongly should it be required? I'm proposing "SHOULD". Naturally as the terminology in the draft changes, this section would need to be updated. However, I believe it provides a concise way to completely define a NAT's behavior, and thus enable the consumer to make an informed choice between competing choices. -david From audet@nortel.com Mon, 11 Jul 2005 18:12:52 -0700 (PDT) From: "Francois Audet" Date: Mon, 11 Jul 2005 18:12:52 -0700 (PDT) Subject: RE: [Ietf-behave] Standard Disclosure Message-ID: <1ECE0EB50388174790F9694F77522CCF0332A6EF@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Or perhaps I could include a little table in section 12 with all your items, but including the REQ number they correspond to. I think it is a reasonable idea. I don't mind adding somthing like that. Anybody opposed? I think I've heard at least two voices supporting this. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > David Barrett > Sent: Monday, July 11, 2005 17:57 > To: 'Behave' > Subject: [Ietf-behave] Standard Disclosure > > > Francois Audet wrote: > > Can you propose some text? Perhaps for section 1, or > whatever section > > you feel is appropriate. > > I'd be happy to try. Reviewing the UDP draft [1] I'd propose > including > the following text: > > [1] > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-02.txt > > ---- > > 12. Standard Disclosure > > To help consumers compare and choose between competing NAT > products, for > each NAT variation there SHOULD be made available a standard > disclosure > of the NAT's behavior in the following form: > > Address and port mapping behavior: > "endpoint independent" | > "address dependent" | > "address and port dependent" > IP address pooling behavior: > "unsupported" | > "arbitrary" | > "paired" > Port preservation: > "yes" | > "no" | > "overloading" > Port-range preservation: > "none" | > "registered" | > "dynamic" | > "registered and dynamic" > Port-parity preservation: > "yes" | > "no" > Port-contiguity preservation: > "yes" | > "no" > Mapping refresh timer: > | > "configurable" > Mapping outbound refresh: > "yes" | > "no" > Mapping inbound refresh: > "yes" | > "no" > Unsolicited packet filtering: > "endpoint independent" | > "address dependent" | > "address and port dependent" > Filter refresh timer: > | > "configurable" > Filter outbound refresh: > "yes" | > "no" > Filter inbound refresh: > "yes" | > "no" > Hairpining behavior: > "none" | > "external source address and port" | > "internal source address and port" > Fixed application level gateways: > | > "none" > Configurable application level gateways: > | > "none" > Mapping and filtering determinism: > "deterministic" | > "non-deterministic" > Supports ICMP destination unreachable: > "yes" | > "no" > Supports fragmentation: > "yes" | > "no" > Fragment receive ordering: > "ordered" | > "out of order" | > "none" > Maximum transmission unit (MTU): > | > "configurable" > > For example, the product datasheet for a given NAT device > might include > the following complete description of its NAT behavior: > > Address and port mapping behavior: endpoint independent > IP address pooling behavior: paired > Port preservation: yes > Port-range preservation: registered and dynamic > Port-parity preservation: yes > Port-contiguity preservation: yes > Mapping refresh timer: configurable > Mapping outbound refresh: yes > Mapping inbound refresh: yes > Unsolicited packet filtering: endpoint independent > Filter refresh timer: configurable > Filter outbound refresh: yes > Filter inbound refresh: yes > Hairpining behavior: external source address > and port > Fixed application level gateways: DNS, FTP > Configurable application level gateways: none > Mapping and filtering determinism: deterministic > Supports ICMP destination unreachable: yes > Supports fragmentation: yes > Fragment receive ordering: out of order > Maximum transmission unit (MTU): configurable > > REQ-14: The product literature and documentation for a NAT SHOULD > include a standard description of its behavior in the > form detailed > by this document. > > ---- > > Questions: > 1) Are they called "external ports and addresses" or "public > ports and > addresses"? I'm using "external". > 2) Should we use "yes/no" or "true/false"? I'm using "yes/no". > 3) Where should this be put? I'm recommending a new section > after all > the definitions, but before the requirements. > 4) How strongly should it be required? I'm proposing "SHOULD". > > Naturally as the terminology in the draft changes, this section would > need to be updated. However, I believe it provides a concise way to > completely define a NAT's behavior, and thus enable the > consumer to make > an informed choice between competing choices. > > -david > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From dbarrett@quinthar.com Mon, 11 Jul 2005 18:23:19 -0700 (PDT) From: David Barrett Date: Mon, 11 Jul 2005 18:23:19 -0700 (PDT) Subject: Re: [Ietf-behave] Standard Disclosure In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0332A6EF@zrc2hxm0.corp.nortel.com> Message-ID: <42D31B7F.5030208@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Francois Audet wrote: Or perhaps I could include a little table in section 12 with all your items, but including the REQ number they correspond to. My original instinct was along these lines, too, but then I decided to keep it focused on exclusively the topic of disclosing NAT behavior in a regular way. I didn't want to confuse the section by unnecessarily cross-referencing it against the requirements -- it's not intended to be an index or summary of requirements. With that in mind, I stick to my original proposal of giving it its own section. I think it is a reasonable idea. I don't mind adding somthing like that. Anybody opposed? I think I've heard at least two voices supporting this. Thanks. I think it'd be useful, too. -david From dbarrett@quinthar.com Mon, 11 Jul 2005 19:03:29 -0700 (PDT) From: David Barrett Date: Mon, 11 Jul 2005 19:03:29 -0700 (PDT) Subject: [Ietf-behave] Growing mapping refresh timers Message-ID: <42D324F0.5060609@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Having just read-through the latest UDP draft, I noticed I've been seeing behavior in the real world that doesn't fit the range of possibilities outlined. Specifically, I've seen the mapping timer grow up to a certain point through use, rather than use a fixed timeout. For example, I created a simple mapping-timeout test that sent a "delayed ping" -- a ping that doesn't reply until after a certain delay. On a certain NAT I found I could initially do a delayed-ping up to 16 seconds, and it'd work fine on the first time. And if I bumped up by powers of two, I could get to a delayed-ping time of 256 seconds, without trouble. But if I started out with a delayed-ping of 256 (or indeed, anything over 16), it would fail and I'd hear no response. My theory is that it's growing the mapping timer in line with activity. I haven't done an exhaustive analysis (ie, does it grow incrementally, or does it upgrade in one step from 16 to 256 seconds?) but either way, I didn't see this type of behavior mentioned. (Though I guess it could fall under the broad category of "non-deterministic".) Have you experienced this or heard of it elsewhere? -david From audet@nortel.com Mon, 11 Jul 2005 19:19:41 -0700 (PDT) From: "Francois Audet" Date: Mon, 11 Jul 2005 19:19:41 -0700 (PDT) Subject: RE: [Ietf-behave] Growing mapping refresh timers Message-ID: <1ECE0EB50388174790F9694F77522CCF0332A710@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Sounds like another form of unpredictability to me... I'm not even surprised anymore by the bizarre behaviors out there... > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > David Barrett > Sent: Monday, July 11, 2005 19:03 > To: 'Behave' > Subject: [Ietf-behave] Growing mapping refresh timers > > > Having just read-through the latest UDP draft, I noticed I've been > seeing behavior in the real world that doesn't fit the range of > possibilities outlined. Specifically, I've seen the mapping > timer grow > up to a certain point through use, rather than use a fixed timeout. > > For example, I created a simple mapping-timeout test that sent a > "delayed ping" -- a ping that doesn't reply until after a > certain delay. > On a certain NAT I found I could initially do a > delayed-ping up to 16 > seconds, and it'd work fine on the first time. And if I bumped up by > powers of two, I could get to a delayed-ping time of 256 seconds, > without trouble. But if I started out with a delayed-ping of 256 (or > indeed, anything over 16), it would fail and I'd hear no response. > > My theory is that it's growing the mapping timer in line with > activity. > I haven't done an exhaustive analysis (ie, does it grow > incrementally, > or does it upgrade in one step from 16 to 256 seconds?) but > either way, > I didn't see this type of behavior mentioned. (Though I > guess it could > fall under the broad category of "non-deterministic".) > > Have you experienced this or heard of it elsewhere? > > -david > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From fluffy@cisco.com Tue, 12 Jul 2005 04:30:17 -0700 (PDT) From: Cullen Jennings Date: Tue, 12 Jul 2005 04:30:17 -0700 (PDT) Subject: Re: [Ietf-behave] Standard Disclosure In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0332A6EF@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cullen with my individual hat on .... Guys, I think this is in the wrong draft. Put all this stuff in the test results draft including the table for all the NATs we have tested. I can move the next version of draft-jennings-behave-test-results to this style. I like the basic way the terminology is set up. If we use these terms in a test draft, it will help others that compare and publish results about NAT behavior. If someone proposed a standard XML format for this, I would make my test programs spit that out as output. That might be very useful for the folks on this list that run web sites that collect results from many NAT. Basically, I like the idea of common terminology, but think it should go in the test-results draft. I would not hold my breath waiting to see this show up on the back of a box that you might see at the local Best Buy. Looking at what is on the boxes now, the amount of space on them etc, I imagine the best we can hope for is is something like it supports "RFC XXX - NAT UDP". And one comment with my chair hat on. I can not think of another circumstance where IETF told vendors what to put on a datasheet. I don't see anything about that in the charter. There are standards group that do this type of branded activity stuff (The "WiFi" brand being one of the best known) but those group have contractual relationships with vendors that allow them to cause things to happen that would be impossible for IETF. Cullen On 7/11/05 9:12 PM, "Francois Audet" wrote: > Or perhaps I could include a little table in section 12 with all your > items, but including the REQ number they correspond to. > > I think it is a reasonable idea. I don't mind adding somthing like that. > > Anybody opposed? > > I think I've heard at least two voices supporting this. > >> -----Original Message----- >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of >> David Barrett >> Sent: Monday, July 11, 2005 17:57 >> To: 'Behave' >> Subject: [Ietf-behave] Standard Disclosure >> >> >> Francois Audet wrote: >>> Can you propose some text? Perhaps for section 1, or >> whatever section >>> you feel is appropriate. >> >> I'd be happy to try. Reviewing the UDP draft [1] I'd propose >> including >> the following text: >> >> [1] >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-02.txt >> >> ---- >> >> 12. Standard Disclosure >> >> To help consumers compare and choose between competing NAT >> products, for >> each NAT variation there SHOULD be made available a standard >> disclosure >> of the NAT's behavior in the following form: >> >> Address and port mapping behavior: >> "endpoint independent" | >> "address dependent" | >> "address and port dependent" >> IP address pooling behavior: >> "unsupported" | >> "arbitrary" | >> "paired" >> Port preservation: >> "yes" | >> "no" | >> "overloading" >> Port-range preservation: >> "none" | >> "registered" | >> "dynamic" | >> "registered and dynamic" >> Port-parity preservation: >> "yes" | >> "no" >> Port-contiguity preservation: >> "yes" | >> "no" >> Mapping refresh timer: >> | >> "configurable" >> Mapping outbound refresh: >> "yes" | >> "no" >> Mapping inbound refresh: >> "yes" | >> "no" >> Unsolicited packet filtering: >> "endpoint independent" | >> "address dependent" | >> "address and port dependent" >> Filter refresh timer: >> | >> "configurable" >> Filter outbound refresh: >> "yes" | >> "no" >> Filter inbound refresh: >> "yes" | >> "no" >> Hairpining behavior: >> "none" | >> "external source address and port" | >> "internal source address and port" >> Fixed application level gateways: >> | >> "none" >> Configurable application level gateways: >> | >> "none" >> Mapping and filtering determinism: >> "deterministic" | >> "non-deterministic" >> Supports ICMP destination unreachable: >> "yes" | >> "no" >> Supports fragmentation: >> "yes" | >> "no" >> Fragment receive ordering: >> "ordered" | >> "out of order" | >> "none" >> Maximum transmission unit (MTU): >> | >> "configurable" >> >> For example, the product datasheet for a given NAT device >> might include >> the following complete description of its NAT behavior: >> >> Address and port mapping behavior: endpoint independent >> IP address pooling behavior: paired >> Port preservation: yes >> Port-range preservation: registered and dynamic >> Port-parity preservation: yes >> Port-contiguity preservation: yes >> Mapping refresh timer: configurable >> Mapping outbound refresh: yes >> Mapping inbound refresh: yes >> Unsolicited packet filtering: endpoint independent >> Filter refresh timer: configurable >> Filter outbound refresh: yes >> Filter inbound refresh: yes >> Hairpining behavior: external source address >> and port >> Fixed application level gateways: DNS, FTP >> Configurable application level gateways: none >> Mapping and filtering determinism: deterministic >> Supports ICMP destination unreachable: yes >> Supports fragmentation: yes >> Fragment receive ordering: out of order >> Maximum transmission unit (MTU): configurable >> >> REQ-14: The product literature and documentation for a NAT SHOULD >> include a standard description of its behavior in the >> form detailed >> by this document. >> >> ---- >> >> Questions: >> 1) Are they called "external ports and addresses" or "public >> ports and >> addresses"? I'm using "external". >> 2) Should we use "yes/no" or "true/false"? I'm using "yes/no". >> 3) Where should this be put? I'm recommending a new section >> after all >> the definitions, but before the requirements. >> 4) How strongly should it be required? I'm proposing "SHOULD". >> >> Naturally as the terminology in the draft changes, this section would >> need to be updated. However, I believe it provides a concise way to >> completely define a NAT's behavior, and thus enable the >> consumer to make >> an informed choice between competing choices. >> >> -david >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> >> From srisuresh@yahoo.com Tue, 12 Jul 2005 06:08:36 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 12 Jul 2005 06:08:36 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1121103606.5211.4.camel@localhost.localdomain> Message-ID: <20050712130833.66154.qmail@web40429.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Sat, 2005-07-09 at 23:50 -0700, Pyda Srisuresh wrote: > > [suresh] So long as the NAT Session is alive for an application-x, the port > > binding would stay alive. SO, there is no chance of another application-y > > reusing the same external port while NAT Session from application-x is kept > > alive. The worst thing that could happen is that the internal host closed > > application-x on its local port, but the associated port binding stays > alive on > > the NAT. > > I am confused. Can you define "port binding" and "NAT session" in the > context of your mail or point me to the RFC that defines them; since I > suspect it differs from that in the UDP draft. > [suresh] Saikat - Take a look at draft-ford-behave-gen-01.txt, section 2. cheers, suresh > -- > Saikat > From srisuresh@yahoo.com Tue, 12 Jul 2005 06:16:08 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 12 Jul 2005 06:16:08 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel In-Reply-To: <1121106653.5211.45.camel@localhost.localdomain> Message-ID: <20050712131607.64062.qmail@web40425.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Mon, 2005-07-11 at 06:24 -0700, Pyda Srisuresh wrote: > > For > > example, there is no case, where a NAT Session uses "Endpoint Indepenent > > mapping" and "Address dependent filtering" (or) "Address dependent mapping" > and > > "Address and Port Dependent filtering". > > Not sure about UDP, but I do see such behavior for TCP. In particular I > see: > > NB=I,EF=I 5% > NB=I,EF=A 10% > NB=I,EF=ADP 55% > NB=ADP,EF=I 2% > NB=ADP,EF=ADP 12% > NB=P,EF=I 1% > NB=P,EF=ADP 3% > > see the STUNT result page for more details. For TCP at least, > "Symmetric" subsumes 5 or more different types of NAT is therefore > unable to distinguish between them. > [suresh] Can you point me to the URL that has the test dscription and the test results? Thanks. cheers, suresh > -- > Saikat > From srisuresh@yahoo.com Tue, 12 Jul 2005 06:43:36 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 12 Jul 2005 06:43:36 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB5ADCE3@xmb-sjc-236.amer.cisco.com> Message-ID: <20050712134335.50546.qmail@web40422.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- "Senthil Sivakumar (ssenthil)" wrote: > > > > -----Original Message----- > > From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] > > Sent: Monday, July 11, 2005 2:01 PM > > To: Pyda Srisuresh > > Cc: Senthil Sivakumar (ssenthil); ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] FW: I-D > > ACTION:draft-ietf-behave-nat-udp-02.txt > > > > On Sun, 2005-07-10 at 02:10 -0700, Pyda Srisuresh wrote: > > > NAT devices do not time latencies [...] NAT devices use > > idle timeouts > > > > "idle timeout" is not defined for protocols where only one > > packet is ever sent or received, as is the case with many > > ICMP requests. > > [suresh] Saikat - What makes you think that "idle timeout" is not used for ICMP requests. If a response is not received within the idle timeout, the NAT Session associated with ICMP request will be dropped. NAT devices do not do latency measurements for ICMP, AFAIK. Are you aware of NAT devices that do this differently using latencies for ICMP requests? > > > > > Making the idle timeouts for UDP Sessions dynamic has serious > > > ramificatiosn on the resource usage and availability, > > > > I do not agree. If the NAT has space to allocate new mappings > > and yet expires existing ones prematurely based on some > > arbitrary timer in anticipation of new connections that may > > or may not arrive, then the NAT is _wasting_ resources. In > > the extreme case, there is not reason why a single host > > behind a NAT (no other internal hosts) running a single > > application (no other network activity) has to ever send a > > 'keep-alive'. > > The NAT box is not just a NAT box - it does a bunch of other things. > Resources consumed by NAT cannot be held on by an infinite amount of > time, because there are other applications/protocols need this resource > for something else. It is just not acceptable to customers to fill up > the memory as I have seen with my experience. IMO, any proposal in these > lines will be ignored by the NAT vendors - atlest majority of them. I am > yet to hear anybody in this list saying that they would implement them. > I don't see how a timer here is an arbitrary timer and how the resource > based removal of mappings provide a consistent behavior of NAT boxes. > > Also, I don't understand how you would implement the resource based > mappings to provide consistent behavior. Let's say that within a minute > all my ICMP mappings are taken. I would have to drop the new ICMP > mappings until when? If I am using the LRU algorithm the one I am > removing was last used just a minute ago(the first one that was > created). I could potentially cause thrashing. I assume you would say > now use the timer when you have to decide which one to remove first. > What should be the duration of this timer? I believe this WG should not > mandate the implementation but just the requirements. I think I have > said enough on this topic, I rest my case with strongly opposing any > proposal of resource availability based removal of mappings. > [suresh] Right. Fully agree with Senthil's comments. I would strongly oppose any requirement mandating new resource management algorithm implementation. There are several caveats to doing this. NATs use idle timeouts to manage their resources, namely NAT Sessions & Bindings. I donot believe, we should propose newer algorithms. However, if you have alternate suggestions, that can go as hints to implementors. cheers, suresh > Senthil > > > > > > > > From srisuresh@yahoo.com Tue, 12 Jul 2005 06:49:01 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 12 Jul 2005 06:49:01 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: Message-ID: <20050712134900.76828.qmail@web40428.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dave Hudson wrote: > * -----Original Message----- > * From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > * [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > * Saikat Guha > * Sent: 11 July 2005 19:01 > * To: Pyda Srisuresh > * Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > * Subject: RE: [Ietf-behave] FW: I-D > * ACTION:draft-ietf-behave-nat-udp-02.txt > * > * I do not agree. If the NAT has space to allocate new mappings > * and yet expires existing ones prematurely based on some > * arbitrary timer in anticipation of new connections that may > * or may not arrive, then the NAT is _wasting_ resources. In > * the extreme case, there is not reason why a single host > * behind a NAT (no other internal hosts) running a single > * application (no other network activity) has to ever send a > * 'keep-alive'. > * I hate to use analogies, but what you propose is like having > * a coffee house throw someone out just because they have not > * been drinking coffee for 5 minutes even though the coffee > * house is empty. What I am suggesting is that they be thrown > * out only when the coffee house is full (or close to full) and > * there are customers waiting for a seat. > > The problem here is a loss of determinism. Some days your app will work > and others it will fail because the NAT mapping is timed-out. > Experience tells me that users will get incredibly frustrated by this as > will OEM tech support staff. Those same tech support staff and users > will complain bitterly about flaky software and after lots of heated > emails on the subject the NAT implementors will be asked to make things > behave the same way under all circumstances. > [suresh] Right. Well said. > I also suspect that most NAT impelementors won't appreciate this either > because it will make regression testing very difficult too - > implementing unit tests for anything potentially non-deterministic is > much harder. > > FWIW there's at least one commercial testsuite used by a lot of SOHO > router manufacturers that current expects that sessions will timeout due > to inactivity. > [suresh] It makes sense because that is what NATs do. cheers, suresh > > Regards, > Dave > From audet@nortel.com Tue, 12 Jul 2005 08:16:10 -0700 (PDT) From: "Francois Audet" Date: Tue, 12 Jul 2005 08:16:10 -0700 (PDT) Subject: RE: [Ietf-behave] Standard Disclosure Message-ID: <1ECE0EB50388174790F9694F77522CCF0332AA7E@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Thanks. Agree. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Tuesday, July 12, 2005 04:30 > To: Audet, Francois [SC100:9T51:EXCH]; David Barrett; Behave > Subject: Re: [Ietf-behave] Standard Disclosure > > > > Cullen with my individual hat on .... > > Guys, I think this is in the wrong draft. Put all this stuff > in the test results draft including the table for all the > NATs we have tested. I can move the next version of > draft-jennings-behave-test-results to this style. I like the > basic way the terminology is set up. If we use these terms in > a test draft, it will help others that compare and publish > results about NAT behavior. If someone proposed a standard > XML format for this, I would make my test programs spit that > out as output. That might be very useful for the folks on > this list that run web sites that collect results from many > NAT. Basically, I like the idea of common terminology, but > think it should go in the test-results draft. > > I would not hold my breath waiting to see this show up on the > back of a box that you might see at the local Best Buy. > Looking at what is on the boxes now, the amount of space on > them etc, I imagine the best we can hope for is is something > like it supports "RFC XXX - NAT UDP". > > > And one comment with my chair hat on. > > I can not think of another circumstance where IETF told > vendors what to put on a datasheet. I don't see anything > about that in the charter. There are standards group that do > this type of branded activity stuff (The "WiFi" brand being > one of the best known) but those group have contractual > relationships with vendors that allow them to cause things to > happen that would be impossible for IETF. > > Cullen > > > > On 7/11/05 9:12 PM, "Francois Audet" wrote: > > > Or perhaps I could include a little table in section 12 > with all your > > items, but including the REQ number they correspond to. > > > > I think it is a reasonable idea. I don't mind adding somthing like > > that. > > > > Anybody opposed? > > > > I think I've heard at least two voices supporting this. > > > >> -----Original Message----- > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf > Of David > >> Barrett > >> Sent: Monday, July 11, 2005 17:57 > >> To: 'Behave' > >> Subject: [Ietf-behave] Standard Disclosure > >> > >> > >> Francois Audet wrote: > >>> Can you propose some text? Perhaps for section 1, or > >> whatever section > >>> you feel is appropriate. > >> > >> I'd be happy to try. Reviewing the UDP draft [1] I'd propose > >> including the following text: > >> > >> [1] > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-02.txt > >> > >> ---- > >> > >> 12. Standard Disclosure > >> > >> To help consumers compare and choose between competing NAT > products, > >> for each NAT variation there SHOULD be made available a standard > >> disclosure > >> of the NAT's behavior in the following form: > >> > >> Address and port mapping behavior: > >> "endpoint independent" | > >> "address dependent" | > >> "address and port dependent" > >> IP address pooling behavior: > >> "unsupported" | > >> "arbitrary" | > >> "paired" > >> Port preservation: > >> "yes" | > >> "no" | > >> "overloading" > >> Port-range preservation: > >> "none" | > >> "registered" | > >> "dynamic" | > >> "registered and dynamic" > >> Port-parity preservation: > >> "yes" | > >> "no" > >> Port-contiguity preservation: > >> "yes" | > >> "no" > >> Mapping refresh timer: > >> | > >> "configurable" > >> Mapping outbound refresh: > >> "yes" | > >> "no" > >> Mapping inbound refresh: > >> "yes" | > >> "no" > >> Unsolicited packet filtering: > >> "endpoint independent" | > >> "address dependent" | > >> "address and port dependent" > >> Filter refresh timer: > >> | > >> "configurable" > >> Filter outbound refresh: > >> "yes" | > >> "no" > >> Filter inbound refresh: > >> "yes" | > >> "no" > >> Hairpining behavior: > >> "none" | > >> "external source address and port" | > >> "internal source address and port" > >> Fixed application level gateways: > >> | > >> "none" > >> Configurable application level gateways: > >> | > >> "none" > >> Mapping and filtering determinism: > >> "deterministic" | > >> "non-deterministic" > >> Supports ICMP destination unreachable: > >> "yes" | > >> "no" > >> Supports fragmentation: > >> "yes" | > >> "no" > >> Fragment receive ordering: > >> "ordered" | > >> "out of order" | > >> "none" > >> Maximum transmission unit (MTU): > >> | > >> "configurable" > >> > >> For example, the product datasheet for a given NAT device might > >> include the following complete description of its NAT behavior: > >> > >> Address and port mapping behavior: endpoint independent > >> IP address pooling behavior: paired > >> Port preservation: yes > >> Port-range preservation: registered > and dynamic > >> Port-parity preservation: yes > >> Port-contiguity preservation: yes > >> Mapping refresh timer: configurable > >> Mapping outbound refresh: yes > >> Mapping inbound refresh: yes > >> Unsolicited packet filtering: endpoint independent > >> Filter refresh timer: configurable > >> Filter outbound refresh: yes > >> Filter inbound refresh: yes > >> Hairpining behavior: external > source address > >> and port > >> Fixed application level gateways: DNS, FTP > >> Configurable application level gateways: none > >> Mapping and filtering determinism: deterministic > >> Supports ICMP destination unreachable: yes > >> Supports fragmentation: yes > >> Fragment receive ordering: out of order > >> Maximum transmission unit (MTU): configurable > >> > >> REQ-14: The product literature and documentation for a NAT SHOULD > >> include a standard description of its behavior in the form > >> detailed > >> by this document. > >> > >> ---- > >> > >> Questions: > >> 1) Are they called "external ports and addresses" or "public ports > >> and addresses"? I'm using "external". > >> 2) Should we use "yes/no" or "true/false"? I'm using "yes/no". > >> 3) Where should this be put? I'm recommending a new section > >> after all > >> the definitions, but before the requirements. > >> 4) How strongly should it be required? I'm proposing "SHOULD". > >> > >> Naturally as the terminology in the draft changes, this > section would > >> need to be updated. However, I believe it provides a > concise way to > >> completely define a NAT's behavior, and thus enable the > consumer to > >> make an informed choice between competing choices. > >> > >> -david > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > >> > > > From sg266@cornell.edu Tue, 12 Jul 2005 14:02:51 -0700 (PDT) From: Saikat Guha Date: Tue, 12 Jul 2005 14:02:51 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel In-Reply-To: <20050712131607.64062.qmail@web40425.mail.yahoo.com> Message-ID: <1121201953.6513.110.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-07-12 at 06:16 -0700, Pyda Srisuresh wrote: > [suresh] Can you point me to the URL that has the test dscription and the test > results? Thanks. Results: https://www.guha.cc/saikat/stunt-results.php?sort=-5,-1 Test Descriptions: http://nutss.gforge.cis.cornell.edu/stunt-client.php cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00064.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00064.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzFDOGhuRmx0cWk2OTEvb1JBa3NsQUo5YmFpYy9hcXdZUjhFUllPVXpS aVliR0laMGR3Q2VPeHpYCnNGVnFJQ3NaQ1JlYVRFV1JZMUw0cEJZPQo9a1VkKwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From audet@nortel.com Tue, 12 Jul 2005 14:10:12 -0700 (PDT) From: "Francois Audet" Date: Tue, 12 Jul 2005 14:10:12 -0700 (PDT) Subject: RE: [Ietf-behave] Determining the precise behavior of a given NATmodel Message-ID: <1ECE0EB50388174790F9694F77522CCF0339304B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Wow, this is great. Thanks for doing this. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Tuesday, July 12, 2005 13:59 > To: Pyda Srisuresh > Cc: Behave > Subject: RE: [Ietf-behave] Determining the precise behavior > of a given NATmodel > > > On Tue, 2005-07-12 at 06:16 -0700, Pyda Srisuresh wrote: > > [suresh] Can you point me to the URL that has the test > dscription and > > the test results? Thanks. > > Results: https://www.guha.cc/saikat/stunt-results.php?sort=-5,-1 > > Test Descriptions: > http://nutss.gforge.cis.cornell.edu/stunt-client.php > > cheers, > -- > Saikat > From sg266@cornell.edu Tue, 12 Jul 2005 14:10:35 -0700 (PDT) From: Saikat Guha Date: Tue, 12 Jul 2005 14:10:35 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <20050712134335.50546.qmail@web40422.mail.yahoo.com> Message-ID: <1121202608.6513.121.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-07-12 at 06:43 -0700, Pyda Srisuresh wrote: > [suresh] Saikat - What makes you think that "idle timeout" is not used for > ICMP > requests. If a response is not received within the idle timeout, the NAT > Session associated with ICMP request will be dropped. NAT devices do not do > latency measurements for ICMP, AFAIK. Are you aware of NAT devices that do > this > differently using latencies for ICMP requests? I may have caused some confusion. I meant that for an ICMP request response pair (like ping), the "idle timer" is used to overcome the latency. I do not know whether or not NATs refresh this "idle timer" when the ping response comes back -- say you were to modify the host being pinged to generate multiple ping responses (spread over a couple of seconds) to a single ping request, would that NAT refresh the timer each time a ping response came in or would it just expire the mapping after a fixed duration from sending the request. Just wondering ... not that this affects the UDP draft. > if you have alternate suggestions, that can go as > hints to implementors. Fair enough. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00065.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00065.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzFER3ZuRmx0cWk2OTEvb1JBbzdBQUo5RWhnNHMwbzI5TzM3aExhVWdv WENaQVJDdzVBQ2ZhU3Q2Cks2RjNHQ0NoZ1lqdjkrdytvME0yTkRnPQo9QmYwcAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From dbarrett@quinthar.com Tue, 12 Jul 2005 14:12:28 -0700 (PDT) From: David Barrett Date: Tue, 12 Jul 2005 14:12:28 -0700 (PDT) Subject: Re: [Ietf-behave] Standard Disclosure In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0332AA7E@zrc2hxm0.corp.nortel.com> Message-ID: <42D4323C.8030301@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain I can see this perspective. I think it depends on whether or not there is an explicit requirement that vendors disclose their NAT behavior in this form. If it is required, it'd need to be kept in the BEHAVE draft with the other requirements. If it's not required, I agree it can (and probably should) be moved to a separate document. And to clarify, I agree it won't likely go onto the box. But I don't think it's onerous to require that it go *somewhere*, such as in the product documentation. The impetus for all this was because I was doing research on a specific NAT model and could find *no* description of its behavior, anywhere, in any detailed form. I proposed the following requirement text: REQ-14: The product literature and documentation for a NAT SHOULD include a standard description of its behavior in the form detailed by this document. This is intentionally ambiguous in its reference to "product literature and documentation" (though perhaps an 'or' would be better there) to give the vendor flexibility in where to put it, so long as it's put *somewhere*. So I pose this question: should BEHAVE make *any* requirement (of any strength) that vendors disclose NAT behavior in a standard way, or not? I vote yes, else I fear vendors will stick with "business as usual" which means non-disclosure. -david Francois Audet wrote: Thanks. Agree. -----Original Message----- From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] Sent: Tuesday, July 12, 2005 04:30 To: Audet, Francois [SC100:9T51:EXCH]; David Barrett; Behave Subject: Re: [Ietf-behave] Standard Disclosure Cullen with my individual hat on .... Guys, I think this is in the wrong draft. Put all this stuff in the test results draft including the table for all the NATs we have tested. I can move the next version of draft-jennings-behave-test-results to this style. I like the basic way the terminology is set up. If we use these terms in a test draft, it will help others that compare and publish results about NAT behavior. If someone proposed a standard XML format for this, I would make my test programs spit that out as output. That might be very useful for the folks on this list that run web sites that collect results from many NAT. Basically, I like the idea of common terminology, but think it should go in the test-results draft. I would not hold my breath waiting to see this show up on the back of a box that you might see at the local Best Buy. Looking at what is on the boxes now, the amount of space on them etc, I imagine the best we can hope for is is something like it supports "RFC XXX - NAT UDP". And one comment with my chair hat on. I can not think of another circumstance where IETF told vendors what to put on a datasheet. I don't see anything about that in the charter. There are standards group that do this type of branded activity stuff (The "WiFi" brand being one of the best known) but those group have contractual relationships with vendors that allow them to cause things to happen that would be impossible for IETF. Cullen On 7/11/05 9:12 PM, "Francois Audet" wrote: Or perhaps I could include a little table in section 12 with all your items, but including the REQ number they correspond to. I think it is a reasonable idea. I don't mind adding somthing like that. Anybody opposed? I think I've heard at least two voices supporting this. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of David Barrett Sent: Monday, July 11, 2005 17:57 To: 'Behave' Subject: [Ietf-behave] Standard Disclosure Francois Audet wrote: Can you propose some text? Perhaps for section 1, or whatever section you feel is appropriate. I'd be happy to try. Reviewing the UDP draft [1] I'd propose including the following text: [1] ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-02.txt ---- 12. Standard Disclosure To help consumers compare and choose between competing NAT products, for each NAT variation there SHOULD be made available a standard disclosure of the NAT's behavior in the following form: Address and port mapping behavior: "endpoint independent" | "address dependent" | "address and port dependent" IP address pooling behavior: "unsupported" | "arbitrary" | "paired" Port preservation: "yes" | "no" | "overloading" Port-range preservation: "none" | "registered" | "dynamic" | "registered and dynamic" Port-parity preservation: "yes" | "no" Port-contiguity preservation: "yes" | "no" Mapping refresh timer: | "configurable" Mapping outbound refresh: "yes" | "no" Mapping inbound refresh: "yes" | "no" Unsolicited packet filtering: "endpoint independent" | "address dependent" | "address and port dependent" Filter refresh timer: | "configurable" Filter outbound refresh: "yes" | "no" Filter inbound refresh: "yes" | "no" Hairpining behavior: "none" | "external source address and port" | "internal source address and port" Fixed application level gateways: | "none" Configurable application level gateways: | "none" Mapping and filtering determinism: "deterministic" | "non-deterministic" Supports ICMP destination unreachable: "yes" | "no" Supports fragmentation: "yes" | "no" Fragment receive ordering: "ordered" | "out of order" | "none" Maximum transmission unit (MTU): | "configurable" For example, the product datasheet for a given NAT device might include the following complete description of its NAT behavior: Address and port mapping behavior: endpoint independent IP address pooling behavior: paired Port preservation: yes Port-range preservation: registered and dynamic Port-parity preservation: yes Port-contiguity preservation: yes Mapping refresh timer: configurable Mapping outbound refresh: yes Mapping inbound refresh: yes Unsolicited packet filtering: endpoint independent Filter refresh timer: configurable Filter outbound refresh: yes Filter inbound refresh: yes Hairpining behavior: external source address and port Fixed application level gateways: DNS, FTP Configurable application level gateways: none Mapping and filtering determinism: deterministic Supports ICMP destination unreachable: yes Supports fragmentation: yes Fragment receive ordering: out of order Maximum transmission unit (MTU): configurable REQ-14: The product literature and documentation for a NAT SHOULD include a standard description of its behavior in the form detailed by this document. ---- Questions: 1) Are they called "external ports and addresses" or "public ports and addresses"? I'm using "external". 2) Should we use "yes/no" or "true/false"? I'm using "yes/no". 3) Where should this be put? I'm recommending a new section after all the definitions, but before the requirements. 4) How strongly should it be required? I'm proposing "SHOULD". Naturally as the terminology in the draft changes, this section would need to be updated. However, I believe it provides a concise way to completely define a NAT's behavior, and thus enable the consumer to make an informed choice between competing choices. -david _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Tue, 12 Jul 2005 14:25:11 -0700 (PDT) From: "Francois Audet" Date: Tue, 12 Jul 2005 14:25:11 -0700 (PDT) Subject: RE: [Ietf-behave] Standard Disclosure Message-ID: <1ECE0EB50388174790F9694F77522CCF0339309B@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Hi David, How about something right into the first paragraphs of section 12 (just before the actual requirements), that says: It is RECOMMENDED that the product literature and documentation for a NAT include a standard description of its behavior in the form detailed by this document. Specifically, it SHOULD detail its support for the individual requirements defined in this section. [ individual reqs follow ] > -----Original Message----- > From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] > Sent: Tuesday, July 12, 2005 14:12 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: Cullen Jennings; Behave > Subject: Re: [Ietf-behave] Standard Disclosure > > > I can see this perspective. I think it depends on whether or > not there > is an explicit requirement that vendors disclose their NAT > behavior in > this form. If it is required, it'd need to be kept in the > BEHAVE draft > with the other requirements. If it's not required, I agree > it can (and > probably should) be moved to a separate document. > > And to clarify, I agree it won't likely go onto the box. But I don't > think it's onerous to require that it go *somewhere*, such as in the > product documentation. The impetus for all this was because > I was doing > research on a specific NAT model and could find *no* > description of its > behavior, anywhere, in any detailed form. > > I proposed the following requirement text: > > REQ-14: The product literature and documentation for a NAT SHOULD > include a standard description of its behavior in the > form detailed > by this document. > > This is intentionally ambiguous in its reference to "product > literature > and documentation" (though perhaps an 'or' would be better there) to > give the vendor flexibility in where to put it, so long as it's put > *somewhere*. > > So I pose this question: should BEHAVE make *any* requirement (of any > strength) that vendors disclose NAT behavior in a standard > way, or not? > > I vote yes, else I fear vendors will stick with "business as usual" > which means non-disclosure. > > -david > > Francois Audet wrote: > > Thanks. > > > > Agree. > > > > > >>-----Original Message----- > >>From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > >>Sent: Tuesday, July 12, 2005 04:30 > >>To: Audet, Francois [SC100:9T51:EXCH]; David Barrett; Behave > >>Subject: Re: [Ietf-behave] Standard Disclosure > >> > >> > >> > >>Cullen with my individual hat on .... > >> > >>Guys, I think this is in the wrong draft. Put all this stuff > >>in the test results draft including the table for all the > >>NATs we have tested. I can move the next version of > >>draft-jennings-behave-test-results to this style. I like the > >>basic way the terminology is set up. If we use these terms in > >>a test draft, it will help others that compare and publish > >>results about NAT behavior. If someone proposed a standard > >>XML format for this, I would make my test programs spit that > >>out as output. That might be very useful for the folks on > >>this list that run web sites that collect results from many > >>NAT. Basically, I like the idea of common terminology, but > >>think it should go in the test-results draft. > >> > >>I would not hold my breath waiting to see this show up on the > >>back of a box that you might see at the local Best Buy. > >>Looking at what is on the boxes now, the amount of space on > >>them etc, I imagine the best we can hope for is is something > >>like it supports "RFC XXX - NAT UDP". > >> > >> > >>And one comment with my chair hat on. > >> > >>I can not think of another circumstance where IETF told > >>vendors what to put on a datasheet. I don't see anything > >>about that in the charter. There are standards group that do > >>this type of branded activity stuff (The "WiFi" brand being > >>one of the best known) but those group have contractual > >>relationships with vendors that allow them to cause things to > >>happen that would be impossible for IETF. > >> > >>Cullen > >> > >> > >> > >>On 7/11/05 9:12 PM, "Francois Audet" wrote: > >> > >> > >>>Or perhaps I could include a little table in section 12 > >> > >>with all your > >> > >>>items, but including the REQ number they correspond to. > >>> > >>>I think it is a reasonable idea. I don't mind adding somthing like > >>>that. > >>> > >>>Anybody opposed? > >>> > >>>I think I've heard at least two voices supporting this. > >>> > >>> > >>>>-----Original Message----- > >>>>From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>>[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf > >> > >>Of David > >> > >>>>Barrett > >>>>Sent: Monday, July 11, 2005 17:57 > >>>>To: 'Behave' > >>>>Subject: [Ietf-behave] Standard Disclosure > >>>> > >>>> > >>>>Francois Audet wrote: > >>>> > >>>>>Can you propose some text? Perhaps for section 1, or > >>>> > >>>>whatever section > >>>> > >>>>>you feel is appropriate. > >>>> > >>>>I'd be happy to try. Reviewing the UDP draft [1] I'd propose > >>>>including the following text: > >>>> > >>>>[1] > >>>>ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat-u > dp-02.txt > >>>> > >>>>---- > >>>> > >>>>12. Standard Disclosure > >>>> > >>>>To help consumers compare and choose between competing NAT > >> > >>products, > >> > >>>>for each NAT variation there SHOULD be made available a standard > >>>>disclosure of the NAT's behavior in the following form: > >>>> > >>>> Address and port mapping behavior: > >>>> "endpoint independent" | > >>>> "address dependent" | > >>>> "address and port dependent" > >>>> IP address pooling behavior: > >>>> "unsupported" | > >>>> "arbitrary" | > >>>> "paired" > >>>> Port preservation: > >>>> "yes" | > >>>> "no" | > >>>> "overloading" > >>>> Port-range preservation: > >>>> "none" | > >>>> "registered" | > >>>> "dynamic" | > >>>> "registered and dynamic" > >>>> Port-parity preservation: > >>>> "yes" | > >>>> "no" > >>>> Port-contiguity preservation: > >>>> "yes" | > >>>> "no" > >>>> Mapping refresh timer: > >>>> | > >>>> "configurable" > >>>> Mapping outbound refresh: > >>>> "yes" | > >>>> "no" > >>>> Mapping inbound refresh: > >>>> "yes" | > >>>> "no" > >>>> Unsolicited packet filtering: > >>>> "endpoint independent" | > >>>> "address dependent" | > >>>> "address and port dependent" > >>>> Filter refresh timer: > >>>> | > >>>> "configurable" > >>>> Filter outbound refresh: > >>>> "yes" | > >>>> "no" > >>>> Filter inbound refresh: > >>>> "yes" | > >>>> "no" > >>>> Hairpining behavior: > >>>> "none" | > >>>> "external source address and port" | > >>>> "internal source address and port" > >>>> Fixed application level gateways: > >>>> | > >>>> "none" > >>>> Configurable application level gateways: > >>>> | > >>>> "none" > >>>> Mapping and filtering determinism: > >>>> "deterministic" | > >>>> "non-deterministic" > >>>> Supports ICMP destination unreachable: > >>>> "yes" | > >>>> "no" > >>>> Supports fragmentation: > >>>> "yes" | > >>>> "no" > >>>> Fragment receive ordering: > >>>> "ordered" | > >>>> "out of order" | > >>>> "none" > >>>> Maximum transmission unit (MTU): > >>>> | > >>>> "configurable" > >>>> > >>>>For example, the product datasheet for a given NAT device might > >>>>include the following complete description of its NAT behavior: > >>>> > >>>> Address and port mapping behavior: endpoint independent > >>>> IP address pooling behavior: paired > >>>> Port preservation: yes > >>>> Port-range preservation: registered > >> > >>and dynamic > >> > >>>> Port-parity preservation: yes > >>>> Port-contiguity preservation: yes > >>>> Mapping refresh timer: configurable > >>>> Mapping outbound refresh: yes > >>>> Mapping inbound refresh: yes > >>>> Unsolicited packet filtering: endpoint independent > >>>> Filter refresh timer: configurable > >>>> Filter outbound refresh: yes > >>>> Filter inbound refresh: yes > >>>> Hairpining behavior: external > >> > >>source address > >> > >>>>and port > >>>> Fixed application level gateways: DNS, FTP > >>>> Configurable application level gateways: none > >>>> Mapping and filtering determinism: deterministic > >>>> Supports ICMP destination unreachable: yes > >>>> Supports fragmentation: yes > >>>> Fragment receive ordering: out of order > >>>> Maximum transmission unit (MTU): configurable > >>>> > >>>>REQ-14: The product literature and documentation for a NAT SHOULD > >>>> include a standard description of its behavior in the form > >>>>detailed > >>>> by this document. > >>>> > >>>>---- > >>>> > >>>>Questions: > >>>>1) Are they called "external ports and addresses" or "public ports > >>>>and addresses"? I'm using "external". > >>>>2) Should we use "yes/no" or "true/false"? I'm using "yes/no". > >>>>3) Where should this be put? I'm recommending a new section > >>>>after all > >>>>the definitions, but before the requirements. > >>>>4) How strongly should it be required? I'm proposing "SHOULD". > >>>> > >>>>Naturally as the terminology in the draft changes, this > >> > >>section would > >> > >>>>need to be updated. However, I believe it provides a > >> > >>concise way to > >> > >>>>completely define a NAT's behavior, and thus enable the > >> > >>consumer to > >> > >>>>make an informed choice between competing choices. > >>>> > >>>>-david > >>>>_______________________________________________ > >>>>Ietf-behave mailing list > >>>>Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>> > >>>> > >> > >> > >> > > > > > > From dhudson@ubicom.com Tue, 12 Jul 2005 14:40:10 -0700 (PDT) From: "Dave Hudson" Date: Tue, 12 Jul 2005 14:40:10 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain * -----Original Message----- * From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] * Sent: 12 July 2005 22:30 * To: Dave Hudson * Cc: Pyda Srisuresh; ietf-behave@xxxxxxxxxxxxxxxxxxx * Subject: RE: [Ietf-behave] FW: I-D * ACTION:draft-ietf-behave-nat-udp-02.txt * * On Mon, 2005-07-11 at 12:16 -0700, Dave Hudson wrote: * > FWIW there's at least one commercial testsuite used by a * lot of SOHO * > router manufacturers that current expects that sessions * will timeout * > due to inactivity. * * Interesting. Could you point me to more about this testsuite. Thanks. Sure - the testsuite is called CDRouter. You can get more info from www.qacafe.com. We've been using it for about 12 months now. Aside from testing basic NAT behaviours (including hairpinning - complete with a reference to one of this WG's drafts) it also includes tests for quite a large number of common ALGs. Regards, Dave From sg266@cornell.edu Tue, 12 Jul 2005 14:53:54 -0700 (PDT) From: Saikat Guha Date: Tue, 12 Jul 2005 14:53:54 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: Message-ID: <1121203801.6513.126.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-07-11 at 12:16 -0700, Dave Hudson wrote: > The problem here is a loss of determinism. I agree, to some extent. > FWIW there's at least one commercial testsuite used by a lot of SOHO > router manufacturers that current expects that sessions will timeout due > to inactivity. Interesting. Could you point me to more about this testsuite. Thanks. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00066.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00066.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzFEWlpuRmx0cWk2OTEvb1JBbmVEQUo5bXBjc3E3aThqZ3JVcC9zUWNi U3hLQ3p4RXVnQ2ZaOVhoClJ6QUtoL1Y1ZWRaM1pFbWdwWXBnaTBBPQo9YkFHYgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From fluffy@cisco.com Tue, 12 Jul 2005 15:09:23 -0700 (PDT) From: Cullen Jennings Date: Tue, 12 Jul 2005 15:09:23 -0700 (PDT) Subject: Re: [Ietf-behave] Standard Disclosure In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0339309B@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I'm very uneasy about this - are there outer places where IETF has done this? On 7/12/05 5:24 PM, "Francois Audet" wrote: > Hi David, > > How about something right into the first paragraphs of section 12 (just > before > the actual requirements), that says: > > It is RECOMMENDED that the product literature and documentation > for a > NAT include a standard description of its behavior in the form > detailed > by this document. Specifically, it SHOULD detail its support for > the > individual requirements defined in this section. > [ individual reqs follow ] > > > >> -----Original Message----- >> From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] >> Sent: Tuesday, July 12, 2005 14:12 >> To: Audet, Francois [SC100:9T51:EXCH] >> Cc: Cullen Jennings; Behave >> Subject: Re: [Ietf-behave] Standard Disclosure >> >> >> I can see this perspective. I think it depends on whether or >> not there >> is an explicit requirement that vendors disclose their NAT >> behavior in >> this form. If it is required, it'd need to be kept in the >> BEHAVE draft >> with the other requirements. If it's not required, I agree >> it can (and >> probably should) be moved to a separate document. >> >> And to clarify, I agree it won't likely go onto the box. But I don't >> think it's onerous to require that it go *somewhere*, such as in the >> product documentation. The impetus for all this was because >> I was doing >> research on a specific NAT model and could find *no* >> description of its >> behavior, anywhere, in any detailed form. >> >> I proposed the following requirement text: >> >> REQ-14: The product literature and documentation for a NAT SHOULD >> include a standard description of its behavior in the >> form detailed >> by this document. >> >> This is intentionally ambiguous in its reference to "product >> literature >> and documentation" (though perhaps an 'or' would be better there) to >> give the vendor flexibility in where to put it, so long as it's put >> *somewhere*. >> >> So I pose this question: should BEHAVE make *any* requirement (of any >> strength) that vendors disclose NAT behavior in a standard >> way, or not? >> >> I vote yes, else I fear vendors will stick with "business as usual" >> which means non-disclosure. >> >> -david >> >> Francois Audet wrote: >>> Thanks. >>> >>> Agree. >>> >>> >>>> -----Original Message----- >>>> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] >>>> Sent: Tuesday, July 12, 2005 04:30 >>>> To: Audet, Francois [SC100:9T51:EXCH]; David Barrett; Behave >>>> Subject: Re: [Ietf-behave] Standard Disclosure >>>> >>>> >>>> >>>> Cullen with my individual hat on .... >>>> >>>> Guys, I think this is in the wrong draft. Put all this stuff >>>> in the test results draft including the table for all the >>>> NATs we have tested. I can move the next version of >>>> draft-jennings-behave-test-results to this style. I like the >>>> basic way the terminology is set up. If we use these terms in >>>> a test draft, it will help others that compare and publish >>>> results about NAT behavior. If someone proposed a standard >>>> XML format for this, I would make my test programs spit that >>>> out as output. That might be very useful for the folks on >>>> this list that run web sites that collect results from many >>>> NAT. Basically, I like the idea of common terminology, but >>>> think it should go in the test-results draft. >>>> >>>> I would not hold my breath waiting to see this show up on the >>>> back of a box that you might see at the local Best Buy. >>>> Looking at what is on the boxes now, the amount of space on >>>> them etc, I imagine the best we can hope for is is something >>>> like it supports "RFC XXX - NAT UDP". >>>> >>>> >>>> And one comment with my chair hat on. >>>> >>>> I can not think of another circumstance where IETF told >>>> vendors what to put on a datasheet. I don't see anything >>>> about that in the charter. There are standards group that do >>>> this type of branded activity stuff (The "WiFi" brand being >>>> one of the best known) but those group have contractual >>>> relationships with vendors that allow them to cause things to >>>> happen that would be impossible for IETF. >>>> >>>> Cullen >>>> >>>> >>>> >>>> On 7/11/05 9:12 PM, "Francois Audet" wrote: >>>> >>>> >>>>> Or perhaps I could include a little table in section 12 >>>> >>>> with all your >>>> >>>>> items, but including the REQ number they correspond to. >>>>> >>>>> I think it is a reasonable idea. I don't mind adding somthing like >>>>> that. >>>>> >>>>> Anybody opposed? >>>>> >>>>> I think I've heard at least two voices supporting this. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >>>>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf >>>> >>>> Of David >>>> >>>>>> Barrett >>>>>> Sent: Monday, July 11, 2005 17:57 >>>>>> To: 'Behave' >>>>>> Subject: [Ietf-behave] Standard Disclosure >>>>>> >>>>>> >>>>>> Francois Audet wrote: >>>>>> >>>>>>> Can you propose some text? Perhaps for section 1, or >>>>>> >>>>>> whatever section >>>>>> >>>>>>> you feel is appropriate. >>>>>> >>>>>> I'd be happy to try. Reviewing the UDP draft [1] I'd propose >>>>>> including the following text: >>>>>> >>>>>> [1] >>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat-u >> dp-02.txt >>>>>> >>>>>> ---- >>>>>> >>>>>> 12. Standard Disclosure >>>>>> >>>>>> To help consumers compare and choose between competing NAT >>>> >>>> products, >>>> >>>>>> for each NAT variation there SHOULD be made available a standard >>>>>> disclosure of the NAT's behavior in the following form: >>>>>> >>>>>> Address and port mapping behavior: >>>>>> "endpoint independent" | >>>>>> "address dependent" | >>>>>> "address and port dependent" >>>>>> IP address pooling behavior: >>>>>> "unsupported" | >>>>>> "arbitrary" | >>>>>> "paired" >>>>>> Port preservation: >>>>>> "yes" | >>>>>> "no" | >>>>>> "overloading" >>>>>> Port-range preservation: >>>>>> "none" | >>>>>> "registered" | >>>>>> "dynamic" | >>>>>> "registered and dynamic" >>>>>> Port-parity preservation: >>>>>> "yes" | >>>>>> "no" >>>>>> Port-contiguity preservation: >>>>>> "yes" | >>>>>> "no" >>>>>> Mapping refresh timer: >>>>>> | >>>>>> "configurable" >>>>>> Mapping outbound refresh: >>>>>> "yes" | >>>>>> "no" >>>>>> Mapping inbound refresh: >>>>>> "yes" | >>>>>> "no" >>>>>> Unsolicited packet filtering: >>>>>> "endpoint independent" | >>>>>> "address dependent" | >>>>>> "address and port dependent" >>>>>> Filter refresh timer: >>>>>> | >>>>>> "configurable" >>>>>> Filter outbound refresh: >>>>>> "yes" | >>>>>> "no" >>>>>> Filter inbound refresh: >>>>>> "yes" | >>>>>> "no" >>>>>> Hairpining behavior: >>>>>> "none" | >>>>>> "external source address and port" | >>>>>> "internal source address and port" >>>>>> Fixed application level gateways: >>>>>> | >>>>>> "none" >>>>>> Configurable application level gateways: >>>>>> | >>>>>> "none" >>>>>> Mapping and filtering determinism: >>>>>> "deterministic" | >>>>>> "non-deterministic" >>>>>> Supports ICMP destination unreachable: >>>>>> "yes" | >>>>>> "no" >>>>>> Supports fragmentation: >>>>>> "yes" | >>>>>> "no" >>>>>> Fragment receive ordering: >>>>>> "ordered" | >>>>>> "out of order" | >>>>>> "none" >>>>>> Maximum transmission unit (MTU): >>>>>> | >>>>>> "configurable" >>>>>> >>>>>> For example, the product datasheet for a given NAT device might >>>>>> include the following complete description of its NAT behavior: >>>>>> >>>>>> Address and port mapping behavior: endpoint independent >>>>>> IP address pooling behavior: paired >>>>>> Port preservation: yes >>>>>> Port-range preservation: registered >>>> >>>> and dynamic >>>> >>>>>> Port-parity preservation: yes >>>>>> Port-contiguity preservation: yes >>>>>> Mapping refresh timer: configurable >>>>>> Mapping outbound refresh: yes >>>>>> Mapping inbound refresh: yes >>>>>> Unsolicited packet filtering: endpoint independent >>>>>> Filter refresh timer: configurable >>>>>> Filter outbound refresh: yes >>>>>> Filter inbound refresh: yes >>>>>> Hairpining behavior: external >>>> >>>> source address >>>> >>>>>> and port >>>>>> Fixed application level gateways: DNS, FTP >>>>>> Configurable application level gateways: none >>>>>> Mapping and filtering determinism: deterministic >>>>>> Supports ICMP destination unreachable: yes >>>>>> Supports fragmentation: yes >>>>>> Fragment receive ordering: out of order >>>>>> Maximum transmission unit (MTU): configurable >>>>>> >>>>>> REQ-14: The product literature and documentation for a NAT SHOULD >>>>>> include a standard description of its behavior in the form >>>>>> detailed >>>>>> by this document. >>>>>> >>>>>> ---- >>>>>> >>>>>> Questions: >>>>>> 1) Are they called "external ports and addresses" or "public ports >>>>>> and addresses"? I'm using "external". >>>>>> 2) Should we use "yes/no" or "true/false"? I'm using "yes/no". >>>>>> 3) Where should this be put? I'm recommending a new section >>>>>> after all >>>>>> the definitions, but before the requirements. >>>>>> 4) How strongly should it be required? I'm proposing "SHOULD". >>>>>> >>>>>> Naturally as the terminology in the draft changes, this >>>> >>>> section would >>>> >>>>>> need to be updated. However, I believe it provides a >>>> >>>> concise way to >>>> >>>>>> completely define a NAT's behavior, and thus enable the >>>> >>>> consumer to >>>> >>>>>> make an informed choice between competing choices. >>>>>> >>>>>> -david >>>>>> _______________________________________________ >>>>>> Ietf-behave mailing list >>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> >> >> From audet@nortel.com Tue, 12 Jul 2005 15:13:41 -0700 (PDT) From: "Francois Audet" Date: Tue, 12 Jul 2005 15:13:41 -0700 (PDT) Subject: RE: [Ietf-behave] Standard Disclosure Message-ID: <1ECE0EB50388174790F9694F77522CCF033931A5@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Don't know. Doubt it. Perhaps something to ask guidance from the AD before we change anything. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Tuesday, July 12, 2005 15:09 > To: Audet, Francois [SC100:9T51:EXCH]; David Barrett > Cc: Behave > Subject: Re: [Ietf-behave] Standard Disclosure > > > > I'm very uneasy about this - are there outer places where > IETF has done this? > > On 7/12/05 5:24 PM, "Francois Audet" wrote: > > > Hi David, > > > > How about something right into the first paragraphs of section 12 > > (just before the actual requirements), that says: > > > > It is RECOMMENDED that the product literature and > documentation for a > > NAT include a standard description of its behavior in the form > > detailed > > by this document. Specifically, it SHOULD detail its support for > > the > > individual requirements defined in this section. > > [ individual reqs follow ] > > > > > > > >> -----Original Message----- > >> From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] > >> Sent: Tuesday, July 12, 2005 14:12 > >> To: Audet, Francois [SC100:9T51:EXCH] > >> Cc: Cullen Jennings; Behave > >> Subject: Re: [Ietf-behave] Standard Disclosure > >> > >> > >> I can see this perspective. I think it depends on whether or > >> not there > >> is an explicit requirement that vendors disclose their NAT > >> behavior in > >> this form. If it is required, it'd need to be kept in the > >> BEHAVE draft > >> with the other requirements. If it's not required, I agree > >> it can (and > >> probably should) be moved to a separate document. > >> > >> And to clarify, I agree it won't likely go onto the box. > But I don't > >> think it's onerous to require that it go *somewhere*, such > as in the > >> product documentation. The impetus for all this was because > >> I was doing > >> research on a specific NAT model and could find *no* > >> description of its > >> behavior, anywhere, in any detailed form. > >> > >> I proposed the following requirement text: > >> > >> REQ-14: The product literature and documentation for a NAT SHOULD > >> include a standard description of its behavior in the > >> form detailed > >> by this document. > >> > >> This is intentionally ambiguous in its reference to "product > >> literature > >> and documentation" (though perhaps an 'or' would be better > there) to > >> give the vendor flexibility in where to put it, so long as it's put > >> *somewhere*. > >> > >> So I pose this question: should BEHAVE make *any* > requirement (of any > >> strength) that vendors disclose NAT behavior in a standard > >> way, or not? > >> > >> I vote yes, else I fear vendors will stick with "business as usual" > >> which means non-disclosure. > >> > >> -david > >> > >> Francois Audet wrote: > >>> Thanks. > >>> > >>> Agree. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > >>>> Sent: Tuesday, July 12, 2005 04:30 > >>>> To: Audet, Francois [SC100:9T51:EXCH]; David Barrett; Behave > >>>> Subject: Re: [Ietf-behave] Standard Disclosure > >>>> > >>>> > >>>> > >>>> Cullen with my individual hat on .... > >>>> > >>>> Guys, I think this is in the wrong draft. Put all this stuff > >>>> in the test results draft including the table for all the > >>>> NATs we have tested. I can move the next version of > >>>> draft-jennings-behave-test-results to this style. I like the > >>>> basic way the terminology is set up. If we use these terms in > >>>> a test draft, it will help others that compare and publish > >>>> results about NAT behavior. If someone proposed a standard > >>>> XML format for this, I would make my test programs spit that > >>>> out as output. That might be very useful for the folks on > >>>> this list that run web sites that collect results from many > >>>> NAT. Basically, I like the idea of common terminology, but > >>>> think it should go in the test-results draft. > >>>> > >>>> I would not hold my breath waiting to see this show up on the > >>>> back of a box that you might see at the local Best Buy. > >>>> Looking at what is on the boxes now, the amount of space on > >>>> them etc, I imagine the best we can hope for is is something > >>>> like it supports "RFC XXX - NAT UDP". > >>>> > >>>> > >>>> And one comment with my chair hat on. > >>>> > >>>> I can not think of another circumstance where IETF told > >>>> vendors what to put on a datasheet. I don't see anything > >>>> about that in the charter. There are standards group that do > >>>> this type of branded activity stuff (The "WiFi" brand being > >>>> one of the best known) but those group have contractual > >>>> relationships with vendors that allow them to cause things to > >>>> happen that would be impossible for IETF. > >>>> > >>>> Cullen > >>>> > >>>> > >>>> > >>>> On 7/11/05 9:12 PM, "Francois Audet" wrote: > >>>> > >>>> > >>>>> Or perhaps I could include a little table in section 12 > >>>> > >>>> with all your > >>>> > >>>>> items, but including the REQ number they correspond to. > >>>>> > >>>>> I think it is a reasonable idea. I don't mind adding > somthing like > >>>>> that. > >>>>> > >>>>> Anybody opposed? > >>>>> > >>>>> I think I've heard at least two voices supporting this. > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf > >>>> > >>>> Of David > >>>> > >>>>>> Barrett > >>>>>> Sent: Monday, July 11, 2005 17:57 > >>>>>> To: 'Behave' > >>>>>> Subject: [Ietf-behave] Standard Disclosure > >>>>>> > >>>>>> > >>>>>> Francois Audet wrote: > >>>>>> > >>>>>>> Can you propose some text? Perhaps for section 1, or > >>>>>> > >>>>>> whatever section > >>>>>> > >>>>>>> you feel is appropriate. > >>>>>> > >>>>>> I'd be happy to try. Reviewing the UDP draft [1] I'd propose > >>>>>> including the following text: > >>>>>> > >>>>>> [1] > >>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat-u > >> dp-02.txt > >>>>>> > >>>>>> ---- > >>>>>> > >>>>>> 12. Standard Disclosure > >>>>>> > >>>>>> To help consumers compare and choose between competing NAT > >>>> > >>>> products, > >>>> > >>>>>> for each NAT variation there SHOULD be made available > a standard > >>>>>> disclosure of the NAT's behavior in the following form: > >>>>>> > >>>>>> Address and port mapping behavior: > >>>>>> "endpoint independent" | > >>>>>> "address dependent" | > >>>>>> "address and port dependent" > >>>>>> IP address pooling behavior: > >>>>>> "unsupported" | > >>>>>> "arbitrary" | > >>>>>> "paired" > >>>>>> Port preservation: > >>>>>> "yes" | > >>>>>> "no" | > >>>>>> "overloading" > >>>>>> Port-range preservation: > >>>>>> "none" | > >>>>>> "registered" | > >>>>>> "dynamic" | > >>>>>> "registered and dynamic" > >>>>>> Port-parity preservation: > >>>>>> "yes" | > >>>>>> "no" > >>>>>> Port-contiguity preservation: > >>>>>> "yes" | > >>>>>> "no" > >>>>>> Mapping refresh timer: > >>>>>> | > >>>>>> "configurable" > >>>>>> Mapping outbound refresh: > >>>>>> "yes" | > >>>>>> "no" > >>>>>> Mapping inbound refresh: > >>>>>> "yes" | > >>>>>> "no" > >>>>>> Unsolicited packet filtering: > >>>>>> "endpoint independent" | > >>>>>> "address dependent" | > >>>>>> "address and port dependent" > >>>>>> Filter refresh timer: > >>>>>> | > >>>>>> "configurable" > >>>>>> Filter outbound refresh: > >>>>>> "yes" | > >>>>>> "no" > >>>>>> Filter inbound refresh: > >>>>>> "yes" | > >>>>>> "no" > >>>>>> Hairpining behavior: > >>>>>> "none" | > >>>>>> "external source address and port" | > >>>>>> "internal source address and port" > >>>>>> Fixed application level gateways: > >>>>>> | > >>>>>> "none" > >>>>>> Configurable application level gateways: > >>>>>> | > >>>>>> "none" > >>>>>> Mapping and filtering determinism: > >>>>>> "deterministic" | > >>>>>> "non-deterministic" > >>>>>> Supports ICMP destination unreachable: > >>>>>> "yes" | > >>>>>> "no" > >>>>>> Supports fragmentation: > >>>>>> "yes" | > >>>>>> "no" > >>>>>> Fragment receive ordering: > >>>>>> "ordered" | > >>>>>> "out of order" | > >>>>>> "none" > >>>>>> Maximum transmission unit (MTU): > >>>>>> | > >>>>>> "configurable" > >>>>>> > >>>>>> For example, the product datasheet for a given NAT device might > >>>>>> include the following complete description of its NAT behavior: > >>>>>> > >>>>>> Address and port mapping behavior: endpoint > independent > >>>>>> IP address pooling behavior: paired > >>>>>> Port preservation: yes > >>>>>> Port-range preservation: registered > >>>> > >>>> and dynamic > >>>> > >>>>>> Port-parity preservation: yes > >>>>>> Port-contiguity preservation: yes > >>>>>> Mapping refresh timer: configurable > >>>>>> Mapping outbound refresh: yes > >>>>>> Mapping inbound refresh: yes > >>>>>> Unsolicited packet filtering: endpoint > independent > >>>>>> Filter refresh timer: configurable > >>>>>> Filter outbound refresh: yes > >>>>>> Filter inbound refresh: yes > >>>>>> Hairpining behavior: external > >>>> > >>>> source address > >>>> > >>>>>> and port > >>>>>> Fixed application level gateways: DNS, FTP > >>>>>> Configurable application level gateways: none > >>>>>> Mapping and filtering determinism: deterministic > >>>>>> Supports ICMP destination unreachable: yes > >>>>>> Supports fragmentation: yes > >>>>>> Fragment receive ordering: out of order > >>>>>> Maximum transmission unit (MTU): configurable > >>>>>> > >>>>>> REQ-14: The product literature and documentation for a > NAT SHOULD > >>>>>> include a standard description of its behavior in the form > >>>>>> detailed > >>>>>> by this document. > >>>>>> > >>>>>> ---- > >>>>>> > >>>>>> Questions: > >>>>>> 1) Are they called "external ports and addresses" or > "public ports > >>>>>> and addresses"? I'm using "external". > >>>>>> 2) Should we use "yes/no" or "true/false"? I'm using "yes/no". > >>>>>> 3) Where should this be put? I'm recommending a new section > >>>>>> after all > >>>>>> the definitions, but before the requirements. > >>>>>> 4) How strongly should it be required? I'm proposing "SHOULD". > >>>>>> > >>>>>> Naturally as the terminology in the draft changes, this > >>>> > >>>> section would > >>>> > >>>>>> need to be updated. However, I believe it provides a > >>>> > >>>> concise way to > >>>> > >>>>>> completely define a NAT's behavior, and thus enable the > >>>> > >>>> consumer to > >>>> > >>>>>> make an informed choice between competing choices. > >>>>>> > >>>>>> -david > >>>>>> _______________________________________________ > >>>>>> Ietf-behave mailing list > >>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>>>> > >>>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > From dbarrett@quinthar.com Tue, 12 Jul 2005 17:55:59 -0700 (PDT) From: David Barrett Date: Tue, 12 Jul 2005 17:55:59 -0700 (PDT) Subject: Re: [Ietf-behave] Standard Disclosure In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0339309B@zrc2hxm0.corp.nortel.com> Message-ID: <42D4669D.5030502@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Francois Audet wrote: Hi David, How about something right into the first paragraphs of section 12 (just before the actual requirements), that says: It is RECOMMENDED that the product literature and documentation for a NAT include a standard description of its behavior in the form detailed by this document. Specifically, it SHOULD detail its support for the individual requirements defined in this section. [ individual reqs follow ] This sounds like a good idea to me. We could then put the BNF-like disclosure grammar into a following section, a supporting document*, or skip it altogether. * I wouldn't recommend putting it into a supporting document, as that introduces maintenance dependencies. It all depends on whether or not we compel or even recommend to NAT vendors that they disclose their behavior in a standardized way. Per Cullen's question of whether other RFCs have done anything like this, the only "prior art" I can find is RFC 1979 requesting acknowledgement of its use (but doesn't require it) in the product documentation. However, whether or not it's common practice, I still think it's a good idea, and I see no prohibition against it. As I believe Francois said earlier "NAT vendors want to do the right thing". We have a unique opportunity to enable them to do so. There is simply no other organization or entity that has the same opportunity as we do now. No one will begrudge us for passing up the chance to create a standardized disclosure format; nobody asked us to do it in the first place. But I find it very unlikely that anybody would complain if we tried, and some might even thank us. -david From audet@nortel.com Wed, 13 Jul 2005 15:20:26 -0700 (PDT) From: "Francois Audet" Date: Wed, 13 Jul 2005 15:20:26 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <1ECE0EB50388174790F9694F77522CCF033CE0DD@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Mapping and Binding do NO mean the same thing. It was decided a while ago to use the term mapping because it applies to both "symmetric" and "cone" NATs, which is not the case for binding. It was felt that the word binding (as described in behave-gen) and other documents was not appropriate for the purpose of this document Furthermore, the classification using the terminoly of "binding" did not reflect the full range of NATs that we experimentaly tested and therefore was not suitable for this document. > -----Original Message----- > From: Saikat Guha [mailto:saikat@xxxxxxxxxxxxxx] > Sent: Wednesday, July 13, 2005 15:16 > To: Pyda Srisuresh > Cc: Audet, Francois [SC100:9T51:EXCH]; Behave > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > > Thanks to suresh's pointer on the definitions, I think I > understand "bindings" now. Correct me if I am wrong; I > believe "Bindings" (draft- > ford-behave-gen-01.txt) mean more or less the same as > "Mapping" (per draft-ietf-behave-nat-udp-02.txt). They are > both something that is created dynamically at the NAT in > response to the first outbound packet from a particular > internal address and port. "Mapping" (as per draft- > ford-behave-gen-01.txt) is a static administrator-configured > entry, usually from a port-forwarding or internal-service > screen in many NAT interfaces. > draft-ietf-behave-nat-udp-02.txt does not mention anything > about these static entries. > > On Fri, 2005-07-08 at 07:02 -0700, Pyda Srisuresh wrote: > > 3. Lastly, the document is missing a key requirement on Bindings. A > > dynamically created Binding (Address and/or Port Binding) MUST be > > refreshed, when there is is at least one live NAT Session using the > > Binding. > > I believe this is what REQ-5 addresses (but uses the term > "mapping" as defined earlier instead of "binding" ... but has > the same meaning). > > > > Alternately, once a Binding > > is created in relation to an endpoint and a NAT Session, subsequent > > NAT Sessions associated with the endpoint MUST reuse the > same Binding. > > I believe this is what REQ-1 addresses. It says that the > dynamically created mapping/binding/whatever must be reused > for new sessions originating from the same internal endpoint. > > -- > Saikat > From sg266@cornell.edu Wed, 13 Jul 2005 15:23:10 -0700 (PDT) From: Saikat Guha Date: Wed, 13 Jul 2005 15:23:10 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050708140235.41800.qmail@web40423.mail.yahoo.com> Message-ID: <1121293363.8532.8.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks to suresh's pointer on the definitions, I think I understand "bindings" now. Correct me if I am wrong; I believe "Bindings" (draft- ford-behave-gen-01.txt) mean more or less the same as "Mapping" (per draft-ietf-behave-nat-udp-02.txt). They are both something that is created dynamically at the NAT in response to the first outbound packet from a particular internal address and port. "Mapping" (as per draft- ford-behave-gen-01.txt) is a static administrator-configured entry, usually from a port-forwarding or internal-service screen in many NAT interfaces. draft-ietf-behave-nat-udp-02.txt does not mention anything about these static entries. On Fri, 2005-07-08 at 07:02 -0700, Pyda Srisuresh wrote: > 3. Lastly, the document is missing a key requirement on Bindings. A > dynamically > created Binding (Address and/or Port Binding) MUST be refreshed, when there is > is at least one live NAT Session using the Binding. I believe this is what REQ-5 addresses (but uses the term "mapping" as defined earlier instead of "binding" ... but has the same meaning). > Alternately, once a Binding > is created in relation to an endpoint and a NAT Session, subsequent NAT > Sessions associated with the endpoint MUST reuse the same Binding. I believe this is what REQ-1 addresses. It says that the dynamically created mapping/binding/whatever must be reused for new sessions originating from the same internal endpoint. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00067.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00067.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzFaUXluRmx0cWk2OTEvb1JBbFVuQUo5TmZ0SW9RY1EyTFEyeEJzaHNB S3VQemRabmFBQ2ZkN1lQCjN4ZENHcUZxYjhFb21kNzFzWFJWRmlRPQo9V0s0RgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Wed, 13 Jul 2005 15:30:32 -0700 (PDT) From: Saikat Guha Date: Wed, 13 Jul 2005 15:30:32 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1ECE0EB50388174790F9694F77522CCF033CE0DD@zrc2hxm0.corp.nortel.com> Message-ID: <1121293803.8532.16.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-07-13 at 17:20 -0500, Francois Audet wrote: > It was decided a while ago to use the term mapping because it > applies to both "symmetric" and "cone" NATs, which is not > the case for binding. True enough ... in that the term "mapping" has a defined value (I=independent,A=address,P=port,ADP=address and port) for any kind of NAT while "implements binding" is equivalent to NB=I only and all of the rest NB=A,NB=P,NB=ADP fall under "inconsistent binding" or "does not implement binding" etc. So yes, the two are not interchangable without loss in fidelity ... but they both refer to the dynamic behavior of NATs in allocating an external endpoint to an internal endpoint. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00068.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00068.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzFaWHFuRmx0cWk2OTEvb1JBbWhDQUo0a2xYUXoxTGp5SHRJQ3JYcW1Q eU5LcXBQN1JBQ2RIcWtPCjlDSElGSzhDZ2NpT2pCdm5mdm5iWDF3PQo9dHpwUQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From fluffy@cisco.com Wed, 13 Jul 2005 20:02:57 -0700 (PDT) From: Cullen Jennings Date: Wed, 13 Jul 2005 20:02:57 -0700 (PDT) Subject: Re: [Ietf-behave] Standard Disclosure In-Reply-To: <42D4669D.5030502@quinthar.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Just as a reality check, the documentation that came with some of the NATs I purchased consisted of a single large sheet of paper folded up, with some pictures that indicated how to plug wires into. It was clearly written in some language other than English then translated to English by someone who, by the looks of it, did not speak English or the original language it was written in. The screen dumps on the paper were clearly from a different version than the software on the device. Not to mention the documentation was inside the box and I had to buy the box to get the documentation. I don't really care about the documentation much because I don't think it is the most effective way to apply economic pressure on the NAT vendors. But let me describe something I do feel strongly about ... This is having things the document says you have to do that are clearly OK not to do. Once we have done that we are down the slippery slope of people thinking it is ok for them to do 80% of the recommendations. Let's specify what we really need, not a bunch of stuff that we don't need. Cullen On 7/12/05 8:55 PM, "David Barrett" wrote: > Francois Audet wrote: >> Hi David, >> >> How about something right into the first paragraphs of section 12 (just >> before >> the actual requirements), that says: >> >> It is RECOMMENDED that the product literature and documentation >> for a >> NAT include a standard description of its behavior in the form >> detailed >> by this document. Specifically, it SHOULD detail its support for >> the >> individual requirements defined in this section. >> [ individual reqs follow ] > > This sounds like a good idea to me. We could then put the BNF-like > disclosure grammar into a following section, a supporting document*, or > skip it altogether. > > * I wouldn't recommend putting it into a supporting document, as that > introduces maintenance dependencies. > > It all depends on whether or not we compel or even recommend to NAT > vendors that they disclose their behavior in a standardized way. Per > Cullen's question of whether other RFCs have done anything like this, > the only "prior art" I can find is RFC 1979 requesting acknowledgement > of its use (but doesn't require it) in the product documentation. > > However, whether or not it's common practice, I still think it's a good > idea, and I see no prohibition against it. As I believe Francois said > earlier "NAT vendors want to do the right thing". We have a unique > opportunity to enable them to do so. There is simply no other > organization or entity that has the same opportunity as we do now. No > one will begrudge us for passing up the chance to create a standardized > disclosure format; nobody asked us to do it in the first place. But I > find it very unlikely that anybody would complain if we tried, and some > might even thank us. > > -david > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dbarrett@quinthar.com Wed, 13 Jul 2005 20:23:14 -0700 (PDT) From: David Barrett Date: Wed, 13 Jul 2005 20:23:14 -0700 (PDT) Subject: Re: [Ietf-behave] Standard Disclosure In-Reply-To: Message-ID: <42D5DA9F.7080803@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Heh, excellent reality check. I totally agree we don't want to pollute the requirements with things that aren't truly required. And if it's the strength of the statement that worries you, I think it'd be just fine to leave it as "vendors MAY report their NAT's behavior in this format" -- if they don't want to, they won't be compelled to, but if they *do* want to we can help them with the "best practice" on how to do it. Given the poor grasp of English in your documentation, this might be even more useful than I had suspected. But I do want to push back on the perceived (low) value of this. My concern is that even if every NAT in the world is suddenly BEHAVE compliant, there is still such a diversity of options that as an application developer, it's still quite difficult to support them all. What I would like to do is put in my product literature "Product X recommends NATs that have 'endpoint independent filtering'." This allows me to ask my customer to place economic pressure on NAT vendors who create address-restricted filtering NATs. However, your experience with NAT documentation is clear evidence that you -- as one of the world's foremost NAT experts -- have absolutely no clue what you are buying. And if you don't know, how can Joe Consumer stand a chance? And if Joe Consumer can't know what he's buying, how is he expect to exert economic pressure on NAT vendors? So to repeat, I'm not asking we demand that NAT vendors put a special label on their boxes. Rather, I'm asking we recommend that NAT vendors indicate precisely how their products behave, and inform the consumer -- via their website, product documentation, box, or whatever. And for their convenience, we've supplied a handy table that they can fill out that ensures they don't leave anything out, and that they report in a consistent fashion. Originally I used 'SHOULD' as the strength, and perhaps that's too strong. At this point, I think 'RECOMMEND' would be the right level, as that's in fact what we do -- we recommend it. However, even 'MAY' or no strength at all is preferable to nothing. -david Cullen Jennings wrote: Just as a reality check, the documentation that came with some of the NATs I purchased consisted of a single large sheet of paper folded up, with some pictures that indicated how to plug wires into. It was clearly written in some language other than English then translated to English by someone who, by the looks of it, did not speak English or the original language it was written in. The screen dumps on the paper were clearly from a different version than the software on the device. Not to mention the documentation was inside the box and I had to buy the box to get the documentation. I don't really care about the documentation much because I don't think it is the most effective way to apply economic pressure on the NAT vendors. But let me describe something I do feel strongly about ... This is having things the document says you have to do that are clearly OK not to do. Once we have done that we are down the slippery slope of people thinking it is ok for them to do 80% of the recommendations. Let's specify what we really need, not a bunch of stuff that we don't need. Cullen On 7/12/05 8:55 PM, "David Barrett" wrote: Francois Audet wrote: Hi David, How about something right into the first paragraphs of section 12 (just before the actual requirements), that says: It is RECOMMENDED that the product literature and documentation for a NAT include a standard description of its behavior in the form detailed by this document. Specifically, it SHOULD detail its support for the individual requirements defined in this section. [ individual reqs follow ] This sounds like a good idea to me. We could then put the BNF-like disclosure grammar into a following section, a supporting document*, or skip it altogether. * I wouldn't recommend putting it into a supporting document, as that introduces maintenance dependencies. It all depends on whether or not we compel or even recommend to NAT vendors that they disclose their behavior in a standardized way. Per Cullen's question of whether other RFCs have done anything like this, the only "prior art" I can find is RFC 1979 requesting acknowledgement of its use (but doesn't require it) in the product documentation. However, whether or not it's common practice, I still think it's a good idea, and I see no prohibition against it. As I believe Francois said earlier "NAT vendors want to do the right thing". We have a unique opportunity to enable them to do so. There is simply no other organization or entity that has the same opportunity as we do now. No one will begrudge us for passing up the chance to create a standardized disclosure format; nobody asked us to do it in the first place. But I find it very unlikely that anybody would complain if we tried, and some might even thank us. -david _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Wed, 13 Jul 2005 22:10:59 -0700 (PDT) From: "Francois Audet" Date: Wed, 13 Jul 2005 22:10:59 -0700 (PDT) Subject: RE: [Ietf-behave] Standard Disclosure Message-ID: <1ECE0EB50388174790F9694F77522CCF011CD6EE@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Standard Disclosure I agree 100%. We need to stop trying to put philosophical models of the Grand Unified Model of NATs in the document. As it stands today, it is useful for NAT vendors because it describe simple things that can be done. If it gets complex, it will be ignored like many other RFCs. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx on behalf of Cullen Jennings Sent: Wed 7/13/2005 8:02 PM To: David Barrett; Behave Subject: Re: [Ietf-behave] Standard Disclosure Just as a reality check, the documentation that came with some of the NATs I purchased consisted of a single large sheet of paper folded up, with some pictures that indicated how to plug wires into. It was clearly written in some language other than English then translated to English by someone who, by the looks of it, did not speak English or the original language it was written in. The screen dumps on the paper were clearly from a different version than the software on the device. Not to mention the documentation was inside the box and I had to buy the box to get the documentation. I don't really care about the documentation much because I don't think it is the most effective way to apply economic pressure on the NAT vendors. But let me describe something I do feel strongly about ... This is having things the document says you have to do that are clearly OK not to do. Once we have done that we are down the slippery slope of people thinking it is ok for them to do 80% of the recommendations. Let's specify what we really need, not a bunch of stuff that we don't need. Cullen On 7/12/05 8:55 PM, "David Barrett" wrote: > Francois Audet wrote: >> Hi David, >> >> How about something right into the first paragraphs of section 12 (just >> before >> the actual requirements), that says: >> >> It is RECOMMENDED that the product literature and documentation >> for a >> NAT include a standard description of its behavior in the form >> detailed >> by this document. Specifically, it SHOULD detail its support for >> the >> individual requirements defined in this section. >> [ individual reqs follow ] > > This sounds like a good idea to me. We could then put the BNF-like > disclosure grammar into a following section, a supporting document*, or > skip it altogether. > > * I wouldn't recommend putting it into a supporting document, as that > introduces maintenance dependencies. > > It all depends on whether or not we compel or even recommend to NAT > vendors that they disclose their behavior in a standardized way. Per > Cullen's question of whether other RFCs have done anything like this, > the only "prior art" I can find is RFC 1979 requesting acknowledgement > of its use (but doesn't require it) in the product documentation. > > However, whether or not it's common practice, I still think it's a good > idea, and I see no prohibition against it. As I believe Francois said > earlier "NAT vendors want to do the right thing". We have a unique > opportunity to enable them to do so. There is simply no other > organization or entity that has the same opportunity as we do now. No > one will begrudge us for passing up the chance to create a standardized > disclosure format; nobody asked us to do it in the first place. But I > find it very unlikely that anybody would complain if we tried, and some > might even thank us. > > -david > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Thu, 14 Jul 2005 10:02:15 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 14 Jul 2005 10:02:15 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1121202608.6513.121.camel@localhost.localdomain> Message-ID: <20050714170214.73150.qmail@web33304.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Tue, 2005-07-12 at 06:43 -0700, Pyda Srisuresh wrote: > > [suresh] Saikat - What makes you think that "idle timeout" is not used for > ICMP > > requests. If a response is not received within the idle timeout, the NAT > > Session associated with ICMP request will be dropped. NAT devices do not do > > latency measurements for ICMP, AFAIK. Are you aware of NAT devices that do > this > > differently using latencies for ICMP requests? > > I may have caused some confusion. I meant that for an ICMP request > response pair (like ping), the "idle timer" is used to overcome the > latency. I do not know whether or not NATs refresh this "idle timer" > when the ping response comes back -- say you were to modify the host > being pinged to generate multiple ping responses (spread over a couple > of seconds) to a single ping request, would that NAT refresh the timer > each time a ping response came in or would it just expire the mapping > after a fixed duration from sending the request. Just wondering ... not > that this affects the UDP draft. > [suresh] The idle timer is dealt with the same way for all NAT Sessions (TCP/UDP/ICMP-pings), AFAIk. So, NAT devices that refresh a NAT Session for both inbound and outbound packets (belonging to that NAT Session) will do the same for TCP NAT Sessions, UDP NAT Sessions and ICMP NAT Sessions. If a NAT device chooses to refresh a NAT Session only for outbound packets (belonging to that NAT Session), it will follow the same approach for TCP NAT Sessions, UDP NAT Sessions and ICMP NAT Sessions. There is just not enough justification to do differently for UDP vs. TCP vs. ICMP NAT Session. cheers, suresh > > if you have alternate suggestions, that can go as > > hints to implementors. > > Fair enough. > > > cheers, > -- > Saikat > From srisuresh@yahoo.com Fri, 15 Jul 2005 06:56:48 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 15 Jul 2005 06:56:48 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1121292933.8532.6.camel@localhost.localdomain> Message-ID: <20050715135647.55105.qmail@web33307.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > Thanks to suresh's pointer on the definitions, I think I understand > "bindings" now. Correct me if I am wrong; I believe "Bindings" (draft- > ford-behave-gen-01.txt) mean more or less the same as "Mapping" (per > draft-ietf-behave-nat-udp-02.txt). They are both something that is > created dynamically at the NAT in response to the first outbound packet > from a particular internal address and port. [suresh] Saikat - I had ascribed the term "mapping" in the draft to mean "NAT Session" based on its usage in REQ-5 & REQ-1, as follows. Howevver, I do agree, the term was not used consistently to mean the same throughout. Say, a private host with a tuple of X:x (assume UDP port x) initiates 3 outgoing UDP Sessions with 3 external tuples Y1:y1, Y2:y2 and Y3:y3. Say, the NAPT device enroute asigned a Port Binding of N:Nx for X:x. In this scenario, the NAPT will have created 4 resources as follows: a) Port Binding-1:: (X:x, N:Nx) b) NAT Session-1 :: ((X:x->Y1:y1) Xlates to (N:Nx->Y1:y1) using Port Binding-1) c) NAT Session-2 :: ((X:x->Y2:y2) Xlates to (N:Nx->Y2:y2) using Port Binding-1) d) NAT Session-3 :: ((X:x->Y3:y3) Xlates to (N:Nx->Y3:y3) using Port Binding-1) In the above scenario, it is possible for NAT Session-1, which uses Port Binding-1 to expire after the 2-minute idle timeout. But NAT Session-2 and NAT Session-3, both of which also use the same Port Binding-1 may remain active. So, the Port Binding-1 itself will be alive. When X:x initiates yet another outgoign session to Y4:y4, the NAT would reuse port Binding to crate a new NAT Session. Section 4.3, REQ-5 reads as follows. REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 minutes. If you take the above example and refer REQ-5, you will note that the term "mapping" in REQ-5 refers to timing inidividual "NAT Sessions". The REQ says, a mapping (i.e.,a specific NAT Session) may be expired after 2 mins. But, that does not mean that the associated Binding has expired. Now, let us take Section 4.1. Please refer the following text in the section. Let's assume that the internal IP address and port X:x is mapped to X1':x1' for this first session. The endpoint then sends from X:x to an external address Y2:y2 and gets a mapping of X2':x2' on the NAT. The above text refers to maping on a per-session basis. Session 1 using a maping of X:x to X1:x1' and Session 2 using a maping of X;x to X2':X2. Once again, the term "mapping" is used in a per session context, just as is the case with "NAT Session". The draft goes on define "Endpoint Independent Mapping" as follows. Endpoint Independent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to any external IP address and port. Specifically, X1':x1' equals X2':x2' for all values of Y2:y2. When multiple NAT Sessions emanating from the same private host tuple, use the same private host tuple transalation, that is when that NAT is said to be using "Port Binding" for the private host tuple. So, I believe, the term "Endpoint Independent Mapping" is the closest equivalent of "Port Binding" in this draft. > "Mapping" (as per draft- > ford-behave-gen-01.txt) is a static administrator-configured entry, > usually from a port-forwarding or internal-service screen in many NAT > interfaces. draft-ietf-behave-nat-udp-02.txt does not mention anything > about these static entries. > [suresh] Right. > On Fri, 2005-07-08 at 07:02 -0700, Pyda Srisuresh wrote: > > 3. Lastly, the document is missing a key requirement on Bindings. A > dynamically > > created Binding (Address and/or Port Binding) MUST be refreshed, when there > is > > is at least one live NAT Session using the Binding. > > I believe this is what REQ-5 addresses (but uses the term "mapping" as > defined earlier instead of "binding" ... but has the same meaning). > [suresh] Please refer my text above. I believe, REQ-5 refers to "NAT Session". No matter, the bottom line is that a behave-compliant NAT device MUST have two types of NAT resources - a) Bindings and b) NAT Sessions. Both resources are created dynamically (Well, not exactly. Static 1-to-1 address maps would result in static Bindings). So, both resources ought to be refreshed for their liveness. SO, I think, you will agree, there ought to be two requirements, one addressing the refresh of "NAT Session" and another addressing the refresh of "Bindings". That was the gist of my comment on 07/08. > > > Alternately, once a Binding > > is created in relation to an endpoint and a NAT Session, subsequent NAT > > Sessions associated with the endpoint MUST reuse the same Binding. > > I believe this is what REQ-1 addresses. It says that the dynamically > created mapping/binding/whatever must be reused for new sessions > originating from the same internal endpoint. > [suresh] As I said earlier, "Endpoint Independent Mapping" is the closest equivalent of "Port Binding" in this draft. So, I read REQ-1 to mean that NATs must support Port Bindings. But, the draft makes no mention of the refresh charcateristics of the Bindings. "Binding" and "NAT Session" are two basic NAT resources. By using these standard terms to characterize NAT behvaioral requirements, you are able to a) avoid the use of Cone/Symmteric NAT terminology, b) qualitatively address the exppected behavioral requirements in terms of NAT resources, and c) avoid using conflicting terms with existing RFCs. cheers, suresh > -- > Saikat > From srisuresh@yahoo.com Fri, 15 Jul 2005 07:26:49 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 15 Jul 2005 07:26:49 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1121293731.8532.14.camel@localhost.localdomain> Message-ID: <20050715142647.83822.qmail@web33311.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Wed, 2005-07-13 at 17:20 -0500, Francois Audet wrote: > > It was decided a while ago to use the term mapping because it > > applies to both "symmetric" and "cone" NATs, which is not > > the case for binding. [suresh] I will ignore the rant about "it was decided a while ago", because there was no such decision on the list. As for the comment about "mapping" applying to both "symmteric" and "Cone" NATs and "Binding" not, it makes no sense to me. Behave-gen draft does exactly that - explain the nuances across "Cone" and "Symmetric" NATS in terms of Bindings and NAT Sessions. > > True enough ... in that the term "mapping" has a defined value > (I=independent,A=address,P=port,ADP=address and port) for any kind of > NAT while the "implements binding" is equivalent to NB=I and all of > NB=A,NB=P,NB=ADP fall under "inconsistent binding" or "does not > implement binding" etc. So yes, the two are not interchangable without > loss in fidelity ... but they both refer to the dynamic behavior of NATs > in allocating an external endpoint to an internal endpoint. > [suresh] Saikat - Section 2.4 of the Behave-gen draft explains "Cone" vs Symmetric" NAT behaviors in terms of "Bindings" and "NAT Sessions". Here is a brief. a. Symmteric NAT - Doesnt support Bindings, only NAT Sessions. b. All types of Cone NATs - Support Bindings and NAT Sessions. b.1. Port Restricted Cone NAT - No wild card matches in NAT Sessions. b.2. Address restricted Cone NAT - Applicable only to UDP sessions. Wild-card match on UDP port for external host in NAT Sessions. b.3. Full Cone NAT - Applicable only to UDP sessions. Wild-card match on external host IP address and UDP port in NAT Sessions. cheers, suresh > -- > Saikat > From srisuresh@yahoo.com Fri, 15 Jul 2005 08:02:11 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 15 Jul 2005 08:02:11 -0700 (PDT) Subject: Use of standard terminology (WAS:: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh) In-Reply-To: <20050715135647.55105.qmail@web33307.mail.mud.yahoo.com> Message-ID: <20050715150209.79792.qmail@web33306.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain <... stuff deleted> > > > Alternately, once a Binding > > > is created in relation to an endpoint and a NAT Session, subsequent NAT > > > Sessions associated with the endpoint MUST reuse the same Binding. > > > > I believe this is what REQ-1 addresses. It says that the dynamically > > created mapping/binding/whatever must be reused for new sessions > > originating from the same internal endpoint. > > > [suresh] As I said earlier, "Endpoint Independent Mapping" is the closest > equivalent of "Port Binding" in this draft. So, I read REQ-1 to mean that > NATs > must support Port Bindings. But, the draft makes no mention of the refresh > charcateristics of the Bindings. > > "Binding" and "NAT Session" are two basic NAT resources. By using these > standard terms to characterize NAT behvaioral requirements, you are able to > a) > avoid the use of Cone/Symmteric NAT terminology, b) qualitatively address the > exppected behavioral requirements in terms of NAT resources, and c) avoid > using > conflicting terms with existing RFCs. > [suresh] I wanted to point out additional benefit to using standard terinology. Standard terms are used to distinguish between various NAT types. As such, use of standard terms in the behave drafts makes the recommendations applicable to all NAT types, including Traditional NATs, Bi-directional NATs, twice NATs, and the newly coined HairPin NATs. Ford-behave-gen and sivakumar-behave-nat-tcp drafts have the requirements written using Bindings and NAT Sessions. As such, the requirements in these drafts are not restricted to Traditional NATs, except as noted. cheers, suresh > cheers, > suresh > > -- > > Saikat > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From sg266@cornell.edu Fri, 15 Jul 2005 15:57:51 -0700 (PDT) From: Saikat Guha Date: Fri, 15 Jul 2005 15:57:51 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050715135647.55105.qmail@web33307.mail.mud.yahoo.com> Message-ID: <1121468241.5803.64.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-07-15 at 06:56 -0700, Pyda Srisuresh wrote: > In this scenario, > the NAPT will have created 4 resources as follows: > > a) Port Binding-1:: (X:x, N:Nx) > b) NAT Session-1 :: ((X:x->Y1:y1) Xlates to (N:Nx->Y1:y1) using Port > Binding-1) > c) NAT Session-2 :: ((X:x->Y2:y2) Xlates to (N:Nx->Y2:y2) using Port > Binding-1) > d) NAT Session-3 :: ((X:x->Y3:y3) Xlates to (N:Nx->Y3:y3) using Port > Binding-1) This is implementation dependent. I can think of an implementation where a) is not created as a separate object but rather inferred from b-d. Note that each of b-d have the full information given by a). What data structures/organization a NAT uses is, no doubt, up to the vendor. > SO, I think, you will agree, there ought to be two requirements, one > addressing > the refresh of "NAT Session" and another addressing the refresh of > "Bindings". Yes. That has always been the case. The "Bindings (behave-gen)" addresses the same issue as "Mappings (behave-udp)". "NAT Session (behave-gen)" addresses the same issues as "NAT Filter Refresh". Your requirement that "Bindings" be refreshed is exactly what REQ-1 and REQ-5 say. In particular, REQ-1 says "Bindings must be implemented" and REQ-5 says "bindings must be refreshed". > [suresh] Please refer my text above. I believe, REQ-5 refers to "NAT Session". I do not believe so. REQ-5 still talks about "mappings (behave-udp)" which is similar to "bindings (behave-gen)". "NAT sessions (behave-gen)" are introduced in Section 5 (not related between REQ-5 by the way). Your requirement that "NAT Sessions" be refreshed used to be in Section 5.2 "NAT Filter Refresh (behave-udp)". I think 5.2 has since been removed as per your request (July 8 mail). If you feel that the July 8 mail was due to a misunderstanding of terminology, I am sure Franois can resurrect the section. As for which terminology to use, I strongly prefer the behave-udp terminology since it can actually differentiate between the types of NATs I actually see in the wild. The behave-gen terminology shoehorns many of them into "symmetric" ... and not all "symmetric" NATs are behave the same way. Indeed I find that NB=A NATs have a 100% traversal success rate when paired up with NB=I NATs, but NB=ADP NATs don't. Both NB=A and NB=ADP are "symmetric" and hence it is not possible to make the observation above if the old terminology is used. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00069.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00069.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzJEOVJuRmx0cWk2OTEvb1JBZ0ZmQUo0bE5PRk9iNUJZNmFtTmdoZ2hs dFV5TG8ramp3Q2NEL2daClEzbFo4WjJZZ21RYXVJekNBaFBtcndNPQo9NENiMAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From srisuresh@yahoo.com Sun, 17 Jul 2005 15:05:15 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 17 Jul 2005 15:05:15 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1121468194.5803.62.camel@localhost.localdomain> Message-ID: <20050717220514.53272.qmail@web33303.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Fri, 2005-07-15 at 06:56 -0700, Pyda Srisuresh wrote: > > In this scenario, > > the NAPT will have created 4 resources as follows: > > > > a) Port Binding-1:: (X:x, N:Nx) > > b) NAT Session-1 :: ((X:x->Y1:y1) Xlates to (N:Nx->Y1:y1) using Port > Binding-1) > > c) NAT Session-2 :: ((X:x->Y2:y2) Xlates to (N:Nx->Y2:y2) using Port > Binding-1) > > d) NAT Session-3 :: ((X:x->Y3:y3) Xlates to (N:Nx->Y3:y3) using Port > Binding-1) > > This is implementation dependent. I can think of an implementation where > a) is not created as a separate object but rather inferred from b-d. > Note that each of b-d have the full information given by a). What data > structures/organization a NAT uses is, no doubt, up to the vendor. > [suresh] The above illustrates the relationship between Binding and the associated NAT Sessions, not implementation. The relationship holds true, no matter what the implementation is. If you can think of implemenations that would not create a) as seperate object, but infer that from b) through d) - That is fine. I would be curious to know how you would do this. Do feel free to send this to me on a private e-mail. Specific implementation ideas may not be of interest to the list. > > > SO, I think, you will agree, there ought to be two requirements, one > addressing > > the refresh of "NAT Session" and another addressing the refresh of > "Bindings". > > Yes. That has always been the case. [suresh] Sounds like we have an agreement here. That is a start. > The "Bindings (behave-gen)" > addresses the same issue as "Mappings (behave-udp)". "NAT Session > (behave-gen)" addresses the same issues as "NAT Filter Refresh". > [suresh] This seems to be where the disconnect is. Let me for a moment go with your above assertion. a) If "NAT Session", is same is NAT filter, why is there not an idle timeout not specificed for NAT filter refresh in section 5.2? The reality is that the filtering characteristic of a NAT device is to simply permit packets belonging to only the NAT Sessions it supports in either direction. The filtering behavior is the same for TCP or UDP and is an inherent characteristic of a NAT Session, but not the only characteristic. Address/Port translation is another key charactristic of a NAT Session. The filtering behaviors specified in section 5.1 are specific only to UDP and not aplicable to TCP. This is because what is different with UDP sessions is that a NAT UDP Session may have wild-card match for external hosts - say (X:x->Y2:*) for an Address retricted Cone NAT or (X:x-. *:*) for a full Cone NAt in item c) above. Whereas, TCP is inherently point-to-point and exhibits just the Address and Port Dependent filtering. Bootom line, refresh timing is not restricted to just the filtering behavior. The refresh timing is applicable to the whole NAT Session. The filtering behavior is evident so long as a NAT Session is alive. This was why, we recently agreed to remove section 5.2 from the draft. b. If Binding is same as Mapping (in behave-udp), the mapping refresh timer specified in REQ-5 doesnt make sense. In the above example, say there was no traffic from X:x to Y2:y2 for 10 mins, but there is continuous ongoing traffic from X:x to Y1:y1 and X:x to Y3:y3. According to your interpretation, the Binding (i.e., item a) ) should be alive. And, The Req-5 says nothing about retiring the NAT Session in item c) after 2 mins. In reality, the above is not true. Here is why. Most NAT devices use a Binding refresh timeout of 0 secs for all kinds of Bindings, including TCP Port Binding, UDP Port Binding and Address Binding. I.e., as soon as the last NAT Session using the Binding is freed, the associated Binding is also freed. Very few NAT devices keep the Binding active longer then 0 secs. Some ALGs (ex: DNS ALG and some P2P ALGs) may keep specific Bindings alive without a NAT Session for longer than 0 secs. Most people on the list, I believe, understood the refresh timeout of 2 mins in REq-5 to be the idle timeout for a UDP NAT Session, not the Binding. I.e., Folks expect the NAT Session in item c) to be freed at the end of no activity for 2 mins. But, the Binding remains alive, so do the remaining two NAT Session in items b) and d). I believe, you are mistaken in your above interpretation. > Your requirement that "Bindings" be refreshed is exactly what > REQ-1 and REQ-5 say. In particular, REQ-1 says "Bindings must be > implemented" and REQ-5 says "bindings must be refreshed". > [suresh] That would be true, if your interpretaion were to match what the draft reads or what the authors intended. But, I dont believe so. In fact, section 3 of the UDP draft states the following explicitly. This document uses the term "address and port mapping" as the translation between an external address and port and an internal address and port. Note that this is not the same as an "address binding" as defined in RFC 2663. I am willing to go with your interpreation somewhat relunctantly for REQ-1. But, the interpretation is just not true for REQ-5. By "Mapping refresh", the UDP authors are in fact refering to "NAT Session refresh". This is the sort of inconsitensy in the draft that worries me. And, there is no coverage of Binding refresh anywhere in the document, not even in the section on filter refresh (Section 5.2). > > [suresh] Please refer my text above. I believe, REQ-5 refers to "NAT > Session". > > I do not believe so. REQ-5 still talks about "mappings (behave-udp)" which is > similar to > "bindings (behave-gen)". > > "NAT sessions (behave-gen)" are introduced in Section 5 (not related > between REQ-5 by the way). Your requirement that "NAT Sessions" be > refreshed used to be in Section 5.2 "NAT Filter Refresh (behave-udp)". I > think 5.2 has since been removed as per your request (July 8 mail). If > you feel that the July 8 mail was due to a misunderstanding of > terminology, I am sure Franois can resurrect the section. > [suresh] Saikat - Please see my response above. Unfortunately, your interpretation is far from true. As for removing section 5.2, we did agree on this because, filtering is not an independent resource that a NAT device has. You can only refresh a resource a NAT device has, not a characteristic. The filtering behavior explained in section 5.1 refers only to the filtering characteristic, but not a NAT Session resource. The real problem, I believe, is the inconsistent use of the "mapping" term in the UDP draft. That may be why the draft does not have refresh timeouts for Binding and NAT Session covered as two independet requirements. > > As for which terminology to use, I strongly prefer the behave-udp > terminology since it can actually differentiate between the types of > NATs I actually see in the wild. [suresh] I strongly recommend otherwise. See my notes above on the inconsistency in your interpretation. > The behave-gen terminology shoehorns > many of them into "symmetric" ... and not all "symmetric" NATs are > behave the same way. [suresh] May be so. I havent reviewed your results yet. More importantly, the Behave-gen terminology is intended to simply identify what is a Behave compliant NAt device and what is not. When a NAT device does not support Bindings, it is simply not Behave compliant. What does it matter, how badly it does not support Bindings. When a NAT device doesnt support hairpin NAT function, it is simply nat Behave compliant. What does it matter, ho wbadly a NAt device does not support hair-pinning. Determining the finer gradation of how badly a NAT device is behave un-compliant is not the goal of this WG charter. > Indeed I find that NB=A NATs have a 100% traversal > success rate when paired up with NB=I NATs, but NB=ADP NATs don't. Both > NB=A and NB=ADP are "symmetric" and hence it is not possible to make the > observation above if the old terminology is used. > [suresh] I havet reviewed your STUNT results yet. I will respond when I do in a different thread. Like I said earlier, it is not the charter of this WG to generate terminology so as to analyze the various gradations of un-compliant NAT devices. The objective is simply be one of of determining whether a NAT device is Behave compliant or not using consistent terms. cheers, suresh > > > -- > Saikat > From sg266@cornell.edu Sun, 17 Jul 2005 19:16:37 -0700 (PDT) From: Saikat Guha Date: Sun, 17 Jul 2005 19:16:37 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050717220514.53272.qmail@web33303.mail.mud.yahoo.com> Message-ID: <1121652965.5864.76.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-07-17 at 15:05 -0700, Pyda Srisuresh wrote: > a) If "NAT Session", is same is NAT filter, why is there not an idle timeout > not specificed for NAT filter refresh in section 5.2? Because, two timers are functionally redundant; a single timer is equivalent. Assume there were two timers, consider the following three cases. Scenario: A ----- N ----- internet ----- B N is NAT. *** Using behave-gen terminology *** Case 1) Binding Timer (BT) < Session Timer (ST) - Doesn't make sense. Binding cannot expire before session that uses it. Case 2) Binding Timer (BT) = Session Timer (ST) = One Timer (OT) - A sends UDP packet to B. New binding created. New session created. - idle for OT seconds - Case 2.1) B sends packet to A. Packet dropped. No binding or session matched. Case 2.2) A sends packet to B. New binding created. New session created. New binding can be different from old binding. Case 3) Binding Timer (BT) > Session Timer (ST) - A sends UDP packet to B. New binding created. New session created. - idle for ST seconds - Case 3.1) B sends packet to A. No existing session. NAT can either drop the packet. Or perhaps, create a new session since binding matches. Case 3.2) A sends packet to B. Create new session. Same binding. The only difference in case 3 is that there is a possibility of ST expiring before BT in which case the session can be recreated. This is the same as setting OT = MAX(BT, ST). *** Done using behave-gen terminology *** Having one timer is sufficient. If NAT vendors happen to implement something where "binding (gen)" and "session (gen)" are different objects as you propose, the requirement translates to saying both should have a 5 minute timer that should be refreshed. > The filtering behaviors specified in section 5.1 are specific only to UDP and > not aplicable to TCP. Not true. Please refer to http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf Section 4.2 > b. If Binding is same as Mapping (in behave-udp) They are not exactly the same; more or less same in the sense that "binding (gen)" is used to enforce "cone" behavior while "mapping (udp)" is used to enforce the same behavior. > the mapping refresh timer > specified in REQ-5 doesnt make sense. In the above example, say there was no > traffic from X:x to Y2:y2 for 10 mins, but there is continuous ongoing traffic > from X:x to Y1:y1 and X:x to Y3:y3. According to your interpretation, the > Binding (i.e., item a) ) should be alive. And, The Req-5 says nothing about > retiring the NAT Session in item c) after 2 mins. This was discussed earlier on the list (see Yutaka-san's mails on requirement 5.2). A per, the now-defunct, section 5.2 a "NAT Filter Scope" of "Per mapping" would describe the behavior you mentioned (where c) would not be reclaimed) and a "NAT Filter Scope" of "Per Session" would allow c) to be reclaimed. Both have their advantages and disadvantages -- the former allowing for a single packet to refresh all sessions and the latter behind more secure. For that reason, it was left for vendors to decide (Franois's June 9 mail). > In reality, the above is not true. Here is why. Most NAT devices use a Binding > refresh timeout of 0 secs for all kinds of Bindings, including TCP Port > Binding, UDP Port Binding and Address Binding. I.e., as soon as the last NAT > Session using the Binding is freed, the associated Binding is also freed. See my response to Case 3 above; setting the mapping timer value to as long as you propose a binding should be valid for is functionally equivalent. > Folks expect the NAT Session in item c) to be freed at the end of no activity > for 2 mins. But, the Binding remains alive, so do the remaining two NAT > Session > in items b) and d). Agreed -- except I don't think in terms of "binding" and "session". I believe c) should expire (in that packets from Y2:y2 may be dropped after 5 minutes of inactivity) while b) and d) remain alive. And in addition, I believe a new e) ((X:x->Y4:y4) Xlates to (N:Nx->Y4:y4) i.e. it uses N:Nx .... and that is *exactly* what the UDP draft says should happen now!! In particular: 1) the old requirement recommending "Per Mapping" filter refresh scope has been removed therefore allowing c) to expire if the vendor wants. 2) the 5-minute requirement prevent b) or d) from being reclaimed before they have been idle for 5 minutes. 3) the EF=I requirement says that a new session (e) should get the same mapping as b) or d) and should therefore use N:Nx. As I see it, both you and the draft are recommending the _exact_ same thing ... which is fantastic ... but just in different terms. > As for removing section 5.2, we did agree on this because, filtering is not an > independent resource that a NAT device has. For each filtering rule, the NAT needs to keep state. Here a filtering rule corresponds to the familiar 7-tuple (Protocol, internal address and port, mapped address and port, external address and port) ... which also goes by the name "NAT Session (gen)". What all amongst these 7-entries the NAT matches an incoming packet to depends on the EF type of the NAT. > > As for which terminology to use, I strongly prefer the behave-udp > > terminology since it can actually differentiate between the types of > > NATs I actually see in the wild. > > [suresh] I strongly recommend otherwise. See my notes above on the > inconsistency in your interpretation. The inadequacy of "Cone/Symmetric" in capturing current real-life behavior has nothing to do with the UDP draft. > When a NAT device does not support > Bindings, it is simply not Behave compliant. What does it matter, how badly it > does not support Bindings. Matters both for legacy NATs and for vendors that refuse to be compliant with behave. > Determining the finer gradation of > how badly a NAT device is behave un-compliant is not the goal of this WG > charter. The finer gradation is not for defining how a device is un-compliant. It just happens to reflect reality better, and as a side-effect ends up pinpointing the problem on an un-compliant NAT than just say "bad". -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00070.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00070.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzJ4RGxuRmx0cWk2OTEvb1JBbzdHQUo5MUxYeXlVaFUxUUZQSThhNlBF MnNaWW1ENWxBQ2VJVWdECjhJSmw3UTljanJqTHBsTkMxSTVaKzFBPQo9dStRdgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Sun, 17 Jul 2005 21:06:38 -0700 (PDT) From: Saikat Guha Date: Sun, 17 Jul 2005 21:06:38 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050717220514.53272.qmail@web33303.mail.mud.yahoo.com> Message-ID: <1121659566.9397.56.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-07-17 at 15:05 -0700, Pyda Srisuresh wrote: > Most NAT devices use a Binding > refresh timeout of 0 secs for all kinds of Bindings Can you point me to a study that shows that? What percentage of NATs use a binding timer of 0? What percentage use a larger value? In fact, can you even point me to something that shows that the NATs that you claim "use a Binding refresh timeout of 0 secs" _even use_ bindings and binding timers in the first place? Instead, let me point you to the Linux source that: 1. DOES NOT use bindings 2. DOES NOT use a binding timer 3. Is a NAT that is behave compliant 4. Would _appear_ to use bindings and a binding timeout of 0 but DOES NOT In the Linux implementation, there _is_ "mapping reuse (behave-udp)". For each "NAT session (behave-gen)" there is a mapping. That mapping is reused -- the reuse gives the _illusion_ of a "binding". That mapping has an associated timer (that would appear as "NAT Session timer (behave-gen)" in your test). That mapping is refreshed (when a packet is accepted on that mapping -- i.e. when the packet is not filtered). When a new connection arrives, existing mappings are checked and their mapped address and port values _reused_. When a mapping expires -- thats it, the mapping expires -- nothing else is touched or refreshed. No binding state is reaped. As long as there is even one live mapping when a new connection arrives from the same internal endpoint the values from that mapping are reused. When all the mappings are gone, a new mapping is created for the new connection and there is no reuse. This gives the _impression_ of having a "binding refresh timeout of 0" ... but in reality, there is NO binding timeout. I invite you to reconfirm this in the Linux 2.6.11 NAT code (annotated below). Not to be rude, but the fact remains that talking of a "binding timeout" as something that absolutely MUST exist in a NAT and MUST be standardized is absurd! A vendor's particular implementation may use "bindings" and "binding timeouts" to implement the requirements specified in behave-udp .... but claiming that "bindings" and "sessions" are the one true terminology that descries what NATs do is unjustified. ---- Linux implementation details / code walkthrough ---- When determining what NAT'ed IP and port to use for a new connection, Linux does the following: 1. Look through each existing session until it finds one where the internal src ip and port matches the new connection. 2. Use the NAT'ed ip and port of that connection. See: get_unique_tuple calls (ip_nat_core.c#L230) find_appropriate_src that iterates over (ip_nat_core.c#L146) existing connections (ip_nat.h#L61) and for each connection, calls same_src (ip_nat_core.c#L147) that checks protocol, internal IP and port for equality (ip_nat_core.c#L128). find_appropriate_src returns after the first match (ip_nat_core.c#L155). (add http://lxr.linux.no/source/net/ipv4/netfilter/ before the file#Lline links above to view online) There is *no table of "bindings"* that it checks. It only checks live "NAT sessions (behave-gen)". When a packet is sent or received: 1. The timer for that connection "NAT session (behave-gen)" is refreshed. (ip_conntrack_proto_udp.c#L73 for UDP, ip_conntrack_proto_tcp.c#L972 for TCP) The connection timer is the only one it ever touches. If there was a binding timer, then it would require at least two timers to be changed -- that is not the case. Further, when a connection expires: The death_by_timeout(ip_conntrack_core.c#L509) function is called that only deletes the timer associated with that "NAT session" (ip_conntrack_core.c#L267). It does NOT check whether other "NAT sessions (gen)" with the same "binding (gen)" are alive or not. It does not refresh or set some new "binding timeout". There is no binding timeout. -- Saikat (huff, pufff) Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00071.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00071.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzJ5cXVuRmx0cWk2OTEvb1JBdW5wQUo5ZC9tOG91ZWgreW5uZzYzWXFX czhQVlMrVk1BQ2VKRldiCnRaRkwvaUJKZHUrR3h3dGdFc0lOeGQ4PQo9Q2NzawotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Mon, 18 Jul 2005 03:52:13 -0700 (PDT) From: Saikat Guha Date: Mon, 18 Jul 2005 03:52:13 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050717220514.53272.qmail@web33303.mail.mud.yahoo.com> Message-ID: <1121683900.13049.18.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2005-07-17 at 21:06 -0700, Saikat Guha wrote: > Linux source that: > 1. DOES NOT use bindings > 2. DOES NOT use a binding timer > 3. Is a NAT that is behave compliant > 4. Would _appear_ to use bindings and a binding timeout of 0 but DOES > NOT As a footnote, I'd like to point out any requirement of a non-zero binding timeout cannot be met without ... well ... actually implementing a separate binding timer. Before you dismiss my argument saying that "bindings" and "binding timeouts" are an abstract concept and are implementation independent, consider that recommending any non-zero timeout would necessitate the implementation you have in mind -- thus making your recommendation very much implementation dependent. In addition, it would discount the Linux implementation, which I might add is a just fine and is used in Linksys NATs (29%). -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00072.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00072.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzI0bThuRmx0cWk2OTEvb1JBblBOQUo5UVF5eWNrejFQNDBwdkxhTkFV RjZoNW5HcG1nQ2VMd3FLCmoxdlNlOVJSUkZ3Wm5RQUQzTmsvZGQwPQo9RXRheQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From audet@nortel.com Mon, 18 Jul 2005 18:15:43 -0700 (PDT) From: "Francois Audet" Date: Mon, 18 Jul 2005 18:15:43 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <1ECE0EB50388174790F9694F77522CCF03552200@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Thank you Saikat, Your very detailed analysis confirms some of the empirical data that was observed by Cullen and I. It explains the reason for the neutral model (i.e., the NAT as seen from the outside) that we used in draft-ietf-behave-nat-udp. I am glad you managed to back it up with a concrete and verifiable example. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Sunday, July 17, 2005 21:06 > To: Behave > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > > On Sun, 2005-07-17 at 15:05 -0700, Pyda Srisuresh wrote: > > Most NAT devices use a Binding > > refresh timeout of 0 secs for all kinds of Bindings > > Can you point me to a study that shows that? What percentage > of NATs use a binding timer of 0? What percentage use a larger value? > > In fact, can you even point me to something that shows that > the NATs that you claim "use a Binding refresh timeout of 0 > secs" _even use_ bindings and binding timers in the first place? > > Instead, let me point you to the Linux source that: > 1. DOES NOT use bindings > 2. DOES NOT use a binding timer > 3. Is a NAT that is behave compliant > 4. Would _appear_ to use bindings and a binding timeout of 0 > but DOES NOT > > In the Linux implementation, there _is_ "mapping reuse > (behave-udp)". For each "NAT session (behave-gen)" there is a > mapping. That mapping is reused -- the reuse gives the > _illusion_ of a "binding". That mapping has an associated > timer (that would appear as "NAT Session timer (behave-gen)" > in your test). That mapping is refreshed (when a packet is > accepted on that mapping -- i.e. when the packet is not > filtered). When a new connection arrives, existing mappings > are checked and their mapped address and port values > _reused_. When a mapping expires -- thats it, the mapping > expires -- nothing else is touched or refreshed. No binding > state is reaped. As long as there is even one live mapping > when a new connection arrives from the same internal endpoint > the values from that mapping are reused. When all the > mappings are gone, a new mapping is created for the new > connection and there is no reuse. This gives the _impression_ > of having a "binding refresh timeout of 0" ... but in > reality, there is NO binding timeout. I invite you to > reconfirm this in the Linux 2.6.11 NAT code (annotated below). > > Not to be rude, but the fact remains that talking of a > "binding timeout" as something that absolutely MUST exist in > a NAT and MUST be standardized is absurd! A vendor's > particular implementation may use "bindings" and "binding > timeouts" to implement the requirements specified in > behave-udp .... but claiming that "bindings" and "sessions" > are the one true terminology that descries what NATs do is > unjustified. > > > ---- Linux implementation details / code walkthrough ---- > > When determining what NAT'ed IP and port to use for a new > connection, Linux does the following: > > 1. Look through each existing session until it finds one where > the internal src ip and port matches the new connection. > 2. Use the NAT'ed ip and port of that connection. > > See: > get_unique_tuple calls (ip_nat_core.c#L230) > find_appropriate_src that iterates over (ip_nat_core.c#L146) > existing connections (ip_nat.h#L61) and for each connection, > calls same_src (ip_nat_core.c#L147) that checks protocol, > internal IP and port for equality (ip_nat_core.c#L128). > find_appropriate_src returns after the first match > (ip_nat_core.c#L155). > > (add http://lxr.linux.no/source/net/ipv4/netfilter/ before > the file#Lline links above to view online) > > There is *no table of "bindings"* that it checks. It only > checks live "NAT sessions (behave-gen)". > > When a packet is sent or received: > 1. The timer for that connection "NAT session (behave-gen)" > is refreshed. (ip_conntrack_proto_udp.c#L73 for UDP, > ip_conntrack_proto_tcp.c#L972 for TCP) > > The connection timer is the only one it ever touches. If > there was a binding timer, then it would require at least two > timers to be changed > -- that is not the case. > > Further, when a connection expires: > The death_by_timeout(ip_conntrack_core.c#L509) function is > called that only deletes the timer associated with that "NAT > session" (ip_conntrack_core.c#L267). > > It does NOT check whether other "NAT sessions (gen)" with the > same "binding (gen)" are alive or not. It does not refresh or > set some new "binding timeout". There is no binding timeout. > > > -- > Saikat > (huff, pufff) > From srisuresh@yahoo.com Tue, 19 Jul 2005 07:13:39 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 19 Jul 2005 07:13:39 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1121652965.5864.76.camel@localhost.localdomain> Message-ID: <20050719141339.31171.qmail@web33310.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Sun, 2005-07-17 at 15:05 -0700, Pyda Srisuresh wrote: > > a) If "NAT Session", is same is NAT filter, why is there not an idle > timeout > > not specificed for NAT filter refresh in section 5.2? > > Because, two timers are functionally redundant; [suresh] Saikat - Idle timeout for a Binding and a NAT Session are two independent timeouts. There is no need to mix them up. It doesnt make sense to make a numerical comparison of the two timeouts either. Essentially, a Binding is alive so long as there is at least one NAT Session using that Binding. A Binding is idle (i.e., unused) when there isnt a NAT Session using the Binding. <... stuff deleted> > > The filtering behaviors specified in section 5.1 are specific only to UDP > and > > not aplicable to TCP. > > Not true. Please refer to > http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf Section 4.2 > [suresh] Saikat - Good work characterizing NATs. Had a chance to review section 4.2 of your paper. 9% of the devices tested apparatly fell under one of EF=A or EF=P in that they accept TCP connection if the external Address or Port alone match the original outgoign connection. For these accpeted connections, does A:P translate back to a:p, or, is it some other internal port tuple? Have you seen any scenario where a NAT device accepts inbound TCP connections, but does not fall under any of the 4 categories you identified (I, AP, A, P)? I suspect, there will be a few that fall under miscellaneous, wierd, unknown categories, if you widen your samples further. How consistent are the NAT devices in their EF=A or EF=P behavior? The EF=P behavior is wierd even for UDP and Cone NATs. The good news is they are less than 10%. Bottom line - There are buggy and bad implementations out there. When you caracterize large samples of implementations, you are bound to run into all kinds of wierd stuff. From a behave WG persepctive, either a NAT devices passes the muster or not. In what way a device fails to pass the muster is not relevant to the WG charter. > > > > b. If Binding is same as Mapping (in behave-udp) > > They are not exactly the same; more or less same in the sense that > "binding (gen)" is used to enforce "cone" behavior while "mapping (udp)" > is used to enforce the same behavior. > > > > the mapping refresh timer > > specified in REQ-5 doesnt make sense. In the above example, say there was > no > > traffic from X:x to Y2:y2 for 10 mins, but there is continuous ongoing > traffic > > from X:x to Y1:y1 and X:x to Y3:y3. According to your interpretation, the > > Binding (i.e., item a) ) should be alive. And, The Req-5 says nothing about > > retiring the NAT Session in item c) after 2 mins. > > > This was discussed earlier on the list (see Yutaka-san's mails on > requirement 5.2). A per, the now-defunct, section 5.2 a "NAT Filter > Scope" of "Per mapping" would describe the behavior you mentioned (where > c) would not be reclaimed) and a "NAT Filter Scope" of "Per Session" > would allow c) to be reclaimed. Both have their advantages and > disadvantages -- the former allowing for a single packet to refresh all > sessions and the latter behind more secure. For that reason, it was left > for vendors to decide (Franois's June 9 mail). > [suresh] Sorry, I dont parse what you say. The timeout mentioned in REQ-5 refers to NAT Session idle timeout. Not same as idletimeout for Binding. > > > In reality, the above is not true. Here is why. Most NAT devices use a > Binding > > refresh timeout of 0 secs for all kinds of Bindings, including TCP Port > > Binding, UDP Port Binding and Address Binding. I.e., as soon as the last > NAT > > Session using the Binding is freed, the associated Binding is also freed. > > See my response to Case 3 above; setting the mapping timer value to as > long as you propose a binding should be valid for is functionally > equivalent. > [suresh] See my note above. Idle timeout for Binding and NAT Session are different. > > > Folks expect the NAT Session in item c) to be freed at the end of no > activity > > for 2 mins. But, the Binding remains alive, so do the remaining two NAT > Session > > in items b) and d). > > Agreed -- except I don't think in terms of "binding" and "session". I > believe c) should expire (in that packets from Y2:y2 may be dropped > after 5 minutes of inactivity) while b) and d) remain alive. And in > addition, I believe a new > e) ((X:x->Y4:y4) Xlates to (N:Nx->Y4:y4) > i.e. it uses N:Nx .... and that is *exactly* what the UDP draft says > should happen now!! > > In particular: > 1) the old requirement recommending "Per Mapping" filter refresh scope > has been removed therefore allowing c) to expire if the vendor wants. > 2) the 5-minute requirement prevent b) or d) from being reclaimed before > they have been idle for 5 minutes. > 3) the EF=I requirement says that a new session (e) should get the same > mapping as b) or d) and should therefore use N:Nx. > > As I see it, both you and the draft are recommending the _exact_ same > thing ... which is fantastic ... but just in different terms. > [suresh] Right. I agree with everything you say if you said mapping in REQ-5 were to be interpreted as "NAT Session" in REQ-5. But, you say, they are not the same. > > > > As for removing section 5.2, we did agree on this because, filtering is not > an > > independent resource that a NAT device has. > > For each filtering rule, the NAT needs to keep state. Here a filtering > rule corresponds to the familiar 7-tuple (Protocol, internal address and > port, mapped address and port, external address and port) ... which also > goes by the name "NAT Session (gen)". What all amongst these 7-entries > the NAT matches an incoming packet to depends on the EF type of the NAT. > [suresh] NAT keeps state for every NAT Session. The state is required for doing more than just filtering. The state is used for translation, idle timeout monitoring and so forth for UDP. The state is used to track even more stuff for TCP - seq/ack no, TCP connection state etc. If all you wanted to do was filtering, you would need just a 5-tuple filter for the external realm, just as a firewall does. NAT Session is a resource that NAT has. filterign is a behavior this resource enforces. > > > > > As for which terminology to use, I strongly prefer the behave-udp > > > terminology since it can actually differentiate between the types of > > > NATs I actually see in the wild. > > > > [suresh] I strongly recommend otherwise. See my notes above on the > > inconsistency in your interpretation. > > The inadequacy of "Cone/Symmetric" in capturing current real-life > behavior has nothing to do with the UDP draft. > [suresh] I agree, the "Cone/Symmetric" behaviors do not capture all the wierd behaviors out there. E.g., EF=P characterization in section 4.2 of your paper proves that. None of the Cone/Symmetric Behaviors explain this. Then again, it is not the charter of this WG to identify terminology to capture all the current real-life behaviors of the NAT devices out there. The charter of the WG is simply to state compliant behavior for NAT devices. > > > > When a NAT device does not support > > Bindings, it is simply not Behave compliant. What does it matter, how badly > it > > does not support Bindings. > > Matters both for legacy NATs and for vendors that refuse to be compliant > with behave. > [suresh] It is not the charter of this WG to characterize non-compliant NAT devices. > > > > Determining the finer gradation of > > how badly a NAT device is behave un-compliant is not the goal of this WG > > charter. > > The finer gradation is not for defining how a device is un-compliant. It > just happens to reflect reality better, and as a side-effect ends up > pinpointing the problem on an un-compliant NAT than just say "bad". > [suresh] That is a fine thing to do. All that is required from the WG standpoint is to characterize requirements for compliance. Either a device meets the requirement or NOT. cheers, suresh > > -- > Saikat > From ssenthil@cisco.com Tue, 19 Jul 2005 08:00:24 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Tue, 19 Jul 2005 08:00:24 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB61E4CD@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Looks like the discussion on timeouts would never end. Just wanted to quickly point out that the bindings (1-1 address binding) are used extensively in large deployments. These bindings are then used to make other policy decisions in the network. You could definitely have an implementation that does not use any bindings, so the end user could get a different address for every session as long as connectivity to the public network is the only requirement. That is not always the case. The characteristics of the bindings is different from the characteristics of the sessions. The bindings don't track the state, but do have a timer (which is usually much larger than the session timeout). Senthil > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Monday, July 18, 2005 12:06 AM > To: Behave > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > On Sun, 2005-07-17 at 15:05 -0700, Pyda Srisuresh wrote: > > Most NAT devices use a Binding > > refresh timeout of 0 secs for all kinds of Bindings > > Can you point me to a study that shows that? What percentage > of NATs use a binding timer of 0? What percentage use a larger value? > > In fact, can you even point me to something that shows that > the NATs that you claim "use a Binding refresh timeout of 0 > secs" _even use_ bindings and binding timers in the first place? > > Instead, let me point you to the Linux source that: > 1. DOES NOT use bindings > 2. DOES NOT use a binding timer > 3. Is a NAT that is behave compliant > 4. Would _appear_ to use bindings and a binding timeout of 0 > but DOES NOT > > In the Linux implementation, there _is_ "mapping reuse (behave-udp)". > For each "NAT session (behave-gen)" there is a mapping. That > mapping is reused -- the reuse gives the _illusion_ of a > "binding". That mapping has an associated timer (that would > appear as "NAT Session timer (behave-gen)" in your test). > That mapping is refreshed (when a packet is accepted on that > mapping -- i.e. when the packet is not filtered). When a new > connection arrives, existing mappings are checked and their > mapped address and port values _reused_. When a mapping > expires -- thats it, the mapping expires -- nothing else is > touched or refreshed. No binding state is reaped. As long as > there is even one live mapping when a new connection arrives > from the same internal endpoint the values from that mapping > are reused. When all the mappings are gone, a new mapping is > created for the new connection and there is no reuse. This > gives the _impression_ of having a "binding refresh timeout > of 0" ... but in reality, there is NO binding timeout. I > invite you to reconfirm this in the Linux 2.6.11 NAT code > (annotated below). > > Not to be rude, but the fact remains that talking of a > "binding timeout" > as something that absolutely MUST exist in a NAT and MUST be > standardized is absurd! A vendor's particular implementation > may use "bindings" and "binding timeouts" to implement the > requirements specified in behave-udp .... but claiming that > "bindings" and "sessions" > are the one true terminology that descries what NATs do is > unjustified. > > > ---- Linux implementation details / code walkthrough ---- > > When determining what NAT'ed IP and port to use for a new > connection, Linux does the following: > > 1. Look through each existing session until it finds one where > the internal src ip and port matches the new connection. > 2. Use the NAT'ed ip and port of that connection. > > See: > get_unique_tuple calls (ip_nat_core.c#L230) > find_appropriate_src that iterates over (ip_nat_core.c#L146) > existing connections (ip_nat.h#L61) and for each connection, > calls same_src (ip_nat_core.c#L147) that checks protocol, > internal IP and port for equality (ip_nat_core.c#L128). > find_appropriate_src returns after the first match > (ip_nat_core.c#L155). > > (add http://lxr.linux.no/source/net/ipv4/netfilter/ before > the file#Lline links above to view online) > > There is *no table of "bindings"* that it checks. It only > checks live "NAT sessions (behave-gen)". > > When a packet is sent or received: > 1. The timer for that connection "NAT session (behave-gen)" > is refreshed. (ip_conntrack_proto_udp.c#L73 for UDP, > ip_conntrack_proto_tcp.c#L972 for TCP) > > The connection timer is the only one it ever touches. If > there was a binding timer, then it would require at least two > timers to be changed > -- that is not the case. > > Further, when a connection expires: > The death_by_timeout(ip_conntrack_core.c#L509) function is > called that only deletes the timer associated with that "NAT > session" (ip_conntrack_core.c#L267). > > It does NOT check whether other "NAT sessions (gen)" with the > same "binding (gen)" are alive or not. It does not refresh or > set some new "binding timeout". There is no binding timeout. > > > -- > Saikat > (huff, pufff) > From srisuresh@yahoo.com Tue, 19 Jul 2005 08:00:55 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 19 Jul 2005 08:00:55 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1121659566.9397.56.camel@localhost.localdomain> Message-ID: <20050719145958.89498.qmail@web33302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Sun, 2005-07-17 at 15:05 -0700, Pyda Srisuresh wrote: > > Most NAT devices use a Binding > > refresh timeout of 0 secs for all kinds of Bindings > > Can you point me to a study that shows that? What percentage of NATs use > a binding timer of 0? What percentage use a larger value? > > In fact, can you even point me to something that shows that the NATs > that you claim "use a Binding refresh timeout of 0 secs" _even use_ > bindings and binding timers in the first place? > [suresh] Saikat - I have not done a study characterizing NAT devices to give you percentages. However, I have done several NAT implementations, know of several people that did NAT implementations and talked with several customers that used NAT implementations. So, I do know a little something of what I am talking about. > Instead, let me point you to the Linux source that: > 1. DOES NOT use bindings > 2. DOES NOT use a binding timer > 3. Is a NAT that is behave compliant > 4. Would _appear_ to use bindings and a binding timeout of 0 but DOES > NOT > > In the Linux implementation, there _is_ "mapping reuse (behave-udp)". > For each "NAT session (behave-gen)" there is a mapping. That mapping is > reused -- the reuse gives the _illusion_ of a "binding". That mapping > has an associated timer (that would appear as "NAT Session timer > (behave-gen)" in your test). That mapping is refreshed (when a packet is > accepted on that mapping -- i.e. when the packet is not filtered). When > a new connection arrives, existing mappings are checked and their mapped > address and port values _reused_. When a mapping expires -- thats it, > the mapping expires -- nothing else is touched or refreshed. No binding > state is reaped. As long as there is even one live mapping when a new > connection arrives from the same internal endpoint the values from that > mapping are reused. When all the mappings are gone, a new mapping is > created for the new connection and there is no reuse. This gives the > _impression_ of having a "binding refresh timeout of 0" ... but in > reality, there is NO binding timeout. I invite you to reconfirm this in > the Linux 2.6.11 NAT code (annotated below). > [suresh] As for the Linux implementation detail - I will take your word for it. Have you looked at how Linux implements DNS-ALG for idle timeout minitoring of an Address Binding (refer RFC 2694 for DNS-ALG)? (or) Have you looked at how Linux implements idle timeout monitoring of Bindings for a P2P ALG or any other ALG that monitors Binding idle timeout? People may choose several ways to implement the Bindings and NAT Sessions. The specific implementations are not relevant to this discussion. What is relevant is that a NAT device has these resources reflected in some form, with complaint relationship and characteristics. > Not to be rude, but the fact remains that talking of a "binding timeout" > as something that absolutely MUST exist in a NAT and MUST be > standardized is absurd! A vendor's particular implementation may use > "bindings" and "binding timeouts" to implement the requirements > specified in behave-udp .... but claiming that "bindings" and "sessions" > are the one true terminology that descries what NATs do is unjustified. > [suresh] Saikat - That a NAT device MUST support Bindings is the most important requirement coming out of the Behave drafts. Binding as a resourc has characteristics such as directionality and idle timeout, in addition to endpoint translation. So,it is only reasonable that it be recognized as a key NAT resource and specify the compliant requirements of this resource and its parameters in the Behave drafts. It is absurd to not recognize Binding and not discuss the behavioral requirements of its idle timeout and directioanlity in Behave drafts. > > ---- Linux implementation details / code walkthrough ---- > > When determining what NAT'ed IP and port to use for a new connection, > Linux does the following: > > 1. Look through each existing session until it finds one where > the internal src ip and port matches the new connection. > 2. Use the NAT'ed ip and port of that connection. > > See: > get_unique_tuple calls (ip_nat_core.c#L230) find_appropriate_src that > iterates over (ip_nat_core.c#L146) existing connections (ip_nat.h#L61) > and for each connection, calls same_src (ip_nat_core.c#L147) that checks > protocol, internal IP and port for equality (ip_nat_core.c#L128). > find_appropriate_src returns after the first match (ip_nat_core.c#L155). > > (add http://lxr.linux.no/source/net/ipv4/netfilter/ before the > file#Lline links above to view online) > > There is *no table of "bindings"* that it checks. It only checks live > "NAT sessions (behave-gen)". > > When a packet is sent or received: > 1. The timer for that connection "NAT session (behave-gen)" is > refreshed. (ip_conntrack_proto_udp.c#L73 for UDP, > ip_conntrack_proto_tcp.c#L972 for TCP) > > The connection timer is the only one it ever touches. If there was a > binding timer, then it would require at least two timers to be changed > -- that is not the case. > > Further, when a connection expires: > The death_by_timeout(ip_conntrack_core.c#L509) function is called that > only deletes the timer associated with that "NAT > session" (ip_conntrack_core.c#L267). > > It does NOT check whether other "NAT sessions (gen)" with the same > "binding (gen)" are alive or not. It does not refresh or set some new > "binding timeout". There is no binding timeout. > [suresh] Saikat - Thanks for the the Linux implementation details. It seems, Linux is implementing a Binding timeout of 0 secs. While the implementation details vary, there are many NAT devices that implement a Binding timeout of 0 secs. Q: Do you know how Linux implements non-zero timeout for Bindings - Address and/or Port Bindings? cheers, suresh > > -- > Saikat > (huff, pufff) > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From sg266@cornell.edu Tue, 19 Jul 2005 14:10:44 -0700 (PDT) From: Saikat Guha Date: Tue, 19 Jul 2005 14:10:44 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB61E4CD@xmb-sjc-236.amer.cisco.com> Message-ID: <1121807439.5918.21.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-07-19 at 07:59 -0700, Senthil Sivakumar (ssenthil) wrote: > You could definitely have an > implementation that does not use any bindings, so the end user could get > a different address for every session It is not as simple as that. What behave-udp currently requires is: - you MUST get the same address for every "session" as long as there is even one live session from the same internal endpoint. behave-udp does not say what happens after all live sessions timeout. you may or may not get the same address, say a couple of hours after the last session expires. That is what "bindings" proposal mandates. In particular, the binding requirement translates to: - you MUST get the same address for every "session" as long as there is even one live session from the same internal endpoint. (same as behave-udp) - in addition, you MUST get the same address for a new session initiated within some time-window since the last live session expired. (where the time-window is defined by the so-called binding-timer) So it is not true that if you do not use binding then you get a different address for every session (see the Linux mail earlier). The first and foremost concern everyone has -- that concurrent "sessions" from the same internal endpoint all get the same address -- is explicitly handled by both proposals. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00073.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00073.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzNXeFBuRmx0cWk2OTEvb1JBZ0I2QUo5ZC96SzkwcHF4bTZ0eFFuVXRP RU10ek8yOStRQ2VNTnRhCm1DU0plNkZjTGYyNHRRT0hyaDlCcHFZPQo9WlQzawotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From audet@nortel.com Tue, 19 Jul 2005 14:33:02 -0700 (PDT) From: "Francois Audet" Date: Tue, 19 Jul 2005 14:33:02 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <1ECE0EB50388174790F9694F77522CCF035BD1B3@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Right. Using bindings is a perfectly reasonable way of implementing this, and people are free to do it. But the mandate of the BEHAVE group is NOT to mandate specific technologies for implementation. This is why the language in the draft keeps it at a higher level (i.e., using "mapping" instead of "binding"). > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Tuesday, July 19, 2005 14:11 > To: Senthil Sivakumar (ssenthil) > Cc: Behave > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > > On Tue, 2005-07-19 at 07:59 -0700, Senthil Sivakumar (ssenthil) wrote: > > You could definitely have an > > implementation that does not use any bindings, so the end > user could > > get a different address for every session > > It is not as simple as that. What behave-udp currently requires is: > > - you MUST get the same address for every "session" as long > as there is > even one live session from the same internal endpoint. > > behave-udp does not say what happens after all live sessions > timeout. you may or may not get the same address, say a > couple of hours after the last session expires. That is what > "bindings" proposal mandates. In particular, the binding > requirement translates to: > > - you MUST get the same address for every "session" as long > as there is > even one live session from the same internal endpoint. > (same as behave-udp) > - in addition, you MUST get the same address for a new > session initiated > within some time-window since the last live session expired. > (where the time-window is defined by the so-called binding-timer) > > So it is not true that if you do not use binding then you get > a different address for every session (see the Linux mail earlier). > > The first and foremost concern everyone has -- that > concurrent "sessions" from the same internal endpoint all get > the same address -- is explicitly handled by both proposals. > > -- > Saikat > From ssenthil@cisco.com Tue, 19 Jul 2005 14:33:21 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Tue, 19 Jul 2005 14:33:21 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB61E735@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] > Sent: Tuesday, July 19, 2005 5:11 PM > To: Senthil Sivakumar (ssenthil) > Cc: Behave > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > On Tue, 2005-07-19 at 07:59 -0700, Senthil Sivakumar (ssenthil) wrote: > > You could definitely have an > > implementation that does not use any bindings, so the end > user could > > get a different address for every session > > It is not as simple as that. What behave-udp currently requires is: > > - you MUST get the same address for every "session" as long > as there is > even one live session from the same internal endpoint. > > behave-udp does not say what happens after all live sessions timeout. > you may or may not get the same address, say a couple of > hours after the last session expires. That is what "bindings" > proposal mandates. In particular, the binding requirement > translates to: > > - you MUST get the same address for every "session" as long > as there is > even one live session from the same internal endpoint. > (same as behave-udp) > - in addition, you MUST get the same address for a new > session initiated > within some time-window since the last live session expired. > (where the time-window is defined by the so-called binding-timer) > > So it is not true that if you do not use binding then you get > a different address for every session (see the Linux mail earlier). How did you know you have to give the same address to the same endpoint? You have to maintain some information that this endpoint was assigned this address for a previous session. This is what I call as binding. You want to call it something else that is your call. I just wanted to point out that there are bindings and there are binding timeouts. I don't understand the point of this discussion whether bindings should exist or not? Do we want to recognize that there are bindings and recommend a timeout? If no, vendors will implement their own timeouts just like today. If we don't want to recongize bindings should exist and hence binding timeouts are not needed the vendors who have implemented bindings will just ignore the recommendation and stick to their implementation. Senthil > > The first and foremost concern everyone has -- that > concurrent "sessions" from the same internal endpoint all get > the same address -- is explicitly handled by both proposals. > > -- > Saikat > From audet@nortel.com Tue, 19 Jul 2005 14:37:38 -0700 (PDT) From: "Francois Audet" Date: Tue, 19 Jul 2005 14:37:38 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <1ECE0EB50388174790F9694F77522CCF035BD1D0@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain > I just wanted to point out that there are bindings and there > are binding timeouts. I don't understand the point of this > discussion whether bindings should exist or not? Do we want > to recognize that there are bindings and recommend a timeout? > If no, vendors will implement their own timeouts just like > today. If we don't want to recongize bindings should exist > and hence binding timeouts are not needed the vendors who > have implemented bindings will just ignore the recommendation > and stick to their implementation. REQ-5 addresses the timeout of mapping. How it relates to "bindings" is implementation details not specifically covered in the document. From sg266@cornell.edu Tue, 19 Jul 2005 14:42:47 -0700 (PDT) From: Saikat Guha Date: Tue, 19 Jul 2005 14:42:47 -0700 (PDT) Subject: STUNT test results (was RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh) In-Reply-To: <20050719141339.31171.qmail@web33310.mail.mud.yahoo.com> Message-ID: <1121809362.5918.44.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-07-19 at 07:13 -0700, Pyda Srisuresh wrote: > > > The filtering behaviors specified in section 5.1 are specific only to UDP > > and > > > not aplicable to TCP. > > > > Not true. Please refer to > > http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf Section 4.2 > > [suresh] Saikat - Good work characterizing NATs. Had a chance to review > section > 4.2 of your paper. 9% of the devices tested apparatly fell under one of EF=A > or > EF=P in that they accept TCP connection if the external Address or Port alone > match the original outgoign connection. For these accpeted connections, does > A:P translate back to a:p, or, is it some other internal port tuple? Yes. A:P translates back to a:p. For lab NATs, I checked packets on the wire to discount the second possibility. > Have you > seen any scenario where a NAT device accepts inbound TCP connections, but does > not fall under any of the 4 categories you identified (I, AP, A, P)? I > suspect, > there will be a few that fall under miscellaneous, wierd, unknown categories, > if you widen your samples further. I have not seen other behavior. It is conceivable that the NAT accepts inbound SYN's if the source is on the same /24 subnet as another host to which it has an established connection for example. If that is the case, the NAT would show up as EF=I in my test (since the two servers are on the same /25 subnet); duplicating the test with more diversely located servers would brand the NAT EF=AP or something. The true type of such a NAT would indeed be something 'weird'. As for my experiments, I checked the NATs in the lab for this particular weirdness and didn't find it, but it is possible some NATs do this. > How consistent are the NAT devices in their EF=A or EF=P behavior? The EF=P > behavior is wierd even for UDP and Cone NATs. Fairly consistent I recall. I repeated the test about 20 times for the lab NATs and the results were identical. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00074.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00074.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzNYUFNuRmx0cWk2OTEvb1JBdWNDQUo0b3VyK2dMQnJjSFZBQ0lSKzhH QUN0WTZaYStRQ2ZjY1VjCndPV0Y0OVpkeE1kSGVWUENuS1NPR21VPQo9R2R4YwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Tue, 19 Jul 2005 14:56:41 -0700 (PDT) From: Saikat Guha Date: Tue, 19 Jul 2005 14:56:41 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB61E735@xmb-sjc-236.amer.cisco.com> Message-ID: <1121810197.5918.56.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-07-19 at 14:33 -0700, Senthil Sivakumar (ssenthil) wrote: > > So it is not true that if you do not use binding then you get > > a different address for every session (see the Linux mail earlier). > > How did you know you have to give the same address to the same endpoint? > You have to maintain some information that this endpoint was assigned > this address for a previous session. This is what I call as binding. You > want to call it something else that is your call. By binding, I am referring to the binding definition in behave-gen. I agree with you that "some information" needs to be maintained -- and may be stored in as binding entry (the (a) entry in suresh's example earlier), or may be stored redundantly in the per-connection 7-or-more- tuple that Linux has (see earlier post). This difference in implementation is abstracted by "mapping" as defined in behave-udp but it is not abstracted by "binding" and "binding timer" as defined in behave-gen. That is all this discussion is about -- what to call it. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00075.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00075.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzNYY1ZuRmx0cWk2OTEvb1JBaG1BQUo5b29QUEdWck56cmVvTjFBTkk3 a3F0S25DaU9RQ2ZTUGJYClUxSGE0QjFZcXFwRS9PbWRTSEJ4OVgwPQo9T1ZhVQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From sg266@cornell.edu Tue, 19 Jul 2005 18:55:11 -0700 (PDT) From: Saikat Guha Date: Tue, 19 Jul 2005 18:55:11 -0700 (PDT) Subject: [Ietf-behave] New revision of draft-hoffman-behave-tcp, now -02 Message-ID: <1121824506.27225.72.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all, As if this list doesn't already generate enough traffic, I'd like to bring to your attention a new revision of draft-hoffman-behave-tcp here: http://www.ietf.org/internet-drafts/draft-hoffman-behave-tcp-02.txt A quick summary -- it has three requirements. Paraphrased, they are: 1. All TCP packets in either direction should be allowed (i.e. to allow simultaneous-open etc) 2. How to respond to unsolicited inbound SYN -- - silently drop is the recommendation (current consensus) - RST is a big no-no (also a consensus) - ICMP is optional (more on this below) 3. Mapping timer for TCP connections in various states - 2 hours for established connections (as per RFC 1122) - 4 minutes for connections in setup or teardown phase (as per RFC 1122) - closed connections (think RST) left unspecified (ignore, 0 seconds, 4 minutes etc whatever the vendor decides) I believe it reflects the IETF 62 consensus and list discussions. The rest of this mail has detailed justifications for each of the requirements above and a comparison against the other behave-tcp drafts. Coffee is RECOMMENDED to the brave reader. -------------- Justifications/Comparison ---------------- ====== Background ====== 4 basic STUN-like TCP NAT-traversal approaches have been proposed. Each approach can be tweaked slightly to perform better under some scenarios. See http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf for a summary. Success and failure rates and reasons thereof are also presented in that paper. ====== REQ 1 ====== REQ-1: A NAT MUST allow all TCP packets in either direction on any open NAT mapping that is a TCP connection. This is mainly to enable simultaneous-TCP-like connection setup. Note that the requirement is not restricted to SYN-in after SYN-out. More generally, it allows the end-host stack to take any transition as it sees fit whether or not the NAT vendor recognizes that transition. In particular, here are some transitions that do not always work today: 1) SYN-out SYN-in (simultaneous open) 2) SYNACK-out (simultaneous open) 3) FIN-in FIN/ACK-out LAST_ACK-in (regular TCP) -- this one leads to hanging TCBs sometimes when the final ACK is filtered. Concerns: 1) How does this affect security? This is at most as secure as the end host. If the endhost stack, for example, is vulnerable to a particular combination of flags or sequence of packets with flags set by an adversary that the NAT would have otherwise filtered, then the endhost will still be vulnerable. 2) How does this affect functionality? It is more functional than existing NATs. Simultaneous open is in the RFC, all NATs don't support this at the moment. 3) What would be most secure and offer best functionality? A NAT that tracks the exact TCP state (not a simplified state machine) of the endhost behind it and allows packets with valid flags. NAT vendors may not be willing to track the full blown TCP state machine. 4) Why not just say allow incoming SYN? Because there are other transitions not currently supported. Simultaneous open, for example, requires outgoing SYNACKs. A protocol could trigger the simultaneous-close (where the FIN's cross in network) and break if the NAT doesn't support that transition. 5) The current wording precludes the "best" implementation as outlined in concern #3. Sort of. It'd be nice if it said 'allow all valid packets', but that ventures into the land of firewalls and the definition of 'valid' would be fuzzy -- had the vendors read the TCP RFC in the first place, they'd have seen the simultaneous open case. Perhaps it's fine to say that functionality wise a _NAT_ must allow all TCP packets, and leave the the security/flag- sanitization part to a _firewall_. ====== REQ 2 ====== REQ-2: A NAT MUST NOT send a RST packet in response to a SYN packet sent from the external side to an address and port mapping that does not exist. a) A NAT MAY send an ICMP Host Unreachable (Type=3, Code=1) in response to such a SYN packet. The basic idea here is that a fatal error must not be generated in response to a SYN packet. That makes simultaneous TCP setup very hard and timing sensitive since then the two SYNs absolutely must cross in the network and one cannot arrive at the NAT before the other exits that NAT. The current consensus is that the packet should be silently rejected. While thats fine for simultaneous setup, thats not fine for regular TCP. For regular TCP, the SYN is sent (and resent) for up to 30 seconds on windows and over a minute on Linux. If no response is received, then the application (email, web browser etc) blocks for 30s to 1m30s depending. Ideally, the NAT signals a non-fatal error so that the application can decide whether to give up (email, web etc) or to keep waiting for TCP simultaneous open to be triggered (peer to peer apps). A non-fatal error can be some (not all) ICMP Destination Unreachable etc. The current group consensus is conducive to p2p apps, but not to regular old TCP apps like ssh, telnet, email, web browsers etc. At the moment, the recommendation above is silent-drop -- in line with consensus ... but ideally I think a non-fatal error would be much better. Concerns: 1) Current wording is insufficient. It allows the NAT to respond with an ICMP port-unreachable -- which is a fatal error as per RFC 1122 Correct -- this needs to be fixed. Fatal and non-fatal errors need to be defined. Fatal errors will include TCP RST, ICMP Port Unreachable and other "hard" errors as per RFC 1122. Non-Fatal errors will include "soft" errors from RFC 1122. The structure of the current requirement is -- MUST NOT return fatal error. MAY return non-fatal error. 2) The WG already has consensus on silent drop. I am not sure all the options were evaluated properly before consensus was reached. (the last meeting's minutes don't mention the possibility of returning an ICMP soft-error). Effects on non P2P TCP was not considered. If the consensus was that RST (or a fatal error) must not be returned, this proposal preserves that. 3) Type=3, Code=1 doesn't describe the condition well. It need not be that. We can figure out what the soft-error should be. There was some discussion on this list earlier about using Code 10 ... but RFC 1122 doesn't explicitly designate that a soft-error. We could add a new code and define it a soft- error. Or overload an existing soft-error. Or use an existing code that has no soft/hard designation and explicitly designate it a soft-error. The exact error needs to be decided upon. 4) ICMP would break legacy NATs. Not necessarily. If the legacy NAT aborts on seeing the ICMP, then the connection attempt can be reversed so the legacy NAT is not on the ICMP receiving side. The problem arises only when the legacy NAT aborts on the ICMP _and_ responds with RST to inbound SYNs (thus preventing the connection reversal). Currently, less than 1% (~0.5%) NATs fall into that category. So returning ICMP does not affect TCP connectivity establishment much even today, let alone over time as legacy NATs firmwares are upgraded to be behave compliant. ====== REQ 3 ====== REQ-3: A NAT TCP mapping timer SHOULD NOT expire in less than 4 minutes for a TCP connection in SYN_SENT, SYN_RCVD, CLOSING, LAST_ACK or TIME_WAIT state. A NAT TCP mapping timer SHOULD NOT expire in less than 2 hours for a TCP connection in any other state except CLOSED. a) When a NAT closes an open TCP mapping, it MUST send RST packets to each end of the connection. b) To maximize application transparency, a NAT MAY expire mappings only when it is low on resources. The basic idea here is that connections have 3 phases ... startup, established and closing (the sivakumar draft also makes the same argument). There is a short-timer during the startup and closing phases to allow inflight packets to arrive -- 2xMSL as defined in TCP with MSL defined as 2 minutes in RFC 1122. There is a long-timer for established connections to accommodate long-lived idle connections -- TCP provides a keepalive mechanism to make sure the other endpoint didn't crash -- the default is 2 hours (RFC 1122). The NAT should respect these default timers. Nevertheless, a NAT may need to timeout connections -- it inform the endhost so the TCP is not left hanging (only to be discovered stale when data actually needs to be sent). Thats what the RST is for. As for keepalives, the RFC does not mandate keepalives to be sent on idle TCPs. So many apps may not even send keepalives every 2-hours. The NAT can try to accommodate them if it can ... but it is merely a suggestion. Concerns: 1) Why is this a SHOULD and not a MUST Absolutely requiring a NAT to examine flags etc is more in the land of firewalls -- it needs to understand that FIN exchange closes etc. A vendor can be compliant by setting a blanket 2- hour timeout for any and all TCP states - no flag analysis required. Yes, that would be inefficient and the vendor may want to do some lightweight flag analysis, but thats up to the vendor. The requirement does not force flag analysis. 2) Why does the NAT send a RST packet and not probe for liveness? The vendor is free to probe for liveness via keep-alive packets and preferably kill dead and expired mappings before live but expired mappings ... but it is not required to do so. Probing is an efficiency concern (since it allows the NAT to reclaim state sooner) and a vendor may choose to do so. 3) Why is RST a MUST? If a mapping is to be killed due to timeout -- either the application/host crashed or it is alive but idle. Since crashes are the exception and not the norm, if a mapping expires then the app is most likely alive and well. In addition, since it is holding the connection open, it expects to send data later -- otherwise why would it hold it open. Therefore if a mapping expires, then it is most likely that the application will notice sooner or later. Explicit RST informs the app of the problem as soon as possible. Though, admittedly, this requires the NAT to track sequence numbers, tcp timestamp etc to generate a in- window RST. So there is a valid argument to making this a SHOULD. Thoughts? 4) This is hard to implement. So many TCP states! Not really. The states above were chosen in a principled way to simplify implementation. For instance, until both ends send an ACK, one cannot be sure the connection has been established. Therefore all the TCP states that come before both ends have sent an ACK are in the short-timer phase. Implementation wise, a NAT just needs to keep track of the ACK flag in either direction -- as soon as it sees both ACKs, it can bump up the timer to 2hrs. Second, the connection is not closed until both sides send a FIN (both sides need to send the FIN since data can still be exchanged if only one side has closed the connection). So all TCP states that come after seeing FIN's going in opposite direction are again in the short-timer phase. Implementation wise this is simple too -- just track the FIN flags for inbound and outbound packets. Ofcourse a NAT doesn't need to do anything if it sets all timers to 2h, but thats vendor slack. The justifcation for REQ-3 text hints at the implementation ease if vendors do care to be resource-efficient. 5) What about packets in CLOSED state? CLOSED (the state after a RST) is intentionally left unspecified. The vendor can choose to kill the mapping as soon as it sees the RST or can choose to allow more packets (such as SYN) and decide to extend the mapping if such packets are exchanged. Not killing the mapping instantly helps P2P TCP with a legacy NAT that is spewing RST packets, while killing the mapping instantly can help reclaim resources and perhaps make it harder to hijack established sessions. The tradeoff is up to the vendor. ======== Differences from draft-sivakumar =========== 1. Requirements common to UDP, like endpoint independent mapping (read Cone behavior) etc are inherited from behave-udp and not re-justified. 2. TCP phase tracking is recommended, not a must. See REQ-3 concern #1 above. 3. REQ-1 above is more general than 'allow SYN packet in a particular phase'. Also see concerns #4 and #5 in REQ-1 above. 4. DoS attacks -- basically out-of-window RST attack, mentioned in the security concerns section. SYN-flood ... handled by short timers. Admittedly, the RFC recommendation of 4 minutes is excessive and most OS's use a 1 minute thing -- the exact timer value is a compliance vs. practice choice I guess. 5. NAT need not initiate keepalives, but may. See REQ-3 concern #2. (same as sivakumar actually, but not explicitly mentioned) 6. NAT MUST sent RST, instead of SHOULD. Concern #3 REQ-3 ========= Differences from draft-modadugu =========== 1. Sequence number adjustment not mentioned. Up to the vendor. (mostly important for ALGs and that too as a correctness issue. if a vendor doesn't implement an ALG, no need to recommend this) 2. The silent drop vs. RST issue is handled in REQ-2 with the added soft-error option. 3. Incoming SYN generalized in REQ-1. Concern #4,5 in REQ-1 ---------- If you wish to discuss any of these requirements on the list, please make a separate new thread for each requirement and for new requirements/omissions. :) cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00076.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00076.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzNhNzZuRmx0cWk2OTEvb1JBc3p5QUo5Z0ZVaHVwSE9udTBXNjF0OS9Q UmVoVVBUdkpnQ2ZmSmJyCjBIN1FxMlpUdkloLzFzZlZuMEpING9VPQo9bnM1TQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From srisuresh@yahoo.com Wed, 20 Jul 2005 06:11:01 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 20 Jul 2005 06:11:01 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1ECE0EB50388174790F9694F77522CCF035BD1B3@zrc2hxm0.corp.nortel.com> Message-ID: <20050720131100.3507.qmail@web33314.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Francois Audet wrote: > Right. > > Using bindings is a perfectly reasonable way of implementing this, and > people are free to do it. [suresh] This is the fundamental disconnect. Let me repeat for the nth time. Binding is not not an implementation detail. Binding is a NAT resource, just as a NAT Session is. Linux version of implementing a Binding is Linux implementation detail. > > But the mandate of the BEHAVE group is NOT to mandate specific > technologies for implementation. This is why the language in the > draft keeps it at a higher level (i.e., using "mapping" instead > of "binding"). > [suresh] The language in the UDP draft is not at a higher level. The language in the UDP draft is the source of inconsistency and confusion. You are using "mapping" at a high level instead of "Binding" to refer to idle timeout of "NAT Sessions" in REQ-5? cheers, suresh > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Saikat Guha > > Sent: Tuesday, July 19, 2005 14:11 > > To: Senthil Sivakumar (ssenthil) > > Cc: Behave > > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > > > > > On Tue, 2005-07-19 at 07:59 -0700, Senthil Sivakumar (ssenthil) wrote: > > > You could definitely have an > > > implementation that does not use any bindings, so the end > > user could > > > get a different address for every session > > > > It is not as simple as that. What behave-udp currently requires is: > > > > - you MUST get the same address for every "session" as long > > as there is > > even one live session from the same internal endpoint. > > > > behave-udp does not say what happens after all live sessions > > timeout. you may or may not get the same address, say a > > couple of hours after the last session expires. That is what > > "bindings" proposal mandates. In particular, the binding > > requirement translates to: > > > > - you MUST get the same address for every "session" as long > > as there is > > even one live session from the same internal endpoint. > > (same as behave-udp) > > - in addition, you MUST get the same address for a new > > session initiated > > within some time-window since the last live session expired. > > (where the time-window is defined by the so-called binding-timer) > > > > So it is not true that if you do not use binding then you get > > a different address for every session (see the Linux mail earlier). > > > > The first and foremost concern everyone has -- that > > concurrent "sessions" from the same internal endpoint all get > > the same address -- is explicitly handled by both proposals. > > > > -- > > Saikat > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Wed, 20 Jul 2005 06:22:20 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 20 Jul 2005 06:22:20 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB61E735@xmb-sjc-236.amer.cisco.com> Message-ID: <20050720132219.60353.qmail@web33305.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- "Senthil Sivakumar (ssenthil)" wrote: > > > > -----Original Message----- > > From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] > > Sent: Tuesday, July 19, 2005 5:11 PM > > To: Senthil Sivakumar (ssenthil) > > Cc: Behave > > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > > > On Tue, 2005-07-19 at 07:59 -0700, Senthil Sivakumar (ssenthil) wrote: > > > You could definitely have an > > > implementation that does not use any bindings, so the end > > user could > > > get a different address for every session > > > > It is not as simple as that. What behave-udp currently requires is: > > > > - you MUST get the same address for every "session" as long > > as there is > > even one live session from the same internal endpoint. > > > > behave-udp does not say what happens after all live sessions timeout. > > you may or may not get the same address, say a couple of > > hours after the last session expires. That is what "bindings" > > proposal mandates. In particular, the binding requirement > > translates to: > > > > - you MUST get the same address for every "session" as long > > as there is > > even one live session from the same internal endpoint. > > (same as behave-udp) > > - in addition, you MUST get the same address for a new > > session initiated > > within some time-window since the last live session expired. > > (where the time-window is defined by the so-called binding-timer) > > > > So it is not true that if you do not use binding then you get > > a different address for every session (see the Linux mail earlier). > > How did you know you have to give the same address to the same endpoint? > You have to maintain some information that this endpoint was assigned > this address for a previous session. This is what I call as binding. You > want to call it something else that is your call. [suresh] Well said, Senthil. The key is recognizing Binding as a NAT resource and not getting caught up in implementation details of how Binding is implemented in Linux. > > I just wanted to point out that there are bindings and there are binding > timeouts. I don't understand the point of this discussion whether > bindings should exist or not? Do we want to recognize that there are > bindings and recommend a timeout? If no, vendors will implement their > own timeouts just like today. If we don't want to recongize bindings > should exist and hence binding timeouts are not needed the vendors who > have implemented bindings will just ignore the recommendation and stick > to their implementation. > [suresh] Good point. I agree. The Behave drafts will become irrelevant if they dont address what is basic to NATs. Vendors will do what they choose to do and simply ignore the Behave recommendations. cheers, suresh > Senthil > > > > > > The first and foremost concern everyone has -- that > > concurrent "sessions" from the same internal endpoint all get > > the same address -- is explicitly handled by both proposals. > > > > -- > > Saikat > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Wed, 20 Jul 2005 06:50:50 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 20 Jul 2005 06:50:50 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1121810197.5918.56.camel@localhost.localdomain> Message-ID: <20050720135050.66867.qmail@web33307.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Tue, 2005-07-19 at 14:33 -0700, Senthil Sivakumar (ssenthil) wrote: > > > So it is not true that if you do not use binding then you get > > > a different address for every session (see the Linux mail earlier). > > > > How did you know you have to give the same address to the same endpoint? > > You have to maintain some information that this endpoint was assigned > > this address for a previous session. This is what I call as binding. You > > want to call it something else that is your call. > > By binding, I am referring to the binding definition in behave-gen. I > agree with you that "some information" needs to be maintained -- and may > be stored in as binding entry (the (a) entry in suresh's example > earlier), or may be stored redundantly in the per-connection 7-or-more- > tuple that Linux has (see earlier post). > [suresh] Saikat - You continue to bring up implementation issues and mix them up with the implementation-independent stuff. What Senthil is refering to and what I had alluded to in the past is that "Binding" is a different type of NAT resource than "NAT Session". Some implementations may use different data structures, one for Binding entries and another for NAT Sessions; and others (as in Linux) may choose to use the same data structure to store the Binding entries as well as the NAT Sessions, or have ways to derive Bindings out of NAT Sessions if they donot implement non-zero Binding timeouts. But, that is an implementation detail, and not relevant to the discussion. Are we in agreement that a NAT device needs to maintain the equivalent of "Binding", and "NAT Session" entries? > This difference in implementation is abstracted by "mapping" as defined > in behave-udp but it is not abstracted by "binding" and "binding timer" > as defined in behave-gen. That is all this discussion is about -- what > to call it. [suresh] The differences in implementations are abstracted by the two terms - "Binding" and "NAT Session". "mapping" is not an abstract term. By using the term "mapping", behave-udp is not able to distinguish between idle timeout for a Binding vs. an idle timeout for a NAT Session. In other words, I do believe, the behave terminology must not assume specific implementations and use terminology that is implementation neutral. "Bindings" and "NAt Sessions" are implementation independent. These are the terms used n NAT-MIB (RFC 4008) cheers, suresh > > -- > Saikat > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Wed, 20 Jul 2005 07:27:30 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 20 Jul 2005 07:27:30 -0700 (PDT) Subject: Re: STUNT test results (was RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh) In-Reply-To: <1121809362.5918.44.camel@localhost.localdomain> Message-ID: <20050720142730.79183.qmail@web33305.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Tue, 2005-07-19 at 07:13 -0700, Pyda Srisuresh wrote: > > > > The filtering behaviors specified in section 5.1 are specific only to > UDP > > > and > > > > not aplicable to TCP. > > > > > > Not true. Please refer to > > > http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf Section 4.2 > > > > [suresh] Saikat - Good work characterizing NATs. Had a chance to review > section > > 4.2 of your paper. 9% of the devices tested apparatly fell under one of > EF=A or > > EF=P in that they accept TCP connection if the external Address or Port > alone > > match the original outgoign connection. For these accpeted connections, > does > > A:P translate back to a:p, or, is it some other internal port tuple? > > Yes. A:P translates back to a:p. For lab NATs, I checked packets on the > wire to discount the second possibility. > [suresh] OK. Thanks for the clarification. > > > Have you > > seen any scenario where a NAT device accepts inbound TCP connections, but > does > > not fall under any of the 4 categories you identified (I, AP, A, P)? I > suspect, > > there will be a few that fall under miscellaneous, wierd, unknown > categories, > > if you widen your samples further. > > I have not seen other behavior. It is conceivable that the NAT accepts > inbound SYN's if the source is on the same /24 subnet as another host to > which it has an established connection for example. If that is the case, > the NAT would show up as EF=I in my test (since the two servers are on > the same /25 subnet); duplicating the test with more diversely located > servers would brand the NAT EF=AP or something. The true type of such a > NAT would indeed be something 'weird'. As for my experiments, I checked > the NATs in the lab for this particular weirdness and didn't find it, > but it is possible some NATs do this. > [suresh] Right. It certainly is a hard problem to identify the various wierd behaviors, some of which may be consistent and some not. > > > How consistent are the NAT devices in their EF=A or EF=P behavior? The EF=P > > behavior is wierd even for UDP and Cone NATs. > > Fairly consistent I recall. I repeated the test about 20 times for the > lab NATs and the results were identical. > [suresh] OK, Thanks. > > > -- > Saikat > From sg266@cornell.edu Thu, 21 Jul 2005 13:26:29 -0700 (PDT) From: Saikat Guha Date: Thu, 21 Jul 2005 13:26:29 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050720135050.66867.qmail@web33307.mail.mud.yahoo.com> Message-ID: <1121977583.5716.25.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-07-20 at 06:50 -0700, Pyda Srisuresh wrote: > Are we in agreement that a NAT device needs to maintain the equivalent of > "Binding", and "NAT Session" entries? The "equivalent of", yes. Drawing an explicit distinction between "binding" and "session" is unnecessary. The "mapping" captures the _equivalent of_ bindings and sessions as you seek. > By using the > term "mapping", behave-udp is not able to distinguish between idle timeout for > a Binding vs. an idle timeout for a NAT Session. As you yourself said, the terminology doesn't need to capture anything and everything that NATs do today. It just needs to capture enough to remove the non-determinism we care about. In particular, behave-udp does not care about how ports are allocated long after *all* mappings for an internal endpoint expires. If you feel that it should, I am sure everyone would appreciate a concrete example where bindings and binding timers allow an application to work where it would not otherwise given the mapping terminology. In particular, consider that a session timeout of 5 minutes and a binding timeout of 5 minutes, is abstracted away with a mapping timeout of 10 minutes. So it is not true that more timers make it more general. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00077.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00077.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzRBVHZuRmx0cWk2OTEvb1JBaXQrQUo5UFBIeTU4UUw3NWJ6K0FSdmhC SXlDbkV4ZE5RQ2VQSm9jCmNidnRmVEkvU3pCMDZCWFRVcll5ZjhZPQo9cXFTRgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From srisuresh@yahoo.com Fri, 22 Jul 2005 13:03:16 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 22 Jul 2005 13:03:16 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1121977583.5716.25.camel@localhost.localdomain> Message-ID: <20050722200316.9829.qmail@web33302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Wed, 2005-07-20 at 06:50 -0700, Pyda Srisuresh wrote: > > Are we in agreement that a NAT device needs to maintain the equivalent of > > "Binding", and "NAT Session" entries? > > The "equivalent of", yes. Drawing an explicit distinction between > "binding" and "session" is unnecessary. The "mapping" captures the > _equivalent of_ bindings and sessions as you seek. > [suresh] Saikat - "Binding" and "NAT Session" are distinct NAT entities. A single term "mapping" cannot mean "Binding" in one context and "Nat Session" in another context. > > > By using the > > term "mapping", behave-udp is not able to distinguish between idle timeout > for > > a Binding vs. an idle timeout for a NAT Session. > > As you yourself said, the terminology doesn't need to capture anything > and everything that NATs do today. It just needs to capture enough to > remove the non-determinism we care about. [suresh] Sure. > In particular, behave-udp does > not care about how ports are allocated long after *all* mappings for an > internal endpoint expires. If you feel that it should, I am sure > everyone would appreciate a concrete example where bindings and binding > timers allow an application to work where it would not otherwise given > the mapping terminology. > [suresh] Here is an example with DNS ALG, where an idle timeout for an Address Binding is required independent of the idle timeout for associated NAT Sessions. 1. Say, the NAT device is configured with an address map as "10.0.0.0/8 mapped to 198.76.29.0/24". 10.0.0.0/8 is the private domain and 198.76.29.0/24 is the external address pool for assignment by the NAT. Say, the DNS Server for the private domain is inside the private domain and NAT has a static Binding for the DNS Server to direct DNS queries from external domain to the DNS server and vice versa. 2. Say, an external host (Host-Y) needs to run an application with "Host-X". Say, Host-X is inside the private domain bearing an address of 10.0.0.7. Host-Y firt initiates a DNS query for "Host-X". 3. NAT redirects the DNS query to the DNS Server inside the private domain. 4. DNS Server responds with an A type RR for Host-X with an IP address of 10.0.0.7. 5. The DNS_ALG would intercept the response packet and request the NAT to create an Address Binding for 10.0.0.7. Say, the NAT created an Address Binding to Bind 10.0.0.7 with 198.76.29.1. DNS-ALG would use the Binding to replace 10.0.0.7 with 198.76.29.1 and redirect the response packet to the external host. At this point, until Host-Y initiates the application with Host-X, the NAT device will not have any NAT Sessions using this Binding. The Binding will however stay alive and not expire until the idle timeout setting. > In particular, consider that a session timeout of 5 minutes and a > binding timeout of 5 minutes, is abstracted away with a mapping timeout > of 10 minutes. [suresh] That is an implementation choice, though not advised. The above implementation choice is possible only in some cases with UDP NAT Sessions. But, it would be wrong to do this with TCP NAT Sessions. TCP NAT sessions have distinct connect, runtime and closing states. So, it woudl be a security violation to keep the TCP NAT Session alive much after the end-2-end session expired in one of "connect phase" or "Closing phase", just to keep the TCP Port Binding alive. > So it is not true that more timers make it more general. > [suresh] Please see my notes above. You do need two idle timers. Idle timeout for Binding is somewhat akin to what DHCP does after lease expiry. DHCP servers often retain an IP address association with a PC's MAC address for a period of time, even after the lease had expired. Some NAT devices retain Bindings for longer duration even when there are no NAT Sessions using it. cheers, suresh > -- > Saikat > From jdrosen@cisco.com Mon, 25 Jul 2005 08:59:13 -0700 (PDT) From: Jonathan Rosenberg Date: Mon, 25 Jul 2005 08:59:13 -0700 (PDT) Subject: [Ietf-behave] draft-ietf-behave-rfc3489bis-02 Message-ID: <42E50C13.9000803@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Has been submitted: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-02.txt the only change was an update of the boilerplate. Once ICE work settles down a bit, I'll be able to add some text to STUN that relaxes some of the constraints needed by ICE. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From audet@nortel.com Mon, 25 Jul 2005 09:14:16 -0700 (PDT) From: "Francois Audet" Date: Mon, 25 Jul 2005 09:14:16 -0700 (PDT) Subject: [Ietf-behave] draft-ietf-nat-udp-03 Message-ID: <1ECE0EB50388174790F9694F77522CCF037376B4@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain The UDP Behave document has been updated, reflecting the latest agreements from the list: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-03.txt ---- Franois AUDET, Nortel Networks mailto:audet@xxxxxxxxxx From sg266@cornell.edu Mon, 25 Jul 2005 18:29:05 -0700 (PDT) From: Saikat Guha Date: Mon, 25 Jul 2005 18:29:05 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050722200316.9829.qmail@web33302.mail.mud.yahoo.com> Message-ID: <1122341334.5636.87.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-07-22 at 13:03 -0700, Pyda Srisuresh wrote: > [suresh] Here is an example with DNS ALG, where an idle timeout for an Address > Binding is required independent of the idle timeout for associated NAT > Sessions. Equivalently, the NAT can create a "mapping" when the DNS query is made and can associate the mapping timer with it. That said, the implementation of ALG's is out of scope of this draft. If the NAT needs to implement bindings to support the DNS-ALG, it is welcome to do so. > Idle timeout for Binding is somewhat akin to what DHCP does after lease > expiry. > DHCP servers often retain an IP address association with a PC's MAC address > for > a period of time, even after the lease had expired. Agreed. Can you point me to a RECOMMENDATION or a MUST clause that asks DHCP servers to do so? > Some NAT devices retain > Bindings for longer duration even when there are no NAT Sessions using it. ... and they certainly are more than welcome to continue to do so. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00078.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00078.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzVaSFduRmx0cWk2OTEvb1JBdEtLQUo5V3VKNkRGTUpWUldKdTlwUnF1 WlJBQ0NQajh3Q2RGNE5hClVpS2d5bmc5QXBIaXRpV1VmcnNFUC9rPQo9TFY5SwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From karlheinz.wurm@skype.net Tue, 26 Jul 2005 01:32:36 -0700 (PDT) From: Karlheinz Wurm Date: Tue, 26 Jul 2005 01:32:36 -0700 (PDT) Subject: [Ietf-behave] New attendee In-Reply-To: <20050722200316.9829.qmail@web33302.mail.mud.yahoo.com> Message-ID: <42E68241.6060609@skype.net> MIME-Version: 1.0 Content-Type: text/plain Hi everyone, I am new in the B E H A V E mail group and want to support it with all the necessary research. It would be nice if someone can give me a quick briefing in what work are already done and what research still have to be done. My special interest is in symmetric NAT 's or bad behave NAT's. I want to find out, how the different NAT vendors allocate there ports in order to create a common pattern and get a better port "prediction" for the hole punching process. Maybe there is already some work done. I would be very thankful for any kind of source in this topic. Hope we can get some work done. regards, Karlheinz Wurm From sg266@cornell.edu Tue, 26 Jul 2005 02:21:22 -0700 (PDT) From: Saikat Guha Date: Tue, 26 Jul 2005 02:21:22 -0700 (PDT) Subject: Re: [Ietf-behave] New attendee In-Reply-To: <20050722200316.9829.qmail@web33302.mail.mud.yahoo.com> Message-ID: <1122369669.5745.23.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Karlheinz, Glad to have you onboard. Below is a collection of links to get you started. The UDP NAT standards draft is nearing consensus (hot on the mailing list), a bunch of TCP drafts and measurement studies are available and work on multicast standardization has just recently been started. I believe, some ICMP behavior has been moved out of UDP draft and is search for a new home. On Tue, 2005-07-26 at 11:34 -0700, Karlheinz Wurm wrote: > a quick > briefing in what work are already done and what research still have to > be done. Mail archives: http://list.sipfoundry.org/archive/ietf-behave/ and a really old status update: o http://list.sipfoundry.org/archive/ietf-behave/msg00311.html UDP: - WG draft: draft-ietf-behave-nat-udp-03.txt - Some research/measurements: o draft-jennings-behave-test-results-01.txt o http://www.brynosaurus.com/pub/net/p2pnat/ TCP: - Proposed WG drafts: o draft-sivakumar-behave-nat-tcp-req-01.txt o draft-hoffman-behave-tcp-02.txt o draft-modadugu-nat-tcp-00.txt - Some research/measurements: o http://www.guha.cc/~saikat/stunt-results.php (http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf) o http://www.brynosaurus.com/pub/net/p2pnat/ Multicast, SCTP, Gen etc drafts: https://datatracker.ietf.org/public/pidtracker.cgi? command=search_list&sub_state_id=6&search_filename=behave&search_button=SEARCH IETF 62 Minutes and presentations: o http://ietf.cse.ucsc.edu/behave/behave62/ o https://datatracker.ietf.org/public/proceeding_interim.cgi? meeting_num=62 ... look for BEHAVE cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00079.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00079.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzVnQ0ZuRmx0cWk2OTEvb1JBcEs5QUp3SW5LRVkrSG5ia0JKZ2N0QzZm d0syR2d5Z0NnQ2ZZWlA5ClgvSElaSWFNZWlxZHlxWHZtbnZ5MURVPQo9ekdJRAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From fluffy@cisco.com Tue, 26 Jul 2005 13:42:21 -0700 (PDT) From: Cullen Jennings Date: Tue, 26 Jul 2005 13:42:21 -0700 (PDT) Subject: [Ietf-behave] Draft BEHAVE agenda IETF 63 Message-ID: MIME-Version: 1.0 Content-Type: text/plain So far there has been very few agenda requests. The basic structure of the meeting is to try to solve issues to make progress on our WG milestones. If people wish to address specific issues or wish to present on these items, please let the chairs know. This agenda will most likely be changing as we get closer. Cullen & Jiri Behavior Engineering for Hindrance Avoidance WG (behave) TUESDAY, August 2, 1630-1800 Afternoon Session II ======================================================== CHAIRS: Jiri Kuthan Cullen Jennings AGENDA: (Last revised July 26) - Agenda Bashing, Bluesheets, Note-takers (5 min) UDP Open Issues (25 min) - Resolve any open issues with moving UDP draft forward draft-ietf-behave-nat-udp-03 Francois Audet TCP Protocol and Document Issues (30 min) - Resolved open issues on how TCP should work - suggestions to get to WG document draft-hoffman-behave-tcp-02.txt draft-sivakumar-behave-nat-tcp-req-01.txt Test Framework Issues (15 min) - what do we want to test draft-jennings-behave-test-results-01 Application Behavior Documents (15 min) - what does this document need to say draft-ford-behave-app-00.txt draft-wing-behave-symmetric-rtprtcp-01 From srisuresh@yahoo.com Tue, 26 Jul 2005 20:14:24 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 26 Jul 2005 20:14:24 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1122341334.5636.87.camel@localhost.localdomain> Message-ID: <20050727031423.3405.qmail@web33308.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Fri, 2005-07-22 at 13:03 -0700, Pyda Srisuresh wrote: > > [suresh] Here is an example with DNS ALG, where an idle timeout for an > Address > > Binding is required independent of the idle timeout for associated NAT > > Sessions. > > Equivalently, the NAT can create a "mapping" when the DNS query is made > and can associate the mapping timer with it. > [suresh] When DNS query is made, the TCP/UDP DNS qeury session is between the query initiator and the DNS Server. Neither of the endpoitns has anything to do with the hostname (Host-X) for which the DNS query was made. What do you mean by "the NAT can create a mapping when DNS query is made"? What is mapping here? Is that a Binding or a NAT Session? What are the endpoints you are talking about in mapping? Further, NAT, by definition, does not touch payloads. ALGs do. When DNS_ALG requests the NAT to create a Binding, the NAT may do so, if it knows to create Bindings. I did all I could to explain the need to distinguish between Binding and NAT Session. Seeing your above response, it seems, I am going nowhere. Enough said. > That said, the implementation of ALG's is out of scope of this draft. If > the NAT needs to implement bindings to support the DNS-ALG, it is > welcome to do so. > [suresh] Support for DNS-ALG is a SHOULD. cheers, suresh From sg266@cornell.edu Tue, 26 Jul 2005 23:13:27 -0700 (PDT) From: Saikat Guha Date: Tue, 26 Jul 2005 23:13:27 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050727031423.3405.qmail@web33308.mail.mud.yahoo.com> Message-ID: <1122444792.6170.15.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-07-26 at 20:14 -0700, Pyda Srisuresh wrote: > What is mapping here? At the risk of beating a dead horse, "mapping" is (as defined in the draft) "the translation between an external address and port and an internal address and port". > Is that a Binding or a NAT Session? Depending on the implementation; it can be either. It can be implemented as a 4-tuple that you would call a "binding" or a 7-tuple that you would call a "NAT session" (with garbage values for the fields that it doesn't have values for) or even with a consistent hash function. Doesn't matter. The functionality is the same one way or the other. The only difference, that I've pointed out repeatedly, is the "binding timer". If you implement mappings with 4-tuples, it makes sense to talk of a separate binding timer. If you implement it with only 7-tuples then the binding timer is implicitly fixed at zero. If you implement it with a consistent hashing function, the binding timer is infinite (modulo collisions). The draft does not specify a fixed binding timer. -- Saikat (who'll shut up now. :-p) Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00080.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00080.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzV5WDRuRmx0cWk2OTEvb1JBbXYxQUowWkgrZHpUQVZKeUpPSVJsUWlT YStpRnR2eVN3Q2ZTS1RoCjZCZEhDTml0Zm5CbFl5d0paNGthaWZNPQo9QzNRLwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From baford@mit.edu Thu, 28 Jul 2005 03:33:26 -0700 (PDT) From: Bryan Ford Date: Thu, 28 Jul 2005 03:33:26 -0700 (PDT) Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050717220514.53272.qmail@web33303.mail.mud.yahoo.com> Message-ID: <200507281233.36764.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Trying to catch up after several weeks of Internet-less travel, I notice that Linux seems to be getting thrown around as an example of "good" NAT... On Monday 18 July 2005 06:06, Saikat Guha wrote: > Instead, let me point you to the Linux source that: > 1. DOES NOT use bindings > 2. DOES NOT use a binding timer > 3. Is a NAT that is behave compliant > 4. Would _appear_ to use bindings and a binding timeout of 0 but DOES > NOT Perhaps your information is newer than mine, but at least as of a few months ago, the Linux NAT implementation is actually *NOT* BEHAVE-compliant; it only pretends very hard to be so, and thus usually passes as "Cone NAT" in STUN-like behavior tests. But it does not always exhibit cone NAT behavior - i.e., it is one of our hated nondeterministic beasts, only it's a little more subtle than most nondeterministic NATs. Here is what Linux actually does, according to what I was told a while ago directly by one of the developers of Linux's NAT implementation. When an outgoing packet causes a new NAT session A to be set up from internal address/port X:x to external endpoint Y:y, the NAT more-or-less arbitrarily chooses a public port X':x' for the new session such that the external session tuple (X':x',Y:y) is not already in use. Linux DOES NOT however _reserve_ the public port x' for exclusive use as the public endpoint corresponding to private endpoint X:x - i.e., it does not create a binding. Now when the NAT sees another outgoing packet from the same internal endpoint X:x to a new external endpoint Z:z, the NAT _tries_ to re-use the previously-allocated public port X':x' in creating the new NAT session between X:x and Z:z, but only succeeds if the external session tuple (X':x',Z:z) does not already happen to be in use. USUALLY, this external session tuple will not already be in use, and so Linux's NAT generally looks like a Cone NAT to testing tools. But it's also entirely possible that some completely unrelated NAT session, say from internal endpoint Q:q to external endpoint Z:z, has already been assigned public port X':x' and hence has allocated the external session tuple (X':x',Z:z), making it unavailable for the new session X:x is attempting to open to Z:z. In this case Linux chooses a new random public port X':x'' for the new session from X:x, and suddenly starts behaving like a Symmetric NAT (i.e., bad). Note that this particular form of bad (non-BEHAVE-compliant) behavior will not typically show up except when the NAT is under heavy load, and as far as I can tell there is easy "black-box" test for this kind of behavior other than by deliberately putting the NAT box under heavy load for some period of time using a large number of simultaneous connections. Furthermore, from an application's perspective, the Linux NAT's behavior is about as evilly nondeterministic as imaginable: an application might successfully use its internal UDP port to hole-punch fifteen connections to different external hosts, and then fail on the sixteenth (i.e., our "unlucky" external host Z). Furthermore, even after failing to connect with host Z, the application might still go on and successfully hole-punch to many other hosts - but Z will remain persistently inaccessible as long as the particular external session tuple needed (X':x',Z:z) is still in use by that unrelated NAT session between Q:q and Z:z. In other words, when the Linux NAT falls into "symmetric mode" due to port allocation conflicts, it appears to the application as if certain external hosts are (inexplicably) inaccessible via hole punching, even if they are known to be alive via other information channels and hole punching works fine for many other hosts. And since the NAT behaves like a Cone NAT "most of the time", even a "smart" application that tries to work around typical (dumb, predictable) Symmetric NAT implementations will not be able to work around Linux's Symmetric NAT. As I said above, perhaps my information about Linux's NAT is outdated and this behavior has subsequently been fixed in the last few months - if so, I would appreciate a pointer to any relevant information. But assuming the above description of Linux's behavior is still accurate, it is certainly not appropriate to hold up Linux as a model for a "binding-free BEHAVE-compliant NAT". In fact, it reinforces the reasons why the BEHAVE documents NEED to talk explicitly about bindings - because NOT talking about them and NOT explicitly defining a clear operational model for NAT is just asking for all kinds of "near-compliant but nondeterministic" implementations similar to Linux's NAT. To reiterate: to my knowledge Linux's NAT is _NOT_ fully BEHAVE-compliant, precisely because it DOES NOT use port bindings to reserve public ports to the exclusive use of particular internal endpoints when the first outgoing connection is seen from that endpoint. Bryan From baford@mit.edu Thu, 28 Jul 2005 03:43:12 -0700 (PDT) From: Bryan Ford Date: Thu, 28 Jul 2005 03:43:12 -0700 (PDT) Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1ECE0EB50388174790F9694F77522CCF035BD1B3@zrc2hxm0.corp.nortel.com> Message-ID: <200507281243.22775.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 19 July 2005 23:32, Francois Audet wrote: > Right. > > Using bindings is a perfectly reasonable way of implementing this, and > people are free to do it. > > But the mandate of the BEHAVE group is NOT to mandate specific > technologies for implementation. This is why the language in the > draft keeps it at a higher level (i.e., using "mapping" instead > of "binding"). If by "higher level" you mean "vague and nowhere explicitly defined", then I agree. Judging from recent discussion there is still rampant confusion about which uses of the term "mapping" in the draft refer to something binding-ish and which uses refer to something session-ish. At least the terms Binding, Session, and NAT Session have very clear definitions with well-established precedent; as far as I can tell mapping is just a verb. Bryan From sg266@cornell.edu Thu, 28 Jul 2005 03:49:11 -0700 (PDT) From: Saikat Guha Date: Thu, 28 Jul 2005 03:49:11 -0700 (PDT) Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1ECE0EB50388174790F9694F77522CCF035BD1B3@zrc2hxm0.corp.nortel.com> Message-ID: <1122547736.5860.2.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-07-28 at 12:43 +0200, Bryan Ford wrote: > This is why the language in the > > draft keeps it at a higher level (i.e., using "mapping" instead > > of "binding"). > > If by "higher level" you mean "vague and nowhere explicitly defined", then I > agree. As far as I understand, draft-ietf-behave-nat-udp-03.txt line 247 defines it fairly explicitly. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00081.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00081.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzZMZ1luRmx0cWk2OTEvb1JBdC85QUo5dTZUS3NjMWhMZmdmTE5qaGp3 cTZWKzZYdmNRQ2RHZEJLCllDMFJPdytVcUhFWDZHV2tGM0ptRW1nPQo9S3FTNQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From baford@mit.edu Thu, 28 Jul 2005 04:10:54 -0700 (PDT) From: Bryan Ford Date: Thu, 28 Jul 2005 04:10:54 -0700 (PDT) Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050727031423.3405.qmail@web33308.mail.mud.yahoo.com> Message-ID: <200507281311.04915.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 27 July 2005 08:13, Saikat Guha wrote: > On Tue, 2005-07-26 at 20:14 -0700, Pyda Srisuresh wrote: > > What is mapping here? > > At the risk of beating a dead horse, "mapping" is (as defined in the > draft) "the translation between an external address and port and an > internal address and port". OK, then what exactly is "a translation", in its usage above as a noun? It's pretty obvious that NATs somehow, at some point, "translate" internal addresses and port numbers into external addresses and port numbers - but what exactly is _a_translation_? Does "the translation" refer to the NAT's momentary action of translating the addresses in a packet as it crosses the wire? Obviously not; the pervasive usage of "mapping" and "translation" throughout the document imply that a "mapping" or "translation" is some kind of persistent abstract entity, but the document never clearly defines what that entity is. And to good reason: because _sometimes_ "mapping" refers to the abstract entity defined in prior RFCs as "binding", and _some (other) times_ "mapping" refers to the abstract entity defined in prior RFCs as "Session" or "NAT Session". In other words, it's just a dysfunctional term that's inadequately trying to play the role of multiple existing and perfectly well-defined terms. The current pseudo-definition of "mapping" in the UDP draft is simply circular. Bryan From sg266@cornell.edu Thu, 28 Jul 2005 04:15:30 -0700 (PDT) From: Saikat Guha Date: Thu, 28 Jul 2005 04:15:30 -0700 (PDT) Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050717220514.53272.qmail@web33303.mail.mud.yahoo.com> Message-ID: <1122549312.5860.25.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-07-28 at 12:33 +0200, Bryan Ford wrote: > When an > outgoing packet causes a new NAT session A to be set up from internal > address/port X:x to external endpoint Y:y, the NAT more-or-less arbitrarily > chooses a public port X':x' for the new session such that the external > session tuple (X':x',Y:y) is not already in use. Linux DOES NOT however > _reserve_ the public port x' for exclusive use as the public endpoint > corresponding to private endpoint X:x - i.e., it does not create a binding. If it does not reserve x' as you say, then it violates REQ-3 ... i.e. it performs port overloading where an external port already allocated to a particular internal endpoint may potentially be used for a different endpoint. But as far as I understand, Linux does NOT do port overloading and the external port can indeed be used only by the internal endpoint that caused its creation (as long as there is one live connection from that internal endpoint). See (ip_nat_core.c#L248 => ip_nat_core.c#L86 => ip_conntrack_core.c#L396 => ip_conntrack_core.c#L291 => ip_conntrack_core.c#L281 => ip_conntrack_tuple.h#L127) where it explicitly makes sure it doesn't overload a port. In fact, going back in the kernel source to more than 2 years (version 2.4.18), I still see the same behavior -- no overloading (#L435). So either your information is really outdated or your friend didn't understand your question. Here is what I think your friend could have meant: 1. Linux allocates X':x' when the internal port X:x connects to Y:y 2. As long as any such above mapping is alive, Linux is _guaranteed_ to allocate X':x' to all new connection initiations form internal port X:x 3. But if all the above mappings expire, Linux does not reserve X':x' for X:x per say. 4. It uses consistent hashing so most of the time, later on, when X:x initiates a new connections it gets X':x' (mind you X:x has no live connections before this). 5. Sometimes there can be a collision where another external host A:a hashes to X':x' as well. Since no connection is using X':x', linux will allocate that. After this, if X:x initiates a connection, the hash will collide and it'll be allocated something else. Perhaps you can reconfirm this interpretation from your friend. But as the source looks now (and even 2 years ago), the condition you mentioned where suddenly your 16th connection may get a different address is simply NOT possible ... as long as any one of the previous 15 connections is still alive. Given the necessity of some non determinism needed to avoid port overloading, Linux IS behave compliant as far as port allocation is concerned. -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00082.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00082.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzZMNUFuRmx0cWk2OTEvb1JBc3FYQUowWXI1aHRoQ3p2Rm1BOHJtV0dn dk9peUNWc1F3Q2ZlTU42CjJ3OC9OOUF2QXh3bEFUdFBSOG1FUko4PQo9RjN3QQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From remi.denis-courmont@nokia.com Thu, 28 Jul 2005 04:25:10 -0700 (PDT) From: Remi Denis-Courmont Date: Thu, 28 Jul 2005 04:25:10 -0700 (PDT) Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050717220514.53272.qmail@web33303.mail.mud.yahoo.com> Message-ID: <1122549904.3869.7.camel@hed040-040103.research.nokia.com> MIME-Version: 1.0 Content-Type: text/plain Hello, Le jeu 28/07/2005 à 13:33, ext Bryan Ford a écrit : > In other words, when the Linux NAT falls into "symmetric mode" due to port > allocation conflicts, it appears to the application as if certain external > hosts are (inexplicably) inaccessible via hole punching, even if they are > known to be alive via other information channels and hole punching works fine > for many other hosts. And since the NAT behaves like a Cone NAT "most of the > time", even a "smart" application that tries to work around typical (dumb, > predictable) Symmetric NAT implementations will not be able to work around > Linux's Symmetric NAT. FYI, my personal experience with Linux/NetFilter was that it also showed this symmetric behavior on an almost systematic basis when the firewall part of NetFilter was configured to "accept" unexpected UDP traffic from the outside, and that traffic happened to have the allocated port as a destination. Linux would then reject the packet with ICMP Port Unreachable and record a conflicting association of this port with itself (ie. the NAT box) as a destination, instead of the user behind the NAT. In particular, this is particularly problematic with STUN or Teredo where the outside server typically (purposedly) sends packets to the same UDP port on the NAT, but from different IP addresses. In other words, one should always set up a Linux NAT to DROP incoming UDP unknown traffic to ports that can be used for MASQUERADE. -- Rémi Denis-Courmont Nokia Summer Trainee Nokia-NRC/Helsinki From baford@mit.edu Thu, 28 Jul 2005 04:30:32 -0700 (PDT) From: Bryan Ford Date: Thu, 28 Jul 2005 04:30:32 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-nat-udp-03 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF037376B4@zrc2hxm0.corp.nortel.com> Message-ID: <200507281330.39645.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain Hi Francois, I see the new UDP draft still has REQ-5(a) as a MAY. > REQ-5 A NAT UDP mapping timer MUST NOT expire in less than 2 > minutes. > a) The value of the NAT UDP mapping timer MAY be configurable. > b) A default value of 5 minutes for the NAT UDP mapping timer > is RECOMMENDED. As per the poll I called on June 27, the majority of those who have expressed an opinion on this issue appear to favor SHOULD. From the original poll: >SHOULD: 3 - me, David, Suresh >MAY: 2 - you (presumably), Saikat No one else subsequently responded with corrections or additions to the tally, except David Barrett to re-confirm his strong preference for SHOULD. I therefore request that the next version of the UDP draft be adjusted to reflect this majority preference, at least until such a point as some kind of true consensus might be reached on this issue. Thanks, Bryan From sg266@cornell.edu Thu, 28 Jul 2005 04:36:44 -0700 (PDT) From: Saikat Guha Date: Thu, 28 Jul 2005 04:36:44 -0700 (PDT) Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050727031423.3405.qmail@web33308.mail.mud.yahoo.com> Message-ID: <1122550591.5860.45.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-07-28 at 13:11 +0200, Bryan Ford wrote: > On Wednesday 27 July 2005 08:13, Saikat Guha wrote: > > On Tue, 2005-07-26 at 20:14 -0700, Pyda Srisuresh wrote: > > > What is mapping here? > > > > At the risk of beating a dead horse, "mapping" is (as defined in the > > draft) "the translation between an external address and port and an > > internal address and port". > > OK, then what exactly is "a translation", in its usage above as a noun? Not to be pedantic, but just for clarity: mapping n. 1. A function such that for every element of one set there is a unique element of another set function n. 1. A variable so related to another that for each value assumed by one there is a value determined for the other. translation n. 2. A translated version of a text. Reading the draft, I take mapping to mean the abstract mathematical notion of a mapping or a function or a translation. The input to this mathematical function is the internal IP and port and the output is the external IP and port to use. One example would be a hash function. The NAT has infinite (well not quite) choices of defining such a function. An input IP:Port X:x can be "mapped" to f1(X:x) => X':x' f2(X:x) => Y':y' f3(X:x) => Z':z' ... so on. When it sees the packet, it must choose one and only of these. That fixes how the NAT maps X:x in the near future. Next time it sees a new packet from the same internal endpoint but to a different remote host, it no longer has the freedom of choosing a new mapping -- it must reuse the mapping it committed itself to earlier (as per the draft). It continues to reuse it as long as even a single connection is alive that is using that mapping. As long as a mapping is alive, the NAT is forbidden from choosing a mapping for a different endpoint that has the same output (external IP/port). This is enforced by the port overloading requirement. What happens after all connections stop using the mapping is left undefined. The NAT can reserve the unused mapping for some idle time, or it may discard it instantly and allow it to be chosen for other internal hosts. The draft doesn't say what happens after all connections stop using the mapping. -- Saikat (who really really tried to honor his last vow to shut up. :( ) Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00083.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00083.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzZNTS9uRmx0cWk2OTEvb1JBam1RQUo0cmZNKzcvM3ROM3R6OGEyY2U2 c0Q1NEdVRTF3Q2VPRnJnClRPbjd3QTFIdGlTNURGcnU2ZGVscFJnPQo9c25OUgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From audet@nortel.com Thu, 28 Jul 2005 10:05:58 -0700 (PDT) From: "Francois Audet" Date: Thu, 28 Jul 2005 10:05:58 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <1ECE0EB50388174790F9694F77522CCF037F743A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Bryan, we have asked many times to show us exactly WHERE the word "mapping" is used erroneously. We have tried to correct mistakes if there are any mistakes. And I think we did. But we keep getting pages of diatribe on why we should be using the -gen draft instead, and base the whole document on the concept of bindings. We are using the term "mapping" the same way the NAT terminology RFCs use it: RFC 2263, 3022, 3027 (all co-authored by Srisuresh I might add). It's nothing new: it's established terminology. We have also decided to not get into the whole "binding" issue because it doesn't seem to be useful, and not necessarily clear to everybody. NATs that are using "bindings" are not the ones that are causing the worst problems (as you point out all the time). The people who are not using bindings at the ones that need more help. The problem is they might not know that they are not using bindings. It is not the mandate of BEHAVE-UDP to say "YOU MUST USE BINDINGS", even if it probably the best way to not get in trouble. So again, if you can briefly describe exactly WHERE we use "mapping" improperly, and how to change wording without getting into the "binding" issue, it would be helpful. At this point, nobody else seems to be seeing the issue. > -----Original Message----- > From: Bryan Ford [mailto:baford@xxxxxxx] > Sent: Thursday, July 28, 2005 03:43 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Cc: Audet, Francois [SC100:9T51:EXCH]; Saikat Guha; Senthil > Sivakumar (ssenthil) > Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > > On Tuesday 19 July 2005 23:32, Francois Audet wrote: > > Right. > > > > Using bindings is a perfectly reasonable way of > implementing this, and > > people are free to do it. > > > > But the mandate of the BEHAVE group is NOT to mandate specific > > technologies for implementation. This is why the language > in the draft > > keeps it at a higher level (i.e., using "mapping" instead of > > "binding"). > > If by "higher level" you mean "vague and nowhere explicitly > defined", then I > agree. Judging from recent discussion there is still rampant > confusion about > which uses of the term "mapping" in the draft refer to > something binding-ish > and which uses refer to something session-ish. At least the > terms Binding, > Session, and NAT Session have very clear definitions with > well-established > precedent; as far as I can tell mapping is just a verb. > > Bryan > > From audet@nortel.com Thu, 28 Jul 2005 10:08:26 -0700 (PDT) From: "Francois Audet" Date: Thu, 28 Jul 2005 10:08:26 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-nat-udp-03 Message-ID: <1ECE0EB50388174790F9694F77522CCF037F7445@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain This is why it is marked as OPEN issue. We will look at it in Paris. > -----Original Message----- > From: Bryan Ford [mailto:baford@xxxxxxx] > Sent: Thursday, July 28, 2005 04:31 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Cc: Audet, Francois [SC100:9T51:EXCH] > Subject: Re: [Ietf-behave] draft-ietf-nat-udp-03 > > > Hi Francois, > > I see the new UDP draft still has REQ-5(a) as a MAY. > > > REQ-5 A NAT UDP mapping timer MUST NOT expire in less than 2 > > minutes. > > a) The value of the NAT UDP mapping timer MAY be > configurable. > > b) A default value of 5 minutes for the NAT UDP > mapping timer > > is RECOMMENDED. > > As per the poll I called on June 27, the majority of those > who have expressed > an opinion on this issue appear to favor SHOULD. From the > original poll: > > >SHOULD: 3 - me, David, Suresh > >MAY: 2 - you (presumably), Saikat > > No one else subsequently responded with corrections or > additions to the tally, > except David Barrett to re-confirm his strong preference for > SHOULD. I > therefore request that the next version of the UDP draft be > adjusted to > reflect this majority preference, at least until such a point > as some kind of > true consensus might be reached on this issue. > > Thanks, > Bryan > > From sg266@cornell.edu Thu, 28 Jul 2005 16:07:48 -0700 (PDT) From: Saikat Guha Date: Thu, 28 Jul 2005 16:07:48 -0700 (PDT) Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <20050717220514.53272.qmail@web33303.mail.mud.yahoo.com> Message-ID: <1122592052.5860.96.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630134.multipart/signed" --Boundary..27398.1163630134.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, On Thu, 2005-07-28 at 14:25 +0300, Remi Denis-Courmont wrote: > when the firewall > part of NetFilter was configured to "accept" unexpected UDP traffic from > the outside I am not sure I understand this. By accept, do you mean that inbound traffic would sent up the UDP stack of the NAT when there was no mapping at that port? > , and that traffic happened to have the allocated port as a > destination. Linux would then reject the packet with ICMP Port > Unreachable So if internal X:x (mapped to X':x') sent a packet to Y':y' and Z':z' sent a packet to X':x', then it would cause a ICMP Port Unreachable because the NAT checks for local apps running on x' and does not check the mappings? Wouldn't that appear as an EF=AP NAT (or a restricted NAT); I think Bryan's UDP measurements put Linux in the Full Cone/EF=I category? Then again I wouldn't be surprised if there was some compile time/runtime config option that could change this behavior. > In other words, one should always set up a Linux NAT to DROP incoming > UDP unknown traffic to ports that can be used for MASQUERADE. Interesting. Thanks. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630134.multipart/signed Content-Type: application/octet-stream; name="pgp00084.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00084.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCQzZXVTBuRmx0cWk2OTEvb1JBZ0NpQUo5U0Y3dFJVS1RoTzNGY1FGYVNo NnZ5WER1WG1nQ2VQUzhNCnJBcXpRT0tRT2FWaEpBRG42aDJ5T0lnPQo9ZGdnTAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630134.multipart/signed-- From srisuresh@yahoo.com Fri, 29 Jul 2005 10:01:42 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 29 Jul 2005 10:01:42 -0700 (PDT) Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <1122547736.5860.2.camel@localhost.localdomain> Message-ID: <20050729170142.98245.qmail@web33310.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Thu, 2005-07-28 at 12:43 +0200, Bryan Ford wrote: > > This is why the language in the > > > draft keeps it at a higher level (i.e., using "mapping" instead > > > of "binding"). > > > > If by "higher level" you mean "vague and nowhere explicitly defined", then > I > > agree. > > As far as I understand, draft-ietf-behave-nat-udp-03.txt line 247 > defines it fairly explicitly. > [suresh] Use of the term "mapping" is inconsitent and far from clear throughout the document. You had claimed in several of your e-mails that Maping is same is Binding. Yet, the draft, right after line 247 says Mappign is not same as Binding. So much for the definition matching your understanding. The same term is used to mean NAt Session in REQ-5. Further, In the mail dated 07/26, when asked what Mapping is, you said it can be either Binding or NAT Session, depending upon implementation. That the term carries different semantics depending upon implmentation and context of its use is precisely the problem with the term. This is what Bryan is referign to as vague. Below is the quote from 07/26 e-mail to jog your memory. Suresh:: > Is that a Binding or a NAT Session? Sakat:: Depending on the implementation; it can be either. Now, the second half of bryan's e-mail, which you omitted in your response, is really the crux. I will quote the text below for convenient reference. "At least the terms Binding, Session, and NAT Session have very clear definitions with well-established precedent; as far as I can tell mapping is just a verb." Why not use terms that have clear definition, carry precise semantics and have established precedence to describe BEHAVE requirements? That is really the question. The terms "Binding" and "NAT Session" are consitent with earlier NAT RFCs, implementation independent and adequate to describe BEHAVE requirements. ford-behave-gen and sivakumar-behave-nat-tcp are testaments to that. Both these drafts have used the terms Binding and NAT Session to derive BEHAVE requirements. It is trivial to do the same wiht behave-udp. cheers, suresh > -- > Saikat > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From audet@nortel.com Fri, 29 Jul 2005 10:26:41 -0700 (PDT) From: "Francois Audet" Date: Fri, 29 Jul 2005 10:26:41 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <1ECE0EB50388174790F9694F77522CCF03859113@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I said that MAPPING is NOT the same as BINDING. Everybody tought that your terminology of "binding" and "NAT session" where confusing and therefore we don't use it. I really couldn't care less about emails from months ago. Tell us what specific line in the document are wrong. You are continuing with the pages of diatribe. It is not helpful. We are NOT going to adopt the term NAT session and binding throughout the document. So make sure you explain what is wrong with something better than "this is a NAT session". > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pyda Srisuresh > Sent: Friday, July 29, 2005 10:02 > To: Saikat Guha; Bryan Ford > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > > > > --- Saikat Guha wrote: > > > On Thu, 2005-07-28 at 12:43 +0200, Bryan Ford wrote: > > > This is why the language in the > > > > draft keeps it at a higher level (i.e., using "mapping" > instead of > > > > "binding"). > > > > > > If by "higher level" you mean "vague and nowhere explicitly > > > defined", then > > I > > > agree. > > > > As far as I understand, draft-ietf-behave-nat-udp-03.txt line 247 > > defines it fairly explicitly. > > > > [suresh] Use of the term "mapping" is inconsitent and far > from clear throughout the document. You had claimed in > several of your e-mails that Maping is same is Binding. Yet, > the draft, right after line 247 says Mappign is not same as > Binding. So much for the definition matching your > understanding. The same term is used to mean NAt Session in REQ-5. > > Further, In the mail dated 07/26, when asked what Mapping is, > you said it can be either Binding or NAT Session, depending > upon implementation. That the term carries different > semantics depending upon implmentation and context of its use > is precisely the problem with the term. This is what Bryan is > referign to as vague. Below is the quote from 07/26 e-mail to > jog your memory. > > Suresh:: > Is that a Binding or a NAT Session? > Sakat:: Depending on the implementation; it can be either. > > Now, the second half of bryan's e-mail, which you omitted in > your response, is really the crux. I will quote the text > below for convenient reference. > > "At least the terms Binding, Session, and NAT Session have > very clear definitions with well-established precedent; as > far as I can tell mapping is just a verb." > > Why not use terms that have clear definition, carry precise > semantics and have established precedence to describe BEHAVE > requirements? That is really the question. The terms > "Binding" and "NAT Session" are consitent with earlier NAT > RFCs, implementation independent and adequate to describe > BEHAVE requirements. ford-behave-gen and > sivakumar-behave-nat-tcp are testaments to that. Both these > drafts have used the terms Binding and NAT Session to derive > BEHAVE requirements. It is trivial to do the same wiht behave-udp. > > cheers, > suresh > > -- > > Saikat > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From ssenthil@cisco.com Fri, 29 Jul 2005 11:23:14 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Fri, 29 Jul 2005 11:23:14 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB6E6431@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Francois Audet > Sent: Friday, July 29, 2005 1:27 PM > To: Pyda Srisuresh; Saikat Guha; Bryan Ford > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > I said that MAPPING is NOT the same as BINDING. > > Everybody tought that your terminology of "binding" and "NAT > session" where confusing and therefore we don't use it. > [Senthil] Who is everybody? I haven't seen anyone complaining the above terminology as confusing. Instead what I have heard is that why should n't we continue to use the current terminology. The real audience these documents are targetted towards should not get confused. That should be the goal of the WG and the drafts this WG produces. If a implementer/tester reads this document (who is going to implement/test the recommendations) it should be clear on what a binding/mapping/session means. Apparently these lengthy and argumentative email threads indicate that such clarity does not exist today in the document. Senthil > I really couldn't care less about emails from months ago. > > Tell us what specific line in the document are wrong. You are > continuing with the pages of diatribe. It is not helpful. > > We are NOT going to adopt the term NAT session and binding > throughout the document. So make sure you explain what is > wrong with something better than "this is a NAT session". > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Pyda > > Srisuresh > > Sent: Friday, July 29, 2005 10:02 > > To: Saikat Guha; Bryan Ford > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh > > > > > > > > > > --- Saikat Guha wrote: > > > > > On Thu, 2005-07-28 at 12:43 +0200, Bryan Ford wrote: > > > > This is why the language in the > > > > > draft keeps it at a higher level (i.e., using "mapping" > > instead of > > > > > "binding"). > > > > > > > > If by "higher level" you mean "vague and nowhere explicitly > > > > defined", then > > > I > > > > agree. > > > > > > As far as I understand, draft-ietf-behave-nat-udp-03.txt line 247 > > > defines it fairly explicitly. > > > > > > > [suresh] Use of the term "mapping" is inconsitent and far > from clear > > throughout the document. You had claimed in several of your e-mails > > that Maping is same is Binding. Yet, the draft, right after > line 247 > > says Mappign is not same as Binding. So much for the definition > > matching your understanding. The same term is used to mean > NAt Session > > in REQ-5. > > > > Further, In the mail dated 07/26, when asked what Mapping > is, you said > > it can be either Binding or NAT Session, depending upon > > implementation. That the term carries different semantics depending > > upon implmentation and context of its use is precisely the problem > > with the term. This is what Bryan is referign to as vague. Below is > > the quote from 07/26 e-mail to jog your memory. > > > > Suresh:: > Is that a Binding or a NAT Session? > > Sakat:: Depending on the implementation; it can be either. > > > > Now, the second half of bryan's e-mail, which you omitted in your > > response, is really the crux. I will quote the text below for > > convenient reference. > > > > "At least the terms Binding, Session, and NAT Session have > very clear > > definitions with well-established precedent; as far as I can tell > > mapping is just a verb." > > > > Why not use terms that have clear definition, carry precise > semantics > > and have established precedence to describe BEHAVE > requirements? That > > is really the question. The terms "Binding" and "NAT Session" are > > consitent with earlier NAT RFCs, implementation independent and > > adequate to describe BEHAVE requirements. ford-behave-gen and > > sivakumar-behave-nat-tcp are testaments to that. Both these drafts > > have used the terms Binding and NAT Session to derive BEHAVE > > requirements. It is trivial to do the same wiht behave-udp. > > > > cheers, > > suresh > > > -- > > > Saikat > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Sun, 31 Jul 2005 03:31:28 -0700 (PDT) From: "Cullen Jennings" Date: Sun, 31 Jul 2005 03:31:28 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF031E7551@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I implementer implement it as 10 ms, then path MTU discovery will not work on any path longer than 10 ms from the NAT. I'm not sure I have seen any implementation that were too short so I will have to think about if I actually care if it is there or not. -----Original Message----- From: Francois Audet [mailto:audet@xxxxxxxxxx] Sent: Thursday, July 07, 2005 2:14 AM To: ietf-behave@xxxxxxxxxxxxxxxxxxx; dwing@xxxxxxxxx; Cullen Jennings Cc: Saikat Guha Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt OK, I don't understand the 2s timer either. I'm hearing a bunch of votes for removing requirement c, and I don't have objections. Dan/Cullen, I think this requirement came from you. Objections to removing it from the UDP draft? (Presumable some ICMP document would clarify further any timers requirement for this, as per Saikat's suggestion below). > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Saikat > Guha > Sent: Wednesday, July 06, 2005 16:39 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] FW: I-D > ACTION:draft-ietf-behave-nat-udp-02.txt > > > On Wed, 2005-07-06 at 17:48 -0500, Francois Audet wrote: > > c) The ICMP timeout SHOULD be greater than 2 seconds. > > > > Or are people still questioning c), and if so what would be the > > proposal. > > Perhaps I am just being obtuse, but I really don't understand > requirement c). See my point #10 in > http://list.sipfoundry.org/archive/ietf-behave/msg00759.html > > In any event, I agree with Paul that there should be no timer unless > an RFC for the ICMP protocol defines one for the particular case ... > and I do not know what the particular timer is for so I cannot say > either yay or nay. > > Some timers that might be relevant based on intent: > > Intent #1: Handling an inbound ICMP packet in response to an outbound > TCP/UDP packet -- The maximum time an in-flight packet is considered > alive is 2 minutes (RFC 1122). So it may take at most 4 minutes for > can ICMP to come back. ... But the encapsulated IP packet inside the > ICMP will have all the data needed to route the packet (as long as the > mapping is alive) ... so there is no point specifying the timeout if > this is the intent. > > Intent #2: Preventing packet storms; ICMP rate-limiting -- RFC 2521 > says ICMP's should be rate limited but the timer is "left to the > implementor's discretion". If this is the intent, I'd suggest not > specifying a timer value. > > Intent #3: Handling inbound ICMP's that do not have an encapsulated IP > packet to help routing, such as ICMP Echo Response -- If this is the > intent, it needs to be made clear. > Also, by the same logic as #1, RFC 1122 would say that an ICMP Echo > Response may be received within at most 4 minutes; so that should be > the recommended value of the timer. That said, reiterating Paul's > point -- unless the NAT is low on available "ICMP mappings", it should > not expire any ICMP mapping. If it is low, then it should expire ICMP > mappings that have been open for more than 4 minutes. If that doesn't > free up any mappings, then it should reject the new ICMP packet -- to > prevent an insider from DoS'ing the NAT. > > I think Intent #3 makes most sense logically; and if we are going to > have a separate ICMP draft (as per the charter), thats where this > issue should go. But if we are not, then the intent should be made > more clear. > > -- > Saikat > From fluffy@cisco.com Sun, 31 Jul 2005 03:31:25 -0700 (PDT) From: "Cullen Jennings" Date: Sun, 31 Jul 2005 03:31:25 -0700 (PDT) Subject: RE: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh In-Reply-To: <200507281233.36764.baford@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Interesting - seem like it would be pretty easy to set up a test for that. Perhaps we should add that to the test draft. I'm thinking of a test like two inside IP I1:p, and I2:p. and two stun servers on outside O1:p, and O2:p. The p are the port and all the same. I1 does stun with 01. Now I2 does stun with 02. Then I1 does stun with O2 and check that mapping has not changed. Would this catch it ? Can anyone confirm how Linux chooses the X':x' mapping? If it was random, this test would not work. Cullen (as individual) -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bryan Ford Sent: Thursday, July 28, 2005 12:34 PM To: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] NAT Mapping refresh vs NAT filter refresh Trying to catch up after several weeks of Internet-less travel, I notice that Linux seems to be getting thrown around as an example of "good" NAT... On Monday 18 July 2005 06:06, Saikat Guha wrote: > Instead, let me point you to the Linux source that: > 1. DOES NOT use bindings > 2. DOES NOT use a binding timer > 3. Is a NAT that is behave compliant > 4. Would _appear_ to use bindings and a binding timeout of 0 but DOES > NOT Perhaps your information is newer than mine, but at least as of a few months ago, the Linux NAT implementation is actually *NOT* BEHAVE-compliant; it only pretends very hard to be so, and thus usually passes as "Cone NAT" in STUN-like behavior tests. But it does not always exhibit cone NAT behavior - i.e., it is one of our hated nondeterministic beasts, only it's a little more subtle than most nondeterministic NATs. Here is what Linux actually does, according to what I was told a while ago directly by one of the developers of Linux's NAT implementation. When an outgoing packet causes a new NAT session A to be set up from internal address/port X:x to external endpoint Y:y, the NAT more-or-less arbitrarily chooses a public port X':x' for the new session such that the external session tuple (X':x',Y:y) is not already in use. Linux DOES NOT however _reserve_ the public port x' for exclusive use as the public endpoint corresponding to private endpoint X:x - i.e., it does not create a binding. Now when the NAT sees another outgoing packet from the same internal endpoint X:x to a new external endpoint Z:z, the NAT _tries_ to re-use the previously-allocated public port X':x' in creating the new NAT session between X:x and Z:z, but only succeeds if the external session tuple (X':x',Z:z) does not already happen to be in use. USUALLY, this external session tuple will not already be in use, and so Linux's NAT generally looks like a Cone NAT to testing tools. But it's also entirely possible that some completely unrelated NAT session, say from internal endpoint Q:q to external endpoint Z:z, has already been assigned public port X':x' and hence has allocated the external session tuple (X':x',Z:z), making it unavailable for the new session X:x is attempting to open to Z:z. In this case Linux chooses a new random public port X':x'' for the new session from X:x, and suddenly starts behaving like a Symmetric NAT (i.e., bad). Note that this particular form of bad (non-BEHAVE-compliant) behavior will not typically show up except when the NAT is under heavy load, and as far as I can tell there is easy "black-box" test for this kind of behavior other than by deliberately putting the NAT box under heavy load for some period of time using a large number of simultaneous connections. Furthermore, from an application's perspective, the Linux NAT's behavior is about as evilly nondeterministic as imaginable: an application might successfully use its internal UDP port to hole-punch fifteen connections to different external hosts, and then fail on the sixteenth (i.e., our "unlucky" external host Z). Furthermore, even after failing to connect with host Z, the application might still go on and successfully hole-punch to many other hosts - but Z will remain persistently inaccessible as long as the particular external session tuple needed (X':x',Z:z) is still in use by that unrelated NAT session between Q:q and Z:z. In other words, when the Linux NAT falls into "symmetric mode" due to port allocation conflicts, it appears to the application as if certain external hosts are (inexplicably) inaccessible via hole punching, even if they are known to be alive via other information channels and hole punching works fine for many other hosts. And since the NAT behaves like a Cone NAT "most of the time", even a "smart" application that tries to work around typical (dumb, predictable) Symmetric NAT implementations will not be able to work around Linux's Symmetric NAT. As I said above, perhaps my information about Linux's NAT is outdated and this behavior has subsequently been fixed in the last few months - if so, I would appreciate a pointer to any relevant information. But assuming the above description of Linux's behavior is still accurate, it is certainly not appropriate to hold up Linux as a model for a "binding-free BEHAVE-compliant NAT". In fact, it reinforces the reasons why the BEHAVE documents NEED to talk explicitly about bindings - because NOT talking about them and NOT explicitly defining a clear operational model for NAT is just asking for all kinds of "near-compliant but nondeterministic" implementations similar to Linux's NAT. To reiterate: to my knowledge Linux's NAT is _NOT_ fully BEHAVE-compliant, precisely because it DOES NOT use port bindings to reserve public ports to the exclusive use of particular internal endpoints when the first outgoing connection is seen from that endpoint. Bryan _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Sun, 31 Jul 2005 03:31:26 -0700 (PDT) From: "Cullen Jennings" Date: Sun, 31 Jul 2005 03:31:26 -0700 (PDT) Subject: RE: [Ietf-behave] ICMP In-Reply-To: <1ECE0EB50388174790F9694F77522CCF032B1867@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Chair comment here, at the last meeting, several people pointed out this document was really assocated with a the protocol and made more sense described in that context. Has something changed that makes it look like we should change our direction here ? Cullen -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Francois Audet Sent: Saturday, July 09, 2005 8:08 PM To: Behave Subject: [Ietf-behave] ICMP What do people think about removing from the UDP spec COMPLETLY any discussion of ICMP (i.e., remove section 9)? We have the following item on the Charter: Nov 05 Produce a BCP that defines basic ICMP behavioral requirements for NATs I certainly don't have a problem with removing it from the UDP spec. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Sun, 31 Jul 2005 03:31:29 -0700 (PDT) From: "Cullen Jennings" Date: Sun, 31 Jul 2005 03:31:29 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain I think this is the backwards way of looking at this spec. This spec is not how to implement a NAT, it is a set of assumptions that an application can make about a NAT. Many NATs today do this timeout very short for "security reasons" whatever those are. I'm not arguing this is good or bad. I'm arguing that so far no one has presented a reason why an application would need to assume a larger value than this and we know it is an issue with NATs so why not ask for what applications need, not ask for things that might be a good idea but we don't need, and not ask for things that will never happen (such as default configuration of EF=I) Cullen -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Paul Hoffman Sent: Thursday, July 07, 2005 1:28 AM To: Francois Audet; ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt At 5:48 PM -0500 7/6/05, Francois Audet wrote: > c) The ICMP timeout SHOULD be greater than 2 seconds. > >Or are people still questioning c), and if so what would be the >proposal. I disagree with such a short timeout. Why not 2 minutes (or shorter, only if the NAT's ICMP message buffer is running out of space)? If the ICMP responder is busy doing something else, and waits 2.1 seconds, and the sender has thrown away the state, this would cause unexpected behavior. If the 2 seconds is specified in the ICMP spec, that's fine; otherwise, we should stretch out as far as we can. --Paul Hoffman, Director --Cybersecurity Association --www.cybersecurity.org _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Sun, 31 Jul 2005 03:31:30 -0700 (PDT) From: "Cullen Jennings" Date: Sun, 31 Jul 2005 03:31:30 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF031E7470@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain C does not say you need to use a timer, just that however you implement it, under fairly normal assumptions this should happen (clearly it would not happen if the NAT was say unplugged) cullen, not as chair -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Francois Audet Sent: Thursday, July 07, 2005 12:48 AM To: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt Did we agree on the following for REQ-11? REQ-11: Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping. a) The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address. b) It is RECOMMENDED that a NAT support ICMP Destination Unreachable messages. c) The ICMP timeout SHOULD be greater than 2 seconds. Or are people still questioning c), and if so what would be the proposal. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Sun, 31 Jul 2005 03:31:31 -0700 (PDT) From: "Cullen Jennings" Date: Sun, 31 Jul 2005 03:31:31 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF030F769A@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I'm not - testing indicates that many devices today do not allow all ICMP packets. Look the only thing so far identified that we need is destination unreachable so that path MTU works. The goals here is not to define how we wished NATs were implemented. It is to define the minimal behavior that we need to them change such that a wide range of applications are possible. Unless someone has a good reason by we need ICMP processing (which is encouraged) instead of ICMP Dest. Unreach, I see no reason to add it in. Cullen -----Original Message----- From: Francois Audet [mailto:audet@xxxxxxxxxx] Sent: Friday, July 01, 2005 2:13 AM To: Saikat Guha; dwing@xxxxxxxxx; Cullen Jennings Cc: Behave Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt I am OK with your proposed clarification for REQ-11, which is basically to change the term "support ICMP Destination Unreachable" terminology with "support ICMP processing". I'm also OK with your alternative with the explicit sub-bullets. Dan, you wrote this. Are you OK with the suggestion? > -----Original Message----- > From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] > Sent: Thursday, June 30, 2005 15:17 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Behave' > Subject: Re: [Ietf-behave] FW: I-D > ACTION:draft-ietf-behave-nat-udp-02.txt > > > On Wed, 2005-06-29 at 13:32 -0400, Francois Audet wrote: > > I want to draw the attention of the group to the new issue of the > > UDP draft. > > Few notes ... some from dangling threads and some new (so there is one > place to look up the issues) > > 1) (old) -- REQ7a. > 'nuff said. > > > 2) (old) -- Clarification: > The ICMP timeout in REQ-11a is still unclear to me. I realize Cullen > is on vacation. Just a reminder. > > > 3) (new) -- Confusing terminology: > > REQ-11: It is RECOMMENDED that a NAT support ICMP Destination > > Unreachable. > > At first glance, I seems this just asks the NAT to support ICMP Type=3 > (Type=3 is Destination Unreachable). > > As defined earlier, however, "Support Destination Unreachable" > actually means "A NAT which performs the functions described in > [section 9]" which includes "Receipt of *any* sort of ICMP message > MUST NOT destroy the NAT mapping." (emphasis mine). It seems unclear > if REQ-11 is for all ICMPs or just Destination unreachable. > > In any case, changing the terminology to "Support ICMP Translations" > or "Support ICMP Processing" etc would avoid this confusing. Also, if > you really meant just ICMP Destination Unreachable in REQ-11, then the > other requirements from the paragraph should also be summarized: > > REQ-11: Receipt of any sort of ICMP message MUST NOT destroy the NAT > mapping. > a) The NAT's default configuration SHOULD NOT filter ICMP messages > based on their source IP address. > b) It is RECOMMENDED that a NAT support ICMP Destination > Unreachable messages. > c) The ICMP timeout SHOULD be greater than 2 seconds. > > or more concisely as, > > REQ-11: It is RECOMMENDED that a NAT support ICMP Processing. > a) The ICMP timeout SHOULD be greater than 2 seconds. > > > -- > Saikat > From fluffy@cisco.com Sun, 31 Jul 2005 03:31:34 -0700 (PDT) From: "Cullen Jennings" Date: Sun, 31 Jul 2005 03:31:34 -0700 (PDT) Subject: RE: [Ietf-behave] Applicability statement in the UDP draft In-Reply-To: <20050710085215.80906.qmail@web40429.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain The scope was NATs. Cullen -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Pyda Srisuresh Sent: Sunday, July 10, 2005 10:52 AM To: Francois Audet; Behave Subject: RE: [Ietf-behave] Applicability statement in the UDP draft --- Francois Audet wrote: > > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Pyda > > Srisuresh > > Sent: Friday, July 08, 2005 07:24 > > To: Behave > > Subject: [Ietf-behave] Applicability statement in the UDP draft > > > > > > Francois, > > > > In section 1, titled "applicability Statement", you state the > > following. > > > > The requirements of this specification apply generally to all NAT > > variations, including the ones described in RFC 2663 [3] > > (Traditional > > NAT, Basic NAT, NAPT, Bi-directional NAT, Twice NAT, and Multihomed > > NATs). However, it is not within the scope of this specification > > to > > address all issues specific to all possible NAT variations. > > > > Yet, in section 3, you state: > > > > In this specification, the term "NAT" refers > > to both "Basic NAT" and "Network Address/Port Translator (NAPT)". > > > > For the reminder of the document, you use the above definition for > > NAT in deriving the Behave requirements. > > > > If the scope of applicability is beyond Traditional NATs, then the > > requirements do not do justice to that, as they assume traditional > > NAT. > > You are correct. We are looking at Traditional NAT only. That section > 1 comment will be modified. > [suresh] Well, the WG charter refers to NATs in general and does not restrict to Traditional NATs. Perhaps, the WG chairs can make the call on what the scope of the drafts should be. cheers, suresh > > You will need to spell out which of the requirements are generic and > > which are specific to Basic NAT and/or NAPT. > > > > > cheers, > > suresh > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Sun, 31 Jul 2005 03:32:48 -0700 (PDT) From: "Cullen Jennings" Date: Sun, 31 Jul 2005 03:32:48 -0700 (PDT) Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt In-Reply-To: <1120425195.5293.17.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: text/plain 2 seconds came as number larger than realistic RTT on satellite link - I have no idea if that is correct but that was the logic. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Saikat Guha Sent: Sunday, July 03, 2005 11:13 PM To: Senthil Sivakumar (ssenthil) Cc: Behave Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt On Sun, 2005-07-03 at 10:58 -0700, Senthil Sivakumar (ssenthil) wrote: > > REQ-11: It is RECOMMENDED that a NAT support ICMP Processing. > > a) The ICMP timeout SHOULD be greater than 2 seconds. > > The above is vague, it does not specify exactly what the requirement is. > IMO, the requirement is that NAT should not delete any mapping as a > result of seeing Destination unreachable. The requirement actually is much stronger -- the NAT shouldn't delete the mapping as a result of any ICMP packet; the details being in section 9. But I agree with you and would prefer something similar to the long form with the explicit sub-bullets. > BTW, how was the timeout of 2 > secs derived? *shrug* What's the timeout for, even? -- Saikat From fluffy@cisco.com Mon, 1 Aug 2005 06:29:26 -0700 (PDT) From: "Cullen Jennings" Date: Mon, 1 Aug 2005 06:29:26 -0700 (PDT) Subject: FW: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 sorry accidentally replied instead of reply all on this one. From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] Sent: Sunday, July 31, 2005 12:31 PMTo: 'Francois Audet'Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 I have no idea how Bryan can think I would be OK with that. But anyways, to clarify, I'm not. (obviosly not as chair) From: Francois Audet [mailto:audet@xxxxxxxxxx] Sent: Wednesday, June 22, 2005 2:03 AMTo: 'Cullen Jennings'Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 Cullen, We are waiting for you to tell us what you really meant: "SHOULD" or "MAY" in 7a. Please say so on the list so we can put this issue to rest... To refresh your memory, I have: REQ-7: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address dependent filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. Bryan is OK with 7, but wants to change the "MAY" to a "SHOULD" in 7a, and claims that you are OK with it. As you know, I really don't give a &*(*#? at this point. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Bryan Ford > Sent: Tuesday, June 21, 2005 12:22 > To: Saikat Guha > Cc: 'Behave' > Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7 > > > On Tuesday 21 June 2005 19:07, Saikat Guha wrote: > > On Tue, 2005-06-21 at 09:59 -0600, Bryan Ford wrote: > > > On Thursday 09 June 2005 16:17, Francois Audet wrote: > > > > a) The filtering behavior MAY be an option > configurable by > > > > the > > > > > > I still feel strongly that the MAY should be > > > a SHOULD in the second. I don't recall hearing any > objections from > > > Cullen or anyone else after my earlier suggestion that we > keep the > > > SHOULD but change "user configurable" to "configurable by the > > > administrator of the NAT". > > > > I agree with Cullen (below) that changing the MAY to should doesn't > > change any interoperability issues. Even if "user configurable" is > > changed to "configurable by the administrator", all of Cullen's > > objections still hold. > > In what way do they still hold? As far as I can tell, > Cullen's objections > were primarily based on his comment that "In many case[s] the > administrator > of the NAT is very different from the user of it" and > therefore it was > unreasonable to expect a NAT's behavior to be > "user-configurable". That > statement I agree with. It is entirely reasonable, however, > to expect a > NAT's behavior to be "administrator-configurable". Every NAT > on the planet > is already "administrator-configurable" - even locked-down > NATs supplied by > ISPs, which are configured by the ISP's administrator > (perhaps before they > are even shipped to the user). The problem was merely a > minor semantic > confusion caused by the distinction between "user" and > "administrator". I > always meant "administrator-configurable"; it just > accidentally came out > "user-configurable" at some point because I wasn't thinking > carefully about > that distinction at the time. > > > Changing it to SHOULD/RECOMMENDED in REQ-7a > > introduces a hidden recommendation that a NAT SHOULD implement both > > filtering behaviors (so it can have an option configurable by the > > admin) ... which is not what REQ-7 says. I support "MAY" in REQ-7a. > > That hidden recommendation that a NAT SHOULD implement both filtering > behaviors is precisely the point. I feel that if a NAT > implements EF=A > filtering (which is a problematic but reasonable security > feature), then it > SHOULD also provide a way for the NAT's administrator to turn > that filtering > feature off. Since an EF=A NAT minus filtering effectively > becomes an EF=I > NAT, what we have is a NAT that is configurable for either > EF=I or EF=A. > This will take an absurdly small amount of implementation > effort by the NAT > implementor - every NAT on the planet has a zillion > configuration options > already; this is just one more, and all it does is turn off a > particular > security feature that sometimes gets in the way of > application connectivity. > Can you explain why it is unreasonable or undesirable for NAT > vendors to be > expected to provide this small but potentially important bit of > configurability? > > Bryan > > > On Wed, 2005-06-01 at 09:25 -0400, Cullen Jennings wrote: > > > > a) The filtering behavior SHOULD be a user configurable option. > > > > > > I could deal with this if we change to MAY but strongly object to > > > the SHOULD. There are going to be devices where this is > difficult. > > > There are going to be devices that only support one type. In many > > > case the administrator of the NAT is very different from > the user of > > > it. There is no reason why the WG should tell vendors how > to build > > > this. Having it as MAY or SHOULD does not change any > > > interoperability issues between devices. Any standards > body should > > > focus on things that it needs to specify to ensure > interoperability. > > > Once vendors start down the slipper slope of not being fully > > > compliant, pain and suffering will ensue - I'd rather avoid that. > > > It's about as useful for the draft to say that all NAT > user manuals > > > SHOULD be in gender neutral language. It has no effect on > > > interoperability. I can not see any good come it and I > can see harm > > > caused by it when key vendors that are not fully complaint start > > > justifying why it is not useful to be fully complaint > with BEHAVE. I > > > know it sounds weird to care about this, but I would like > to have a > > > chance of getting the largest vendor of residential and corporate > > > NATs to do this and this is not going to help. > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From fluffy@cisco.com Tue, 2 Aug 2005 00:15:10 -0700 (PDT) From: "Cullen Jennings" Date: Tue, 2 Aug 2005 00:15:10 -0700 (PDT) Subject: [Ietf-behave] New Draft BEHAVE agenda IETF 63 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Behavior Engineering for Hindrance Avoidance WG (behave) TUESDAY, August 2, 1630-1800 Afternoon Session II ======================================================== CHAIRS: Jiri Kuthan Cullen Jennings AGENDA: (Last revised Aug 2) - Agenda Bashing, Bluesheets, Note-takers (5 min) UDP Open Issues - Resolve any open issues with moving UDP draft forward draft-ietf-behave-nat-udp-03 (Francois Audet - 30 min) - Discuss moving forward UDP (5 min - chairs) TCP Protocol and Document Issues - Resolved open issues on how TCP should work draft-hoffman-behave-tcp-02.txt (Paul Hoffman - 15 min) draft-sivakumar-behave-nat-tcp-req-01.txt (Bryan Ford - 15 min) - suggestions to get to WG document (note if earlier things go over, we may not get to this) Application Behavior Documents - draft-wing-behave-symmetric-rtprtcp-01 (Dan Win - 10 min) - draft-ford-behave-app-00.txt (Bryan Ford - 10 min) From audet@nortel.com Thu, 11 Aug 2005 13:36:31 -0700 (PDT) From: "Francois Audet" Date: Thu, 11 Aug 2005 13:36:31 -0700 (PDT) Subject: [Ietf-behave] UDP draft and Fragmentation Message-ID: <1ECE0EB50388174790F9694F77522CCF03C04325@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Hi guys, As per the agreement of last week's BEHAVE meeting, Bryan Ford has created some text to address the Fragmentation aspects of the document. Also as per the agreement, David Oran, Cullen Jennings and myself have looked at it and agree unanimously that the text should go in. The question to the group is do everybody agree with the new proposal below: REQ-13: A NAT MUST support receiving in order and out of order fragments, so it MUST have "Received Fragment Out of Order" behavior. Replace REQ-13a with: REQ-13(a): A NAT's out of order fragment processing mechanism MUST be designed so that fragmentation-based DoS attacks do not compromise the NAT's ability to process in-order and unfragmented IP packets. Unless anybody complains, it's in. From dwing@cisco.com Thu, 11 Aug 2005 16:16:15 -0700 (PDT) From: "Dan Wing" Date: Thu, 11 Aug 2005 16:16:15 -0700 (PDT) Subject: [Ietf-behave] draft-wing-behave-symmetric-rtprtcp Message-ID: <200508112316.QAA05981@edison.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I'd like draft-wing-behave-symmetric-rtprtcp to become an RFC. Should we turn it into a WG item first, or just ask for an IETF 4 week last call on it? -d From fluffy@cisco.com Sun, 14 Aug 2005 15:14:58 -0700 (PDT) From: Cullen Jennings Date: Sun, 14 Aug 2005 15:14:58 -0700 (PDT) Subject: [Ietf-behave] Re: Rough minutes for BEHAVE In-Reply-To: <42F7783E.2040605@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Re: Rough minutes for BEHAVE Paul, thank you for taking notes... Just to add a few more bits of information... On the last topic of in Paul's notes, the topic Bryan Ford had brought up with the group was the adoption of gen and overall organization of the documents. The blue sheets had 102 names on them. Cullen On 8/8/05 8:20 AM, "Paul Kyzivat" wrote: Attached are my notes from the BEHAVE session. There is a point down near the ned that I didn't get good notes on.  Paul Notes: Behave WG – IETF63, Tuesday 2-aug-2005 Scribe: Paul Kyzivat Draft-ietf-behave-nat-udp-03 Presented by Francois Audet Discussed status and changes. There were two open issues: 1.     Removal of Section 5.2. Final Resolution: Approved. 2.     In new REQ-7 (a) there is debate whether to use MAY or SHOULD in: the filtering behavior {MAY/SHOULD} be an option configurable by the administrator of the NAT. Brian Ford advocated SHOULD, Cullen Jennings advocated MAY. Cullen said applications can’t depend on this favor anyway, so no point in requiring it. Paul Hoffmann noted that SHOULD must include the rationale when it can be violated, and he thought that may be hard to do in this case. Jon Peterson thought there was confusion regarding the target for this requirement – a NAT builder or administrator. Brian said just having the option is helpful for self organizing peer-to-peer systems where some of the nodes need to be super nodes that require special NAT behavior. He postulated that the objection to SHOULD was that some NAT vendors might object to meeting it. He asked if there were NAT vendors in the room that could answer, but none did. Jon asked for anybody other than Brian in favor of SHOULD to respond. Nobody did. Someone from Juniper (I didn’t catch who) spoke as a NAT vendor.  He said they are concerned about security in their NAT, and that if they were convinced to implement the option they would strongly encourage customers not to enable it. Final resolution: this stays a MAY. Other discussion on the draft: Dan Wing suggested that maybe the document should be targeted at application developers (what they should expect) rather than what NAT vendors should do. Brian Ford brought up an issue regarding fragmented UDP packets. He said some operating systems routinely send fragmented packets out of order, and this breaks applications. This was identified as a change from a MAY to a MUST in Requirement 13. Cullen claimed it is impossible because it opens up DOS attacks. Dave Oran said there is no DOS attack if reassembly of fragmented packets is done right. (By reserving a fixed number of reassembly buffers and only doing reassembly when a buffer is available.) Final resolution: Agreed in principle to this change pending a write-up by Brian Ford. Brian brought up another issue: Twice NAT is becoming a big issue. Almost all consumer NATs use DHCP to obtain their IP address. If this gets an address from another NAT, then the downstream and upstream addresses could end up the same. Some NATs have been observed to fail in this case. He requested language that NAT vendors be sure to cope with this. There was some question of whether use of twice NAT is increasing or decreasing. However no one in the room had first hand knowledge of this situation – only hearsay. Final resolution: Brian and Cullen will come up with wording to address this. Brian had an issue regarding document organization. Final Resolution: Paul Hoffman said that can be done by chairs and AD – it doesn’t require consensus. Brian had another issue about terminology. Jon Peterson thought it appropriate. [ed: I didn’t catch what the actual issue was, and this item doesn’t make much sense to me now.] Brian complained he hasn’t had a hearing on all the documents he has tried to offer. Jon Peterson thought this has had ample hearing on the list. The room was polled for others agreeing with Brian. No one responded, so Brian agreed to drop his objections. The end of the meeting was then at hand so there was no time to discuss other documents. From audet@nortel.com Sun, 14 Aug 2005 19:59:01 -0700 (PDT) From: "Francois Audet" Date: Sun, 14 Aug 2005 19:59:01 -0700 (PDT) Subject: [Ietf-behave] UDP draft: Conflicting Internal and External IP address spaces Message-ID: <430004D5.2030302@nortel.com> MIME-Version: 1.0 Content-Type: text/plain Hi all, This is the new proposed text from Bryan Ford on the issue of overlapping IP address spaces, for the UDP draft. This is a per the agreement in IETF 63. The text has been reviewed and agreed-to by Cullen and myself. Any objections? -------------------------------------------------------------------- 4.4. Conflicting Internal and External IP Address Spaces Many NATs, particularly consumer-level devices designed to be deployed by nontechnical users, routinely obtain their external IP address, default router, and other IP configuration information for their external interface dynamically from an external network such as an upstream ISP. The NAT in turn automatically sets up its own internal subnet in one of the private IP address spaces assigned to this purpose in RFC 1918, typically providing dynamic IP configuration services for hosts on this internal network. Auto-configuration of NATs and private networks can be problematic, however, if the NAT's external network is also in RFC 1918 private address space. In a common scenario, an ISP places its customers behind a NAT and hands out private RFC 1918 addresses to them. Some of these customers in turn deploy consumer-level NATs, which in effect act as "second-level" NATs, multiplexing their own private RFC 1918 IP subnets onto the single RFC 1918 IP address provided by the ISP. There is no inherent guarantee in this case that the ISP's "intermediate" privately-addressed network and the customer's internal privately-addressed network will not use numerically identical or overlapping RFC 1918 IP subnets. Customers of consumer-level NATs further cannot be expected to have the technical knowledge to prevent this scenario from occurring by manually configuring their internal network with non-conflicting RFC 1918 subnets. NAT vendors need to design their NATs to ensure that they function correctly and robustly even in such problematic scenarios. One possible solution is for the NAT to ensure that whenever its external link is configured with an RFC 1918 private IP address, the NAT automatically selects a different, non-conflicting RFC 1918 IP subnet for its internal network. A disadvantage of this solution is that if the NAT's external interface is dynamically configured or re-configured after its internal network is already in use, then the NAT may have to renumber its entire internal network dynamically if it detects a conflict. An alternative solution is for the NAT to be designed so that it can translate and forward traffic correctly even when its external and internal interfaces are configured with numerically overlapping IP subnets. In this scenario, for example, if the NAT's external interface has been assigned an IP address P in RFC 1918 space, then there might also be an internal node I having the same RFC 1918 private IP address P. An IP packet with destination address P on the external network is directed at the NAT, whereas an IP packet with the same destination address P on the internal network is directed at node I. The NAT therefore needs to maintain a clear operational distinction between "external IP addresses" and "internal IP addresses" to avoid confusing internal node I with its own external interface. In general, the NAT needs to allow all internal nodes (including I) to communicate with all external nodes having public (non-RFC 1918) IP addresses or having private IP addresses that do not conflict with the addresses used by its internal network. REQ-XX: A NAT device whose external IP interface can be configured dynamically MUST either (1) automatically ensure that its internal network uses IP addresses that do not conflict with its external network, or (2) be able to translate and forward traffic between all internal nodes and all external nodes whose IP addresses do not numerically conflict with the internal network. Justification: If a NAT's external and internal interfaces are configured with overlapping IP subnets, then there is of course no way for an internal host with RFC 1918 IP address Q to initiate a direct communication session to an external node having the same RFC 1918 address Q, or to other external nodes with IP addresses that numerically conflict with the internal subnet. Such nodes can still open communication sessions indirectly via NAT traversal techniques, however, with the help of a third-party server such as a STUN server having a public, non-RFC 1918 IP address. In this case, nodes with conflicting private RFC 1918 addresses on opposite sides of the second-level NAT can communicate with each other via their respective temporary public endpoints on the main Internet, as long as their common first-level NAT (e.g., the upstream ISP's NAT) supports hairpinning behavior as described later in Section 6. From audet@nortel.com Sun, 14 Aug 2005 20:10:22 -0700 (PDT) From: "Francois Audet" Date: Sun, 14 Aug 2005 20:10:22 -0700 (PDT) Subject: [Ietf-behave] UDP draft: Conflicting Internal and External IP address spaces Message-ID: <43000794.6010600@nortel.com> MIME-Version: 1.0 Content-Type: text/plain Hi all, This is the new proposed text from Bryan Ford on the issue of overlapping IP address spaces, for the UDP draft. This is a per the agreement in IETF 63. The text has been reviewed and agreed-to by Cullen and myself. Any objections? -------------------------------------------------------------------- 4.4. Conflicting Internal and External IP Address Spaces Many NATs, particularly consumer-level devices designed to be deployed by nontechnical users, routinely obtain their external IP address, default router, and other IP configuration information for their external interface dynamically from an external network such as an upstream ISP. The NAT in turn automatically sets up its own internal subnet in one of the private IP address spaces assigned to this purpose in RFC 1918, typically providing dynamic IP configuration services for hosts on this internal network. Auto-configuration of NATs and private networks can be problematic, however, if the NAT's external network is also in RFC 1918 private address space. In a common scenario, an ISP places its customers behind a NAT and hands out private RFC 1918 addresses to them. Some of these customers in turn deploy consumer-level NATs, which in effect act as "second-level" NATs, multiplexing their own private RFC 1918 IP subnets onto the single RFC 1918 IP address provided by the ISP. There is no inherent guarantee in this case that the ISP's "intermediate" privately-addressed network and the customer's internal privately-addressed network will not use numerically identical or overlapping RFC 1918 IP subnets. Customers of consumer-level NATs further cannot be expected to have the technical knowledge to prevent this scenario from occurring by manually configuring their internal network with non-conflicting RFC 1918 subnets. NAT vendors need to design their NATs to ensure that they function correctly and robustly even in such problematic scenarios. One possible solution is for the NAT to ensure that whenever its external link is configured with an RFC 1918 private IP address, the NAT automatically selects a different, non-conflicting RFC 1918 IP subnet for its internal network. A disadvantage of this solution is that if the NAT's external interface is dynamically configured or re-configured after its internal network is already in use, then the NAT may have to renumber its entire internal network dynamically if it detects a conflict. An alternative solution is for the NAT to be designed so that it can translate and forward traffic correctly even when its external and internal interfaces are configured with numerically overlapping IP subnets. In this scenario, for example, if the NAT's external interface has been assigned an IP address P in RFC 1918 space, then there might also be an internal node I having the same RFC 1918 private IP address P. An IP packet with destination address P on the external network is directed at the NAT, whereas an IP packet with the same destination address P on the internal network is directed at node I. The NAT therefore needs to maintain a clear operational distinction between "external IP addresses" and "internal IP addresses" to avoid confusing internal node I with its own external interface. In general, the NAT needs to allow all internal nodes (including I) to communicate with all external nodes having public (non-RFC 1918) IP addresses or having private IP addresses that do not conflict with the addresses used by its internal network. REQ-XX: A NAT device whose external IP interface can be configured dynamically MUST either (1) automatically ensure that its internal network uses IP addresses that do not conflict with its external network, or (2) be able to translate and forward traffic between all internal nodes and all external nodes whose IP addresses do not numerically conflict with the internal network. Justification: If a NAT's external and internal interfaces are configured with overlapping IP subnets, then there is of course no way for an internal host with RFC 1918 IP address Q to initiate a direct communication session to an external node having the same RFC 1918 address Q, or to other external nodes with IP addresses that numerically conflict with the internal subnet. Such nodes can still open communication sessions indirectly via NAT traversal techniques, however, with the help of a third-party server such as a STUN server having a public, non-RFC 1918 IP address. In this case, nodes with conflicting private RFC 1918 addresses on opposite sides of the second-level NAT can communicate with each other via their respective temporary public endpoints on the main Internet, as long as their common first-level NAT (e.g., the upstream ISP's NAT) supports hairpinning behavior as described later in Section 6. From dwing@cisco.com Mon, 15 Aug 2005 18:40:53 -0700 (PDT) From: "Dan Wing" Date: Mon, 15 Aug 2005 18:40:53 -0700 (PDT) Subject: [Ietf-behave] DNS ALG, REQ-9 Message-ID: <200508160140.SAA10209@edison.cisco.com> MIME-Version: 1.0 Content-Type: text/plain -ietf-behave-nat-udp-03 reads: REQ-9: If a NAT includes ALGs, it is RECOMMENDED that all of those ALGs (except for DNS [19] and FTP [18]) be disabled by default. This implies the converse -- that a DNS ALG SHOULD be enabled. Is that the intention of your text? I understand the FTP ALG, it's well described in section 7.1 of RFC2663. However, I don't understand what the DNS ALG is supposed to do especially in a Dlink/Netgear/Linksys-class device; section 4.3 of RFC2663 implies it would only be necessary if you're doing "twice NAT" (see RFC2663 for details) and only during pure NAT (that is, not doing port address translation). I would like a better explanation of the intended function of the DNS ALG in -ietf-behave-nat-udp-, or a cite to a specific section and RFC. I'm concerned the existing text might cause proliferation of DNSSEC-breaking DNS ALG functions in seldom-upgraded consumer NATs. -d From audet@nortel.com Tue, 16 Aug 2005 09:09:51 -0700 (PDT) From: "Francois Audet" Date: Tue, 16 Aug 2005 09:09:51 -0700 (PDT) Subject: RE: [Ietf-behave] DNS ALG, REQ-9 Message-ID: <1ECE0EB50388174790F9694F77522CCF03CEDEAB@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I don't remember why we put DNS in there. Srisuresh, was it you that requested it? PS: I will add the reference to 7.1/RFC 2663 for FTP ALG. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wing > Sent: Monday, August 15, 2005 18:41 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] DNS ALG, REQ-9 > > > -ietf-behave-nat-udp-03 reads: > > REQ-9: If a NAT includes ALGs, it is RECOMMENDED that all of those > ALGs (except for DNS [19] and FTP [18]) be disabled by default. > > This implies the converse -- that a DNS ALG SHOULD be > enabled. Is that the intention of your text? > > I understand the FTP ALG, it's well described in section 7.1 > of RFC2663. However, I don't understand what the DNS ALG is > supposed to do especially in a Dlink/Netgear/Linksys-class > device; section 4.3 of RFC2663 implies it would only be > necessary if you're doing "twice NAT" (see RFC2663 for > details) and only during pure NAT (that is, not doing port > address translation). > > I would like a better explanation of the intended function of > the DNS ALG in -ietf-behave-nat-udp-, or a cite to a specific > section and RFC. I'm concerned the existing text might cause > proliferation of DNSSEC-breaking DNS ALG functions in > seldom-upgraded consumer NATs. > > -d > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From dbarrett@quinthar.com Wed, 17 Aug 2005 17:38:05 -0700 (PDT) From: David Barrett Date: Wed, 17 Aug 2005 17:38:05 -0700 (PDT) Subject: [Ietf-behave] Unidirectional or Bidirectional Manual Port Forwarding? Message-ID: <4303D866.9050908@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain I'm experimenting with a particular user, and I'm experiencing unexpected behavior with regard to UDP port forwarding. I'm not sure if something is broken, or if I just misunderstand how it's supposed to work. Can you offer me any clarity on what BEHAVE says should occur in this situation? Specifically, a user has configured his NAT (some DLink, address-restricted filtering model) to manually forward external traffic sent to a given port a specific internal IP:port. And this works fine -- traffic sent to the external endpoint X is in fact forwarded without trouble to internal endpoint Y. This this works great when a remote host is initiating a UDP session to the internal host. However, the reverse doesn't work so great. What I *expected* would happen is that all UDP sessions initiated from internal endpoint Y would be advertised to remote users as coming from external endpoint X. ie, I expected internally-initiated connections would "go out" through the manually-configured port-forwarded mapping. Thus regardless of which side initiated the connection, the remote side would see and use external endpoint X. But in practice, it appears the NAT ignores the port mapping when the internal machine initiates the connection, and instead establishes a new external mapping -- with the very address-restricted filtering properties I was hoping to avoid. So I guess what I'm asking is: 1) Are manually-forwarded NAT port mappings typically unidirectional or bidirectional? Does this depend on the NAT model? 2) Is it possible to manually configure the outbound mapping (ie, force all traffic originating from an internal endpoint to use a specific external endpoint)? 2) What type of mapping does UPnP attempt to establish? Thanks, and sorry for the meandering question -- I don't know enough to phrase it more succinctly! -david From audet@nortel.com Wed, 17 Aug 2005 17:45:59 -0700 (PDT) From: "Francois Audet" Date: Wed, 17 Aug 2005 17:45:59 -0700 (PDT) Subject: RE: [Ietf-behave] Unidirectional or Bidirectional Manual PortForwarding? Message-ID: <1ECE0EB50388174790F9694F77522CCF03DA86E6@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I guess this behavior will kill any hope of symmetic operation... I must say I am not surprised... My expectations are very low. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > David Barrett > Sent: Wednesday, August 17, 2005 17:38 > To: 'Behave' > Subject: [Ietf-behave] Unidirectional or Bidirectional Manual > PortForwarding? > > > I'm experimenting with a particular user, and I'm experiencing > unexpected behavior with regard to UDP port forwarding. I'm > not sure if > something is broken, or if I just misunderstand how it's supposed to > work. Can you offer me any clarity on what BEHAVE says > should occur in > this situation? > > Specifically, a user has configured his NAT (some DLink, > address-restricted filtering model) to manually forward > external traffic > sent to a given port a specific internal IP:port. And this > works fine > -- traffic sent to the external endpoint X is in fact > forwarded without > trouble to internal endpoint Y. This this works great when a remote > host is initiating a UDP session to the internal host. > > However, the reverse doesn't work so great. What I *expected* would > happen is that all UDP sessions initiated from internal > endpoint Y would > be advertised to remote users as coming from external > endpoint X. ie, I > expected internally-initiated connections would "go out" through the > manually-configured port-forwarded mapping. Thus regardless of which > side initiated the connection, the remote side would see and use > external endpoint X. > > But in practice, it appears the NAT ignores the port mapping when the > internal machine initiates the connection, and instead > establishes a new > external mapping -- with the very address-restricted filtering > properties I was hoping to avoid. > > So I guess what I'm asking is: > > 1) Are manually-forwarded NAT port mappings typically > unidirectional or > bidirectional? Does this depend on the NAT model? > > 2) Is it possible to manually configure the outbound mapping > (ie, force > all traffic originating from an internal endpoint to use a specific > external endpoint)? > > 2) What type of mapping does UPnP attempt to establish? > > Thanks, and sorry for the meandering question -- I don't know > enough to > phrase it more succinctly! > > -david > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From kbiswas@cisco.com Wed, 17 Aug 2005 18:02:56 -0700 (PDT) From: "Kaushik Biswas (kbiswas)" Date: Wed, 17 Aug 2005 18:02:56 -0700 (PDT) Subject: RE: [Ietf-behave] DNS ALG, REQ-9 Message-ID: <378E78E5F361564BB066432F6415764B811F6E@xmb-sjc-228.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain It was an outcome of the IETF 62 (Minneapolis) discussions whereby it was felt that FTP & DNS ALGs turning off won't be acceptable. BTW IMO behave-udp draft shouldn't be talking about FTP in the first place. If we are talking about FTP in behave-udp draft then we should also putting a cross reference to draft-sivakumar-behave-nat-tcp-req-01's Sections: 4.2 & 4.3. Thanks, Kaushik > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Francois Audet > Sent: Tuesday, August 16, 2005 9:11 AM > To: Dan Wing (dwing); ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] DNS ALG, REQ-9 > > I don't remember why we put DNS in there. > > Srisuresh, was it you that requested it? > > PS: I will add the reference to 7.1/RFC 2663 for FTP ALG. > > > > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf > Of Dan Wing > > Sent: Monday, August 15, 2005 18:41 > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: [Ietf-behave] DNS ALG, REQ-9 > > > > > > -ietf-behave-nat-udp-03 reads: > > > > REQ-9: If a NAT includes ALGs, it is RECOMMENDED that > all of those > > ALGs (except for DNS [19] and FTP [18]) be disabled > by default. > > > > This implies the converse -- that a DNS ALG SHOULD be enabled. Is > > that the intention of your text? > > > > I understand the FTP ALG, it's well described in section 7.1 of > > RFC2663. However, I don't understand what the DNS ALG is > supposed to > > do especially in a Dlink/Netgear/Linksys-class device; > section 4.3 of > > RFC2663 implies it would only be necessary if you're doing > "twice NAT" > > (see RFC2663 for > > details) and only during pure NAT (that is, not doing port address > > translation). > > > > I would like a better explanation of the intended function > of the DNS > > ALG in -ietf-behave-nat-udp-, or a cite to a specific > section and RFC. > > I'm concerned the existing text might cause proliferation of > > DNSSEC-breaking DNS ALG functions in seldom-upgraded consumer NATs. > > > > -d > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From dwing@cisco.com Wed, 17 Aug 2005 18:39:35 -0700 (PDT) From: "Dan Wing" Date: Wed, 17 Aug 2005 18:39:35 -0700 (PDT) Subject: RE: [Ietf-behave] DNS ALG, REQ-9 In-Reply-To: <378E78E5F361564BB066432F6415764B811F6E@xmb-sjc-228.amer.cisco.com> Message-ID: <200508180139.SAA02014@edison.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > It was an outcome of the IETF 62 (Minneapolis) discussions whereby it > was felt that FTP & DNS ALGs turning off won't be acceptable. Umkay. But the basis for that decision seems to have been lost to history. I want additional text added to the document explaining what a DNS ALG is supposed to do, and not supposed to do. As it is, the BEHAVE document doesn't cite what behavior it's recommending a DNS ALG to perform. I am questioning the need for a DNS ALG at all considering that I can't find that the major consumer-grade NAT manufacturers don't seem to include it as a feature (I checked Linksys, D-Link, and Netgear). It seems only useful if you're doing NAT in the truest sense of NAT -- that is, you're only rewriting IP addresses and you're not rewriting ports and not overloading ports (NAPT). > BTW IMO behave-udp draft shouldn't be talking about FTP in the first > place. If we are talking about FTP in behave-udp draft then we should > also putting a cross reference to > draft-sivakumar-behave-nat-tcp-req-01's Sections: 4.2 & 4.3. Good point - the UDP document shouldn't talk about an FTP ALG. -d > Thanks, > Kaushik > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Francois Audet > > Sent: Tuesday, August 16, 2005 9:11 AM > > To: Dan Wing (dwing); ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] DNS ALG, REQ-9 > > > > I don't remember why we put DNS in there. > > > > Srisuresh, was it you that requested it? > > > > PS: I will add the reference to 7.1/RFC 2663 for FTP ALG. > > > > > > > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf > > Of Dan Wing > > > Sent: Monday, August 15, 2005 18:41 > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: [Ietf-behave] DNS ALG, REQ-9 > > > > > > > > > -ietf-behave-nat-udp-03 reads: > > > > > > REQ-9: If a NAT includes ALGs, it is RECOMMENDED that > > all of those > > > ALGs (except for DNS [19] and FTP [18]) be disabled > > by default. > > > > > > This implies the converse -- that a DNS ALG SHOULD be > enabled. Is > > > that the intention of your text? > > > > > > I understand the FTP ALG, it's well described in section 7.1 of > > > RFC2663. However, I don't understand what the DNS ALG is > > supposed to > > > do especially in a Dlink/Netgear/Linksys-class device; > > section 4.3 of > > > RFC2663 implies it would only be necessary if you're doing > > "twice NAT" > > > (see RFC2663 for > > > details) and only during pure NAT (that is, not doing > port address > > > translation). > > > > > > I would like a better explanation of the intended function > > of the DNS > > > ALG in -ietf-behave-nat-udp-, or a cite to a specific > > section and RFC. > > > I'm concerned the existing text might cause proliferation of > > > DNSSEC-breaking DNS ALG functions in seldom-upgraded > consumer NATs. > > > > > > -d > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortel.com Thu, 18 Aug 2005 08:01:33 -0700 (PDT) From: "Francois Audet" Date: Thu, 18 Aug 2005 08:01:33 -0700 (PDT) Subject: RE: [Ietf-behave] DNS ALG, REQ-9 Message-ID: <1ECE0EB50388174790F9694F77522CCF03DA89AF@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Same here, the residential/branch NATs and the large Corporate NATs that I looked at do not support DNS ALGs (they do FTP ALGs of course). I agree about the point on FTP. I think we need to change REQ-9 to something like: REQ-9: If a NAT includes ALGs that affect UDP, it is RECOMMENDED that all of those ALGs be disabled by default. a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the NAT administrator to enable or disable each ALG separately. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Wednesday, August 17, 2005 18:40 > To: 'Kaushik Biswas (kbiswas)'; Audet, Francois > [SC100:9T51:EXCH]; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] DNS ALG, REQ-9 > > > > It was an outcome of the IETF 62 (Minneapolis) discussions > whereby it > > was felt that FTP & DNS ALGs turning off won't be acceptable. > > Umkay. But the basis for that decision seems to have been > lost to history. > > I want additional text added to the document explaining what > a DNS ALG is supposed to do, and not supposed to do. As it > is, the BEHAVE > document doesn't cite what behavior it's recommending a DNS > ALG to perform. I am questioning the need for a DNS ALG at > all considering that I can't find that the major > consumer-grade NAT manufacturers don't seem to include it as > a feature (I checked Linksys, D-Link, and > Netgear). It seems only useful if you're doing NAT in the > truest sense of NAT -- that is, you're only rewriting IP > addresses and you're not rewriting ports and not overloading > ports (NAPT). > > > BTW IMO behave-udp draft shouldn't be talking about FTP in > the first > > place. If we are talking about FTP in behave-udp draft then > we should > > also putting a cross reference to > > draft-sivakumar-behave-nat-tcp-req-01's Sections: 4.2 & 4.3. > > Good point - the UDP document shouldn't talk about an FTP ALG. > > -d > > > > Thanks, > > Kaushik > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > Francois Audet > > > Sent: Tuesday, August 16, 2005 9:11 AM > > > To: Dan Wing (dwing); ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: RE: [Ietf-behave] DNS ALG, REQ-9 > > > > > > I don't remember why we put DNS in there. > > > > > > Srisuresh, was it you that requested it? > > > > > > PS: I will add the reference to 7.1/RFC 2663 for FTP ALG. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf > > > Of Dan Wing > > > > Sent: Monday, August 15, 2005 18:41 > > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Subject: [Ietf-behave] DNS ALG, REQ-9 > > > > > > > > > > > > -ietf-behave-nat-udp-03 reads: > > > > > > > > REQ-9: If a NAT includes ALGs, it is RECOMMENDED that > > > all of those > > > > ALGs (except for DNS [19] and FTP [18]) be disabled > > > by default. > > > > > > > > This implies the converse -- that a DNS ALG SHOULD be > > enabled. Is > > > > that the intention of your text? > > > > > > > > I understand the FTP ALG, it's well described in section 7.1 of > > > > RFC2663. However, I don't understand what the DNS ALG is > > > supposed to > > > > do especially in a Dlink/Netgear/Linksys-class device; > > > section 4.3 of > > > > RFC2663 implies it would only be necessary if you're doing > > > "twice NAT" > > > > (see RFC2663 for > > > > details) and only during pure NAT (that is, not doing > > port address > > > > translation). > > > > > > > > I would like a better explanation of the intended function > > > of the DNS > > > > ALG in -ietf-behave-nat-udp-, or a cite to a specific > > > section and RFC. > > > > I'm concerned the existing text might cause proliferation of > > > > DNSSEC-breaking DNS ALG functions in seldom-upgraded > > consumer NATs. > > > > > > > > -d > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > From dwing@cisco.com Mon, 29 Aug 2005 17:24:06 -0700 (PDT) From: "Dan Wing" Date: Mon, 29 Aug 2005 17:24:06 -0700 (PDT) Subject: [Ietf-behave] RE: [Fwd: [Sip] STUN state machine question] In-Reply-To: <1125286822.2496.0.camel@localhost.localdomain> Message-ID: <200508300024.RAA26710@edison.cisco.com> MIME-Version: 1.0 Content-Type: text/plain CC'ing the BEHAVE mailing list, where much of this activity is discussed now-a-days. The revision to RFC3489 (STUN) is also owned by BEHAVE (draft-ietf-behave-rfc3489bis). Determining the 'type of NAT' has been found to less useful than originally envisioned. Some NATs change their behavior after they've exchanged packets for a little while with a stream, and some NATs change behavior when they're really busy and become symmetric. So testing a NAT and declaring it's a certain kind of NAT may result in different answers based on the NAT's load, the duration of the stream being used for the test, and other factors. -d ----- > -----Original Message----- > From: sip-bounces@xxxxxxxx [mailto:sip-bounces@xxxxxxxx] On > Behalf Of Frank W. Miller > Sent: Sunday, August 28, 2005 8:40 PM > To: sip@xxxxxxxx > Subject: [Fwd: [Sip] STUN state machine question] > > > Hi, > > I didn't get any response to this message a week ago so I thought I > would try again... > > Thanks for any comments... > > FM -----Original Message----- From: sip-bounces@xxxxxxxx [mailto:sip-bounces@xxxxxxxx] On Behalf Of Frank W. Miller Sent: Sunday, August 21, 2005 11:41 AM To: sip@xxxxxxxx Subject: [Sip] STUN state machine question Greetings, I've been working with STUN a bit lately and have run into an interesting situation. This may have been discussed elsewhere and I just haven't seen it. If so, I apologize and would appreciate a pointer to that discussion. In the state diagram, Figure 2 of RFC 3489, there is a path to repeat Test I. That is, if the first execution of Test I yields a different IP address than the current host interface IP address and no response is received from the STUN server for Test II, the client repeats Test I sending the Binding Request to the IP address specified in the CHANGED-ADDRESS attribute from the first execution of Test I. My question is, what should the client assume if no response is received for the repeated execution of Test I? It seems to me that in theory, this situation should never occur. The reason is because the first execution of Test I returned a response and the second execution is doing the same thing, just with a different IP address and port number. However, I have encountered situations in practice where this does occur. My guess would be that you can certainly assume a NAT and use the MAPPED-ADDRESS that you get from the response to the first Test I. Would that be a good assumption? Also, what type of NAT would I then call that? Thoughts? FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sipping@xxxxxxxx for new developments on the application of sip From hgs@cs.columbia.edu Tue, 13 Sep 2005 06:16:08 -0700 (PDT) From: Henning Schulzrinne Date: Tue, 13 Sep 2005 06:16:08 -0700 (PDT) Subject: [Ietf-behave] NAT slides? Message-ID: <4326D12E.3060105@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain For a class I'm teaching, I'd like to include some basic information about various NAT types. Rather than duplicate work, I wonder if somebody has suitable PPT slides (obviously to be used with credit...). Thanks. Henning From ml-behave@ringle.org Tue, 13 Sep 2005 06:33:13 -0700 (PDT) From: Jon Ringle Date: Tue, 13 Sep 2005 06:33:13 -0700 (PDT) Subject: Re: [Ietf-behave] NAT slides? Message-ID: <200509130931.59930.ml-behave@ringle.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..27398.1163630135.multipart/mixed" --Boundary..27398.1163630135.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tuesday 13 September 2005 09:16 am, Henning Schulzrinne wrote: > For a class I'm teaching, I'd like to include some basic information > about various NAT types. Rather than duplicate work, I wonder if > somebody has suitable PPT slides (obviously to be used with credit...). Here are some slides I made a quite a while ago. It may be suitable. The files were created in Visio. Jon Attachment: NAT-types.pdf --Boundary..27398.1163630135.multipart/mixed Content-Type: application/octet-stream; name="pdf00000.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pdf00000.pdf" Content-Description: "Description: Adobe PDF document" JVBERi0xLjQKJcfsj6IKOCAwIG9iago8PC9MZW5ndGggOSAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nO2cXXPethGF7/UreJl0Rgx2scACmfYiSdtpO51OG7kXnclNvj9q5Tvt9N8X AEnswWtIlizZTiLZYw/JQ4IPSfDwkFy+3y1uZVlc/XsMfHx59t3ZW+/H5fMfzr5bZKUYozYFhz++ XN59UmYjXmh58tmZWygt5/WfW3xeQ8558ZJWScuTy7M3/vbmk6/O3KpcFn3yydkb72zjMe4N1mlP 9mnHPMs2zukK/X/buCRo49ttWgi+/NmnfTqZ9sM+bR99u46ehzVK2YaV27Q/7qsjWOynSVNPd0y+ Yvx0M9472RXfTNr8+oabcdr2jXfzH54s/zij5fPy78uz6MqxTbqQCwtzWL7/9Oyz35zx8t+i/qX8 +2o2x8UZl93337PS8hJcKsOXbThmWp4W1ZXGb9N90urKzt/+L50p5IWY61jtPn/ft0MpyrFt32/T PCcfju3/8tj3PiXap/1n7yaZgz/2wYfHvixz5n3aj8e+LM3x6T6H+ZbJfH/a93vBo3R6XGHZHyYs P/bjUfc4i4alnD1tf7KU3bCN1F3KIhm00gtQYw+aU9R8VtN82TOoKYEWwqAJsHgeWDwBi3cDC2dg YR1YOAILh4GFBVhqP0ONgIXywEIJWEgHForAQjKwkAcW4oGFCFhcHlhcAhYXBxYXgMXJwOI8sDga WJwzlrJ5yEI5EWgxDFoIoPk8aJxBIz9ozlgoJWShpMCS4sCSArCUc2DQGFiSG1g0A4umgUUVWDQM LCrAon5gUQYWdQNLzMASdWCJEVhiGFiiAEvkgSUSsEQ3sIQMLEEHlhCBJcjAEjywBB5YAgGL5IFF ErCIDiwSgUVkYBEPLEIDizhg8Xlg8QlYfBxYfAAWLwOL98DiaWDxDlg4DSyswMJxYOEALOwHFmZg YRpY2AELpYGFwHeJBt8lAt8lGnyXCHyXaPBdcuC75AbfLXMCixt8lxz4LrnBd8mB75IbfDeD7ebB dTOYbh48N4Pl5sFxMxhuGvw2gd2mwW0TmG0avDaB1abBaRMYrQ4+q2CzOrisgsnq4LEKFquDwyoY 7IlXlKhSEw6V871MGmPQXMD0U7qVX4/4U7p/3Ju9ewLilNa0JaCeRinLaRiFgPF0EoBm02Yh5r0b hpivJ9M+fTbElDO4Z5g23CNMV8qxAoW9KeVYmVLjy6HU9AKKkikhoCJGUJMLKGQENbeYUmPLodTU Ako0gppZQBEjqH0DFDKCmldMqXGlK4oENax0RZCgRpWuMBLUoHIoNaeYUmNKVyISuGAENaOA4o2g JhRQXCdo+aQrLZ50JQZUQjDFZ1Q4m0IeFdcJWi4xJakR1FQCSjCCmklAYSOoicQUzUZQ8wgoagQ1 jYAiRlCzCChsBNVdTInZCGoOASUaQU0hoIgR1AwCChlBTSCmhGwEQZEgRCMIggTBG0FgJAhkBJKR QJIRiCKBRCMQQQLxRiCEBOKMwGck8MkIfEQCH4zACxJ4bwSekMA7I+CEBKxGwBEJOBgBeyRgNgIm JGBnBJSQgMwTidATW7zoCnpiCxddQU9s0eJQHHpiCxZdQU9ssaIr6IktVHQFPTGbJWZ0xGyGmNEP s9lhRjfMZoYJvTCZFSZ0wmRGmNAHk9lgQhdMZoKKHqhmgYoOqGaAiv6nZn+K7qdmfuPZfUSH5HtC 8EN0eEYYokMqh34LDsWT7+vBiYhfNV754GSWGz66YZaYPWD5eF/WqcRnHky9+EOSob3Zw5nZOt6Z 5JAcXM8hddhyyKHUg24Ke1PqYe9KyyG70nKIKUqmhICKGEHLIaaQEbQc0pWWQ3al5RBTohG0HGKK GEHLIaaQEbQc0pWWQw5FkaDlkEMRJGg55FAYCVoO2ZWWQ7rScsihRCRwwQhaDjHFG0HLIaa4TrDl kEPZcsihxIBKCKb4jApnU8ij4jrBlkO6ktQIWg4xJRhByyGmsBG0HNIVzUbQcogpagQth5giRtBy iClsBM2puhKzEbQcYko0gpZDTBEjaDnEFDKClkO6ErIRBEWCEI0gCBIEbwSBkSCQEUhGAklGIIoE Eo1ABAnEG4EQEogzAp+RwCcj8BEJfDACL0jgvRF4QgLvjIATErAaAUck4GAE7JGA2QiYkICdEVBC AjJP3HKIKeaJWw4xxTxxyyFdceaJWw4xxTxxyyGmmCduOcQU88QthxxKNkvM6IjZDDGjH2azw4xu mM0ME3phMitM6ITJjDChDyazwYQumMwEFT1QzQIVHVDNABX9T83+FN1PzfyGszvBU+DUQl+53B/C EZii1CTCZZVPy9YEGLGY+AXOdonKsHhJN75cYG/b+sWVrV+0C/Y2AbSyG46YpSkuydd3dqLlv3Il Wo+gdcfIlLUOlQvLuj1r+eckqPx+Mm0WrmahZDbf7A3ULEj9ezJt9lZqFpA+eGPyiuyDN3tEymWP S+lA+xFscfU4GnfYnV7LfiwGtG4RlCa0OpnGk2nrZKtm7cU7LHvT+dxVzFTyfDWBqxd9XZs7Qz7m iykGxXVQm0/uYU/dZT5pKKE96HzNKKEVBUg56bUEivNirlkdX3mL8rt9Wirp92fYF15K1z+Z9vak vdl8s2lXrrcYSyo7OtTKDMpSUkGVPpnMfsMj8Mr6zg32zqy92d7xk2ky3OvipbilrRIbegDYk8p2 7c1e7BK9j1g++wJnu0RlWBwDwC1av7iydQgAqLk0BAAKLvbr/31e/X3kh3P1Py+XLF9uWZZzXsv9 J93V017ZheEGZ1SazDebNvO0xnIeV5fqA4NHv5n4TVxr6ZJfahdq7yJ/AV3nle2c0nXKWeX9L6rr vLoTi0vn8SktuHMeu87edUrKKabD99Z1HnPmLXNmvyUuEaM+ZEjanqbUh46SqdV0SKp1rpLjPlan BlcfUYiGNryVlIg2pSUwqYUrHPahtA/VFlJ7uCGttCSJ25YMTWkJp4xJbS8Fv49RGU7bsK9rSG3Z XYkRl1HC9nRvb1tXkhUoMu9s2bl9qNy8u74ZZST1LSSmABtPzNz3SxnZ4dq7Sb9Rb3uzPrdcb/9k Ia851juv+r9btES07Wl5WTcP77cix3DcgR+FweUyJccRPt5bUbntPe56e2GwzxpPg5kwDQW6ZVlV ckeOaiHsPKyuvnepJeNO0nZr+OfJ3DPKZTLfO5P5PpkQzabNtvrTyXzdcKPrN/uzaTO+9/cYXA50 fqZEGtYx24tPJ0fgcr9obu0Nu5EmTehkGk+mrRP0WXvxhsu6O8z31m1YmgXtJ4yvj5V2/ykjh+W0 E80z4UlYEr6doN4LeFCJI8fpTT708zsnBQugnAP4A7vN0pp1sCPXXaWMxN1u2DF1HyojwaZnmL/d /x0tiYN1iPb1swuHI+UycphaHVEwojJi28k6GBErGFEZMSNiHYyojN6fEUkdkCuN6KfJcf7ohqfG zLDaHeK5rElz4EfXuZvr3Hg3fj1p9spLwg12z6y92bL2XQiVUKKy5pzTwqGcxb6cFVH3apJaS0Ll LGfN21c4baRc0m7ezUP/hqvuD27fcPGqoXTxWE69uHXxv+79hE6gj2vn58/Rvz7RW3+yk+y8nJe5 PpEY7ylPU+9J59lHvzlZ108n4x+Ps5+inX5H9eGJ/slzxvtxvqL9E9rZ12ew9m9Plj7duNO1tZ5S zMnD12unhKf771R/DvGPJ4i9DuikU5/mqHjD5U838bS9X8EBsk/uXKsgaxdFqmezrsM3d1fIF80H it9ouycI6177p22+LMtRPEbkeL9R6DMkqTo59f0WAmZrj3M3NKkX3xza3UVdMLQ4cR8PWrmsKi7M pZ/y8E0oPlQ9rkX4sPT47hNK32fPWWclbLNytVn5+uw++6bLfj6ZNnuqMWOePbedlcTNln286b+P l0vk11aP8vjE7vl7bNkv2Gk/wce1/XZfIqujwzjPx0v8iTrr1Td8HjjziZmf/Gtw3lrhwME9W6lb fXcuYrUuB+rVusr3Va0bndQrx0Os1n23H51ercuRe7VuG+7Vul0pl1VQ2JviFJRarXsotVoXFCVT QkBFjKBW64JCRlCrdU2p1bqHUqt1QYlGUKt1QREjqNW6oJAR1GpdU2q1blcUCWq1blcECWq1blcY CWq17qHUal1TarVuVyISuGAEtVoXFG8EtVoXFNcJWrVuV1q1bldiQCUEU3xGhbMp5FFxnaBV65qS 1AhqtS4owQhqtS4obAS1WtcUzUZQq3VBUSOo1bqgiBHUal1Q2AhqPZ8pMRtBrdYFJRpBrdYFRYyg VuuCQkZQq3VNCdkIgiJBiEYQBAmCN4LASBDICCQjgSQjEEUCiUYgggTijUAICcQZgc9I4JMR+IgE PhiBFyTw3gg8IYF3RsAJCViNgCMScDAC9kjAbARMSMDOCCghAZkntmpdUMwTW7UuKOaJrVrXFGee 2Kp1QTFPbNW6oJgntmpdUMwTW7VuV7JZYkZHzGaIGf0wmx1mdMNsZpjQC5NZYUInTGaECX0wmQ0m dMFkJqjogWoWqOiAagao6H9q9qfofmrmN5zdLx4YvIZyEyX1PdMWGX4l709nkXb2rvTKcP/46v26 IP9rfvV+967z+Or9Nd+F+7y2/e7d2nbt6+x2ce8S2z3TuY9rs5VfwAkz6yaPZU6v3muldJnad35B Xvvqus6j175ur5XN0M7Dumm/ou75mCIfne21dZ1HZ/s5FHAOP/RSh6Pn42e+xp+bazVPsRU0kSeB EfhxsC9wxstRG5rYv4d5kXVcXLOO7auYbUNMjfvHve2VbX2y/FK+i/Uu1dKPh/dd7PCRfhv2x2dI w88I5a0itv3g7X54+5j9SMwXw5yXgza2gX3oliu5uGYl0IcG1e9fiPVedP8fV+1d6EF9XLV1oeCd /aJFHe5dqI3139xycDxD/eFsGHPQhWDOy0Eb2zi60Aus5OKalexdaJsC6tCFRF/G93m17zzgLnQc wzIMV7I6Cj8a6+zCsh3ePuLwSmYzXo7a0AR2oVuu4+KadUAXAnW4ktUO9HKuZFsfeoBXMoUfYKzD 0IcUfzhaBZKKRkgqNlvrQzbj5agNTRx96AXWcXHNOvY+1DbE1KEPqXtJaUgoPtA+lJP5UB2GPlRH 7QfGFTwip4wjgw/ZjJejNjRx9KEXWMfFNevY+1DbEFOHPpT5JfmQFKiH2YcUSjqaJ/U4NDiUYNjV iGFXAyZqmPNy0MY20IduuZKLa1YCPjSoQxyqTkTbd30vx4pEeE0PqxvVU7XX/yRM1YNJKQbezSVs DFM1zHk5aGMbaEW3XMnFNSsBKxrUoRtVM3pJ3Whzo4fXjerf/wP45S0YZW5kc3RyZWFtCmVuZG9i ago5IDAgb2JqCjM5NjQKZW5kb2JqCjIyIDAgb2JqCjw8L0xlbmd0aCAyMyAwIFIvRmlsdGVyIC9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nO1dXZPcuHV9n1/Rj+tUTRv34uMCLudh7aQqSaVSiUd5cJVf vNJ6ZUcte21vXPn3wQVJ3AMuetQjzUiWpndLWoIHBE6TlwcH5AX3+4M7cjg4/XfbeHm6+f7m+0M4 UkpJ2i7cfnk6/OLFzU9/RXygw4vf3bgD5cOt/nEHX46xlHLwIR9DPrw43Xz1Hz958YcbdxSuh754 dfPV10s5pbVB3fdi3bfVOSxlzmfw/1vKIUMbf1r2xejrP+u+byf7/rLuW4s/0+KtHJ3+hiO3fb/a Ub6gmb/uGP95KXsPh/x+rbM1+/L+Jma9vprs25+sX+7Y/3FyzNsLT9a+7Ysv5j+/OPzXDR2+q39+ f5NcjaAsB3LxwBwPf/725nf/cMOHv1X03+qfP8xq3N1wPTV/u6ktH6LLdfvUtlOhw5uKutr4Q4I0 H1043C5/15CN5UDMWtIg/c/1dwilwLtLyNnHvL+EPmda9/3vGoyFo9/OwW+3c1lrlv31rc39KLKg 3mFS71/W817pUd5fVzj2LxMuf+3XQ884B4mHeo+288mhnoaloKeUQyiA1ShAjD1gThDzRQzz9cwg JgRYjAMWgIvngYsn4OLdwIULcGEZuHACLhwHLhyAi8YZYgRcqAxcKAMXkoELJeBCYeBCHrgQD1yI gIsrAxeXgYtLAxcXgYsLAxfngYujgYtzxqX+PORCJRNgKQ5YjID5MmBcACM/YM64UM7IhbIAl5wG LjkCl3oPDBgDl+wGLlKAi+SBiwhwkThwkQBcxA9chIGLuIFLKsAlycAlJeCS4sAlBeCSeOCSCLgk N3CJBbhEGbjEBFxiGLhED1wiD1wiAZdQBi4hA5cgA5eQgEsIA5fggUuggUtwwMWXgYvPwMWngYuP wMWHgYv3wMXTwMU74MJ54MICXDgNXDgCF/YDF2bgwjRwYQdcKA9cCHSXaNBdItBdokF3iUB3iQbd JQe6S27Q3VoTuLhBd8mB7pIbdJcc6C65QXcLyG4ZVLeA6JZBcwtIbhkUt4Dg5kFvM8htHtQ2g9jm QWszSG0elDaD0MqgswIyK4PKCoisDBorILEyKKyAwO60oloVdTj10qqPaSan/qzFBs0BdD81Wjbz U2+a+Ejupw6bandPZnfRXMyMyWZ5nYTk7zE1lxqnlxe2N+Py6kLj9MsLjdPbyb5vf2ycqmp039S2 u23qSI0PQNgbUuPDELVMG6KOCRAhQ2JEJBgDdUuAkDFQr2SIWqUNUacESDIG6pMACcZAXRIgZAzU IxmiFqkjggzUIHUkIAO1Rx1hZKDmaEPUGxmi1qgjCRm4aAzUFwHijYG6IkBcZ9A8UUeaJepIiojE aIgviHAxhDwirjNoXsiQLMZAnRAg0RioDwKEjYG6IEOkGAP1QICIMVAHBEgwBup/AGFjoIpmSCrG QL0PIMkYqPMBJBgD9T2AkDFQ12NILMYgCjKIyRjEgAyiNwaRkUEkYxAKMgjZGARBBiEZgxCQQfDG IBAyCM4Y+IIMfDYGPiEDH42BD8jAe2PgCRl4Zww4IwMWY8AJGXA0BuyRAbMxYEIG7IwBZWRApolE qInN0nQENbEZmo6gJjY7syEONbGZmY6gJjYr0xHUxGZkOoKaWEwSCypiMUEsqIfF5LCgGhYTw4xa mE0KMyphNiHMqIPZZDCjCmYTQUENFJNAQQUUE0BB/ROTP0H1ExO/8e7e7Er2vLkSH9Gu/AgY7Equ l36xK1WTH+thTQj+KOnsw5ofJuP3N5N9byY+5FJv8ggPZt7pdWZ9fD3xISW67kN023zIhuhFN4S9 IXrZO9J8yIo0H2KIkCExIhKMQfMhhpAxaD6kI82HrEjzIYYkY9B8iCHBGDQfYggZg+ZDOtJ8yIYI Mmg+ZEMCMmg+ZEMYGTQfsiLNh3Sk+ZANScjARWPQfIgh3hg0H2KI6wwWH7Ihiw/ZkBQRidEQXxDh Ygh5RFxnsPiQjmQxBs2HGBKNQfMhhrAxaD6kI1KMQfMhhogxaD7EkGAMmg8xhI1BU6qOpGIMmg8x JBmD5kMMCcag+RBDyBg0H9KRWIxBFGQQkzGIARlEbwwiI4NIxiAUZBCyMQiCDEIyBiEgg+CNQSBk EJwx8AUZ+GwMfEIGPhoDH5CB98bAEzLwzhhwRgYsxoATMuBoDNgjA2ZjwIQM2BkDysiATBMXH2KI aeLiQwwxTVx8SEecaeLiQwwxTVx8iCGmiYsPMcQ0cfEhG1JMEgsqYjFBLKiHxeSwoBoWE8OMWphN CjMqYTYhzKiD2WQwowpmE0FBDRSTQEEFFBNAQf0Tkz9B9RMTv+HuzvDkOTfTV4f7DdgMUwrqRLh2 +ab+mggFs4mvsdoJkeHw6m58HWAf2vrd2dbv2oC97ACsnobNZklOh+z1HWCQ+lcdiY6b0fpAy1RE t+rAclzecP33xKj802TfzFzNTMms3uyt18xI/c9k3+whz8wg/earydOl3/ykW6RSz3ioAbRewWZX t6vxAafTSz2PVYCOiwWlCVuZ7OPJvuPkV83aSx9w7KX13DnOVP28isD5Qz/Vz51R3uqlnKJgH9Tq hUc4Ux9SLzQq8ZiIyiemElu6Q6g3vVRDcVvFtYjjs1OUf1z35ep+/w5j4UlCf7fvZ5P2ZvVm+872 W4Ul1xMdNeeESqiu4NxD7QuvwEeLnQvOzqy92dnxk31hmOviUNzcVrUN3QCsTmUZe4sPNkSvBfNn r7HaCZHhcDQAD2j97mzrYAAQc3kwABRd6uP/Y47+PvHzGf1v65Dl65TlcMvHOv+kD9W0jzYwXHBH 5Um92b6ZpjUut+nosj4wuOrNRG/S0edc78FbOdZ7oU5ZP4PQ+Wgnp4ZOvavqnOVzCp2Pd2NxDZ72 tApOzjV01tCpLqeKDj9a6Fx95gN9Zp8SV4uhDxmytKcp+tAxFGrpKSFr6kkoaS3p3uj0EUWQ2LaX NJYgDWkOLGiyDMd1K69b2kJuDzdC0tdBObjlyNiQ5nBqKWh7Ofq1RHU7L9tee8jt2BVJCY8RwvZk bW/pK4cjsCi8civOrVt18u76z6iF3H8hMUX48cTM/bzUwkquvZv0C+vlbOpzy+PDnyyUY0k689K/ 3UGqRVuelte+eXi/lTjFbQbe88nFh+0Kb++tqE57t1lvT0b2RdLemAWmISm4HitCbsj5uY1Hp+9d NBnehbxMDf91UnvG8jCp9/Wk3qsJo9m+2a/+dlKvC25yfbI/2zfj15P9WaPmfB+zs/hmcgVO66C5 tDecRpo0IZN9PNl3nFCftZcuPNZ9QL2fPoRLk6D1hvH6WGnVn1rYJKfdaJ4Jb8Lq8O0G9T6ABlU7 st3e5GO/v0sWkAAqJYI+sFskrUkHO3JdVWohrXLDjqnrUC1E21+gfpv/bS0FB30E6f2zi5silVrY RE0LAkJUC/Y7WQYhYgEhqgUTIpZBiGrx8YQo6EY4K0Q/TK7zNxfeGjPBajPE23DMUiJfVefDVOfi 0/h20uzZIeGC0zNrb3asrUWhakokHEsp+cCx3sW+3hVJ1mwSzSWhepezlGXlTyvUIe3yMI99dZqe D26r0/gosYZ4qrdeWkL839c4oR3pbez87h342x3e4slusjqjjEWfSIQhOvaudxc8a/GPu75+2JV3 68f21PZrt367w1+9o9yv85n2d2xn6+qg9z/tjt7/uH1vLVKqOOkDnW1d3p7h/vzt8Xcw3i+426/P e7s7fH8C33X8/ifu2/sCLlBf5ldaImAbEzUtrI1HtszvDHrXVIBcG28L0XKnL0VK6xNUfRJKLqRa IWCFxdmT5tEsyBus1h7mNmJ56dVJmzPoFMY/zitWDrHWrv/hLTFtWx2JT1S3gQiflG7LWalOivex ALO/Wf7aLFdtlrs+m2Rfeux3k32zRxozzrOHtrN8uNmx1xn/Y7xZquG/vNu7Pq575xk7rKN1Xu/w sbefr0cUcbSp5u04vu/QWVR/IQ8DZzo207tfD8OCpl9wdD9OI9ZRYQ5iKjFH6qnEwo+VSpxc0GHt OaYS/6JfnZ5KzIl7KnHb7qnEHaljPiDsDXECiKYSb4imEgMiZEiMiARjoKnEgJAx0FRiQzSVeEM0 lRiQZAw0lRiQYAw0lRgQMgaaSmyIphJ3RJCBphJ3JCADTSXuCCMDTSXeEE0lNkRTiTuSkIGLxkBT iQHxxkAtECCuM2ipxB1pqcQdSRGRGA3xBREuhpBHxHUGLZXYkCzGQFOJAYnGQFOJAWFjoKnEhkgx BppKDIgYA00lBiQYA305AwgbA002NCQVY6CpxIAkY6CpxIAEY6CpxICQMdBUYkNiMQZRkEFMxiAG ZBC9MYiMDCIZg1CQQcjGIAgyCMkYhIAMgjcGgZBBcMbAF2TgszHwCRn4aAx8QAbeGwNPyMA7Y8AZ GbAYA07IgKMxYI8MmI0BEzJgZwwoIwMyTWypxICYJrZUYkBME1sqsSHONLGlEgNimthSiQExTWyp xICYJrZU4o4Uk8SCilhMEAvqYTE5LKiGxcQwoxZmk8KMSphNCDPqYDYZzKiC2URQUAPFJFBQAcUE UFD/xORPUP3ExG+4u9/fMHhfjukQ9CXYYhm+ED83s9yzF7lnJx/XvID7JhqaF7CsCfjy8gI+PHSu eQGf+ClBFTVNeNLkFb2FP2XUpTUilinTrWYJePks7pdZlFxTsD6+1IZ0bJ87+4yk9uOFzlVqP7XU hqOe0dt4XKAvKDqvHvLJha0Nil+gsF095GcvbMtDfoKvIel28rx99Yzwy5HUFs+klmtF1NbLbAX4 Nt1rrHgasaGJdanO+/Rxd08fy4Kd5YcYmtZ1x+17tuToaZbssrBmpTy/JbtLDPXV+5rgt62QGqJr XX/dvv+7Xt5ewsXeWPM0YGMbGEMP7OTunk4ghgbUr4vXehQ9/rqvNYSe1bqvJYR8dvZxCt3uIdRK 2+ezxMH19LkMJQchBDVPAza2sYXQe3Ryd08nawgtewAdQsjzUywdrK0+5xDarmHdhpFMi/aN2XbV 1oFluby94HAks4qnERuawBB6YB939/QBIQToMJJpAD3JSLbG0PMbyeop7DHUti2GWhG+BW7XtyIF CxhDUPE0YkMTawy9Tx939/SxxNDyQwzFGGInTxRDmtn+PGPImx1p2xBDHtyupk7YJfXgdoev7L/G irsv8A9NbDH0Hn3c3dPHGkM+DugQQ/6pHHVM7pnGkN6nPQ3Fgx0aFYrBqawSYSWwQ1jzNGBjG6hD D+zk7p5OQIcGFO1QUyJalhw+jRSFwMf8vMLIW17QIks9jAaRwjnTqhK9hBMzrDl+3HpsA6XogZ3c 3dMJSNGADmGkYvREYbSo0fMLoy3Nyb7i3Cdn/ZvOp5b+BDOlmHHqDd9+fj3UPA3Y2MbmrN+jk7t7 Olmd9bIH0GFyFrmFkYcwehxrLV5X5+nXcJ/NkHZmMVdeBncuu9tpt3wn7ZdQlx2zc8t7Xu7Kr3ft 7et/s8O3/OBhLd09V7bGYjpEXRX6WSQaXd9+/128JFoUVvAxuOC3MtfSon6C37MkwQ9aWr0msYKf tERsbGOT2Pfo5O6eTlaJlbhH4dOZuvr1aaYNobb03L6dqV/P0tVoj/TxrOvLtOsHAR9xCDCR6yKj M5OYxTSuZ/U3UeHkgslPL1me9euh5mnAxjZQ4x7Yyd09nYDGDWiU7VsOXeWeZj6yytyzmo/c8vUj gV/WRwI/mg21/6NthtXs+uEKW+t+DloXuuv7yb7MXQvjIvfSpKIvc2+1l0XuxceOvBkr9oXulHNf 515V8vh4C91DclUhruvckfN1nfunNkzXde7Xde5P4FUftM5dg5BTdaHXILwG4SOalYd/bEH//X+x 3UDtZW5kc3RyZWFtCmVuZG9iagoyMyAwIG9iago0MzcyCmVuZG9iagoyNiAwIG9iago8PC9MZW5n dGggMjcgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXduS3bYRfN+v4KOdqqUx g8sAruTBdlKVpFKpxKu8+cWWZMuOjnxPKn8fACQxDQpndVa7q4v32CWZQINAH3LYbIID+sfJzOwm U/7dNh4fLn68+HFyM4UQpFbh9uPD9Omji48+J55oevT1hZkoTpflj5lsmn1KabIuzi5Ojw4XH/z9 w0ffXZhZOO/66MnFB58s5RDWDkvdo7VuazMtZY5H8P8tZRehjx+WOu9t/metezqo+3mtW4sfl+Jl nMnl3zBzrfvHgOL3g65+WuqshbpfdtT3P+Xz3eE4geK+y9Gw365ttm4fX9/FaNQng7o9+8927EdH 5cWJJ2Lf98mB8qdH0z8vaPom//n2IpgcnVEmMn5i9tNPTy++/t0FT//N6F/zn+9GLa4uOB+a/17k nidvYt4+1O2QaHqeUZM7v8kFEGeTw2f5O18OPk3EXErlAtiiSSg43p1CjtbH/Sm0MdJa95810BN7 ux2DL7djmVum/fnN3b0UWdBuGrT783rcMz2K+/MK+/484PJLOx/liLMTP+Xrvx5PdvkwLIVySNm5 BFiOAsTYAmYEMZtEMZuPDGJCgHnfYQ64WO64WAIu1nRcOAEXlo4LB+DCvuPCDriUOEOMgAuljgtF 4ELScaEAXMh1XMgCF+KOCxFwManjYiJwMaHjYjxwMa7jYixwMdRxMUa55J+HXChFAiz4DvMeMJs6 jBNgZDvMKBeKEblQFOASQ8cleuCSr4EOY+ASTcdFEnCR2HERAS7iOy7igIvYjoswcBHTcQkJuATp uIQAXILvuAQHXAJ3XAIBl2A6Lj4BFy8dFx+Ai3cdF2+Bi+eOiyfg4lLHxUXg4qTj4gJwca7j4ixw cdRxcQa42NRxsRG42NBxsR64WNdxsRa4WOq4WANcOHZcWIALh44Le+DCtuPCDFyYOi5sgAvFjguB 7hJ1uksEukvU6S4R6C5Rp7tkQHfJdLqbWwIX0+kuGdBdMp3ukgHdJdPpbgLZTZ3qJhDd1GluAslN neImENzY6W0EuY2d2kYQ29hpbQSpjZ3SRhBa6XRWQGalU1kBkZVOYwUkVjqFFRDYnVZkq1IcTj59 tloc69xqgkbV6HzyXWLpsRacNWuXt3c/HOIc4lH3M3IXI0c0cjUjB/P5wMGM3M/mq4248JJfh/5O dWePT+xvxOXJie7ssxPd2YtB3dOX3VmWpmbO6nbzZg3JQQgIW0VyECpSfNmGFFsGiJAi3iPilEGx ZICQMiiGTJHixzak2DFAgjIoZgwQpwyKFQOElEExYooUH9YQQQbFhTXEIYPiwRrCyKA4sA0pBkyR 4r8aEpCB8cqgmC9ArDIo1gsQ0xhU49WQ6rsaEjwi3itiEyKcFCGLiGkMquFSJIoyKHYLEK8MitkC hJVBsVqKSFIGxWgBIsqg2CxAnDIoJgsQVgZFNhUJSRkUgwVIUAbFXgHilEExV4CQMijWShGflIEX ZOCDMvAOGXirDDwjA0/KwCVk4KIycIIMXFAGziEDZ5WBI2TgjDKwCRnYqAxsQAbWKwPrkIG1ysAS MrBGGXBEBizKgAMyYK8M2CIDZmXAhAzYKAOKyIBUE4lQE6tvaghqYnVNDUFNrJ5pQwxqYnVMDUFN rH6pIaiJ1S01BDUxqSQmVMSkgphQD5PKYUI1TCqGEbUwqhRGVMKoQhhRB6PKYEQVjCqCghooKoGC CigqgIL6Jyp/guonKn791b15omiL26kTP9ajK3oJ6HxRzKd+cUVZk+9qRsg5O0s46ol+Hdy/vxrU PR/4kFO9yR3M/rzS64zG+GTgQ5I3zYeUbfUhG1JOuiJsFSmnvSHVh6xI9SGKCCniPSJOGVQfoggp g+pDGlJ9yIpUH6JIUAbVhyjilEH1IYqQMqg+pCHVh2yIIIPqQzbEIYPqQzaEkUH1IStSfUhDqg/Z kIAMjFcG1YcoYpVB9SGKmMZg8SEbsviQDQkeEe8VsQkRToqQRcQ0BosPaUgUZVB9iCJeGVQfoggr g+pDGiJJGVQfoogog+pDFHHKoPoQRVgZVKVqSEjKoPoQRYIyqD5EEacMqg9RhJRB9SEN8UkZeEEG PigD75CBt8rAMzLwpAxcQgYuKgMnyMAFZeAcMnBWGThCBs4oA5uQgY3KwAZkYL0ysA4ZWKsMLCED a5QBR2TAogw4IAP2yoAtMmBWBkzIgI0yoIgMSDVx8SGKqCYuPkQR1cTFhzTEqCYuPkQR1cTFhyii mrj4EEVUExcfsiFJJTGhIiYVxIR6mFQOE6phUjGMqIVRpTCiEkYVwog6GFUGI6pgVBEU1EBRCRRU QFEBFNQ/UfkTVD9R8euu7gjT27Gavny734DNMAVXnAjnIZ/nX+OhoDbxGTY7INLtnt2NzTfYm/Z+ dbT3q3rDXioAy4dhs1kSwxTrzJGT/Fe+E82b0bqlZUpStvKNZV5eo/1rYFT+OKgbmauRKRm1G71a Gxmpfw/qRpM8I4P0xQeD2aUvPmwWKeUj7nIArWew2tXtbNzicFrJxzEL0LxYUBqwlUEdD+rmwa8a 9Rduse+p7cwxzpT9fBGB47u+rZ87ory1CzF4wTGotnN3cKRu085VKn4OROktU/E1X8Pli16yobjM 4prE8NFHlD+sdTG733cwFu4l9Hd1Hw/6G7Ub1R0dNwtLzAfal6QZSi67gmOT2ieegTcWOyccnVF/ o6NjB3Wue9bFW3F1W9k2NAOwOpXl3pus01v0WlB/9gybHRDpdkcDcIPer472DgYAMRM7A0DehHb/ v8u7vw38cO7+l/mWZfMjy3TJc37+pNtq2hu7MZxwRcVBu1HdSNMql8swm1gmDM56M9CbMNsY8zV4 KXO+FvIj63sQOm/s4OTQyVdVfmZ5n0LnzV1YnIOnzlbBwTmHzho62eVk0eE7C52zz7yhz2yPxNli lEmGKHU2pUw6ukQ1YcXFksDrUlhLpdabMkXhxNftJVfGSUWqA3MlI4f9uhXXrdJDrJMbLpTXQdEt KTHOV6Q6nFxypb/o7VqivB2XbVtGiHXfFQkB9xHC/mTtbxkruhlYJF65JWPWrfzwbtrPyIXYfiEx efjxxMztuOTCSq6+m7QL6+VolnnL+eYzC2lOoTx5lb/NJNmiLbPleWzu3m8FDn57Am9J62Lddoa3 91aUH3u3p96W8WyThL0xc0xd5nHeV4RMl/Nz6WdT3ruUbH7j4vJo+JdB6xHLadDuk0G7JwNGo7rR r346aNcEN5j2sD+qG/FrKwq4RM3xMUZH8fngDBzWm+bSX3cYadCFDOp4UDcPqI/6Cyfua27R7qOb cKkStF4wtkwrrfqTC5vk1AvNMuFFmB2+XqDWOtCgbEe2y5usb9d3igISQCl50Ac2i6RV6WBDpqlK LoRVbtgwNR3KBa/1CdrX57+tJ2dgDCdtfDZ+U6SUC5uolYKAEOWC/k6WTohYQIhyQYWIpROiXLw7 IXJlwx0Vol8H5/mrEy+NkWDVJ8RLN0dJns+qczvVOfkwvhh0e/SWcMLhGfU32lcXvFA2JeLmlFKc 2Oer2OarIsiaTVJySShf5SxpWV5UC/mWdnqY+7a8rhwPrsvreBafQzzkSy8sIf63NU5oR3q7d37z CvzFDq/xpBdZfqL0qcxIuC469q53Fzxr8fvdWL/uyrtFantq+wViX+7wJ68ot/N8pP8d29HCQBj9 h93e+x+3H61GShYnCwsL9wz3x2+Pv4LxflXffhHgi93u+wP4qv33P3Hf32/gBLW1hKkmAtZ7Yk2X lxnXEh5Br6oKkKn320S0XOlLkcI6g1pmQsm4kBs4bLA4eyp5NAvyHJvVydxKLC6jGqnPDOURxt7N K1Z2PrfO/+EtMW1bgokzqtuNCGdKt/W4lB+K97EAT3+j/LVRrtood330kH3qvt8M6kZTGiPOo0nb UT7caN/zE/9dvFnK4V9eLZ2n6044YtN6t47rFd6P9vt1jySGNtW87O/vO3QU1efJQHipt6UWszcv pxaXO8UYxPRi9tTSi4XvKr04GFdudQ8xvfjTdnZaejEHbunFdbulFzck+wBA2CqStUeRkl68ISW9 GBAhRbxHxCmDkl4MCCmDkl6sSEkv3pCSXgxIUAYlvRgQpwxKejEgpAxKerEiJb24IYIMSnpxQxwy KOnFDWFkUNKLN6SkFytS0osbEpCB8cqgpBcDYpVBsUWAmMagphc3pKYXNyR4RLxXxCZEOClCFhHT GNT0YkWiKIOSXgyIVwYlvRgQVgYlvVgRScqgpBcDIsqgpBcD4pRBeWEDCCuDkoCoSEjKoKQXAxKU QUkvBsQpg5JeDAgpg5JerIhPysALMvBBGXiHDLxVBp6RgSdl4BIycFEZOEEGLigD55CBs8rAETJw RhnYhAxsVAY2IAPrlYF1yMBaZWAJGVijDDgiAxZlwAEZsFcGbJEBszJgQgZslAFFZECqiUSoiTW9 uCGoiTW9uCGoiTW9eEMMamJNL24IamJNL24IamJNL24IamJSSUyoiEkFMaEeJpXDhGqYVAwjamFU KYyohFGFMKIORpXBiCoYVQQFNVBUAgUVUFQABfVPVP4E1U9U/Lqr+/UNg7VpDpMrL8YWy/Ab8Xgj Gz7yc0cfSM65Atc9fFCapQr9XI/R2/zN9TE4x/PiSS/Lq1kr70XywugB/pz38ubzXlyY64es3qO8 lzcXOue8l7c8C2bdXIJwuvTzgv2GwvN8l75XZVvmqQg+8lG2g+Xti0GEX12jmhMeagoBUU0D3wrw Xadn2PDQY10Xawb664xxdc0YSx768kMUDetyuvotyPwccT8r0Vi4vGx9eCvRlhhqi1JL3sqW+N9F 17qssH47cz29rYRrGLHlocP6PjCGbjjI1TWDQAx1qF3XZLQouvvlDGsIPajlDEsI2Wh0zXXZbiFU S9tXYcTA+bQxdSUDIQQtDx3W97GF0GsMcnXNIGsILTWAdiFk+T5WxOReH2YI5QPYzmHd1jtZLcI3 UE27sWQkYcHAnQwaHnqs62INodcZ4+qaMZYQWn6IongnYyP3tKa6JNs9yDtZPcbtDYYFGeqji0Eh 1tOrJZAhbHnosL4PjKEbDnJ1zSAQQx2KMlSjiJYM9vsJI+d4jg8rjKyHF3toiPQ7h4f6+g/OqUWv gt9DfNa17L+V2PexhdFrDHJ1zSBrGFm/Q7swssUQ3U8YBfMww2h7Q6YfBWymqH0i8FDfnIFD8REt L3xK8FnXsv/MYN/HZopeY5CrawZZTdFSA2hnijzXMLIQRndji8SWZO/ycbUHc0s7khsc6+XEnHaX 0y4bNOxX5KQds2PZoo935We7/vbtv9rhW2pJl5p9zZnNsRgmvzw5vQfvqM7z+u/Q7Jfg9JPgp5fW 0qJ+gp9HIsHvI2m7KrGCX0hCrO9jk9jXGOTqmkFWiRW/R+FLTGUxxf08Nrjc00P7FFP5GENJbr6j bzGc33+cvy9z56monciUJxMfRTWuJYRVUeFgnMpPK2mKzrOu5aHD+j5Q4244yNU1g4DGdaiXbWlg U7n7eR5ZZe5BPY9c8vmbM7+tb868MRuq/xe2CIujyjpIXTp1DFrXTZX3Am3VVCn0a6ZSlYq2aqq2 XtZMJesb8rxv2NZNUYxt2VRWyTtcN+WCyQpxXjZ1Xjb1Lhmm87Kp87Kpd9GrlsCsuZnnwDwH5rtk YI5MoxaPEt63adRLP5dkwfr/cyuV7wXp6iDLv/8HY1LKqWVuZHN0cmVhbQplbmRvYmoKMjcgMCBv YmoKNDI3MAplbmRvYmoKMzAgMCBvYmoKPDwvTGVuZ3RoIDMxIDAgUi9GaWx0ZXIgL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnic7V1dj922EX3fX3EfkwJ7wxl+DBm0DwlaoC2Kos26b3lJnA8n9eY7DfLv y6EkzqHMu96113acvQ3sijwUeS5FHR5RQ/n7gztyODj9bzt4fH3x/cX3h3CklJK0LDx+fH348NHF ex8RH+jw6IsLd6B8uNQ/7uDLMZZSDj7kY8iHR9cX7/zz3UdfX7ijcD310WcX73ywpFNaK9S8R2ve VuawpDmfwH9d0iFDHd8teTH6+r817/NJ3o9r3pp8X5OX8ZhT/Q1HbnlXE4qzJq+XvOyh+lnejMZP u5/4w5L2eN5Xa5ntZz8eqe976dY9/ZdHh39f0OHL+ueri+Tq5c1yIBcPzPHww+cXX/zhgg+/VPTv 9c/XsxJXF1xp/HJRaz5El+vxdTtOhQ5PK+pq5XcZQfnowuFy+buOp1gOxKwpHUH/Wn+HUAq86y7O PuZ9d/mcac3733rZCke/9cEn2+WoJcv+ctTqeH/ZoNxhUu6va79XerRx+XZy7o8TLj/166E9zkHi od5ArT851G5YEtqlHEIBrA4SxNgD5gQxX8QwX3sGMSHAYhywAFw8D1w8ARfvBi5cgAvLwIUTcOE4 cOEAXHScIUbAhcrAhTJwIRm4UAIuFAYu5IEL8cCFCLi4MnBxGbi4NHBxEbi4MHBxHrg4Grg4Z1zq z0MuVDIBluKAxQiYLwPGBTDyA+aMC+WMXCgLcMlp4JIjcKn3wIAxcMlu4CIFuEgeuIgAF4kDFwnA RfzARRi4iBu4pAJckgxcUgIuKQ5cUgAuiQcuiYBLcgOXWIBLlIFLTMAlhoFL9MAl8sAlEnAJZeAS MnAJMnAJCbiEMHAJHrgEGrgEB1x8Gbj4DFx8Grj4CFx8GLh4D1w8DVy8Ay6cBy4swIXTwIUjcGE/ cGEGLkwDF3bAhfLAhUB3iQbdJQLdJRp0lwh0l2jQXXKgu+QG3a0lgYsbdJcc6C65QXfJge6SG3S3 gOyWQXULiG4ZNLeA5JZBcQsIbh70NoPc5kFtM4htHrQ2g9TmQWkzCK0MOisgszKorIDIyqCxAhIr g8IKCOxOK6pVUYdD9X6vWaMNmgPofqhq8Gp+6p0Q1kpf3v9wTsfFQF9N7M+vEyuxOc/oJKQb8ma2 ZmZ/bmuxHj9rYer92x1MO+4GpiP1SgHC3pB6pQxR87Ih6l0AETIkRkSCMVDfAggZA3Uthqhp2RD1 LIAkY6COBZBgDHRkAELGQN2KIWpWOiLIQK1KRwIyUKPSEUYGalM2RF2KIWpSOpKQgYvGQB0KIN4Y qD8BxHUGzZ10pJmTjqSISIyG+IIIF0PII+I6g+ZKDMliDNSTABKNgToSQNgYqB8xRIoxUDcCiBgD 9SKABGOgTgQQNgaqLYakYgzUhQCSjIF6EECCMVAHAggZA/UfhsRiDKIgg5iMQQzIIHpjEBkZRDIG oSCDkI1BEGQQkjEIARkEbwwCIYPgjIEvyMBnY+ATMvDRGPiADLw3Bp6QgXfGgDMyYDEGnJABR2PA HhkwGwMmZMDOGFBGBmSaSISa2MxFR1ATm7XoCGpiMxYb4lATm63oCGpiMxUdQU1slqIjqInFJLGg IhYTxIJ6WEwOC6phMTHMqIXZpDCjEmYTwow6mE0GM6pgNhEU1EAxCRRUQDEBFNQ/MfkTVD8x8Rvv 7s04ZN/9gR+MwzPAYBxyvfSLcaiafF/LJiH4o6STyyY/T+b+Tyd5Tyfz/Mm5v56r9sLf3xLJUN/M m8za+GDiQ0p03YfosfmQDdGLbgh7Q/Syd6T5kBVpPsQQIUNiRCQYg+ZDDCFj0HxIR5oPWZHmQwxJ xqD5EEOCMWg+xBAyBs2HdKT5kA0RZNB8yIYEZNB8yIYwMmg+ZEWaD+lI8yEbkpCBi8ag+RBDvDFo PsQQ1xksPmRDFh+yISkiEqMhviDCxRDyiLjOYPEhHcliDJoPMSQag+ZDDGFj0HxIR6QYg+ZDDBFj 0HyIIcEYNB9iCBuDplQdScUYNB9iSDIGzYcYEoxB8yGGkDFoPqQjsRiDKMggJmMQAzKI3hhERgaR jEEoyCBkYxAEGYRkDEJABsEbg0DIIDhj4Asy8NkY+IQMfDQGPiAD742BJ2TgnTHgjAxYjAEnZMDR GLBHBszGgAkZsDMGlJEBmSYuPsQQ08TFhxhimrj4kI4408TFhxhimrj4EENMExcfYohp4uJDNqSY JBZUxGKCWFAPi8lhQTUsJoYZtTCbFGZUwmxCmFEHs8lgRhXMJoKCGigmgYIKKCaAgvonJn+C6icm fsPdnWENODfTV6f7DdgMU9KViTqaSkVyiJAwm/gEi10jMpxe3Y2vE+xda786WftVm7CXDMBqN2w2 S3I6ZK9vvoLUv+pMdNyM1ktapiJ6VCeW4/Ku6T8To/LnSd7MXM1Myazc7P3TzEj9d5J328Wbj9+Z rN58/G63SKX2eKgDaL2Cza5uV+MlutNL7ccqQMfFgtKErUzyeJJ3nPyqWX3pJc69bTl3ijNVP68i cPrUN/VzZ5S3cimnKNgGtXLhHnrqZcqFRiUeE1F5w1RiiwoI9aaXaiguq7gWcXzyEeVPa16u7vc3 OBZeydDf5b0/qW9WbpZ3st0qLLp0HTU0g0qorkChzybFb3kFXtvYuUXvzOqb9Y6f5IXhWRen4ua2 qm3oBmB1KsvcW3ywKXpNmD97gsWuERlORwNwh9qvTtYOBgAxlwcDQNGlPv/f5+zvEz+c2f+yTlm+ PrIcLvlYnz/pZTXttU0Mt7ij8qTcLG+maY3LZTq6rAsGZ72Z6E06+pzrPXgpx3ov1EfWt2DovLbO qUOn3lX1meVtGjqv78biOnjaahV0znnorEOnupwqOnxvQ+fsM+/oM/sjcbUYusiQpa2m6KJjKNRi OkLWKNdQ0prS3Oh0iSJIbMdLQEmQhjQHFjRsheN6lNcjrSG3xY3QAktycMuZsSHN4dRU0Ppy9GuK 6nFejr22kNu5K5ISniOE9cla39JWDkdgUXjlVpxbj+rDu+s/oyZy/4XEFOHHEzP3fqmJlVx7N+kX 1ktv6rrl8e4rC+VYkj556d/uINWiLavltW0e3m8lTnF7Au9R1OLDdoW391ZUH3u3p94eFuyLbHEx 3ZgFpiE8t54rQm7zUc2EXcaj0/cuGjPuQl4eDf82KT1jeZiU+2BS7rMJo1ne7Fd/PinXBTe5/rA/ y5vx+2i1wfVCl2cCpKGNWS8+nVyB63XSXOobupEmVcgkjyd5xwn1WX3plue6lyj33l24NAlabxiv y0qr/tTEJjntRvNMeBNWh283qPcBNKjake32Jh/7/V2ygARQKRH0gd0iaU062JHrqlITaZUbdkxd h2oiWn6B8u35b6spOGgjSG+fXdwUqdTEJmqaEBCimrDfyTIIEQsIUU2YELEMQlST9ydEQQ/CSSH6 eXKdP73lrTETrPaEeBmOWUrks+q8nOrcuhu/ucuUcIvumdU3O9d2hVA1JRKOpZR84FjvYl/viiRr NInGklC9y1nKsgenJeqUdvthHvsmLu0Pbpu4+CixDvFUb720DPF/rOOEdqS3ufPL5+Df7PA2nuwm q0+UseiKRBhGx9717gbPmvx219bPu/Ru19Se2n4X1Sc7/LPnpPt1PlH/ju1s+xm0/t3u7P2P27fW RkoVJ13Q2bav7Rnu+2+PP4fxfqfaflfaN7vT9x34vPP3P3Ff3+/gAvUNd6UFArY5UcPC2nxkG+5O oFdNBci1+bYQLXf6kqS0rqDqSii5kGqBgAUWZ08aR7MgT7FYW8xtxPLSqpP2zKCPMP5+XrFyiLV0 /T/eAtO2fYq4orpNRLhSuu36pPpQvB8L8PQ3i1+bxap9Myk3e8i+7blfTvJmSxozzrNF21k83Ozc 8xP/fbxZqsNfXy2dl+tu0WOHdbbO6x0+tvbH9YwijjbVvBzn9x06G9XnxUB4qbeFFnN0z4YW60wx BzG8mCP18GLh+wovTi7oVPcQw4s/7Fenhxdz4h5e3I57eHFHqg8AhL0hVXsM0fDiDdHwYkCEDIkR kWAMNLwYEDIGGl5siIYXb4iGFwOSjIGGFwMSjIGGFwNCxkDDiw3R8OKOCDLQ8OKOBGSg4cUdYWSg 4cUbouHFhmh4cUcSMnDRGGh4MSDeGKgtAsR1Bi28uCMtvLgjKSISoyG+IMLFEPKIuM6ghRcbksUY aHgxINEYaHgxIGwMNLzYECnGQMOLARFjoOHFgARjoC9sAGFjoAGIhqRiDDS8GJBkDDS8GJBgDDS8 GBAyBhpebEgsxiAKMojJGMSADKI3BpGRQSRjEAoyCNkYBEEGIRmDEJBB8MYgEDIIzhj4ggx8NgY+ IQMfjYEPyMB7Y+AJGXhnDDgjAxZjwAkZcDQG7JEBszFgQgbsjAFlZECmiS28GBDTxBZeDIhpYgsv NsSZJrbwYkBME1t4MSCmiS28GBDTxBZe3JFiklhQEYsJYkE9LCaHBdWwmBhm1MJsUphRCbMJYUYd zCaDGVUwmwgKaqCYBAoqoJgACuqfmPwJqp+Y+A1394sbBu/LMR2CvhhbLMPvxOPNbPjMz518IDnH Ctz08EHlKE3oj62P3uRvbo/BdTwvnvRSX816eSuCF2YP8Oe4lzcYUBaPC3geO+exc7tlsGUlgOAz CnqcPG8fLiH8+BO1qNvUXtIStUDbLQGfl3mCBa9HbKhijfF9kTaubmhjifRdfoihad2w1D5JV53a q9nrw8L6Ouvh7fVZxlDf9qeRAVto9TC61o1b7RN+6+XtKdwlhiWvB2ysA8fQHRu5uqERGEMD6teo 9z6K7j9gfB1CDypgfBlCPjvb1arHfQi11PbdDXFwPX0uQ8rBEIKS1wM21rENoRdo5OqGRtYhtOQA Ogwhz69iz0Gt9WEOodqBztb3PAyhJbV+eEg3D/brWZEypGAIYcnrARvrWIfQizRydUMjyxBacwDF IcRO2nc+XsFkphFNdRiFwOtXwh7MMPIRlr1xMrOvgF23xXG4ph7nGfxa2JOh5PglsbGObRi9QCNX NzSyDiMfd+gwjLxOZq9mGCX3MIfRtn5sn8zqE1r/gNZ1W1eG2SVmtCvwoa0nQ8nxI1xjHduE9gKN XN3QyDqhLTmADhNa5DaMPAyj+5nSxGsopH566MFMaSci53K7nZjL7nbaxUqlfbz6Pn7yVCzV4136 ya6+fflPd/j24nUIXLzhytaxmA5RQ3DfihXc88rFm165IFNYwaUDwQ+TrKlF/QQ/HkKCXw+xck1i Bb8fgthYxyaxL9DI1Q2NrBIrcY/Cd0o01PjVLF6EWtND+1CJblXW0L972ql8jpE7f33h3gO1BpHR J5OYxTSuh0s0UeHkgslPT9kL7CdDyesBG+tAjbtjI1c3NAIaN6BRto0zXeVezfPIKnMP6nnkks9f ZDipc2/lFxlemw21f8gnw9YB3SVkGwtOQeuuAl3T7XsKNDHuKChNKvqeglZ62VFQfOzI07Fg31VA OfdNBVUl73FXQUiuKsR5U8F5U8FvyTCdNxWcNxX8Fr2qDswWuXQemM/vxfPAfH0G5sQyqnqU9LYt o17GY9B/RDK2rLeCsm1nGV5rDWFG8M8C9ldeS9TP+sZrSwxhRlBw9y8LDlXgW7U7tnF1QxvwVg1Q DDNq79ReyUrd+krtQa3U1ZL9KW1x1meRg9n3/H2v38L3vfS//wNkqnVDZW5kc3RyZWFtCmVuZG9i agozMSAwIG9iago0MjQ3CmVuZG9iago3IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAw IDYxMiA3OTJdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgMTkgMCBSCi9Gb250IDIwIDAgUgo+PgovQ29udGVudHMgOCAw IFIKPj4KZW5kb2JqCjIxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJd Ci9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9Gb250IDI0IDAgUgo+PgovQ29udGVudHMgMjIgMCBSCj4+CmVuZG9iagoyNSAwIG9iago8PC9U eXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDkwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCAyOCAwIFIKPj4KL0NvbnRlbnRz IDI2IDAgUgo+PgplbmRvYmoKMjkgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEy IDc5Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv VGV4dF0KL0ZvbnQgMzIgMCBSCj4+Ci9Db250ZW50cyAzMCAwIFIKPj4KZW5kb2JqCjMgMCBvYmoK PDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNyAwIFIKMjEgMCBSCjI1IDAgUgoyOSAwIFIKXSAvQ291 bnQgNAo+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUgo+Pgpl bmRvYmoKNiAwIG9iago8PC9UeXBlL0V4dEdTdGF0ZS9OYW1lL1I2L1RSL0lkZW50aXR5L0JHIDQg MCBSL1VDUiA1IDAgUi9PUE0gMS9TTSAwLjAyPj4KZW5kb2JqCjE5IDAgb2JqCjw8L1I2CjYgMCBS Pj4KZW5kb2JqCjIwIDAgb2JqCjw8L1IxNQoxNSAwIFIvUjE4CjE4IDAgUi9SMTIKMTIgMCBSPj4K ZW5kb2JqCjUgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9GdW5jdGlvblR5cGUgMAovRG9t YWluWzAKMV0KL1JhbmdlWy0xCjFdCi9CaXRzUGVyU2FtcGxlIDgKL1NpemVbMjU2XS9MZW5ndGgg MjU5Pj5zdHJlYW0KeJwFwYNiAgEAANBfz65bNpZ9tWwsG8u4tGws196DweBwBAKJRKHQaAwGi8Xh 8HgCgUgkkchkCgUAgA8qlUaj0xkMJpPFYrM5HC6Xx+PzBQKhUCQSi8USyadUKpPJ5QqFUqlSqdUa jVar0+n1BoPRCIKgyWQ2f1ksVqvNZrc7HE6ny+V2ezxer8/n9wcCgWAwFAqHvyORaDQWi8cTiWQy lUqnM5lsNpfL5/OFQrFYKpXLP5VKtVqr1euNRrPZarXbnU63C0FQr9fvDwbD4Wj0Ox5PJtPpbDaf LxbL5Wq1Xm82m+12t9vvD4fj8XT6O58vl+v1drvfH4/n8/V6v/8BcSu/ZQplbmRzdHJlYW0KZW5k b2JqCjQgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9GdW5jdGlvblR5cGUgMAovRG9tYWlu WzAKMV0KL1JhbmdlWzAKMV0KL0JpdHNQZXJTYW1wbGUgOAovU2l6ZVsyNTZdL0xlbmd0aCAyNjc+ PnN0cmVhbQp4nAEAAf/+AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygp KissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFi Y2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqb nJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU 1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/632f4EKZW5kc3RyZWFt CmVuZG9iagoyNCAwIG9iago8PC9SMTUKMTUgMCBSL1IxOAoxOCAwIFIvUjEyCjEyIDAgUj4+CmVu ZG9iagoyOCAwIG9iago8PC9SMTUKMTUgMCBSL1IxOAoxOCAwIFIvUjEyCjEyIDAgUj4+CmVuZG9i agozMiAwIG9iago8PC9SMTUKMTUgMCBSL1IxOAoxOCAwIFIvUjEyCjEyIDAgUj4+CmVuZG9iagox NyAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1hUV0pWSitDb3VyaWVyLUJv bGQvRm9udEJCb3hbLTEzOCAtMjc4IDg4OCAxMDI5XS9GbGFncyAzNAovQXNjZW50IDEwMjkKL0Nh cEhlaWdodCA1OTcKL0Rlc2NlbnQgLTI3OAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTUwCi9NaXNz aW5nV2lkdGggNjAwCi9YSGVpZ2h0IDQ1MQovQ2hhclNldCgvaHlwaGVuL2xlc3MpCi9Gb250Rmls ZTMgMTYgMCBSPj4KZW5kb2JqCjE2IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMzMgMCBSPj5zdHJlYW0KeJxjZGBhYmBkZBSJCAn3CvPSds4vLcpMLdJ1 ys9JAYmr/ZBm/CHD9EOW+bfc71W/eH7NZJVlsKvbxbvwh5TQ90bB7zX83ysEGJgZGcs7pznnF1QW ZaZnlChohAaFa2pr6yBEDC0tLRWSKmEyCi6pxZnpeQpqQEZZak5+QW5qXom1gjNQdU5OZrJCek5l QUaxQmJKagpIV1hiTmq2gltmTmZBQX6ZgoazpoKRgYGhLpAw8svMTSotVvDNz8tX8FEAORxFhIGB gclGl4FBloEP5EyWoMk/3vD9ePO9//tq0e8zv0sumj5levc8ye6JnZM6Jnb1SrTOrJ5W293c3dhR 3/rH6XeGxA+n37nTWqd1TO6WnNk9e9rEmT29En2Teid1T+ie1zS9ZDoHyLTK94w/Gr5Xii7snt47 ecKsKVPmdM/pnt0yq25q46TG3sJujj8ibEXdzV1NrTWNTdXdVd3Vk2tmNE5pmda5pJuDr3z+D8/5 34Xmz5/P9oHrA/eLyTw8H3h4GRgAhuKkMAplbmRzdHJlYW0KZW5kb2JqCjMzIDAgb2JqCjM5NApl bmRvYmoKMTQgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9HWkZLR0grSGVs dmV0aWNhLUJvbGQvRm9udEJCb3hbLTE3MyAtMzA3IDEwOTcgOTc5XS9GbGFncyAzMgovQXNjZW50 IDk3OQovQ2FwSGVpZ2h0IDc0MQovRGVzY2VudCAtMzA3Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAx NTAKL01pc3NpbmdXaWR0aCAyNzgKL1hIZWlnaHQgNTQ5Ci9DaGFyU2V0KC9ML1UvYS9iL2MvZC9l L2cvaC9sL24vcikKL0ZvbnRGaWxlMyAxMyAwIFI+PgplbmRvYmoKMTMgMCBvYmoKPDwvU3VidHlw ZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzNCAwIFI+PnN0cmVhbQp4nHWSfUxT VxjGz22h94qA4vWKrNpe3KYWaPyeY85slLbCxLmNAQ4ErW1pO/s1qEjRGT6Mbh5002kgwiwgaqhR a8TZUVTUKVEjoHEZW8RkIzOYDDcX9b14dNktOpf9sX9O7nnfe57znOf9UShCgiiKmrQkX790SUZy htleZvbYjAa1xmU3hTszBDklTJEIU6UkjXQ/HnhsiZyKshqHYg5OiYyYAPvjYNs42DgeSSmqfFtd usvtLbFZrB5+Zs4Heark5JR/K3NSU1P5Nd5/OrzWXGqzOPnp4keZ2e5yO8xOzyI+XfzbbrcZeYvd 67aW8gaTyWwKH8s12M1reb3NbnO7XWX8zHQVP3f27DlqcZn7rs2xZl0pn21wlvJZfNj6fyoIoegs p9FkLrFYc+yGNQip0XKkRTqkR9koA2Wi19AypEHpKEZMA0WgaciMTlGTqA1UULJAUiO5LPlFWi79 AfyxAmCIE275KAxJUqgYcXAk6alD2Apx5L4s3G0S1DDW6ZuAgYdVwMezwStCgHsSELf9NNt/NXiy t7vt46UK8rNY+YuGsZm9hNbku5cbFWzwRzpW6PJAJNyDSPEGXirsgztcFUye9xORY4YsUCeSLKIf ehnmQ/ydW8DVK8lLMq/O5c7BjHb11Qdn9oQaDysb2vwNJ/B3+KC7QcuIpjwwRt0kzIIxMP+Zscqw sY2CahLwIw7CkzqZ9dzK1gzxBk5FxpOFmua0Y3lKtjMvcM12Td6DO1qPdjEkSojhbnToX1EVLNHp Cvru/R66fl0ZNvwIpg3BuEeU0ARlXG0d/hLvwudqTm86bhmef4lQouysFBJBMkna3URQQ8xw30O/ kihkFatNJSuwEa9tXN+2ybdl/+dnmO1D3O6Bo+2X8VF8uMLnql+/s2xHsfiGBDHYBFA+CzaeDbwI 9QTN9g20tw/s3bPts30KmEbX1G7BW/FSnG1waBg28FCMFIjz1wfi6+/AmOeT2QQJ8ewtIUVUeZ1m f7tqKDy0TE4mJpM4soi8OUgiIOHK8X2Xzio19Dv5Rbpca3N7pYK8Kqs1NDiPOb6xdlfcxgwsvHsT WKWoc17UIDsJ4q6f1cxQrcjQZBb2DN//9kav8gUSYvThiUKuONUeEZunjlEiLgdPXWnbX7muQVHn /eJTbGXI7VEucI83VOy3HyjaW4T1+COX6T0GfHTsSLEHJgp/jOIHfhFBoVbUelJNzysyqNVFJwcV QjVJEvc4tfn9zlVdBf2fDOJB3H+gK9R5qvkiHmCEajoW/LhpRDvqRwrGMMN82I7sGXxzmoR5EDka 03KYGs+WC02NXEnL5r34EANdNEjevkCmk+lvLSNx1QqQy3ZdaPm6DzPnDnot3uoNG2uU5VUY6yuz qybz3rwPcRIurDe3uhk2uNbfUR6Sd+PzBzrPMGw5du2oqt/AQIqMLAYHxwbfMBZqVzpbT5xs9l2s U4R2B3bt3N7wVcL/A3zpeY5i/J25RzpKeuXADcM4WHhz3feWs8rirswjmTgDF5TYchiooyGKnOb6 OnUzVPk6vXZl75/DoT4RYE+LEPDBYl9BiwyioiBxLETtjo6GxD3RMQj9DWqgY5EKZW5kc3RyZWFt CmVuZG9iagozNCAwIG9iagoxMTk0CmVuZG9iagoxMSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlw dG9yL0ZvbnROYW1lL1ZWUUNOWitIZWx2ZXRpY2EvRm9udEJCb3hbLTE3NCAtMjg1IDEwMjggOTUz XS9GbGFncyAzMgovQXNjZW50IDk1MwovQ2FwSGVpZ2h0IDc0MQovRGVzY2VudCAtMjg1Ci9JdGFs aWNBbmdsZSAwCi9TdGVtViAxMDQKL01pc3NpbmdXaWR0aCAyNzgKL1hIZWlnaHQgNTM5Ci9DaGFy U2V0KC9zcGFjZS9wYXJlbmxlZnQvcGFyZW5yaWdodC9wZXJpb2Qvc2xhc2gvemVyby9vbmUvdHdv L3RocmVlL2ZvdXIvZml2ZS9zaXgvc2V2ZW4vZWlnaHQvY29sb24vZXF1YWwvQS9CL0MvRC9GL0gv SS9OL1AvUi9TL1QvVS9ZL2EvYi9jL2QvZS9nL2kvay9sL20vbi9vL3Avci9zL3QvdS92L3kpCi9G b250RmlsZTMgMTAgMCBSPj4KZW5kb2JqCjEwIDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGggMzUgMCBSPj5zdHJlYW0KeJxdVgtUE9fWnhgyMyqiMB1R0CSK D1AUefkGFHnf8BYs+ECECEgSkDcWrFar1YP1thcrtVYePkCqgihqNSqI76poi5aogBKw0eLVq/bu SU9Y/3+C9v7rv2tlTWb2nL3n7G9/+ztbRFkMokQikXVsbOSisPipQUpVnjInLSnRbJws2IuEMYOE sWLsi4//WfZnqGQspdj7bFjVmOH+NsIIazg6HNaNoMQiUcGOPYsyMguz0lJSc+SOMVFLnKZOdf4/ i+ucOXPkqwr/eiP3U2anpWjkk8hNnlKVkalWanLmyReR1SpVWpI8RVWYmZotT0xOViab3WITVcp0 eUCaKi0zMyNP7rjISe42Y4brNHJxC0tTr8rNlkcnarLlCnmUMiVXlZj1/4wURbkuLNQk+WYkx4Ut ylT6RWSlBGRH5aRFB+UuDs5Lj1Elqle5erm5O3o4ec6Uz5o9fa7LDIoaT8VT4ZQf5UBFUP7UXMqF mkBFUgHURMqViqaCqMnUYsqdiqFCKA/KiYqlPKkp1BJKQc2kQilfKoxaRNlQUoqjPqIGUzw1hBpJ 2VIiahQ1mhpO2VMjKGvKjUBPWZDQG6lm0TDRPpF+kO+gtYP2igeJl4u14j8tfCw2SGwkMyWV9Ag6 mE6j/2BkTDxTwHzJHGd62YnsPLZtsMvgLYNrB18d4jSkdsjTofxQxdBqy1GW9paBllctf7V8M8xy WCLUWhldUAXE64QZ5SJBAxn8A5wheUvjUqNagi1pXNavlvyTbocMCfxDx+MiGizhicRK+AJrOowf EZ9RQgWPJ5qcsZ3gLHGjwd9UlT57/eqC4lQ0+lNUvKNwJ7uA2fvZ3q2V6BCqKa387uC+PZXfNUKx 0WqUldCEKoTIttRyG9Tu3QVfdtpyJ++RgNwRU0UXNDJc279b7j293ZikkOL/6RTkTHdIyySvOLXv cil3Us+QbeS0C87tItQtFtLhNb/1woYj+TUpWkWNL2LxOBdsQfjp1SuH8WD98AF8tEs2iy6etTLR D7Euix/ACLBt1j27d3qV7y6ZGYgO2NkBRR02yAAPDWEGW054OBI66Lvowr6GRpZ7V3e8/OJlO6RP appex3LC7dpjzfftUFP+WeVR5bG47/zJN7W0Ad/hoQiCmIuoZvOBgoP536pREkouVq3NzyrQbF5C FgXhpzzshHzmDDq8oTKbRK7M2Z2eYodSP03PzcnNVm9YgVgCzl/JQVO3GA4IdTye7DYe+2E//Xhw gsm972ABBHu8xVNlJd788xZvPBIPj/RymR7VDhzYXNYZZOYgusUVgkIH3gTkbrhIIC4SNhnV/Gy8 n05tiq4273qMGxbheTJOi/27sQjG/XL+0K0zUq4o4D6D1wmJfO/ledja/HpY5Dx3l7DHYAVW1x8/ kw6wx+hXLoKjBrFgCw08HBLCJVhM42QMeA2ABDM0HDURW4OBsTKufr8c6QWpXmy0I9twNxlok7Vg kEzqV+sFPS0MM+kl72iyNKdD6OsQIYPYOEVAvAY8XHTYAzmh+aqY8OBFKQ4ID0HYsn7CXb+WyF8y XyAIQK9+r4QYdiq9KW5jWpFGHR6a5kWym+gCLIRAuB4YGHf1UmHGYdmhrD2qb2IGMNYJU3R/EfBC ty13pBlr+C44SJ+O0Wa3Ihbse0AEBJw28POEQVjmF5Uemkz499Cb4W7BOgX/27W52BoPDZs7wz3y EQyH4Vce6QeQb4egVvBoF5U8FQu7YD2PHn1+rqgh7em8i05kW5OmEXouwAuejYPJYNnZCnQFoWdO wLKUIBSLVuzPOJ1/ePPh7RfZHa38131Xb3YhtuNmoOc2tG37NpkZyg7hhhkfYYxB3DMSjtKgAAlI IR/ysAVIcagMH6UN/fa8cAMWMDDh1yk4DCt8nPAE2fuuP9kBpeYA0NMnJr43eCikL6MzexuOnT6x 7yy6w8LYue14ghQ396sNtGBvAaUQy/Q0LZ03L3apm8wKnpLu9dV/AM+Wq79rbt0ac+seYNCDfdoT NSx39+C+A19dKWGfMMU7NpdsQDFoVfpSL5arf0Hatwlr7oG1meWpA+w8SaI8FmaQMD4M13cj8eOa IHs82hWz2Nuzyv9UnKwhoWXtJXQb/Vh99jabySC/z1bmaXJVKws/RkqUtivn+4I9m77dUsvOpEsd 2yNgONKhOweONp44t+c2guEsCR5CAuOCUL63yQfbYusYH/cZiwfapUXXQ4oGBJefOqB4gHjwN3jC w+sO/BqKBXmHqdiMw39Ep6wbPiO6EyJY8dvfBF7Bw0hNreYrpsxpTIYRapmu4EpxVR5Sjo6PX+O7 QllWmSddv+fzPVvqWXd6Jx7WGgljCblGdd16rUs45XBANm9f4HeaSlQ/+typ2tY7dZrFO6QD/QI/ mmXJrEm4d26fLfcOwoAozGa6sz7JVcYJ20PQin8klKlHg6SKTt2/+eC2vu1gWVA3/yjRlY4TRy50 2oHN/LvYQYp7BuootyDak0vk6fCmqvwDeWVrUALrmZDsKLWC2pw2YUqr6OdOMXxNiuAJE2bjCX6B P5vkdGyd+lZ5+Y6/V0vvMRu+WL/9E8SmbNxVLwP8lLGCLMKE/HIILReVEN8pxHe2qaKTNqotZo3v Is3sQpr5tc4G6YMN8FIfSKS1XTAIu/nt4ODUiecT5Dwc5+BRbmejf8+SQfBSCdfzW3bj6ig7lJyX pMrV5C/fEIHmo5h9qY2ZP3x6rOQMAbEkqCyhJul8YFcKiFE3+rn8bJ22ofYWuol6o287HsJ/047i 2t33p1e32N2/pX0J7K1Y55IPmJISnyMy9FwYQnTrHKkyfmIwqqfjVtNQaJ3er34OT8z0zGmLM+dl gzphJxHOAiFvpFAxG59nuDPyaH+P4MQTN6UCM9vkyHjciv5Xu/bQXa2UK/BlBnhkpDtEsJmw6N9G ex42dZjuzoHN/faEQVD7QQafiyGWaOA08kEzrwZAFMHxkbBcqJBMo7GjyQvLBS9yCwpTheSvJWac EcF5nFnG+9WdsJJ+/Aj8cb3kDU1E93cidsESOY2zcJZkQEiN0nKzUJiT1RIfUynj5BeOB8cklB1I laZUr6tHl1ihdDqxY8c/XGAh+MCg5zBJKpS+r+3AZrvE4EycZ/WrSUUJNvf824QZ7ea2LRvA5gct z53Z9tlWtMVe88megzK4zhgCz2PeR5GbnCrNztyo3raE7aK//ul4jQ6xDxoz4mS5DErNKwrehIcU FW5NXx+WpVqGAlmuwPl2+B+3m6qar0q/ij2Y3Yz2orIdh74mkgmBPMrYtC4rJ0216pN4xIYoa5su 1Vf3lMn0u7/fWV3GWhnv/2ek6IJM88+W05pnCrMsdTDc418vXW+9cUwZJMX9ZoP58XpdcrD5URjL PI+56OSfmBcRL1W1JO4PRP5o+doVCpbT3mf+6yzthIvktChqJpD0qx/cYTht2IkmTZs9SHuJDPuC t+c7LF30cWZEsgxqGJiEK3jD+4Mi9L8PCgIwGb/AVS+G3cIO3rRDb4yLZFRYlF+Ex6xjFeTTj0F8 71/3REIt/MGbCvyFAnqixft/s3+30NguEmx7xcKX3bxpMF165Yf67guvmkf9s/lCG+mNq9mXEo8n Hl/yfRByRUHpyeFZyg0J2xaxevrLc1/V7K6qOvXjwSbEProW5RO9ZqkiReayBDvOWhm0Cc8YLagG qq2DqgdQ1G6zRw9lvQG9ZDaCtaDjv6HrSyTcu77zCTPdFse6TF127s3nMiJwUbtW702vC7yX2kdE btLzbrDrTT0/s4bo1e2DR87/bAdWc9uwPXbw8cJTv5Dq6ZJTO/d/U1necHr/JcTqzi5fEFeoTv5E lr1RtTV0O0uOGmMcoeBjMWwgeE/GtgocgrArwm43ccgrbMteot3BIR7mI/BA4K4FLz2MZwegBaeH goKge5Gg+wi8eeytB+93D8cLK0MY/MAUJZnOwMWHPM6iIQtuSj58CsY+FhtwKv8KbG9CCAJXBG4K CJkMtuxiWo8dtES0yDSC3eOxlzse/36SgG4duHSTmZgUItMYx5sG0bGmkZLH9Ent0b0krxfXQsZP jAid6r2s4VEeQWl35K6MirUnYn5RPSIoObx6C1NAPv13PCYuab16lawa4iVw7gP613WdFU91opIe OEWibyGEXgesz11MIS/kr0xUJATkk+3wCA/93qdRcTzqhkpnnl36XoEMRrkaMOe/OHOJUlYCC1t+ f41uoFPJ3wayhI2e/JOmCGe38JC5c0Jbn+mvXe8mB3vt+8n8JcllrzkPjYfA0dgLfx6AHWNxMfuc boD8HlgCHpD2IfUf7kM2EfjekF7YTi623BvBXhjMc31tp/fX3bEDsYcO22Brdy8sDt6f8ssKKfdm bnJShJcdHvnSFeQgf9kL/MOkq3MapJiFb4jjg3MJAcHxCQsXxp++06o9fV+Gz1twb/TXomfPCo92 9Qy/3Nl5rUVv3i16K0JvxRD9lndweDsgr2/h7nvbmvc2ocLiw6v8CuPHpLyFhEZ4Y/9GySUaNho3 SgbEXtDpRKgX6nvFUE3SDkbhmtXxy0NznBFhGN70CHPgDFM6yLRQDNLc35b9JF19PqI6CLFeFi/O TsVRePnyaU7Tl72EWIg9++KFzCqnSqgwq7WiitYN6Ryq+7ul5ZNSy2EU9b+9fqF/CmVuZHN0cmVh bQplbmRvYmoKMzUgMCBvYmoKMzQ4OQplbmRvYmoKMTUgMCBvYmoKPDwvU3VidHlwZS9UeXBlMS9C YXNlRm9udC9HWkZLR0grSGVsdmV0aWNhLUJvbGQvVHlwZS9Gb250L05hbWUvUjE1L0ZvbnREZXNj cmlwdG9yIDE0IDAgUi9GaXJzdENoYXIgMS9MYXN0Q2hhciAyNTUvV2lkdGhzWyAzMzMgMzMzIDMz MyAyNzggNjExIDYxMSAxNjcgMzMzIDYxMSAyNzggNTg0IDMzMyAzMzMgNjExIDUwMAoyNzggMjc4 IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzgK Mjc4IDMzMyA0NzQgNTU2IDU1NiA4ODkgNzIyIDIzOCAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAy NzggMjc4CjU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAzMzMgMzMzIDU4 NCA1ODQgNTg0IDYxMQo5NzUgNzIyIDcyMiA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggNTU2 IDcyMiA2MTEgODMzIDcyMiA3NzgKNjY3IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2Njcg NjY3IDYxMSAzMzMgMjc4IDMzMyA1ODQgNTU2CjMzMyA1NTYgNjExIDU1NiA2MTEgNTU2IDMzMyA2 MTEgNjExIDI3OCAyNzggNTU2IDI3OCA4ODkgNjExIDYxMQo2MTEgNjExIDM4OSA1NTYgMzMzIDYx MSA1NTYgNzc4IDU1NiA1NTYgNTAwIDM4OSAyODAgMzg5IDU4NCAyNzgKNTU2IDI3OCAyNzggNTU2 IDUwMCAxMDAwIDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyAxMDAwIDI3OCAyNzggMjc4CjI3OCAy NzggMjc4IDUwMCA1MDAgMzUwIDU1NiAxMDAwIDMzMyAxMDAwIDU1NiAzMzMgOTQ0IDI3OCAyNzgg NjY3CjI3OCAzMzMgNTU2IDU1NiA1NTYgNTU2IDI4MCA1NTYgMzMzIDczNyAzNzAgNTU2IDU4NCAy NzggNzM3IDMzMwo2MDYgNTg0IDM1MSAzNTEgMzMzIDYxMSA1NTYgMjc4IDMzMyAzNTEgMzY1IDU1 NiA4NjkgODY5IDg2OSA2MTEKNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgMTAwMCA3MjIgNjY3IDY2 NyA2NjcgNjY3IDI3OCAyNzggMjc4IDI3OAo3MjIgNzIyIDc3OCA3NzggNzc4IDc3OCA3NzggNTg0 IDc3OCA3MjIgNzIyIDcyMiA3MjIgNjY3IDY2NyA2MTEKNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYg ODg5IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAyNzggMjc4CjYxMSA2MTEgNjExIDYxMSA2 MTEgNjExIDYxMSA1ODQgNjExIDYxMSA2MTEgNjExIDYxMSA1NTYgNjExIDU1Nl0KPj4KZW5kb2Jq CjE4IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvWFRXSlZKK0NvdXJpZXItQm9sZC9U eXBlL0ZvbnQvTmFtZS9SMTgvRm9udERlc2NyaXB0b3IgMTcgMCBSL0ZpcnN0Q2hhciAxL0xhc3RD aGFyIDI1NS9XaWR0aHNbIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwXQo+PgplbmRvYmoKMTIgMCBvYmoKPDwvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9W VlFDTlorSGVsdmV0aWNhL1R5cGUvRm9udC9OYW1lL1IxMi9Gb250RGVzY3JpcHRvciAxMSAwIFIv Rmlyc3RDaGFyIDEvTGFzdENoYXIgMjU1L1dpZHRoc1sgMzMzIDMzMyAzMzMgMjc4IDUwMCA1MDAg MTY3IDMzMyA1NTYgMjIyIDU4NCAzMzMgMzMzIDYxMSA1MDAKMjc4IDI3OCAyNzggMjc4IDI3OCAy NzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4CjI3OCAyNzggMzU1IDU1 NiA1NTYgODg5IDY2NyAxOTEgMzMzIDMzMyAzODkgNTg0IDI3OCAzMzMgMjc4IDI3OAo1NTYgNTU2 IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCA1ODQgNTg0IDU4NCA1NTYK MTAxNSA2NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1MDAgNjY3IDU1NiA4MzMg NzIyIDc3OAo2NjcgNzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2NjcgNjExIDI3OCAy NzggMjc4IDQ2OSA1NTYKMzMzIDU1NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDIy MiA1MDAgMjIyIDgzMyA1NTYgNTU2CjU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAw IDUwMCA1MDAgMzM0IDI2MCAzMzQgNTg0IDI3OAo1NTYgMjc4IDIyMiA1NTYgMzMzIDEwMDAgNTU2 IDU1NiAzMzMgMTAwMCA2NjcgMzMzIDEwMDAgMjc4IDI3OCAyNzgKMjc4IDIyMiAyMjEgMzMzIDMz MyAzNTAgNTU2IDEwMDAgMzMzIDEwMDAgNTAwIDMzMyA5NDQgMjc4IDI3OCA2NjcKMjc4IDMzMyA1 NTYgNTU2IDU1NiA1NTYgMjYwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0IDI3OCA3MzcgMzMzCjYw NiA1ODQgMzUxIDM1MSAzMzMgNTU2IDUzNyAyNzggMzMzIDM1MSAzNjUgNTU2IDg2OSA4NjkgODY5 IDYxMQo2NjcgNjY3IDY2NyA2NjcgNjY3IDY2NyAxMDAwIDcyMiA2NjcgNjY3IDY2NyA2NjcgMjc4 IDI3OCAyNzggMjc4CjcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4IDcyMiA3MjIg NzIyIDcyMiA2NjYgNjY2IDYxMQo1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA4ODkgNTAwIDU1NiA1 NTYgNTU2IDU1NiAyNzggMjc4IDI3OCAyNzgKNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU4 NCA2MTEgNTU2IDU1NiA1NTYgNTU2IDUwMCA1NTUgNTAwXQo+PgplbmRvYmoKMiAwIG9iago8PC9Q cm9kdWNlcihFU1AgR2hvc3RzY3JpcHQgNy4wNSk+PmVuZG9iagp4cmVmCjAgMzYKMDAwMDAwMDAw MCA2NTUzNSBmIAowMDAwMDE3OTEzIDAwMDAwIG4gCjAwMDAwMjg4ODcgMDAwMDAgbiAKMDAwMDAx NzgzMyAwMDAwMCBuIAowMDAwMDE4NTI5IDAwMDAwIG4gCjAwMDAwMTgxMzMgMDAwMDAgbiAKMDAw MDAxNzk2MSAwMDAwMCBuIAowMDAwMDE3MjM3IDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAK MDAwMDAwNDA0OSAwMDAwMCBuIAowMDAwMDIxNzk5IDAwMDAwIG4gCjAwMDAwMjE0MDQgMDAwMDAg biAKMDAwMDAyNzcyMyAwMDAwMCBuIAowMDAwMDIwMTAzIDAwMDAwIG4gCjAwMDAwMTk4NDIgMDAw MDAgbiAKMDAwMDAyNTM5NSAwMDAwMCBuIAowMDAwMDE5MzQyIDAwMDAwIG4gCjAwMDAwMTkwOTQg MDAwMDAgbiAKMDAwMDAyNjU2MyAwMDAwMCBuIAowMDAwMDE4MDQ5IDAwMDAwIG4gCjAwMDAwMTgw NzkgMDAwMDAgbiAKMDAwMDAxNzM5OCAwMDAwMCBuIAowMDAwMDA0MDY5IDAwMDAwIG4gCjAwMDAw MDg1MTMgMDAwMDAgbiAKMDAwMDAxODkzMiAwMDAwMCBuIAowMDAwMDE3NTQzIDAwMDAwIG4gCjAw MDAwMDg1MzQgMDAwMDAgbiAKMDAwMDAxMjg3NiAwMDAwMCBuIAowMDAwMDE4OTg2IDAwMDAwIG4g CjAwMDAwMTc2ODggMDAwMDAgbiAKMDAwMDAxMjg5NyAwMDAwMCBuIAowMDAwMDE3MjE2IDAwMDAw IG4gCjAwMDAwMTkwNDAgMDAwMDAgbiAKMDAwMDAxOTgyMiAwMDAwMCBuIAowMDAwMDIxMzgzIDAw MDAwIG4gCjAwMDAwMjUzNzQgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAzNiAvUm9vdCAxIDAg UiAvSW5mbyAyIDAgUgo+PgpzdGFydHhyZWYKMjg5MzcKJSVFT0YK --Boundary..27398.1163630135.multipart/mixed-- From audet@nortel.com Thu, 15 Sep 2005 15:20:49 -0700 (PDT) From: "Francois Audet" Date: Thu, 15 Sep 2005 15:20:49 -0700 (PDT) Subject: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-04.txt Message-ID: <1ECE0EB50388174790F9694F77522CCF0448FBA6@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..27398.1163630135.multipart/mixed" --Boundary..27398.1163630135.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all, I want to draw everybody's attention to draft-ietf-behave-nat-udp-04. It includes all the changes resulting from WGLC and the Paris meeting. Many thanks to Bryan Ford, Cullen Jennings and Dan Wing who helped in finalizing the wording. The changes are: - Removal of section 5.2 - Addition of section 4.4 (including new REQ-7) - Modification to now-REQ-14 - Adjusted the wording on the ALG requirement - Correction of typos and spelling mistakes - Updated list of references. > -----Original Message----- > From: i-d-announce-bounces@xxxxxxxx > [mailto:i-d-announce-bounces@xxxxxxxx] On Behalf Of > Internet-Drafts@xxxxxxxx > Sent: Wednesday, September 14, 2005 12:50 > To: i-d-announce@xxxxxxxx > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: I-D ACTION:draft-ietf-behave-nat-udp-04.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > Behavior Engineering for Hindrance Avoidance Working Group of > the IETF. > > Title : NAT Behavioral Requirements for Unicast UDP > Author(s) : F. Audet, C. Jennings > Filename : draft-ietf-behave-nat-udp-04.txt > Pages : 28 > Date : 2005-9-14 > > This document defines basic terminology for describing different > types of NAT behavior when handling Unicast UDP and also defines a > set of requirements that would allow many applications, such as > multimedia communications or on-line gaming, to work consistently. > Developing NATs that meet this set of requirements will greatly > increase the likelihood that these applications will function > properly. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-04.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@xxxxxxxx with the word unsubscribe in > the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-behave-nat-udp-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@xxxxxxxxx > In the body type: > "FILE /internet-drafts/draft-ietf-behave-nat-udp-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > Attachment: draft-ietf-behave-nat-udp-04.URL --Boundary..27398.1163630135.multipart/mixed Content-Type: application/octet-stream; name="bin00004.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bin00004.bin" Content-Description: "Description: draft-ietf-behave-nat-udp-04.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWJlaGF2ZS1uYXQtdWRwLTA0LnR4dA0K --Boundary..27398.1163630135.multipart/mixed-- From fluffy@cisco.com Wed, 21 Sep 2005 14:31:12 -0700 (PDT) From: Cullen Jennings Date: Wed, 21 Sep 2005 14:31:12 -0700 (PDT) Subject: Re: [Ietf-behave] NAT slides? In-Reply-To: <4326D12E.3060105@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 9/13/05 6:16 AM, "Henning Schulzrinne" wrote: > For a class I'm teaching, I'd like to include some basic information > about various NAT types. Rather than duplicate work, I wonder if > somebody has suitable PPT slides (obviously to be used with credit...). > > Thanks. > > Henning > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave I put some slides at http://www.dial911anddie.com/papers/Telcom04-NAT-v3.pdf and http://www.dial911anddie.com/papers/Telcom04-NAT-v3.ppt They are old but still seem 95% correct From fluffy@cisco.com Wed, 21 Sep 2005 14:31:23 -0700 (PDT) From: Cullen Jennings Date: Wed, 21 Sep 2005 14:31:23 -0700 (PDT) Subject: [Ietf-behave] About that TCP draft .... Message-ID: MIME-Version: 1.0 Content-Type: text/plain We seem to have closed up the UDP stuff and I was hoping to solve some of the issues around the TCP work. Trolling through old email traffic, I formed a list of issues that have been discussed. We may have already come to closure on many of these. I probably missed many. My take of the conclusions may be all wrong, but ... When there is not an open mapping, what is the response to an SYN? I think we agreed not to send a RST. There has been discussion on sending an ICMP error of some sort. When there is an open mapping, what to do with incoming packets such at SYN, SYNACK, and LAST_ACK? I suspect the only reasonable answer is forward them. Should the NAT track TCP sequence numbers and timestamps and be able to remap them when a stream is manipulated. I believe we came to the conclusion that NATs should not be required to do this. Clearly a NAT running a specific ALG on a protocol inside a TCP stream might have to do that but that is about NATing some protocol that uses TCP non NATing a generic TCP stream. There was discussion of if the NAT should initiate keep alives. I don't think we got to consensus on this but it seemed at last IETF that most people where not in favor of this. There was discussion of timer values - one of the comments I got that made a lot of sense was that we should logical derive these based on the recommendations in the TCP RFCs. Anyways, I am sure these are not all the issues and I may have summarized them in completely the wrong way. I'm not trying to really get the list right here - I just want to start discussion on what the issues are, what the proposed solutions to the issues are, and pro's and cons. If we can get out of the next IETF meeting and be very close to done on a WG TCP document I would be very happy. Cullen From fluffy@cisco.com Wed, 21 Sep 2005 14:51:42 -0700 (PDT) From: Cullen Jennings Date: Wed, 21 Sep 2005 14:51:42 -0700 (PDT) Subject: [Ietf-behave] FW: Approval to Post Version -00 Internet-Drafts for the 64th IETF Meeting in Vancouver, British Columbia, Canada In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain If anyone is expecting new 00 WG drafts before Vancouver, please let Jiri and I know. ------ Forwarded Message From: Internet-Drafts Administrator Date: Fri, 16 Sep 2005 00:00:01 -0400 Subject: Approval to Post Version -00 Internet-Drafts for the 64th IETF Meeting in Vancouver, British Columbia, Canada Dear IETF Working Group Chairs: In order to expedite the processing of the many version -00 I-Ds that the Secretariat receives before an IETF meeting, we ask that you please notify the Secretariat prior to the initial submission cutoff date of all version -00 I-Ds that you expect to approve for posting as WG documents. Please send the filenames of your approved -00 I-Ds to internet-drafts@xxxxxxxxx We would appreciate receiving your list of approved drafts five (5) business days prior to the cutoff date for -00 submissions, or by Monday, October 10th at 9:00 AM ET for the 64th IETF Meeting. Please include the word "Approved I-Ds" in the "Subject" field. This procedure will help to ensure that version -00 I-Ds are posted in a timely manner, allowing more time for review by the public. Thank you for your cooperation in this matter. The Internet-Drafts Administrator FYI: The Internet-Draft cutoff dates as well as other significant dates for the 64th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_64.html. ------ End of Forwarded Message From srisuresh@yahoo.com Fri, 23 Sep 2005 14:56:37 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 23 Sep 2005 14:56:37 -0700 (PDT) Subject: Re: [Ietf-behave] NAT slides? In-Reply-To: Message-ID: <20050923215636.79742.qmail@web33303.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Well, I donot have any slides on this. However, I looked at Cullen's slides and the slides from Jon Ringle (earlier posting in response to the same query). Both sets of slides are nicely done. However, both sets of slides refer to Symmetric NAT, Port-restricted Cone NAT, Address-Restricted Cone NAT and Full Cone NATs only. These are variations of NAPT, but leave out other NAT types. I figured, I should mention that there are other NAT types in addition to those listed above. Here they are - Basic NAT, Twice NAT, Bi-directional NAT, V4/V6 NAT-PT and Load Share NAT. Hairpin NAT is a new NAT type introduced to cover the multi-level NAT realities. Cullen's slides cover this new NAT type. Below is an ASCII art to illustrate the distinction amongst these NAT types. Hope this helps. -------------+---------+---------+---------+---------+---------+---------- NAT Type | Address | Port | Bindings| UDP NAT | TCP NAT | Session | Binding | Binding | per NAT | Sessions| Sessions| Direction | | | Session | | | -------------+---------+---------+---------+---------+---------+---------- Basic NAT | Yes, | No | 1 | Yes | Yes |Outbound | Outbound| | | | | -------------+---------+---------+---------+---------+---------+---------- Twice NAT | Yes, | Yes, | 2 | Yes | Yes |Outbound | Outbound| Outbound| | | | -------------+---------+---------+---------+---------+---------+---------- Bidirectional| Yes, | Yes, | 1 | Yes | Yes |Outbound, NAT | Bi-direc| Bi-direc| | | |Inbound | tional | tional | | | | -------------+---------+---------+---------+---------+---------+---------- Load Share | Yes, | Yes, | 1 | Yes | Yes |Inbound NAT | Inbound | Inbound | | | | -------------+---------+---------+---------+---------+---------+---------- Symmetric NAT| No, | No | 0 | Yes | Yes |Outbound - A NAPT type| | | | | | -------------+---------+---------+---------+---------+---------+---------- Port Restrict| No, | Yes, | 1 | Yes | Yes |Outbound, ed Cone NAT | | Outbound| | | | - A NAPT Type| | | | | | -------------+---------+---------+---------+---------+---------+---------- Addr Restrict| No | Yes, | 1 | Yes | No |Outbound, ed Cone NAT | | Outbound| | | |Inbound - A NAPT Type| | | | | |(Addr restr) -------------+---------+---------+---------+---------+---------+---------- Full Cone | No | Yes, | 1 | Yes | No |Outbound, - A NAPTtype | | Outbound| | | |Inbound -------------+---------+---------+---------+---------+---------+---------- Hairpin NAT | Yes, | Yes, | 2 | Yes | Yes |Outbound, | Outbound| Outbound| | | |Hairpin -------------+---------+---------+---------+---------+---------+---------- cheers, suresh --- Cullen Jennings wrote: > On 9/13/05 6:16 AM, "Henning Schulzrinne" wrote: > > > For a class I'm teaching, I'd like to include some basic information > > about various NAT types. Rather than duplicate work, I wonder if > > somebody has suitable PPT slides (obviously to be used with credit...). > > > > Thanks. > > > > Henning > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > I put some slides at > > http://www.dial911anddie.com/papers/Telcom04-NAT-v3.pdf > and > http://www.dial911anddie.com/papers/Telcom04-NAT-v3.ppt > > They are old but still seem 95% correct > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Sat, 24 Sep 2005 09:34:22 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 24 Sep 2005 09:34:22 -0700 (PDT) Subject: Re: [Ietf-behave] About that TCP draft .... In-Reply-To: Message-ID: <20050924163422.59376.qmail@web33313.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > > We seem to have closed up the UDP stuff and I was hoping to solve some of > the issues around the TCP work. Trolling through old email traffic, I formed > a list of issues that have been discussed. We may have already come to > closure on many of these. I probably missed many. My take of the conclusions > may be all wrong, but ... > > When there is not an open mapping, what is the response to an SYN? I think > we agreed not to send a RST. There has been discussion on sending an ICMP > error of some sort. [suresh] My recollection is to simply drop. > > When there is an open mapping, what to do with incoming packets such at SYN, > SYNACK, and LAST_ACK? I suspect the only reasonable answer is forward them. > [suresh] Cullen - By "open mapping", if you are refering to an open TCP NAT Session, I agree with what you say. However, if "open mapping" refers to an open Binding, permitting or not permitting the SYN packet depends on the directionality of the Binding on the NAT. cheers, suresh From sg266@cornell.edu Sun, 25 Sep 2005 07:24:33 -0700 (PDT) From: Saikat Guha Date: Sun, 25 Sep 2005 07:24:33 -0700 (PDT) Subject: [Ietf-behave] Announcing: TCP NAT Traversal Library Message-ID: <1127658542.3061.59.camel@himalaya.cs.cornell.edu> MIME-Version: 1.0 Content-Type: text/plain Hi all, (apologies if you get multiple copies of this) I'd like to announce the availability of a open-source TCP NAT Traversal/Hole-Punching library based on our research published in [1]. [1] "Characterization and Measurement of TCP Traversal through NATs and Firewalls", S. Guha and P. Francis. IMC 2005. http://nutss.net/pub/imc05-tcpnat.pdf The key result of the paper is: TCP NAT Traversal can work 85%-90% of the time today (without any special assumptions on NATs), and 100% of the time between pairs of certain well-behaved NATs. See [1] for more details. An open-source Java library for TCP NAT Traversal is now available: binaries: http://nutss.net/stunt.jar source: http://nutss.net/jstunt_cvs.php documentation for library users: http://nutss.net/jstunt/doc documentation for library developers: http://nutss.net/jstunt/devdoc The above library has been tested for pair-wise connectivity across 11 brands of NATs from Windows and Linux hosts. NATs tested were Linksys, DLink, Netgear, Belkin, 3Com, Netopia, Allied Telesyn, SMC, Trendnet, USR. Out of the 121 possible pair-wise combinations, 113 connections are successful. The only ones that failed are when both the endpoints are behind the _same_ NAT that does not support TCP hairpin-behavior yet (see [1]). The java library is released under LGPL; contact me if this does not meet your needs. Feel free to extend it/port it etc. For P2P developers and users of the library -------------------------------------------- The JAR file above includes a sample echo-server/client program. The source code for the sample applications is at http://nutss.net/EchoServer.java and http://nutss.net/EchoClient.java respectively. To start the server, on a host behind a NAT, execute: java -cp stunt.jar EchoServer you@xxxxxxxxxxxxxxx To connect to your echoserver from a client, execute: java -cp stunt.jar EchoClient you@xxxxxxxxxxxxxxx (if you cannot run your own echo server, try pointing the client to the one I am running at echo@xxxxxxxxx) If everything goes well, you'll see something along the lines of: On Server: Accepted saikat930@xxxxxxxxxxxxxxxxxxx On Client: Greetings saikat930@xxxxxxxxxxxxxxxxxxx, this is the EchoServer at echo@xxxxxxxxxx Now you say something. On the client, you'll be able to type lines and have it be echoed by the server when you press enter. The library takes between 200ms to 1 second to connect, but slow DNS (sometimes due to the NAT) can increase the connection time by a bit. For people who want to develop the library further -------------------------------------------------- Anonymous CVS access is at: cvs -d :pserver:anonymous@xxxxxxxxxxxxxxxxxxxxxx:/cvsroot/nutss checkout stunt_java The TCP hole-punching code and state machine are in the file STUNTCont.java. Extensive online documentation of all internal functions is provided. Things to do: - Wrap a java Sockets or Channels api around the existing API - Port to C, Python etc (may require writing a separate STUNT server) - Implement SIP backend for signaling messages (framework glue in place) - Implement some ICE-type negotiations for stacks of NATs - Integrate UDP hole-punching If you have any questions, comments, suggestions, or problems, do not hesitate to contact me. Cheers and have fun. -- Saikat From wuxy@huawei.com Tue, 27 Sep 2005 00:35:02 -0700 (PDT) From: "=?GB2312?Q?=CE=E2=CF=F2=D1=F4(Steven Wu)?=" Date: Tue, 27 Sep 2005 00:35:02 -0700 (PDT) Subject: [Ietf-behave] Please give your comment on this draft:draft-wu-behave-udp-tunnel-00.txt Message-ID: <0ING006Z4TLD0G@szxml01-in.huawei.com> MIME-Version: 1.0 Content-Type: text/plain ietf-behave-request: Hello, everybody. I have submit a new draft on NAT traversal, wellcome to give me your advice on it, thank you all. This is the link to the document: http://www.ietf.org/internet-drafts/draft-wu-behave-udp-tunnel-00txt Best regards 　　　　　　　　Xiangyang Wu(Steven Wu) 　　　　　　　　wuxy@xxxxxxxxxx 　　　　　　　　　　2005-09-27 From dbarrett@quinthar.com Tue, 27 Sep 2005 15:16:24 -0700 (PDT) From: David Barrett Date: Tue, 27 Sep 2005 15:16:24 -0700 (PDT) Subject: Re: [Ietf-behave] Please give your comment on this draft:draft-wu-behave-udp-tunnel-00.txt In-Reply-To: <0ING006Z4TLD0G@szxml01-in.huawei.com> Message-ID: <4339C4B0.8020604@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain That link didn't work for me, but this one did: http://www.ietf.org/internet-drafts/draft-wu-behave-udp-tunnel-00.txt 吴向阳(Steven Wu) wrote: > ietf-behave-request: > > Hello, everybody. > > I have submit a new draft on NAT traversal, wellcome to give me your advice > on it, thank you all. > This is the link to the document: > http://www.ietf.org/internet-drafts/draft-wu-behave-udp-tunnel-00txt > > > Best regards > > > 　　　　　　　　Xiangyang Wu(Steven Wu) > 　　　　　　　　wuxy@xxxxxxxxxx > 　　　　　　　　　　2005-09-27 > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From wuxy@huawei.com Wed, 28 Sep 2005 21:08:12 -0700 (PDT) From: "=?GB2312?Q?=CE=E2=CF=F2=D1=F4(Steven Wu)?=" Date: Wed, 28 Sep 2005 21:08:12 -0700 (PDT) Subject: update link [Ietf-behave] Please give your comment on thisdraft:draft-wu-behave-udp-tunnel-00.txt Message-ID: <0INK00LBC9CN4R@szxml01-in.huawei.com> MIME-Version: 1.0 Content-Type: text/plain Mr David Barrett: I'm sorry for the mistake. Thanks for your help. Please go ahead to give me advice on the document. Thanks again. ======= 2005-09-27 15:16:00 您在来信中写道：======= >That link didn't work for me, but this one did: > >http://www.ietf.org/internet-drafts/draft-wu-behave-udp-tunnel-00.txt > >吴向阳(Steven Wu) wrote: >> ietf-behave-request: >> >> Hello, everybody. >> >> I have submit a new draft on NAT traversal, wellcome to give me your advice >> on it, thank you all. >> This is the link to the document: >> http://www.ietf.org/internet-drafts/draft-wu-behave-udp-tunnel-00txt >> >> >> Best regards >> >> >> 　　　　　　　　Xiangyang Wu(Steven Wu) >> 　　　　　　　　wuxy@xxxxxxxxxx >> 　　　　　　　　　　2005-09-27 >> >> >> >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> >> = = = = = = = = = = = = = = = = = = = = Best regards 　　　　　　　　Xiangyang wu(Steven Wu) 　　　　　　　　wuxy@xxxxxxxxxx 　　　　　　　　　　2005-09-29 From sg266@cornell.edu Thu, 29 Sep 2005 20:29:54 -0700 (PDT) From: Saikat Guha Date: Thu, 29 Sep 2005 20:29:54 -0700 (PDT) Subject: Re: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-04.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0448FBA6@zrc2hxm0.corp.nortel.com> Message-ID: <1128064082.24218.234.camel@himalaya.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630135.multipart/signed" --Boundary..27398.1163630135.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2005-09-15 at 17:20 -0500, Francois Audet wrote: > Hi all, I want to draw everybody's attention to > draft-ietf-behave-nat-udp-04. Regarding endpoint filtering behavior in section 5, the draft says that a NAT can either filter a packet, or not filter a packet. Clearly, not filtering a packet implies that is it translated and routed to the internal host. What does filtering a packet entail? Options would be to either DROP it silently, or respond with some ICMP error. Currently, I think the implicit assumption is that the NAT drops the packet. I am not sure if the ICMP option has been discussed (and rejected) on the list, but I would think that ICMP makes more sense. Justification: Consider a VoIP phone that retries for 3 minutes before giving up. If the NAT simply drops the incoming request packet, the application has _no choice_ but to keep retrying for 3 minutes since it does not know if a NAT is actively blocking the packet, or if the host is intermittently down. If the NAT responds with an ICMP, the application knows that there is a problem and has the choice of either aborting early and reporting the error to the user within seconds, or continuing to retry for 3 minutes as before. Implicitly (or explicitly) recommending that the NAT silently drop the packet and not report an error severely/permanently restricts the application's responsiveness since it forces the application to guess what happened to the packet. The ICMP gives the application a choice. Justification Against: One can make the argument that sending back an ICMP response allows an attacker to check whether a host is present at that address or not. The same can be said for Internet hosts responding to ping messages. RFC 1122 says that an ICMP ECHO server MUST be implemented, and MAY ignore _only_ multicast and broadcast echo requests. Therefore, RFC 1122 doesn't make a case for "stealth" hosts. Another argument can be that an attacker can send these probe packets and find an open mapping by tracking which ports do not return an ICMP error. This is NOT the case. If the NAT is security conscious (and therefore has "address and port dependent endpoint filtering"), then the NAT will filter such UDP probes to open mappings and respond with ICMP errors that are indistinguishable from the ICMP errors generated for non-existing mappings. An attacker cannot infer which mappings are open for such NATs. For NATs that are not security conscious and aim for application transparency instead (endpoint independent filtering NATs), sending back an ICMP makes even more sense. Therefore, I suggest the following text: REQ-8 b) If a NAT filters a packet, it is RECOMMENDED that it send an ICMP error in response. The next question ofcourse becomes what ICMP error to send. It would be Type=3 (Destination Unreachable). As for the sub-code, this has been discussed earlier on the list with no clear winner: either Code=1 (Host Unreachable), or Code=10 (Host Prohibited), or come up with a new one Code=16 (No Route To Destination). The choice of the Code defines application behavior -- if it is a "soft-error", then the VoIP application is allowed to retry (for instance when it is trying to establish STUN). Code=1 is explicitly designated a soft-error in RFC 1122. Code=10 is left unspecified so it becomes host dependent as existing stacks treat it non-deterministically; designating it soft-error now breaks legacy stacks. If we create a new Code=16, we can explicitly designate it a soft-error without breaking legacy implementations. Thoughts? -- Saikat -- Saikat Attachment: signature.asc --Boundary..27398.1163630135.multipart/signed Content-Type: application/octet-stream; name="pgp00085.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00085.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv TGludXgpCgppRDhEQlFCRFBPUlNuRmx0cWk2OTEvb1JBdUx3QUpvRGhKeVJIZi82SHIrL21RYnZj SnAvLzJaVkNnQ2NENkVoCmxOZWFpZmdUSDFHUmx0Tk9uNmRsSUFvPQo9aDMzYQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630135.multipart/signed-- From sg266@cornell.edu Sat, 15 Oct 2005 23:48:26 -0700 (PDT) From: Saikat Guha Date: Sat, 15 Oct 2005 23:48:26 -0700 (PDT) Subject: Re: [Ietf-behave] About that TCP draft .... In-Reply-To: Message-ID: <1129449095.7327.58.camel@himalaya.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630135.multipart/signed" --Boundary..27398.1163630135.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello all, A new version of draft-hoffman-behave-tcp-03 is now up that addresses these issues. The major changes are: 1. Expansion of Security Considerations 2. Modifications of some requirements to reflect group consensus. On Wed, 2005-09-21 at 13:50 -0700, Cullen Jennings wrote: > When there is not an open mapping, what is the response to an SYN? I think > we agreed not to send a RST. There has been discussion on sending an ICMP > error of some sort. Correct. Not sending an RST is crucial for all TCP traversal approaches. NATs can silently drop packets; this can raise a security concern (see draft). This draft allows NATs to return ICMP errors to alleviate this problem, but doesn't require/recommend/not-recommend it. > When there is an open mapping, what to do with incoming packets such at SYN, > SYNACK, and LAST_ACK? I suspect the only reasonable answer is forward them. Agreed. Specifically, this draft requires all valid TCP transitions should be supported; it allows NAT vendors to forward all packets if they chose, or implement more stringent TCP checks (checking in-window packets etc). > Should the NAT track TCP sequence numbers and timestamps and be able to > remap them when a stream is manipulated. I believe we came to the conclusion > that NATs should not be required to do this. Agreed. This draft does not _require_ them to track sequence numbers; security conscious NATs will want to track them, however, and this draft covers this aspect under security considerations. > There was discussion of if the NAT should initiate keep alives. I don't > think we got to consensus on this but it seemed at last IETF that most > people where not in favor of this. This draft does not require keepalives; it leaves them up to the vendor. > There was discussion of timer values - one of the comments I got that made a > lot of sense was that we should logical derive these based on the > recommendations in the TCP RFCs. Yes. RFC 1122 mentions several timers for TCP stacks (keepalive, in-flight packets etc). This draft incorporates them. I'd appreciate comments, feedback etc on the draft. Thanks, -- Saikat Attachment: signature.asc --Boundary..27398.1163630135.multipart/signed Content-Type: application/octet-stream; name="pgp00086.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00086.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFCRFVnYUhuRmx0cWk2OTEvb1JBcGdTQUo5U0hlTHh4blBlS3VvVm5WOEJ0 ck9vY09iWUhnQ2Zmb21kCkw0WnJYYW5jWUtoWkhpNk1XY1ZKR2RvPQo9YThxYgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630135.multipart/signed-- From fluffy@cisco.com Thu, 20 Oct 2005 15:50:37 -0700 (PDT) From: Cullen Jennings Date: Thu, 20 Oct 2005 15:50:37 -0700 (PDT) Subject: [Ietf-behave] Agenda Time Requests Message-ID: MIME-Version: 1.0 Content-Type: text/plain Could folks please email Jiri and I any requests for agenda time. We plan to use a significant amount of time in the meeting to work on the issues around the TCP drafts. Thanks, Cullen (with my Chair hat on) From Michael.Tuexen@lurchi.franken.de Fri, 21 Oct 2005 05:44:02 -0700 (PDT) From: Michael Tuexen Date: Fri, 21 Oct 2005 05:44:02 -0700 (PDT) Subject: Re: [Ietf-behave] Agenda Time Requests In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Cullen and Jiri, if there is interest in the behave working group I would like to give a short presentation on NAT for SCTP as described in draft-stewart-behave-sctpnat-01.txt and draft-tuexen-sctp-udp-encaps-00.txt Best regards Michael On Oct 21, 2005, at 0:50 Uhr, Cullen Jennings wrote: Could folks please email Jiri and I any requests for agenda time. We plan to use a significant amount of time in the meeting to work on the issues around the TCP drafts. Thanks, Cullen (with my Chair hat on) _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From kbiswas@cisco.com Mon, 24 Oct 2005 11:30:14 -0700 (PDT) From: "Kaushik Biswas (kbiswas)" Date: Mon, 24 Oct 2005 11:30:14 -0700 (PDT) Subject: RE: [Ietf-behave] About that TCP draft .... Message-ID: <378E78E5F361564BB066432F6415764BCBC596@xmb-sjc-228.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain A new revision of draft-sivakumar-behave-nat-tcp-req-02.txt is available with changes so as to conform to the UDP-draft terminology. Also, references to behave-gen removed and other changes made to reflect the WG consensus. Comments appreciated. We would like to request this to be adopted as WG document. Thanks, Kaushik > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pyda Srisuresh > Sent: Saturday, September 24, 2005 9:34 AM > To: Cullen Jennings [fluffy@xxxxxxxxx]; Behave > Subject: Re: [Ietf-behave] About that TCP draft .... > > > --- Cullen Jennings wrote: > > > > > We seem to have closed up the UDP stuff and I was hoping to > solve some > > of the issues around the TCP work. Trolling through old > email traffic, > > I formed a list of issues that have been discussed. We may have > > already come to closure on many of these. I probably missed > many. My > > take of the conclusions may be all wrong, but ... > > > > When there is not an open mapping, what is the response to > an SYN? I > > think we agreed not to send a RST. There has been discussion on > > sending an ICMP error of some sort. > > [suresh] My recollection is to simply drop. > > > > > When there is an open mapping, what to do with incoming > packets such > > at SYN, SYNACK, and LAST_ACK? I suspect the only reasonable > answer is forward them. > > > > [suresh] Cullen - By "open mapping", if you are refering to > an open TCP NAT Session, I agree with what you say. However, > if "open mapping" refers to an open Binding, permitting or > not permitting the SYN packet depends on the directionality > of the Binding on the NAT. > > cheers, > suresh > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From rpenno@juniper.net Tue, 25 Oct 2005 07:55:07 -0700 (PDT) From: "Reinaldo Penno" Date: Tue, 25 Oct 2005 07:55:07 -0700 (PDT) Subject: [Ietf-behave] Port forwarding and NAT behavior Message-ID: <9BD5D7887235424FA97DFC223CAE3C2801667725@proton.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Hello, I read the current UDP behavior NAT but I believe it is more concerned with stand-alone sessions initiated from private network. My question is more concerned with server behind a firewall and subsequent sessions. Let's suppose a NAT device configured with port forwarding, for example: 80.0.0.1:5060 -> 10.0.0.1:5060 80.0.0.2:5060-> 10.0.0.2:5060 So, that SIP signaling packets can reach the SIP phone behind the NAT. In other words, the SIP phone can receive external calls even when in a private network. Now, noticing that the NAT device has more than one public address, when phone 10.0.0.1 sends a SIP INVITE, should the NAT device pick 80.0.0.1 as the public IP address? Is this the recommended behavior? Moreover, should the source port be the same (more than just in the same range)? I guess I'm trying to gauge if the recommended behavior (now or as a result of this WG) should be that if port forwarding is configured, the NAT device should "reserve" that mapping and not give to anyone else. Thanks, Reinaldo From dwing@cisco.com Tue, 25 Oct 2005 18:46:44 -0700 (PDT) From: "Dan Wing" Date: Tue, 25 Oct 2005 18:46:44 -0700 (PDT) Subject: RE: [Ietf-behave] Port forwarding and NAT behavior In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2801667725@proton.jnpr.net> Message-ID: <200510260146.j9Q1kfUw015826@sj-core-4.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Now, noticing that the NAT device has more than one public > address, when phone 10.0.0.1 sends a SIP INVITE, should the NAT > device pick 80.0.0.1 as the public IP address? Is this the > recommended behavior? As long as the NAT always picks 80.0.0.1, it seems to meet the requirement REQ-2 of draft-ietf-behave-nat-udp-04.txt. > Moreover, should the source port be the same (more than just > in the same range)? > > I guess I'm trying to gauge if the recommended behavior (now or as a > result of this WG) should be that if port forwarding is > configured, the > NAT device should "reserve" that mapping and not give > to anyone else. Right, it should be reserved for the device that is configured to receive that traffic. Otherwise, if it isn't reserved, you're doing port overloading which is fraught with complexity and interoperation problems, namely when you receive a packet on port 5060, do you hand it to the last device that sent a UDP packet with source=5060, or do you hand it to the configured device? It's impossible to develop an algorithm that will behave correctly in all situations which is why port overloading is a MUST NOT in that I-D. -d From jdrosen@cisco.com Fri, 28 Oct 2005 14:51:02 -0700 (PDT) From: Jonathan Rosenberg Date: Fri, 28 Oct 2005 14:51:02 -0700 (PDT) Subject: [Ietf-behave] RFC3489bis - towards a framework approach Message-ID: <43629D42.2030800@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Folks, Unfortunately, I didnt get around to submitting a much-needed revision to rfc3489bis. One of the reasons is that I believe it requires a fairly substantive change in structure (though not so much a change on the wire), and I wanted to run this by the group. At this point in time, we actually have several things we are doing with STUN, and indeed, when folks say "stun", its not clear what they actually mean. STUN refers to any or all of the following: 1. The specific approach to nat traversal in rfc3489 that involves determingin your nat type through a test, and then figuring out your address on the outside of the nat for use in an offer or answer. 2. The specific request/response protocol that provides a client with a mapped address on the other side of the nat. 3. The usage with draft-ietf-sip-outbound which muxes STUN on the SIP ports (over UDP and TCP) for the purposes of binding keepalives and detection of nat reboots. 4. The usage with ICE whereby a client allocates a candidate for inclusion in an offer or answer. 5. The usage with ICE for connectivity checks. I think its good that we have this general nat traversal tool that is finding use inside several other protocols. However, it is beginning to be unclear about how these all inter-relate, and what the requirements are on the protocol for each of these usages. Indeed, we have small variations in what is needed. In case (1) above, the CHANGE-REQUEST flags are important, while in others (3,4,5) this flag is not needed. ICE, in fact, tells an endpoint to reject a request if the flag is present. So, what I wanted to do is restructure the spec, so that it is really two parts. One is the "STUN Framework". This framework defines the basic stun transaction, message encoding, transport. It defines a base set of attributes, and two request types (BindingRequest and SharedSecret Request). It defines the notion of a usage, which is a concrete use case for the stun protocol, and defines requiremetns for usages. Those requirements would be definition of new attributes or messages, and specification of whether certain attributes are required or need to be omitted, how authentication happens, etc. Then, the spec would define two usages. These are the "Binding Acquisition" and the "Connectivity Check". The former usage is how you talk to a stun server on the public network, and get an address for inclusion in an offer/answer. The latter is the usage we have in sip-outbound and ICE, where its used as a keepalive and connectivity check, multiplexed on the port of some other protocol. Other protocols have been structured this way. DIAMETER comes to mind as a good example. I think this change would very much clear up the confusion around what STUN actually is, and also allow for the usages we have in ICE and sip-outbound in a more clean way. The only way it would change things on the wire are the fixes we know we need to make for sip-outboudn and ICE, namely: a. allowing BindingRequest over TCP b. making CHANGE-REQUEST optional in the BindingRequest So, before I go and do this, I wanted some feedback. Is this a good direction to take? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From audet@nortel.com Fri, 28 Oct 2005 15:27:08 -0700 (PDT) From: "Francois Audet" Date: Fri, 28 Oct 2005 15:27:08 -0700 (PDT) Subject: RE: [Ietf-behave] RFC3489bis - towards a framework approach Message-ID: <1ECE0EB50388174790F9694F77522CCF04FCE1A0@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Make sense to me. Wouldn't it be better to say "STUN Protocol" instead of "STUN Framework"? I like "STUN Usage" for the second part. PS: ICE refers to RFC 3489. I believe it should refer to rfc3489bis. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jonathan Rosenberg > Sent: Friday, October 28, 2005 14:51 > To: Behave > Subject: [Ietf-behave] RFC3489bis - towards a framework approach > > > Folks, > > Unfortunately, I didnt get around to submitting a much-needed > revision > to rfc3489bis. One of the reasons is that I believe it > requires a fairly > substantive change in structure (though not so much a change on the > wire), and I wanted to run this by the group. > > At this point in time, we actually have several things we are > doing with > STUN, and indeed, when folks say "stun", its not clear what they > actually mean. STUN refers to any or all of the following: > > 1. The specific approach to nat traversal in rfc3489 that involves > determingin your nat type through a test, and then figuring out your > address on the outside of the nat for use in an offer or answer. > > 2. The specific request/response protocol that provides a > client with a > mapped address on the other side of the nat. > > 3. The usage with draft-ietf-sip-outbound which muxes STUN on the SIP > ports (over UDP and TCP) for the purposes of binding keepalives and > detection of nat reboots. > > 4. The usage with ICE whereby a client allocates a candidate for > inclusion in an offer or answer. > > 5. The usage with ICE for connectivity checks. > > > I think its good that we have this general nat traversal tool that is > finding use inside several other protocols. However, it is > beginning to > be unclear about how these all inter-relate, and what the > requirements > are on the protocol for each of these usages. Indeed, we have small > variations in what is needed. In case (1) above, the CHANGE-REQUEST > flags are important, while in others (3,4,5) this flag is not needed. > ICE, in fact, tells an endpoint to reject a request if the > flag is present. > > So, what I wanted to do is restructure the spec, so that it is really > two parts. One is the "STUN Framework". This framework > defines the basic > stun transaction, message encoding, transport. It defines a > base set of > attributes, and two request types (BindingRequest and SharedSecret > Request). It defines the notion of a usage, which is a > concrete use case > for the stun protocol, and defines requiremetns for usages. Those > requirements would be definition of new attributes or messages, and > specification of whether certain attributes are required or > need to be > omitted, how authentication happens, etc. > > Then, the spec would define two usages. These are the "Binding > Acquisition" and the "Connectivity Check". The former usage > is how you > talk to a stun server on the public network, and get an address for > inclusion in an offer/answer. The latter is the usage we have in > sip-outbound and ICE, where its used as a keepalive and connectivity > check, multiplexed on the port of some other protocol. > > Other protocols have been structured this way. DIAMETER comes > to mind as > a good example. > > I think this change would very much clear up the confusion > around what > STUN actually is, and also allow for the usages we have in ICE and > sip-outbound in a more clean way. The only way it would > change things on > the wire are the fixes we know we need to make for > sip-outboudn and ICE, > namely: > > a. allowing BindingRequest over TCP > b. making CHANGE-REQUEST optional in the BindingRequest > > > So, before I go and do this, I wanted some feedback. Is this a good > direction to take? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From fluffy@cisco.com Fri, 28 Oct 2005 19:46:24 -0700 (PDT) From: Cullen Jennings Date: Fri, 28 Oct 2005 19:46:24 -0700 (PDT) Subject: Re: [Ietf-behave] RFC3489bis - towards a framework approach In-Reply-To: <1ECE0EB50388174790F9694F77522CCF04FCE1A0@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain First a Chair comment .... We have a Jul 05 deliverable for a revision of STUN. This is important work. I hope everyone can give Jonathan the input he need so this can get done quickly. Second a individual contributor comment ... Framework always sounds sort of complicated but ignoring that, when I think about the key changes needed here I see * make it so a server is allowed to run on only one IP address (but may still do two) * allow binding requests over TCP I think both of these are fine ideas. Perhaps framework is way to go - Perhaps it could be done by defining one protocol called STUN, then defining STUN servers, then defining a new type of special server called a STUN-TEST server that is exactly a STUN server except it MUST have two IP addresses and support the CHANGE-REQUEST flags. That's my 2 cents but I agree with what you are proposing. Cullen On 10/28/05 3:27 PM, "Francois Audet" wrote: > Make sense to me. > > Wouldn't it be better to say "STUN Protocol" instead of "STUN > Framework"? > I like "STUN Usage" for the second part. > > PS: ICE refers to RFC 3489. I believe it should refer to rfc3489bis. > >> -----Original Message----- >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of >> Jonathan Rosenberg >> Sent: Friday, October 28, 2005 14:51 >> To: Behave >> Subject: [Ietf-behave] RFC3489bis - towards a framework approach >> >> >> Folks, >> >> Unfortunately, I didnt get around to submitting a much-needed >> revision >> to rfc3489bis. One of the reasons is that I believe it >> requires a fairly >> substantive change in structure (though not so much a change on the >> wire), and I wanted to run this by the group. >> >> At this point in time, we actually have several things we are >> doing with >> STUN, and indeed, when folks say "stun", its not clear what they >> actually mean. STUN refers to any or all of the following: >> >> 1. The specific approach to nat traversal in rfc3489 that involves >> determingin your nat type through a test, and then figuring out your >> address on the outside of the nat for use in an offer or answer. >> >> 2. The specific request/response protocol that provides a >> client with a >> mapped address on the other side of the nat. >> >> 3. The usage with draft-ietf-sip-outbound which muxes STUN on the SIP >> ports (over UDP and TCP) for the purposes of binding keepalives and >> detection of nat reboots. >> >> 4. The usage with ICE whereby a client allocates a candidate for >> inclusion in an offer or answer. >> >> 5. The usage with ICE for connectivity checks. >> >> >> I think its good that we have this general nat traversal tool that is >> finding use inside several other protocols. However, it is >> beginning to >> be unclear about how these all inter-relate, and what the >> requirements >> are on the protocol for each of these usages. Indeed, we have small >> variations in what is needed. In case (1) above, the CHANGE-REQUEST >> flags are important, while in others (3,4,5) this flag is not needed. >> ICE, in fact, tells an endpoint to reject a request if the >> flag is present. >> >> So, what I wanted to do is restructure the spec, so that it is really >> two parts. One is the "STUN Framework". This framework >> defines the basic >> stun transaction, message encoding, transport. It defines a >> base set of >> attributes, and two request types (BindingRequest and SharedSecret >> Request). It defines the notion of a usage, which is a >> concrete use case >> for the stun protocol, and defines requiremetns for usages. Those >> requirements would be definition of new attributes or messages, and >> specification of whether certain attributes are required or >> need to be >> omitted, how authentication happens, etc. >> >> Then, the spec would define two usages. These are the "Binding >> Acquisition" and the "Connectivity Check". The former usage >> is how you >> talk to a stun server on the public network, and get an address for >> inclusion in an offer/answer. The latter is the usage we have in >> sip-outbound and ICE, where its used as a keepalive and connectivity >> check, multiplexed on the port of some other protocol. >> >> Other protocols have been structured this way. DIAMETER comes >> to mind as >> a good example. >> >> I think this change would very much clear up the confusion >> around what >> STUN actually is, and also allow for the usages we have in ICE and >> sip-outbound in a more clean way. The only way it would >> change things on >> the wire are the fixes we know we need to make for >> sip-outboudn and ICE, >> namely: >> >> a. allowing BindingRequest over TCP >> b. making CHANGE-REQUEST optional in the BindingRequest >> >> >> So, before I go and do this, I wanted some feedback. Is this a good >> direction to take? >> >> Thanks, >> Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Director, Service Provider VoIP Architecture Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@xxxxxxxxx FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> >> > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dbarrett@quinthar.com Fri, 28 Oct 2005 19:54:38 -0700 (PDT) From: David Barrett Date: Fri, 28 Oct 2005 19:54:38 -0700 (PDT) Subject: Re: [Ietf-behave] RFC3489bis - towards a framework approach In-Reply-To: <43629D42.2030800@cisco.com> Message-ID: <4362E46B.7020106@quinthar.com> MIME-Version: 1.0 Content-Type: text/plain Hi there, I think this is a great idea. However, one challenge I've had with STUN/TURN/ICE their rather clunky "glued on" feel with respect to SIP. STUN and TURN are similar, but ICE is very different, and SIP even more different still. In my ideal world, SIP would be expanded to include all the functionality of STUN/TURN/ICE, within the context of a single design/grammar. Yes, there are valid arguments to keep them apart, but I'm making the opposite case. Granted, this is far outside the scope of what you're proposing, but that's my feedback anyway. -david Jonathan Rosenberg wrote: Folks, Unfortunately, I didnt get around to submitting a much-needed revision to rfc3489bis. One of the reasons is that I believe it requires a fairly substantive change in structure (though not so much a change on the wire), and I wanted to run this by the group. At this point in time, we actually have several things we are doing with STUN, and indeed, when folks say "stun", its not clear what they actually mean. STUN refers to any or all of the following: 1. The specific approach to nat traversal in rfc3489 that involves determingin your nat type through a test, and then figuring out your address on the outside of the nat for use in an offer or answer. 2. The specific request/response protocol that provides a client with a mapped address on the other side of the nat. 3. The usage with draft-ietf-sip-outbound which muxes STUN on the SIP ports (over UDP and TCP) for the purposes of binding keepalives and detection of nat reboots. 4. The usage with ICE whereby a client allocates a candidate for inclusion in an offer or answer. 5. The usage with ICE for connectivity checks. I think its good that we have this general nat traversal tool that is finding use inside several other protocols. However, it is beginning to be unclear about how these all inter-relate, and what the requirements are on the protocol for each of these usages. Indeed, we have small variations in what is needed. In case (1) above, the CHANGE-REQUEST flags are important, while in others (3,4,5) this flag is not needed. ICE, in fact, tells an endpoint to reject a request if the flag is present. So, what I wanted to do is restructure the spec, so that it is really two parts. One is the "STUN Framework". This framework defines the basic stun transaction, message encoding, transport. It defines a base set of attributes, and two request types (BindingRequest and SharedSecret Request). It defines the notion of a usage, which is a concrete use case for the stun protocol, and defines requiremetns for usages. Those requirements would be definition of new attributes or messages, and specification of whether certain attributes are required or need to be omitted, how authentication happens, etc. Then, the spec would define two usages. These are the "Binding Acquisition" and the "Connectivity Check". The former usage is how you talk to a stun server on the public network, and get an address for inclusion in an offer/answer. The latter is the usage we have in sip-outbound and ICE, where its used as a keepalive and connectivity check, multiplexed on the port of some other protocol. Other protocols have been structured this way. DIAMETER comes to mind as a good example. I think this change would very much clear up the confusion around what STUN actually is, and also allow for the usages we have in ICE and sip-outbound in a more clean way. The only way it would change things on the wire are the fixes we know we need to make for sip-outboudn and ICE, namely: a. allowing BindingRequest over TCP b. making CHANGE-REQUEST optional in the BindingRequest So, before I go and do this, I wanted some feedback. Is this a good direction to take? Thanks, Jonathan R. From fluffy@cisco.com Fri, 28 Oct 2005 21:48:59 -0700 (PDT) From: Cullen Jennings Date: Fri, 28 Oct 2005 21:48:59 -0700 (PDT) Subject: [Ietf-behave] Draft BEHAVE Agenda IETF 64 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Here is the current draft. Let Jiri and I know if we have missed something. Update & Agenda Bash (5 min) Updating Milestones - Chairs (10 min) STUN - Jonathan Rosenberg (30 min) http://list.sipfoundry.org/archive/ietf-behave/msg01001.html TCP - Saikat Guha (20 min) draft-hoffman-behave-tcp-03 TCP - Kaushik Biswas (20 min) draft-sivakumar-behave-nat-tcp-req-02 How to finish TCP - Everyone (20 min) SCTP - Michael Tuexen (15 min) draft-tuexen-sctp-udp-encaps-00 draft-stewart-behave-sctpnat-01 ------------------------------------------- We also have one pending request for draft-wu-behave-udp-tunnel-01.txt. We are trying to figure out if it is appropriate use of time or not but would like to note their was a request. Cullen From alan@jasomi.com Fri, 28 Oct 2005 23:10:45 -0700 (PDT) From: Alan Hawrylyshen Date: Fri, 28 Oct 2005 23:10:45 -0700 (PDT) Subject: Re: [Ietf-behave] RFC3489bis - towards a framework approach In-Reply-To: <43629D42.2030800@cisco.com> Message-ID: <2D106211-0674-4074-970F-D6D2E8D9E5E3@jasomi.com> MIME-Version: 1.0 Content-Type: text/plain Jonathan, I support these changes and think it is a better way to structure the protocol description and application notes (if you will) so people better pick up on the concepts around STUN. Other than the additional work invovled, I think this is a win. Cheers, Alan Hawrylyshen ahawrylyshen@xxxxxxxxxxxxx Ditech Communications Corp From sg266@cornell.edu Fri, 28 Oct 2005 23:47:20 -0700 (PDT) From: Saikat Guha Date: Fri, 28 Oct 2005 23:47:20 -0700 (PDT) Subject: Re: [Ietf-behave] RFC3489bis - towards a framework approach In-Reply-To: Message-ID: <1130569140.15110.15.camel@himalaya.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630135.multipart/signed" --Boundary..27398.1163630135.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-10-28 at 19:46 -0700, Cullen Jennings wrote: > * allow binding requests over TCP I agree. This is the primary functionality required for TCP NAT traversal. Some considerations: RFC3489 requires that the TCP port reserved for STUN be used for TLS encoded Shared Secret exchanges; the same port number for UDP is used directly for binding discovery. TCP bindings could be sent to (i) a different (new) reserved port, or (ii) to the old port with the server figuring out whether it is a binding request or a TLS session initiation (ugh), or (iii) to a new port discovered over the TLS session or (iv) over TLS to the old port (both bad ideas latency-wise). -- Saikat Attachment: signature.asc --Boundary..27398.1163630135.multipart/signed Content-Type: application/octet-stream; name="pgp00087.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00087.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFCRFl4MjBuRmx0cWk2OTEvb1JBc3NGQUo0NTl6MDBwWXpZekNSUU5HazRj a1ZrWkd4SmdnQ2VJMk5PClcvaXl3TG9SQnlXMHVmS2luVnQ0VG5JPQo9ZFpvOAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630135.multipart/signed-- From srisuresh@yahoo.com Mon, 31 Oct 2005 09:41:56 -0800 (PST) From: Pyda Srisuresh Date: Mon, 31 Oct 2005 09:41:56 -0800 (PST) Subject: Re: [Ietf-behave] Port forwarding and NAT behavior In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2801667725@proton.jnpr.net> Message-ID: <20051031174156.36916.qmail@web33305.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Reinaldo Penno wrote: > Hello, > > I read the current UDP behavior NAT but I believe it is more concerned > with stand-alone sessions initiated from private network. My question is > more concerned with server behind a firewall and subsequent sessions. > > Let's suppose a NAT device configured with port forwarding, for example: > > 80.0.0.1:5060 -> 10.0.0.1:5060 > 80.0.0.2:5060-> 10.0.0.2:5060 > > So, that SIP signaling packets can reach the SIP phone behind the NAT. > In other words, the SIP phone can receive external calls even when in a > private network. > > Now, noticing that the NAT device has more than one public address, when > phone 10.0.0.1 sends a SIP INVITE, should the NAT device pick 80.0.0.1 > as the public IP address? Is this the recommended behavior? > The above static configuration for port forwarding sounds fine. > Moreover, should the source port be the same (more than just in the same > range)? > By source port, what packets are you refering to - Packets from SIP initiator or SIP responder? > I guess I'm trying to gauge if the recommended behavior (now or as a > result of this WG) should be that if port forwarding is configured, the > NAT device should "reserve" that mapping and not give > to anyone else. The Behave requirements do not address inbound port forwarding. As such, static port forwarding as you suggest should be fine. cheers, suresh > > Thanks, > > Reinaldo > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Mon, 31 Oct 2005 13:49:41 -0800 (PST) From: Cullen Jennings Date: Mon, 31 Oct 2005 13:49:41 -0800 (PST) Subject: [Ietf-behave] Draft Agenda for IETF 64 take 2 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Behavior Engineering for Hindrance Avoidance (behave) - IETF 64 Chairs: J Kuthan Cullen Jennings TUESDAY, November 8, 2005, 1510-1710 in Salon C ================================================ Update & Agenda Bash (5 min) TCP - Saikat Guha (15 min) draft-hoffman-behave-tcp-03 http://www1.tools.ietf.org/wg/behave/draft-hoffman-behave-tcp-03.txt TCP - Kaushik Biswas (15 min) draft-sivakumar-behave-nat-tcp-req-02 www.ietf.org/internet-drafts/draft-sivakumar-behave-nat-tcp-req-02.txt How to finish TCP - Everyone (20 min) STUN - Jonathan Rosenberg (14 min) http://list.sipfoundry.org/archive/ietf-behave/msg01001.html www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-02.txt Media Relays - Chairs (1 min) TURN - Jonathan Rosenberg (10 min) www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-08.txt TURN & IPv6 - Gonzalo Camarillo (10 min) (time permitting) www.ietf.org/internet-drafts/draft-camarillo-midcom-turn-ipv6-00.txt UDP Tunnel - Xiangyang Wu (10 min) (time permitting) http://www.ietf.org/internet-drafts/draft-wu-behave-udp-tunnel-01.txt Updating Milestones & Charter - Chairs (10 min) This item will start at least 15 minutes before the end of the session and previous things may get cut off. SCTP - Michael Tuexen (10 min) (time permitting) draft-tuexen-sctp-udp-encaps-00 www.ietf.org/internet-drafts/draft-tuexen-sctp-udp-encaps-00.txt draft-stewart-behave-sctpnat-01 www1.tools.ietf.org/wg/behave/draft-stewart-behave-sctpnat-01.txt Revision #2 of Agenda From srisuresh@yahoo.com Mon, 31 Oct 2005 14:25:18 -0800 (PST) From: Pyda Srisuresh Date: Mon, 31 Oct 2005 14:25:18 -0800 (PST) Subject: Re: [Ietf-behave] Draft Agenda for IETF 64 take 2 In-Reply-To: Message-ID: <20051031222517.37929.qmail@web33308.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain > Updating Milestones & Charter - Chairs (10 min) > This item will start at least 15 minutes before the end > of the session and previous things may get cut off. For those of us, who wont be able to attend the IETF, can you expand on what you propose to cover here? Is this eliminating/adding new milestones (or) updating the target dates for the existing milestones? In case of the former, woudl appreciate some elaboration on this on the list. Thanks. cheers, suresh --- Cullen Jennings wrote: > > Behavior Engineering for Hindrance Avoidance (behave) - IETF 64 > > Chairs: > J Kuthan > Cullen Jennings > > TUESDAY, November 8, 2005, 1510-1710 in Salon C > ================================================ > > Update & Agenda Bash (5 min) > > TCP - Saikat Guha (15 min) > draft-hoffman-behave-tcp-03 > http://www1.tools.ietf.org/wg/behave/draft-hoffman-behave-tcp-03.txt > > TCP - Kaushik Biswas (15 min) > draft-sivakumar-behave-nat-tcp-req-02 > www.ietf.org/internet-drafts/draft-sivakumar-behave-nat-tcp-req-02.txt > > How to finish TCP - Everyone (20 min) > > STUN - Jonathan Rosenberg (14 min) > http://list.sipfoundry.org/archive/ietf-behave/msg01001.html > www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-02.txt > > Media Relays - Chairs (1 min) > > TURN - Jonathan Rosenberg (10 min) > www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-08.txt > > TURN & IPv6 - Gonzalo Camarillo (10 min) (time permitting) > www.ietf.org/internet-drafts/draft-camarillo-midcom-turn-ipv6-00.txt > > UDP Tunnel - Xiangyang Wu (10 min) (time permitting) > http://www.ietf.org/internet-drafts/draft-wu-behave-udp-tunnel-01.txt > > Updating Milestones & Charter - Chairs (10 min) > This item will start at least 15 minutes before the end > of the session and previous things may get cut off. > > SCTP - Michael Tuexen (10 min) (time permitting) > draft-tuexen-sctp-udp-encaps-00 > www.ietf.org/internet-drafts/draft-tuexen-sctp-udp-encaps-00.txt > draft-stewart-behave-sctpnat-01 > www1.tools.ietf.org/wg/behave/draft-stewart-behave-sctpnat-01.txt > > > Revision #2 of Agenda > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Mon, 31 Oct 2005 15:20:57 -0800 (PST) From: Cullen Jennings Date: Mon, 31 Oct 2005 15:20:57 -0800 (PST) Subject: [Ietf-behave] Milestones In-Reply-To: <20051031222517.37929.qmail@web33308.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 10/31/05 2:25 PM, "Pyda Srisuresh" wrote: >> Updating Milestones & Charter - Chairs (10 min) >> This item will start at least 15 minutes before the end >> of the session and previous things may get cut off. > > For those of us, who wont be able to attend the IETF, can you expand on what > you propose to cover here? Is this eliminating/adding new milestones (or) > updating the target dates for the existing milestones? In case of the former, > woudl appreciate some elaboration on this on the list. Thanks. > > cheers, > suresh Certainly. Also, anything in the meeting would definitely come to the list to get ratified. It is two things - One is easy. We need to move the dates on all our milestones. I'd like to get input on that. The second thing is harder. The 1 minute "Media Relays" section on the agenda is for the chairs to point out that media relays are not in the charter. We then have 3 people talking about media relay issues. At the end of that, I would like some discussion about media relays and the charter. I hope to get some input that might be useful in the ADs thinking about charter changes to add the media relay work. The media relay work is needed. There is a lot of agreement on that. It's hard to think of a WG other than behave that has better expertise to review the drafts. I would like to get input on if there is people in the WG willing to put work into media relay. I would not want to significantly impact any of our other key milestones. Cullen (not as chair) From mshore@cisco.com Mon, 31 Oct 2005 15:35:20 -0800 (PST) From: Melinda Shore Date: Mon, 31 Oct 2005 15:35:20 -0800 (PST) Subject: Re: [Ietf-behave] Milestones In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 10/31/05 6:20 PM, "Cullen Jennings" wrote: > The media relay work is needed. There is a lot of agreement on that. It's > hard to think of a WG other than behave that has better expertise to review > the drafts. I don't quite see that. Isn't media relaying a voice application issue rather than a NAT behavior issue? Melinda From jdrosen@cisco.com Mon, 31 Oct 2005 18:39:47 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 31 Oct 2005 18:39:47 -0800 (PST) Subject: Re: [Ietf-behave] Milestones In-Reply-To: Message-ID: <4366D56C.7060400@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Relays are not specific to voice. I view work on relays as a natural extension of the work we're already doing on STUN. -Jonathan R. Melinda Shore wrote: On 10/31/05 6:20 PM, "Cullen Jennings" wrote: The media relay work is needed. There is a lot of agreement on that. It's hard to think of a WG other than behave that has better expertise to review the drafts. I don't quite see that. Isn't media relaying a voice application issue rather than a NAT behavior issue? Melinda _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 31 Oct 2005 20:12:18 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 31 Oct 2005 20:12:18 -0800 (PST) Subject: Re: [Ietf-behave] RFC3489bis - towards a framework approach In-Reply-To: <1ECE0EB50388174790F9694F77522CCF04FCE1A0@zrc2hxm0.corp.nortel.com> Message-ID: <4366EB1D.7060308@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Francois Audet wrote: Make sense to me. Wouldn't it be better to say "STUN Protocol" instead of "STUN Framework"? I like "STUN Usage" for the second part. I latched onto framework because the idea was, you couldn't use the framework directly - you needed an usage to tell you how. PS: ICE refers to RFC 3489. I believe it should refer to rfc3489bis. Yes. I havent done that yet. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 31 Oct 2005 20:13:35 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 31 Oct 2005 20:13:35 -0800 (PST) Subject: Re: [Ietf-behave] RFC3489bis - towards a framework approach In-Reply-To: Message-ID: <4366EB6B.4040605@cisco.com> MIME-Version: 1.0 Content-Type: text/plain inline. Cullen Jennings wrote: I think both of these are fine ideas. Perhaps framework is way to go - Perhaps it could be done by defining one protocol called STUN, then defining STUN servers, then defining a new type of special server called a STUN-TEST server that is exactly a STUN server except it MUST have two IP addresses and support the CHANGE-REQUEST flags. Unfortunately its a bit more complicated than that; things like security bootstrapping differ amongst these usages, IP address and port discovery too. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 31 Oct 2005 20:17:49 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 31 Oct 2005 20:17:49 -0800 (PST) Subject: Re: [Ietf-behave] RFC3489bis - towards a framework approach In-Reply-To: Message-ID: <4366EC4E.6060401@cisco.com> MIME-Version: 1.0 Content-Type: text/plain inline. Saikat Guha wrote: On Fri, 2005-10-28 at 19:46 -0700, Cullen Jennings wrote: * allow binding requests over TCP I agree. This is the primary functionality required for TCP NAT traversal. Some considerations: RFC3489 requires that the TCP port reserved for STUN be used for TLS encoded Shared Secret exchanges; the same port number for UDP is used directly for binding discovery. TCP bindings could be sent to (i) a different (new) reserved port, or (ii) to the old port with the server figuring out whether it is a binding request or a TLS session initiation (ugh), or (iii) to a new port discovered over the TLS session or (iv) over TLS to the old port (both bad ideas latency-wise). Yes, this has been one of the few remaining open issues in TURN for some time, which has the same problem since it allowed TCP-based bindings to be allocated. I kind of prefer option (i); as you say its the easiest. My only hesitation is that I know there tends to be reluctance in allocating separate ports for protocols just because they run over tls. But I suppose the idea is that there are really two sub-protocols here - a password allocation protocol and a binding allocation protocol, and that its THOSE we are running on different ports. Indeed, if you want to run a Binding Request over TCP/TLS, you would need TLS for both sub-protocols... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 31 Oct 2005 20:20:38 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 31 Oct 2005 20:20:38 -0800 (PST) Subject: Re: [Ietf-behave] RFC3489bis - towards a framework approach In-Reply-To: <43629D42.2030800@cisco.com> Message-ID: <4366ED12.9000303@cisco.com> MIME-Version: 1.0 Content-Type: text/plain inline. David Barrett wrote: Hi there, I think this is a great idea. However, one challenge I've had with STUN/TURN/ICE their rather clunky "glued on" feel with respect to SIP. STUN and TURN are similar, but ICE is very different, and SIP even more different still. In my ideal world, SIP would be expanded to include all the functionality of STUN/TURN/ICE, within the context of a single design/grammar. Are you talking literally a grammar, in terms of syntax? Or something else? Perhaps my perspective is tainted by my closeness to the work, but I don't really see how ICE could be done much differently from a call flow perspective. Maybe we could have simplified the RTP/STUN demux, that is true, but I'm not sure what else. I will say that, had I the ability to do it over again, I would have made all of this nat traversal stuff part of the baseline specs, rather than something we did afterwards. From my perspective, sip-outbound and ICE are really essential parts of the protocol, and any implementation that is not doing them should be viewed as missing a major part of the protocol. But, SIP was developed at IETF back in the days when NATs were largely ignored in IETF, and so here we are... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From Gonzalo.Camarillo@ericsson.com Tue, 1 Nov 2005 04:02:55 -0800 (PST) From: Gonzalo Camarillo Date: Tue, 1 Nov 2005 04:02:55 -0800 (PST) Subject: [Ietf-behave] IPv6 extension for TURN Message-ID: <43675958.1080303@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Folks, the following draft defines an attribute that allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). http://www.ietf.org/internet-drafts/draft-camarillo-midcom-turn-ipv6-00.txt This draft is a dependency of the IPv6 transition work for SIP: http://www.ietf.org/internet-drafts/draft-ietf-sipping-v6-transition-01.txt Comments are welcome. Cheers, Gonzalo From mshore@cisco.com Tue, 1 Nov 2005 04:06:28 -0800 (PST) From: Melinda Shore Date: Tue, 1 Nov 2005 04:06:28 -0800 (PST) Subject: Re: [Ietf-behave] Milestones In-Reply-To: <4366D56C.7060400@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 10/31/05 9:39 PM, "Jonathan Rosenberg" wrote: > Relays are not specific to voice. They're really not a NAT issue - to the extent that they are it's because they're a mechanism to avoid NATs/firewalls. They are completely different technology, however. I really see this work as being quite far outside the scope of the existing behave working group. And aside from SIPPING, which is a somewhat different case, the IETF does not treat working groups as pools of experts chartered to work in some broad area. I think having the behave working group standardize TURN would be a mistake on both process and technical grounds, although certainly not the worst mistake the IETF has ever made. Melinda From srisuresh@yahoo.com Tue, 1 Nov 2005 08:33:15 -0800 (PST) From: Pyda Srisuresh Date: Tue, 1 Nov 2005 08:33:15 -0800 (PST) Subject: Re: [Ietf-behave] Milestones In-Reply-To: Message-ID: <20051101163314.67300.qmail@web33305.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen did say that the chairs were going to comment that media relays are outside the scope of the WG charter. Sounds like, everyone is in agreement that media relays are clearly outside the scope of the current WG charter. As for media tunnels being a natural extension to the WG charter, I dont see how that is. As Melinda said, I do agree, relay tunnels is a new technology outside NAT BEHAVE work and I donot believe should be padded on top of Behave charter. Besides, there are already several individual drafts that fall within the WG charter. I woudl much rather see the energy of the WG spent on determining which of the drafts should be accepted as WG drafts and what new milestones should be added. As a WG, we have much mork left to do still. We donot yet have any drafts that cleared WG last call or reached the IESG. IMHO, it is just too early to revise the WG charter at this point in my opinion. If there are substantial number of folks who believe that media tunneling technology should proceed forward right away, why not have a Bof and create a seperate WG to address that. My 2c. Thanks. regards, suresh --- Melinda Shore wrote: > On 10/31/05 9:39 PM, "Jonathan Rosenberg" wrote: > > Relays are not specific to voice. > > They're really not a NAT issue - to the extent that they are it's > because they're a mechanism to avoid NATs/firewalls. They are > completely different technology, however. I really see this > work as being quite far outside the scope of the existing behave working > group. And aside from SIPPING, which is a somewhat different case, the > IETF does not treat working groups as pools of experts chartered to work > in some broad area. I think having the behave working group standardize > TURN would be a mistake on both process and technical grounds, although > certainly not the worst mistake the IETF has ever made. > > Melinda > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Tue, 1 Nov 2005 09:12:43 -0800 (PST) From: Pyda Srisuresh Date: Tue, 1 Nov 2005 09:12:43 -0800 (PST) Subject: TCP drafts (Was Re: [Ietf-behave] Draft Agenda for IETF 64 take 2) In-Reply-To: Message-ID: <20051101171243.92987.qmail@web33313.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain > > How to finish TCP - Everyone (20 min) > Cullen - As I mentioned earlier, I wont be at the WG meeting. Some of my co-authors will also be not at the meeting. Frankly, I have no idea what this entails. Can we discuss this on the list first? DO you have some suggestions by which you wish to address this? I do not see substantial differences between the two TCP drafts. Saikat or Paul - As co-authors of one of the TCP drafts, can you comment your thoughts on this? What do you see as substantial differences and How do you like to see them resolved? Thanks. regards, suresh --- Cullen Jennings wrote: > > Behavior Engineering for Hindrance Avoidance (behave) - IETF 64 > > Chairs: > J Kuthan > Cullen Jennings > > TUESDAY, November 8, 2005, 1510-1710 in Salon C > ================================================ > > Update & Agenda Bash (5 min) > > TCP - Saikat Guha (15 min) > draft-hoffman-behave-tcp-03 > http://www1.tools.ietf.org/wg/behave/draft-hoffman-behave-tcp-03.txt > > TCP - Kaushik Biswas (15 min) > draft-sivakumar-behave-nat-tcp-req-02 > www.ietf.org/internet-drafts/draft-sivakumar-behave-nat-tcp-req-02.txt > > How to finish TCP - Everyone (20 min) > > STUN - Jonathan Rosenberg (14 min) > http://list.sipfoundry.org/archive/ietf-behave/msg01001.html > www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-02.txt > > Media Relays - Chairs (1 min) > > TURN - Jonathan Rosenberg (10 min) > www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-08.txt > > TURN & IPv6 - Gonzalo Camarillo (10 min) (time permitting) > www.ietf.org/internet-drafts/draft-camarillo-midcom-turn-ipv6-00.txt > > UDP Tunnel - Xiangyang Wu (10 min) (time permitting) > http://www.ietf.org/internet-drafts/draft-wu-behave-udp-tunnel-01.txt > > Updating Milestones & Charter - Chairs (10 min) > This item will start at least 15 minutes before the end > of the session and previous things may get cut off. > > SCTP - Michael Tuexen (10 min) (time permitting) > draft-tuexen-sctp-udp-encaps-00 > www.ietf.org/internet-drafts/draft-tuexen-sctp-udp-encaps-00.txt > draft-stewart-behave-sctpnat-01 > www1.tools.ietf.org/wg/behave/draft-stewart-behave-sctpnat-01.txt > > > Revision #2 of Agenda > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Tue, 1 Nov 2005 11:27:32 -0800 (PST) From: Cullen Jennings Date: Tue, 1 Nov 2005 11:27:32 -0800 (PST) Subject: Re: [Ietf-behave] Milestones In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 10/31/05 3:35 PM, "Melinda Shore" wrote: > On 10/31/05 6:20 PM, "Cullen Jennings" wrote: >> The media relay work is needed. There is a lot of agreement on that. It's >> hard to think of a WG other than behave that has better expertise to review >> the drafts. > > I don't quite see that. Isn't media relaying a voice application issue > rather than a NAT behavior issue? > > Melinda It's definitely a topic that needs discussion. BEHAVE does deal with things applications need to do in an environment with BEHAVE compliant NATs. PS (I had on my todo list for today to send you a pointer to this thread but I see you found it :-) From fluffy@cisco.com Tue, 1 Nov 2005 11:30:09 -0800 (PST) From: Cullen Jennings Date: Tue, 1 Nov 2005 11:30:09 -0800 (PST) Subject: Re: [Ietf-behave] Milestones In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 11/1/05 4:06 AM, "Melinda Shore" wrote: > On 10/31/05 9:39 PM, "Jonathan Rosenberg" wrote: >> Relays are not specific to voice. > > They're really not a NAT issue - to the extent that they are it's > because they're a mechanism to avoid NATs/firewalls. They are > completely different technology, however. I really see this > work as being quite far outside the scope of the existing behave working > group. And aside from SIPPING, which is a somewhat different case, the > IETF does not treat working groups as pools of experts chartered to work > in some broad area. I think having the behave working group standardize > TURN would be a mistake on both process and technical grounds, although > certainly not the worst mistake the IETF has ever made. Well agree that some charter would need to be change or it would be a process problem. However, what I am really interested in at this point is the discussion on the technical grounds of where it makes sense to do this work. From fluffy@cisco.com Tue, 1 Nov 2005 11:42:16 -0800 (PST) From: Cullen Jennings Date: Tue, 1 Nov 2005 11:42:16 -0800 (PST) Subject: Re: [Ietf-behave] Milestones In-Reply-To: <20051101163314.67300.qmail@web33305.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 11/1/05 8:33 AM, "Pyda Srisuresh" wrote: > As for media tunnels being a natural extension to the WG charter, I dont see > how that is. As Melinda said, I do agree, relay tunnels is a new technology > outside NAT BEHAVE work and I donot believe should be padded on top of Behave > charter. Ok, good input. Can you add input on where this work should be done or how we would decide where to do it? > > Besides, there are already several individual drafts that fall within the WG > charter. I woudl much rather see the energy of the WG spent on determining > which of the drafts should be accepted as WG drafts and what new milestones > should be added. As a WG, we have much mork left to do still. Prioritizing and sequencing the work in the WG is definitely critical. I'm am always looking for input on that. As you point out, unless we are finishing some stuff, any discussion of adding more task is meaningless. From mshore@cisco.com Tue, 1 Nov 2005 13:01:37 -0800 (PST) From: Melinda Shore Date: Tue, 1 Nov 2005 13:01:37 -0800 (PST) Subject: Re: [Ietf-behave] Milestones In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 11/1/05 2:27 PM, "Cullen Jennings" wrote: > It's definitely a topic that needs discussion. BEHAVE does deal with things > applications need to do in an environment with BEHAVE compliant NATs. Sure, but it seems to me that in terms of the behavior of the relaying protocol and how it's actually deployed, the behavior of the NAT itself is pretty much orthogonal (apologies if I'm misunderstanding something about TURN). In that sense I suspect that TURN is topically closer to ICE and perhaps SIPPING than it is to BEHAVE. That is to say, there's not that much in BEHAVE that affects decisions that need to be made about TURN, but there's probably quite a bit in ICE/ SIPPING that affects decisions that need to be made about TURN. Melinda From srisuresh@yahoo.com Tue, 1 Nov 2005 14:41:38 -0800 (PST) From: Pyda Srisuresh Date: Tue, 1 Nov 2005 14:41:38 -0800 (PST) Subject: Re: [Ietf-behave] Milestones In-Reply-To: Message-ID: <20051101224137.60279.qmail@web33302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > On 11/1/05 8:33 AM, "Pyda Srisuresh" wrote: > > > As for media tunnels being a natural extension to the WG charter, I dont > see > > how that is. As Melinda said, I do agree, relay tunnels is a new technology > > outside NAT BEHAVE work and I donot believe should be padded on top of > Behave > > charter. > > Ok, good input. Can you add input on where this work should be done or how > we would decide where to do it? > [suresh] ICE is currently being pursued in MMUSIC. Relay tunneling to traverse NATs fall under the same category, I believe. Tunnel endpoints incorporate ALG function to traverse NATs in this new relay tunnelign work, right. Perhaps mmusic may be a good WG to take on this work. Alternately, the combination of TURN, ICE and the new relay tunneling could be pursued in a new NAT-Traversal WG. > > > > Besides, there are already several individual drafts that fall within the > WG > > charter. I woudl much rather see the energy of the WG spent on determining > > which of the drafts should be accepted as WG drafts and what new milestones > > should be added. As a WG, we have much mork left to do still. > > Prioritizing and sequencing the work in the WG is definitely critical. I'm > am always looking for input on that. As you point out, unless we are > finishing some stuff, any discussion of adding more task is meaningless. > [suresh] Right. Given that we have a lot of work left to do in this WG based on the current charter, why expand the charter, take on additional items and add distraction? cheers, suresh > From sg266@cornell.edu Fri, 4 Nov 2005 18:00:31 -0800 (PST) From: Saikat Guha Date: Fri, 4 Nov 2005 18:00:31 -0800 (PST) Subject: [Ietf-behave] Re: TCP drafts In-Reply-To: <378E78E5F361564BB066432F6415764BDF73C1@xmb-sjc-228.amer.cisco.com> Message-ID: <1131158639.14940.16.camel@himalaya.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630135.multipart/signed" --Boundary..27398.1163630135.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-11-04 at 16:56 -0800, Kaushik Biswas (kbiswas) wrote: > Being co-authors of draft-hoffman-behave-tcp-03.txt, we wanted to > check with you on your willingness to merge the 2 TCP drafts: yours > and ours (draft-sivakumar-behave-nat-tcp-req-02.txt). Would like to > hear the concerns, if otherwise. Absolutely. I suppose my original reply didn't make it to the list; indeed both draft have the very similar requirements and it makes sense to merge them. draft-hoffman-behave-tcp is minimalistic and is structured as an addendum to behave-udp; perhaps it makes sense to start with that as the base and add other stuff to it as deemed necessary. -- Saikat Attachment: signature.asc --Boundary..27398.1163630135.multipart/signed Content-Type: application/octet-stream; name="pgp00088.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00088.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFCRGJCeHZuRmx0cWk2OTEvb1JBdkV4QUo5WE1EazJPTkZpN2s1MW95NktF MGpyTjRCaE53Q2ZUNXIyCjRzeXdhUVRjY3N1L2dqWGVkT1VMOGdNPQo9blNpdgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630135.multipart/signed-- From srisuresh@yahoo.com Mon, 14 Nov 2005 09:36:13 -0800 (PST) From: Pyda Srisuresh Date: Mon, 14 Nov 2005 09:36:13 -0800 (PST) Subject: [Ietf-behave] Adapting individual drafts as WG documents Message-ID: <20051114173612.33971.qmail@web33305.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Dear WG Chairs (Cullen & Jiri), We have the following two drafts out that match the BEHAVE WG milestones for a) ICMP behavioral requirements and b) Application design techniques for NAT traversal respectively. Please initiate the procedure to adapt these as WG documents. Thanks. draft-srisuresh-behave-nat-icmp-00.txt draft-ford-behave-app-01.txt Related to the second draft, we have another draft on "State of P2P traversal across NATs" (). Currently, there is no milestone associated with this. Would appreciate if you could assess the interest in reviewing this in the WG. And, if there is, please initiate the process for adapting this also as WG document. Thanks. regards, suresh From fluffy@cisco.com Tue, 15 Nov 2005 21:10:45 -0800 (PST) From: Cullen Jennings Date: Tue, 15 Nov 2005 21:10:45 -0800 (PST) Subject: Re: [Ietf-behave] Adapting individual drafts as WG documents In-Reply-To: <20051114173612.33971.qmail@web33305.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain We had discussion of milestones at the meeting and Jiri and I will be sending out the questions from that from that some time in next week or two for confirmation on the list. On 11/14/05 9:36 AM, "Pyda Srisuresh" wrote: > Dear WG Chairs (Cullen & Jiri), > > We have the following two drafts out that match the BEHAVE WG milestones for > a) > ICMP behavioral requirements and b) Application design techniques for NAT > traversal respectively. Please initiate the procedure to adapt these as WG > documents. Thanks. > > draft-srisuresh-behave-nat-icmp-00.txt > draft-ford-behave-app-01.txt > > Related to the second draft, we have another draft on "State of P2P traversal > across NATs" (). Currently, there is > no milestone associated with this. Would appreciate if you could assess the > interest in reviewing this in the WG. And, if there is, please initiate the > process for adapting this also as WG document. Thanks. > > regards, > suresh > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From jdrosen@cisco.com Mon, 5 Dec 2005 07:17:10 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 5 Dec 2005 07:17:10 -0800 (PST) Subject: [Ietf-behave] Fora for TURN discussion: BEHAVE list Message-ID: <439459C4.7000808@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Sorry for the broad distribution here, but I wanted to let folks know that I'm going to be moving discussions on TURN over to the behave list (http://www.ietf.org/html.charters/behave-charter.html). I'll be posting some issues shortly which require discussion, so if you are interested, please subscribe there. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 5 Dec 2005 07:56:45 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 5 Dec 2005 07:56:45 -0800 (PST) Subject: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification Message-ID: <43946339.1040306@cisco.com> MIME-Version: 1.0 Content-Type: text/plain As I mentioned during the IETF meeting, I am working on a revision of STUN that structures the protocol into a "framework" layer (though we agreed not to call it that per se), and various "usages" that can define extensions, define what messages and attributes get used, and define various security considerations. The plan is for TURN to become a STUn usage rather than a separate protocol. I think this is a good thing, since TURN repeats a lot of stun, and its relationship with it is unclear. One of the things I mentioned as a side benefit of this unification is that the TURN Allocate request could perform a stun check as a side effect. The Allocate response can include the source IP/port of the Allocate request (equivalent to the MAPPED-ADDRESS in the STUn Binding Response). This way, an ICE endpoint, for example, can issue just a single Allocate request to a turn server, and get back its stun-derived AND turn-derived addresses in one operation. This will reduce the overhead of ICE and simplify things. There seemed to be good support for doing this when I proposed it in the meeting last month. So, whats the issue? Syntax, unfortunately. The IDEAL solution for doing this is that the MAPPED-ADDRESS attribute always indicate the source IP/port as seen by the server in the request, and that it be usable with the existing STUN Binding Response and the TURN Allocate Response. Unfortunately, TURN redefined MAPPED-ADDRESS, and the meaning of MAPPED-ADDRESS in a TURN Allocate Response is the address allocated by the TURN server itself. So, there are several options: 1. break backwards compatibility with TURN, and define MAPPED-ADDRESS to be the source IP/port of the request. Define a new attribute, say RELAY-ADDRESS, that contains the allocated address on the TURN server, and use that in the Allocate response. 2. retain backwards compatibility with TURN, and define a new attribute, ALLOC-SOURCE-ADDR, which indicates the source IP/port of the Allocate request. Thus, we'd have two attributes with the same definition, and you'd need to use one of them with one request type (MAPPED-ADDRESS with Binding Request) and the other with the other request type (ALLOC-SOURCE-ADDR with Allocate Request). 3. Do (1), but only if the client indicates it supports this capability. If not, MAPPED-ADDRESS retains its current meaning and there is no way to get the source IP/port from the Allocate request. Technically speaking, in a greenfield environment, #1 is clearly the right solution. The problem is, there are now several deployments of TURN, some of them large in fact, and I want to be sensitive to backwards compatibility issues. So, I'd like to hear from folks on this, especially ones with implementations or deployments. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 5 Dec 2005 08:19:06 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 5 Dec 2005 08:19:06 -0800 (PST) Subject: [Ietf-behave] TURN Issue #2: Digest for Allocate directly Message-ID: <43946871.80702@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Currently, TURN security relies on a one-time-password approach. The client connects to the TURN server over TLS, and asks for a one time username and password. This request is itself authenticated using digest -over-TLS (using the same username/password structures as SIP). Then, the actual allocate request itself is authenticated using this one-time-password. This approach is reasonably secure, and is not susceptible to the dictionary attacks that regular digest authentication is susceptible too. The cost, however, is that TURN security is very complicated and expensive, processing wise. It will require many TCP/TLS connections to be established, and for them to see significant churn over time. I've also gotten some feedback that it makes TURN load balancing more complicated, since you would need to share these one time passwords between a load balancing element and the TURN server that does the actual allocations. I'm increasingly worried these days that complicated security, even when good, won't be deployed if the costs are too high. And that will mean TURN without any security at all, which is really bad. So, it has been suggested to me to allow the Allocate request itself to be authenticated using a Digest mechanism. The initial Allocate request is sent without credentials. Its rejected with a 401 that provides a nonce, and the request is retried with message-integrity that has an HMAC that includes the NONCE. (I'd likely do this by bringing in the digest authentication into the core stun protocol, and then allowing the TURN allocate to use it). This would vastly simplify TURN security, and make it on par with most existing SIP deployments which work the same way. The other option would continue to exist and be supported, I'd probably also add a way for the TURN server to reject the digest credentials and tell the user they need to obtain a one-time-password. This allows for server operators to change policies about whether this is allowed and still maintain interop with clients. I'd like to go ahead and make this change, but would like feedback from the group on it. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 5 Dec 2005 08:24:25 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 5 Dec 2005 08:24:25 -0800 (PST) Subject: [Ietf-behave] TURN Issue #3: TCP to UDP allocations Message-ID: <439469B5.7050301@cisco.com> MIME-Version: 1.0 Content-Type: text/plain TURN currently provides TCP allocations and UDP allocations. You can open a TCP connection to the sevrer and get a TCP port, and you can open a "UDP connection" to the server and get a UDP port. However, you cannot open a TCP connection to the server and get a UDP port allocated. Such a capability would require the TURN server to apply framing (such as the AVT contrans spec) to push UDP contents over a TCP connection. The benefit to this kind of approach is that it allows for partial UDP transport in situations where one side is behind a nasty symmetric nat or direwall (and thus must have tcp), whereas the other side has UDP connectivity. I've spoken to several people who have deployed voip configurations with this split UDP/TCP RTP transport, and claim it is better than all TCP. I think this is a good idea and we should do it. There are three options here: 1. No, don't allow this. 2. Yes, allow this, but do it via an extension to TURN, rather than in the core spec. 3. Yes, allow it by adding some attributes to the core spec. My proposal is option 2. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 5 Dec 2005 08:29:50 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 5 Dec 2005 08:29:50 -0800 (PST) Subject: [Ietf-behave] TURN Issue #4: TLS TURN requests Message-ID: <43946AF0.6000809@cisco.com> MIME-Version: 1.0 Content-Type: text/plain TURN allows TLS connectivity for the Shared Secret request, but not for the Allocate request itself. I have gotten a request to allow the Allocate request to run over TLS. Once you've swallowed the RTP-over-TCP pill, I don't think this one is a big jump from there. I'll note that there is currently no way in SDP that I know of to signal RTP over TLS; I seem to recall from meeting minutes last month in AVT this was discussed and rejected. That means that this mechanism would be useful with SIP only in conjunction with the TCP to UDP conversion I posted about in Issue #3. In essence, the proposal here is to allow TLS to UDP conversion as well. I'd propose that the general transport of STUN requests (include those defined by usages) over TLS be defined in the core STUN spec. TLS is already there, but just for Shared Secret. One of the things I want to do in the stun revision (like what we did in sip) is separate the transport out so that TCP or TLS transport can be used for any request type. Comments? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From ssenthil@cisco.com Mon, 5 Dec 2005 08:53:39 -0800 (PST) From: "Senthil Sivakumar (ssenthil)" Date: Mon, 5 Dec 2005 08:53:39 -0800 (PST) Subject: [Ietf-behave] Meeting minutes please.. Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FBF7AE6C@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Can someone please post the meeting minutes of the Vancouver meeting and what was decided regarding the TCP draft, for the sake of people who could not attend the meeting? Senthil From jdrosen@cisco.com Mon, 5 Dec 2005 12:24:06 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 5 Dec 2005 12:24:06 -0800 (PST) Subject: [Ietf-behave] TURN Issue #5: the STARTTLS problem Message-ID: <4394A1CF.1010109@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Right now, there is a single TCP port associated with TURN. Unfortunately, there are two distinct uses for TCP: 1. for issuing a Shared Secret request, in which case the message sent by the client after opening the connection will be a TLS ClientHello. 2. for obtaining TCP bindings, in which case the message sent by the client after opening the connection will be a STUN Binding Request. If we allow binding requests over TCP/TLS, that adds another case. This is not a new problem; many protocols have faced the challenge of muxing an application protocol and its TLS version together. There are only a finite set of solutions to it: 1. Different well-known ports for TCP/TLS and just TCP. This is in common usage today with HTTP (443 for HTTP over TCP/TLS and 80 for HTTP over TCP). This approach has the drawback of halving the number of ports that can be registered, and for this reason there has historically been pushback on it. 2. DNS NAPTR records to discover dynamic ports for the protocol versions over TLS/TCP and just TCP. SIP does this (RFC3263), though it also defines a pair of well-known ports (approach 1). 3. STARTTLS procedures. SMTP and HTTP both have procedures that define application layer messages that coordinate an upgrade to TLS. 4. Have the server figure out whether the first message is STUN or TLS, and direct it appropriately. Getting this addresses is probably something that belongs in the core STUn protocol. Generally, you don't want to mix the transport and methods so tightly together as we have them today. I'm inclined to go with #2, with the caveat that there is already a default stun udp and tcp port and those would remain valid (see open issue #6 on applicability to turn). Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 5 Dec 2005 12:33:51 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 5 Dec 2005 12:33:51 -0800 (PST) Subject: [Ietf-behave] TURN Issue #6: port numbers Message-ID: <4394A42C.3000109@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Right now, TURN has no default port. Its marked as XXXX in the spec. With the view that TURN would be a stun usage, its not clear that it needs a separate port from the STUN port. The only reason to have that is if folks think there is a desire from firewall admins to block TURN by disabling its port, but allow STUN. There are a few options here: 1. TURN will reuse the STUN default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN/TURN, but they are always shared. 2. TURN has a separate default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN, and there is also a procedure to detect them for TURN. This would be done by defining a separate NAPTR service for Allocate requests. 3. TURN will reuse the STUN default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN, and there is also a procedure to detect them for TURN. This would be done by defining a separate NAPTR service for Allocate requests. 4. TURN has a separate default port, and there are no DNS procedures defined at all for STUN or TURN. This would imply a specific solution to the TLS problem in Issue #5 (in particular, would imply no DNS-based solutions). Why do this? The only reason is to force usage of TURN over a specific port since no discovery mechanism would exist. This would facilitate firewall port-blocking. Of course, its easily circumvented through configuration of the TURN port (which is what is done today), but its an option. I tend to prefer #1 for simplicity. Unless there is a compelling argument brought about why the TURN and STUN requests NEED to run on different ports, I see no reason for anything else. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 5 Dec 2005 12:41:55 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 5 Dec 2005 12:41:55 -0800 (PST) Subject: [Ietf-behave] TURN Issue #7: Forking interactions Message-ID: <4394A5FC.6070703@cisco.com> MIME-Version: 1.0 Content-Type: text/plain The way TURN works right now, you can only have a single correspondent for media streams if you want to avoid the TURN encapsulations. This is because there can only be one active destination. This has interesting interactions with forking. If a SIP INVITE forks, and you get back multiple 200 OK, each with a single media stream, the caller has to handle that. To avoid encapsulation, it would have to do an additional TURN allocation for each forked branch after the first, and issue a re-invite to modify the media destination to use that new allocated address. Also, after the first 200 OK, it cannot immediately issue a set active destination; it needs to wait a little bit to see if there are any more 200 OK coming. There are a few options here: 1. change nothing; just document this use case in a section that talks specifically about SIP interactions 2. allow for multiple active destinations. This would be a sizeable change in the protocol, requiring that encapsulation always be used, and probably requiring a different encapsulation technique Given how common multiple 200 OK is in practice right now (not much), this strikes me as a corner case for which a non-optimal solution is OK. As such, I would propose #1. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 5 Dec 2005 12:51:05 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 5 Dec 2005 12:51:05 -0800 (PST) Subject: [Ietf-behave] TURN Issue #8: Send Reliable or not? Message-ID: <4394A82F.2040207@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Right now, the Send request is a reliable transaction. This is actually somewhat odd; the corresponding request from server to client, Data Indication, is not reliable. There is actually no reason why Send has to be reliable. I've gotten a proposal from an implementor to change Send to an unreliabel indication. The claim, which I can believe, is that it much simplified things. Any protocol riding about TURN that sends data (like STUn connectivity checks) has its own reliability mechanism anyway, making the mechanism redundant. In and of itself, I think this is a good idea, but it would break backwards compatibility with any existing implementations. As such, I'd like some input prior to making any kind of change. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From derek@counterpath.com Mon, 5 Dec 2005 13:23:04 -0800 (PST) From: "Derek MacDonald" Date: Mon, 5 Dec 2005 13:23:04 -0800 (PST) Subject: RE: [Ietf-behave] TURN Issue #8: Send Reliable or not? In-Reply-To: <4394A82F.2040207@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I agree with the Send request not being reliable. I gather it would then act like a Data Indication where no response is sent? --Derek > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave- > bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jonathan Rosenberg > Sent: Monday, December 05, 2005 12:51 PM > To: Behave > Subject: [Ietf-behave] TURN Issue #8: Send Reliable or not? > > Right now, the Send request is a reliable transaction. This is actually > somewhat odd; the corresponding request from server to client, Data > Indication, is not reliable. There is actually no reason why Send has to > be reliable. I've gotten a proposal from an implementor to change Send > to an unreliabel indication. The claim, which I can believe, is that it > much simplified things. Any protocol riding about TURN that sends data > (like STUn connectivity checks) has its own reliability mechanism > anyway, making the mechanism redundant. > > In and of itself, I think this is a good idea, but it would break > backwards compatibility with any existing implementations. As such, I'd > like some input prior to making any kind of change. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From jdrosen@cisco.com Mon, 5 Dec 2005 13:24:58 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 5 Dec 2005 13:24:58 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #8: Send Reliable or not? In-Reply-To: Message-ID: <4394B01D.1060703@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Yes. -Jonathan R. Derek MacDonald wrote: I agree with the Send request not being reliable. I gather it would then act like a Data Indication where no response is sent? --Derek -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave- bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jonathan Rosenberg Sent: Monday, December 05, 2005 12:51 PM To: Behave Subject: [Ietf-behave] TURN Issue #8: Send Reliable or not? Right now, the Send request is a reliable transaction. This is actually somewhat odd; the corresponding request from server to client, Data Indication, is not reliable. There is actually no reason why Send has to be reliable. I've gotten a proposal from an implementor to change Send to an unreliabel indication. The claim, which I can believe, is that it much simplified things. Any protocol riding about TURN that sends data (like STUn connectivity checks) has its own reliability mechanism anyway, making the mechanism redundant. In and of itself, I think this is a good idea, but it would break backwards compatibility with any existing implementations. As such, I'd like some input prior to making any kind of change. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From audet@nortel.com Mon, 5 Dec 2005 13:38:42 -0800 (PST) From: "Francois Audet" Date: Mon, 5 Dec 2005 13:38:42 -0800 (PST) Subject: RE: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification Message-ID: <1ECE0EB50388174790F9694F77522CCF0597637D@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain >From my own selfish point of view, I prefer 1. This stuff is already complex enough. I believe 1 makes it simpler. 2 and 3 makes it more complex. I'm putting a higher premium on simplicity than backward compatibility which a draft (TURN is not an RFC: in fact, it wasn't even a working group draft). Cheers. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jonathan Rosenberg > Sent: Monday, December 05, 2005 07:57 > To: Behave > Subject: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification > > > As I mentioned during the IETF meeting, I am working on a revision of > STUN that structures the protocol into a "framework" layer (though we > agreed not to call it that per se), and various "usages" that > can define > extensions, define what messages and attributes get used, and define > various security considerations. The plan is for TURN to > become a STUn > usage rather than a separate protocol. I think this is a good thing, > since TURN repeats a lot of stun, and its relationship with > it is unclear. > > One of the things I mentioned as a side benefit of this > unification is > that the TURN Allocate request could perform a stun check as a side > effect. The Allocate response can include the source IP/port of the > Allocate request (equivalent to the MAPPED-ADDRESS in the > STUn Binding > Response). This way, an ICE endpoint, for example, can issue just a > single Allocate request to a turn server, and get back its > stun-derived > AND turn-derived addresses in one operation. This will reduce the > overhead of ICE and simplify things. There seemed to be good > support for > doing this when I proposed it in the meeting last month. > > So, whats the issue? Syntax, unfortunately. > > The IDEAL solution for doing this is that the MAPPED-ADDRESS > attribute > always indicate the source IP/port as seen by the server in > the request, > and that it be usable with the existing STUN Binding Response and the > TURN Allocate Response. Unfortunately, TURN redefined MAPPED-ADDRESS, > and the meaning of MAPPED-ADDRESS in a TURN Allocate Response is the > address allocated by the TURN server itself. > > So, there are several options: > > 1. break backwards compatibility with TURN, and define > MAPPED-ADDRESS to > be the source IP/port of the request. Define a new attribute, say > RELAY-ADDRESS, that contains the allocated address on the > TURN server, > and use that in the Allocate response. > > 2. retain backwards compatibility with TURN, and define a new > attribute, > ALLOC-SOURCE-ADDR, which indicates the source IP/port of the Allocate > request. Thus, we'd have two attributes with the same definition, and > you'd need to use one of them with one request type > (MAPPED-ADDRESS with > Binding Request) and the other with the other request type > (ALLOC-SOURCE-ADDR with Allocate Request). > > 3. Do (1), but only if the client indicates it supports this > capability. > If not, MAPPED-ADDRESS retains its current meaning and there > is no way > to get the source IP/port from the Allocate request. > > > > Technically speaking, in a greenfield environment, #1 is clearly the > right solution. The problem is, there are now several deployments of > TURN, some of them large in fact, and I want to be sensitive to > backwards compatibility issues. > > So, I'd like to hear from folks on this, especially ones with > implementations or deployments. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortel.com Mon, 5 Dec 2005 13:53:47 -0800 (PST) From: "Francois Audet" Date: Mon, 5 Dec 2005 13:53:47 -0800 (PST) Subject: RE: [Ietf-behave] TURN Issue #7: Forking interactions Message-ID: <1ECE0EB50388174790F9694F77522CCF059763EA@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Don't we have the same problem with multiple 183s with SDP for early media? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jonathan Rosenberg > Sent: Monday, December 05, 2005 12:42 > To: Behave > Subject: [Ietf-behave] TURN Issue #7: Forking interactions > > > The way TURN works right now, you can only have a single > correspondent > for media streams if you want to avoid the TURN > encapsulations. This is > because there can only be one active destination. > > This has interesting interactions with forking. If a SIP > INVITE forks, > and you get back multiple 200 OK, each with a single media > stream, the > caller has to handle that. To avoid encapsulation, it would > have to do > an additional TURN allocation for each forked branch after the first, > and issue a re-invite to modify the media destination to use that new > allocated address. Also, after the first 200 OK, it cannot > immediately > issue a set active destination; it needs to wait a little bit > to see if > there are any more 200 OK coming. > > There are a few options here: > > 1. change nothing; just document this use case in a section > that talks > specifically about SIP interactions > > 2. allow for multiple active destinations. This would be a sizeable > change in the protocol, requiring that encapsulation always > be used, and > probably requiring a different encapsulation technique > > > Given how common multiple 200 OK is in practice right now (not much), > this strikes me as a corner case for which a non-optimal > solution is OK. > As such, I would propose #1. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From K.Johns@CableLabs.com Mon, 5 Dec 2005 14:15:09 -0800 (PST) From: "Kevin Johns" Date: Mon, 5 Dec 2005 14:15:09 -0800 (PST) Subject: RE: [Ietf-behave] TURN Issue #6: port numbers Message-ID: MIME-Version: 1.0 Content-Type: text/plain Jonathan, How would approach 1 work if a single box was running both STUn and TURN services? Kevin -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxx] Sent: Monday, December 05, 2005 1:34 PM To: Behave Subject: [Ietf-behave] TURN Issue #6: port numbers Right now, TURN has no default port. Its marked as XXXX in the spec. With the view that TURN would be a stun usage, its not clear that it needs a separate port from the STUN port. The only reason to have that is if folks think there is a desire from firewall admins to block TURN by disabling its port, but allow STUN. There are a few options here: 1. TURN will reuse the STUN default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN/TURN, but they are always shared. 2. TURN has a separate default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN, and there is also a procedure to detect them for TURN. This would be done by defining a separate NAPTR service for Allocate requests. 3. TURN will reuse the STUN default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN, and there is also a procedure to detect them for TURN. This would be done by defining a separate NAPTR service for Allocate requests. 4. TURN has a separate default port, and there are no DNS procedures defined at all for STUN or TURN. This would imply a specific solution to the TLS problem in Issue #5 (in particular, would imply no DNS-based solutions). Why do this? The only reason is to force usage of TURN over a specific port since no discovery mechanism would exist. This would facilitate firewall port-blocking. Of course, its easily circumvented through configuration of the TURN port (which is what is done today), but its an option. I tend to prefer #1 for simplicity. Unless there is a compelling argument brought about why the TURN and STUN requests NEED to run on different ports, I see no reason for anything else. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From derek@counterpath.com Mon, 5 Dec 2005 14:15:42 -0800 (PST) From: "Derek MacDonald" Date: Mon, 5 Dec 2005 14:15:42 -0800 (PST) Subject: RE: [Ietf-behave] TURN Issue #7: Forking interactions In-Reply-To: <1ECE0EB50388174790F9694F77522CCF059763EA@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I wasn't under impressions that setting an active destination restricted traffic to that destination only. If we make Send Request unreliable, it seems that we could use turn encapsulation for one of the targets with minimal overhead. The client needs to keep track of which of the multiple targets is active, and possibly optimize the current active destination when some call legs are removed but it shouldn't be too hard. Given the above assumptions I vote for #1. --Derek > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave- > bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Francois Audet > Sent: Monday, December 05, 2005 1:54 PM > To: Jonathan Rosenberg; Behave > Subject: RE: [Ietf-behave] TURN Issue #7: Forking interactions > > Don't we have the same problem with multiple 183s with SDP for > early media? > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Jonathan Rosenberg > > Sent: Monday, December 05, 2005 12:42 > > To: Behave > > Subject: [Ietf-behave] TURN Issue #7: Forking interactions > > > > > > The way TURN works right now, you can only have a single > > correspondent > > for media streams if you want to avoid the TURN > > encapsulations. This is > > because there can only be one active destination. > > > > This has interesting interactions with forking. If a SIP > > INVITE forks, > > and you get back multiple 200 OK, each with a single media > > stream, the > > caller has to handle that. To avoid encapsulation, it would > > have to do > > an additional TURN allocation for each forked branch after the first, > > and issue a re-invite to modify the media destination to use that new > > allocated address. Also, after the first 200 OK, it cannot > > immediately > > issue a set active destination; it needs to wait a little bit > > to see if > > there are any more 200 OK coming. > > > > There are a few options here: > > > > 1. change nothing; just document this use case in a section > > that talks > > specifically about SIP interactions > > > > 2. allow for multiple active destinations. This would be a sizeable > > change in the protocol, requiring that encapsulation always > > be used, and > > probably requiring a different encapsulation technique > > > > > > Given how common multiple 200 OK is in practice right now (not much), > > this strikes me as a corner case for which a non-optimal > > solution is OK. > > As such, I would propose #1. > > > > Thanks, > > Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Mon, 5 Dec 2005 18:00:53 -0800 (PST) From: "Francois Audet" Date: Mon, 5 Dec 2005 18:00:53 -0800 (PST) Subject: RE: [Ietf-behave] TURN Issue #6: port numbers Message-ID: <1ECE0EB50388174790F9694F77522CCF05976746@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I agree. I think it facilitates integration of STUN server and TURN server on Enterprise Firewalls. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jonathan Rosenberg > Sent: Monday, December 05, 2005 12:34 > To: Behave > Subject: [Ietf-behave] TURN Issue #6: port numbers > > > Right now, TURN has no default port. Its marked as XXXX in the spec. > With the view that TURN would be a stun usage, its not clear that it > needs a separate port from the STUN port. The only reason to > have that > is if folks think there is a desire from firewall admins to > block TURN > by disabling its port, but allow STUN. There are a few options here: > > 1. TURN will reuse the STUN default port. DNS procedures also > exist to > detect the udp, tcp, etc. ports for STUN/TURN, but they are > always shared. > > 2. TURN has a separate default port. DNS procedures also > exist to detect > the udp, tcp, etc. ports for STUN, and there is also a procedure to > detect them for TURN. This would be done by defining a separate NAPTR > service for Allocate requests. > > 3. TURN will reuse the STUN default port. DNS procedures also > exist to > detect the udp, tcp, etc. ports for STUN, and there is also a > procedure > to detect them for TURN. This would be done by defining a > separate NAPTR > service for Allocate requests. > > 4. TURN has a separate default port, and there are no DNS procedures > defined at all for STUN or TURN. This would imply a specific > solution to > the TLS problem in Issue #5 (in particular, would imply no DNS-based > solutions). Why do this? The only reason is to force usage of > TURN over > a specific port since no discovery mechanism would exist. This would > facilitate firewall port-blocking. Of course, its easily circumvented > through configuration of the TURN port (which is what is done today), > but its an option. > > > I tend to prefer #1 for simplicity. Unless there is a compelling > argument brought about why the TURN and STUN requests NEED to run on > different ports, I see no reason for anything else. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From jason@counterpath.com Mon, 5 Dec 2005 18:01:12 -0800 (PST) From: Jason Fischl Date: Mon, 5 Dec 2005 18:01:12 -0800 (PST) Subject: Re: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0597637D@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 12/5/05, Francois Audet wrote: > >From my own selfish point of view, I prefer 1. > > This stuff is already complex enough. I believe 1 makes it simpler. 2 > and 3 > makes it more complex. > > I'm putting a higher premium on simplicity than backward compatibility > which > a draft (TURN is not an RFC: in fact, it wasn't even a working group > draft). > I agree with option 1. From diegob@mailvision.com Mon, 5 Dec 2005 23:23:45 -0800 (PST) From: Diego B Date: Mon, 5 Dec 2005 23:23:45 -0800 (PST) Subject: Re: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0597637D@zrc2hxm0.corp.nortel.com> Message-ID: <43953C77.3080209@mailvision.com> MIME-Version: 1.0 Content-Type: text/plain I vote for 1; We also have some large deployments using the old drafts, but if you really wants to turn STUn into a framework and TURN to be an application of that framework, I think is better "breaking" backwards compatibility now that TURN is still in draft and putting a strong requirements on future extencions ( or applications ) than let other applications to redefine agaian the "base" attributes. Regards Diego B -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jonathan Rosenberg Sent: Monday, December 05, 2005 07:57 To: Behave Subject: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification As I mentioned during the IETF meeting, I am working on a revision of STUN that structures the protocol into a "framework" layer (though we agreed not to call it that per se), and various "usages" that can define extensions, define what messages and attributes get used, and define various security considerations. The plan is for TURN to become a STUn usage rather than a separate protocol. I think this is a good thing, since TURN repeats a lot of stun, and its relationship with it is unclear. One of the things I mentioned as a side benefit of this unification is that the TURN Allocate request could perform a stun check as a side effect. The Allocate response can include the source IP/port of the Allocate request (equivalent to the MAPPED-ADDRESS in the STUn Binding Response). This way, an ICE endpoint, for example, can issue just a single Allocate request to a turn server, and get back its stun-derived AND turn-derived addresses in one operation. This will reduce the overhead of ICE and simplify things. There seemed to be good support for doing this when I proposed it in the meeting last month. So, whats the issue? Syntax, unfortunately. The IDEAL solution for doing this is that the MAPPED-ADDRESS attribute always indicate the source IP/port as seen by the server in the request, and that it be usable with the existing STUN Binding Response and the TURN Allocate Response. Unfortunately, TURN redefined MAPPED-ADDRESS, and the meaning of MAPPED-ADDRESS in a TURN Allocate Response is the address allocated by the TURN server itself. So, there are several options: 1. break backwards compatibility with TURN, and define MAPPED-ADDRESS to be the source IP/port of the request. Define a new attribute, say RELAY-ADDRESS, that contains the allocated address on the TURN server, and use that in the Allocate response. 2. retain backwards compatibility with TURN, and define a new attribute, ALLOC-SOURCE-ADDR, which indicates the source IP/port of the Allocate request. Thus, we'd have two attributes with the same definition, and you'd need to use one of them with one request type (MAPPED-ADDRESS with Binding Request) and the other with the other request type (ALLOC-SOURCE-ADDR with Allocate Request). 3. Do (1), but only if the client indicates it supports this capability. If not, MAPPED-ADDRESS retains its current meaning and there is no way to get the source IP/port from the Allocate request. Technically speaking, in a greenfield environment, #1 is clearly the right solution. The problem is, there are now several deployments of TURN, some of them large in fact, and I want to be sensitive to backwards compatibility issues. So, I'd like to hear from folks on this, especially ones with implementations or deployments. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From sg266@cornell.edu Tue, 6 Dec 2005 01:41:14 -0800 (PST) From: Saikat Guha Date: Tue, 6 Dec 2005 01:41:14 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #3: TCP to UDP allocations In-Reply-To: <439469B5.7050301@cisco.com> Message-ID: <1133862073.3099.28.camel@himalaya.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630135.multipart/signed" --Boundary..27398.1163630135.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-12-05 at 11:24 -0500, Jonathan Rosenberg wrote: > However, you cannot > open a TCP connection to the server and get a UDP port allocated. > [...] > > 1. No, don't allow this. > > 2. Yes, allow this, but do it via an extension to TURN, rather than in > the core spec. > > 3. Yes, allow it by adding some attributes to the core spec. FWIW, when NAT traversal in Skype fails, it falls back onto a TURN-like relay server, which bridges UDP and TCP. I have data that shows that this functionality is invoked often (I can get numbers if people think thats useful). So my vote is either option 2 or 3. -- Saikat Attachment: signature.asc --Boundary..27398.1163630135.multipart/signed Content-Type: application/octet-stream; name="pgp00089.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00089.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFCRGxWeTVuRmx0cWk2OTEvb1JBdGpsQUo5NzUwa3hWU29aelgrOUJFb29Y MGRaeDFxSTNBQ2ZSN28vClQrd2gzRzFPMi8xdk1Bcm9mbndGa2MwPQo9NThWYQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630135.multipart/signed-- From saikat@cs.cornell.edu Tue, 6 Dec 2005 02:00:58 -0800 (PST) From: Saikat Guha Date: Tue, 6 Dec 2005 02:00:58 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #5: the STARTTLS problem In-Reply-To: <4394A1CF.1010109@cisco.com> Message-ID: <1133863256.3099.41.camel@himalaya.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630135.multipart/signed" --Boundary..27398.1163630135.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-12-05 at 15:23 -0500, Jonathan Rosenberg wrote: > Right now, there is a single TCP port associated with TURN. > > 1. Different well-known ports [...] > 2. DNS NAPTR records to discover dynamic ports [...] > 3. STARTTLS procedures. [...] > 4. Have the server figure out whether the first message is STUN or TLS[...] > > I'm inclined to go with #2, with the caveat that there is already a > default stun udp and tcp port and those would remain valid (see open > issue #6 on applicability to turn). Would #2 require that TURN servers (and potentially ICE endpoints) have some DNS server where they can advertise their dynamic ports, hopefully through some secure dynamic-DNS-update protocol? If so, is the presence of such a DNS-relationship already required? Given how hard it is to convince my IT department to add just a CNAME, #2 would be at the bottom of my preference list. #3 makes for a nice compromise between 1 and 4. -- Saikat Attachment: signature.asc --Boundary..27398.1163630135.multipart/signed Content-Type: application/octet-stream; name="pgp00090.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00090.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFCRGxXRlluRmx0cWk2OTEvb1JBblBLQUo5Y0o5aXlpelVRZUFteWxUTnZa eHFQR3pvaEhBQ2VPbWhyCnBpUDNzaWZqWmpJTytKNzROY0FZNmhVPQo9MGM0MwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630135.multipart/signed-- From jason@counterpath.com Tue, 6 Dec 2005 08:11:03 -0800 (PST) From: Jason Fischl Date: Tue, 6 Dec 2005 08:11:03 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #3: TCP to UDP allocations In-Reply-To: <439469B5.7050301@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 12/6/05, Saikat Guha wrote: > On Mon, 2005-12-05 at 11:24 -0500, Jonathan Rosenberg wrote: > > However, you cannot > > open a TCP connection to the server and get a UDP port allocated. > > [...] > > > > 1. No, don't allow this. > > > > 2. Yes, allow this, but do it via an extension to TURN, rather than in > > the core spec. > > > > 3. Yes, allow it by adding some attributes to the core spec. > My vote is 3. > > FWIW, when NAT traversal in Skype fails, it falls back onto a TURN-like > relay server, which bridges UDP and TCP. I have data that shows that > this functionality is invoked often (I can get numbers if people think > thats useful). > Yes. Please provide any stats that you might have. From petithug@acm.org Tue, 6 Dec 2005 08:21:49 -0800 (PST) From: Marc Petit-Huguenin Date: Tue, 6 Dec 2005 08:21:49 -0800 (PST) Subject: Re: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification In-Reply-To: <43946339.1040306@cisco.com> Message-ID: <4395BA8E.2050802@acm.org> MIME-Version: 1.0 Content-Type: text/plain I vote for #1. Jonathan Rosenberg wrote: > As I mentioned during the IETF meeting, I am working on a revision of > STUN that structures the protocol into a "framework" layer (though we > agreed not to call it that per se), and various "usages" that can define > extensions, define what messages and attributes get used, and define > various security considerations. The plan is for TURN to become a STUn > usage rather than a separate protocol. I think this is a good thing, > since TURN repeats a lot of stun, and its relationship with it is unclear. > > One of the things I mentioned as a side benefit of this unification is > that the TURN Allocate request could perform a stun check as a side > effect. The Allocate response can include the source IP/port of the > Allocate request (equivalent to the MAPPED-ADDRESS in the STUn Binding > Response). This way, an ICE endpoint, for example, can issue just a > single Allocate request to a turn server, and get back its stun-derived > AND turn-derived addresses in one operation. This will reduce the > overhead of ICE and simplify things. There seemed to be good support for > doing this when I proposed it in the meeting last month. > > So, whats the issue? Syntax, unfortunately. > > The IDEAL solution for doing this is that the MAPPED-ADDRESS attribute > always indicate the source IP/port as seen by the server in the request, > and that it be usable with the existing STUN Binding Response and the > TURN Allocate Response. Unfortunately, TURN redefined MAPPED-ADDRESS, > and the meaning of MAPPED-ADDRESS in a TURN Allocate Response is the > address allocated by the TURN server itself. > > So, there are several options: > > 1. break backwards compatibility with TURN, and define MAPPED-ADDRESS to > be the source IP/port of the request. Define a new attribute, say > RELAY-ADDRESS, that contains the allocated address on the TURN server, > and use that in the Allocate response. > > 2. retain backwards compatibility with TURN, and define a new attribute, > ALLOC-SOURCE-ADDR, which indicates the source IP/port of the Allocate > request. Thus, we'd have two attributes with the same definition, and > you'd need to use one of them with one request type (MAPPED-ADDRESS with > Binding Request) and the other with the other request type > (ALLOC-SOURCE-ADDR with Allocate Request). > > 3. Do (1), but only if the client indicates it supports this capability. > If not, MAPPED-ADDRESS retains its current meaning and there is no way > to get the source IP/port from the Allocate request. > > > > Technically speaking, in a greenfield environment, #1 is clearly the > right solution. The problem is, there are now several deployments of > TURN, some of them large in fact, and I want to be sensitive to > backwards compatibility issues. > > So, I'd like to hear from folks on this, especially ones with > implementations or deployments. > > Thanks, > Jonathan R. -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Professional: petithug@xxxxxxx Work: marc@xxxxxxx From petithug@acm.org Tue, 6 Dec 2005 08:28:01 -0800 (PST) From: Marc Petit-Huguenin Date: Tue, 6 Dec 2005 08:28:01 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #8: Send Reliable or not? In-Reply-To: <4394A82F.2040207@cisco.com> Message-ID: <4395BBCE.8020100@acm.org> MIME-Version: 1.0 Content-Type: text/plain Jonathan Rosenberg wrote: > Right now, the Send request is a reliable transaction. This is actually > somewhat odd; the corresponding request from server to client, Data > Indication, is not reliable. There is actually no reason why Send has to > be reliable. I've gotten a proposal from an implementor to change Send > to an unreliabel indication. The claim, which I can believe, is that it > much simplified things. Any protocol riding about TURN that sends data > (like STUn connectivity checks) has its own reliability mechanism > anyway, making the mechanism redundant. > > In and of itself, I think this is a good idea, but it would break > backwards compatibility with any existing implementations. As such, I'd > like some input prior to making any kind of change. We also had a lot of problems with this and we chose to do not retransmit the SendRequest on the client side if no response is received. The solution of not having any response is even better. > > Thanks, > Jonathan R. -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Professional: petithug@xxxxxxx Work: marc@xxxxxxx From csp@csperkins.org Tue, 6 Dec 2005 10:16:17 -0800 (PST) From: Colin Perkins Date: Tue, 6 Dec 2005 10:16:17 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #4: TLS TURN requests In-Reply-To: <43946AF0.6000809@cisco.com> Message-ID: <77E0B4E8-ECDB-4399-8F5D-9F01FAAEA9BA@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain On 5 Dec 2005, at 16:29, Jonathan Rosenberg wrote: TURN allows TLS connectivity for the Shared Secret request, but not for the Allocate request itself. I have gotten a request to allow the Allocate request to run over TLS. Once you've swallowed the RTP- over-TCP pill, I don't think this one is a big jump from there. I'll note that there is currently no way in SDP that I know of to signal RTP over TLS; I seem to recall from meeting minutes last month in AVT this was discussed and rejected. AVT has an existing milestone to work on RTP-over-TLS, but it seems no-one is interested in doing the work. The discussion in the meeting was that we would remove the milestone when updating our charter, unless there was interest. Colin From derek@counterpath.com Tue, 6 Dec 2005 11:01:53 -0800 (PST) From: "Derek MacDonald" Date: Tue, 6 Dec 2005 11:01:53 -0800 (PST) Subject: RE: [Ietf-behave] TURN Issue #3: TCP to UDP allocations In-Reply-To: <439469B5.7050301@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I vote #3. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave- > bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jonathan Rosenberg > Sent: Monday, December 05, 2005 8:24 AM > To: Behave > Subject: [Ietf-behave] TURN Issue #3: TCP to UDP allocations > > TURN currently provides TCP allocations and UDP allocations. You can > open a TCP connection to the sevrer and get a TCP port, and you can open > a "UDP connection" to the server and get a UDP port. However, you cannot > open a TCP connection to the server and get a UDP port allocated. Such a > capability would require the TURN server to apply framing (such as the > AVT contrans spec) to push UDP contents over a TCP connection. > > The benefit to this kind of approach is that it allows for partial UDP > transport in situations where one side is behind a nasty symmetric nat > or direwall (and thus must have tcp), whereas the other side has UDP > connectivity. I've spoken to several people who have deployed voip > configurations with this split UDP/TCP RTP transport, and claim it is > better than all TCP. > > I think this is a good idea and we should do it. There are three options > here: > > 1. No, don't allow this. > > 2. Yes, allow this, but do it via an extension to TURN, rather than in > the core spec. > > 3. Yes, allow it by adding some attributes to the core spec. > > > My proposal is option 2. > > Comments? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fernando@gont.com.ar Fri, 9 Dec 2005 04:37:11 -0800 (PST) From: Fernando Gont Date: Fri, 9 Dec 2005 04:37:11 -0800 (PST) Subject: [Ietf-behave] Feedback on the meeting minutes Message-ID: <6.2.0.14.0.20051209042742.03b7ad88@localhost> MIME-Version: 1.0 Content-Type: text/plain Hi, Some feedback on the meeting minutes 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. One issue I raised at the meeting and that is not reflected in the minutes is that the authors seem to assume that an ICMP soft-error will prevent identity theft, when it won't. As per RFC 1122, TCP will not abort connections upon receipt of an ICMP soft error. However, an internet-draft on TCP's reaction to soft errors that has become a WG item of the TCPM WG describes an alternative behaviour implemented in many TCP implementations, which makes TCP abort a connection when it is in any of the non-synchronized states. (see http://www.gont.com.ar , TCP's reaction to soft errors). Even then, note that if anything, sending an ICMP soft error (in case the above behaviour is implemented) will elict the same reaction from TCP than a TCP RST. So, if anything, use TCP resets, instead of ICMP messages. Kindest regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx From jdrosen@cisco.com Fri, 9 Dec 2005 11:54:24 -0800 (PST) From: Jonathan Rosenberg Date: Fri, 9 Dec 2005 11:54:24 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #6: port numbers In-Reply-To: Message-ID: <4399E0E6.4030506@cisco.com> MIME-Version: 1.0 Content-Type: text/plain It would work fine because there wouldn't really be a separate STUN and TURN server. Rather, there would be a STUN server that supports the binding discovery usage (i.e., the BindingRequest) and the relay usage (i.e., the Allocate Request). -Jonathan R. Kevin Johns wrote: Jonathan, How would approach 1 work if a single box was running both STUn and TURN services? Kevin -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxx] Sent: Monday, December 05, 2005 1:34 PM To: Behave Subject: [Ietf-behave] TURN Issue #6: port numbers Right now, TURN has no default port. Its marked as XXXX in the spec. With the view that TURN would be a stun usage, its not clear that it needs a separate port from the STUN port. The only reason to have that is if folks think there is a desire from firewall admins to block TURN by disabling its port, but allow STUN. There are a few options here: 1. TURN will reuse the STUN default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN/TURN, but they are always shared. 2. TURN has a separate default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN, and there is also a procedure to detect them for TURN. This would be done by defining a separate NAPTR service for Allocate requests. 3. TURN will reuse the STUN default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN, and there is also a procedure to detect them for TURN. This would be done by defining a separate NAPTR service for Allocate requests. 4. TURN has a separate default port, and there are no DNS procedures defined at all for STUN or TURN. This would imply a specific solution to the TLS problem in Issue #5 (in particular, would imply no DNS-based solutions). Why do this? The only reason is to force usage of TURN over a specific port since no discovery mechanism would exist. This would facilitate firewall port-blocking. Of course, its easily circumvented through configuration of the TURN port (which is what is done today), but its an option. I tend to prefer #1 for simplicity. Unless there is a compelling argument brought about why the TURN and STUN requests NEED to run on different ports, I see no reason for anything else. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jiri@iptel.org Fri, 9 Dec 2005 23:59:10 -0800 (PST) From: Jiri Kuthan Date: Fri, 9 Dec 2005 23:59:10 -0800 (PST) Subject: Re: [Ietf-behave] Meeting minutes please.. In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FBF7AE6C@xmb-sjc-236.amer.cisco.com> Message-ID: <6.2.5.6.0.20051210085830.061f4a90@iptel.org> MIME-Version: 1.0 Content-Type: text/plain Attached are raw minutes, courtesy of Eric Burger. -jiri ---------------------------------------------------------------- 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). At 05:53 PM 12/5/2005, Senthil Sivakumar (ssenthil) wrote: >Can someone please post the meeting minutes of the Vancouver meeting and >what was decided regarding the TCP draft, for the sake of people who >could not attend the meeting? > >Senthil >_______________________________________________ >Ietf-behave mailing list >Ietf-behave@xxxxxxxxxxxxxxxxxxx >https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jiri Kuthan http://iptel.org/~jiri/ From fluffy@cisco.com Tue, 13 Dec 2005 20:36:30 -0800 (PST) From: Cullen Jennings Date: Tue, 13 Dec 2005 20:36:30 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #6: port numbers In-Reply-To: <4394A42C.3000109@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain If STUN and TURN are on the same port, it make it much harder to right rate limiting rules for them. I don't know if this matters much but worth a bit of thought. On 12/5/05 12:33 PM, "Jonathan Rosenberg" wrote: > Right now, TURN has no default port. Its marked as XXXX in the spec. > With the view that TURN would be a stun usage, its not clear that it > needs a separate port from the STUN port. The only reason to have that > is if folks think there is a desire from firewall admins to block TURN > by disabling its port, but allow STUN. There are a few options here: > > 1. TURN will reuse the STUN default port. DNS procedures also exist to > detect the udp, tcp, etc. ports for STUN/TURN, but they are always shared. > > 2. TURN has a separate default port. DNS procedures also exist to detect > the udp, tcp, etc. ports for STUN, and there is also a procedure to > detect them for TURN. This would be done by defining a separate NAPTR > service for Allocate requests. > > 3. TURN will reuse the STUN default port. DNS procedures also exist to > detect the udp, tcp, etc. ports for STUN, and there is also a procedure > to detect them for TURN. This would be done by defining a separate NAPTR > service for Allocate requests. > > 4. TURN has a separate default port, and there are no DNS procedures > defined at all for STUN or TURN. This would imply a specific solution to > the TLS problem in Issue #5 (in particular, would imply no DNS-based > solutions). Why do this? The only reason is to force usage of TURN over > a specific port since no discovery mechanism would exist. This would > facilitate firewall port-blocking. Of course, its easily circumvented > through configuration of the TURN port (which is what is done today), > but its an option. > > > I tend to prefer #1 for simplicity. Unless there is a compelling > argument brought about why the TURN and STUN requests NEED to run on > different ports, I see no reason for anything else. > > -Jonathan R. > > From fluffy@cisco.com Tue, 13 Dec 2005 20:36:32 -0800 (PST) From: Cullen Jennings Date: Tue, 13 Dec 2005 20:36:32 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #5: the STARTTLS problem In-Reply-To: <4394A1CF.1010109@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I would prefer a solution that was possible to deploy without using NAPTR (note, I'm ok if NAPTR is MUST implement just have problems with MUST deploy). NAPTR is still difficult to deploy in many situations. If you do a STARTTLS start TLS on a connection, you can not stop it so all the data traffic after that would have to be TLS encrypted. This is probably not a good thing. I think the combination of the above two makes me lean towards #1. On 12/5/05 12:23 PM, "Jonathan Rosenberg" wrote: > Right now, there is a single TCP port associated with TURN. > Unfortunately, there are two distinct uses for TCP: > > 1. for issuing a Shared Secret request, in which case the message sent > by the client after opening the connection will be a TLS ClientHello. > > 2. for obtaining TCP bindings, in which case the message sent by the > client after opening the connection will be a STUN Binding Request. > > > If we allow binding requests over TCP/TLS, that adds another case. > > This is not a new problem; many protocols have faced the challenge of > muxing an application protocol and its TLS version together. There are > only a finite set of solutions to it: > > 1. Different well-known ports for TCP/TLS and just TCP. This is in > common usage today with HTTP (443 for HTTP over TCP/TLS and 80 for HTTP > over TCP). This approach has the drawback of halving the number of ports > that can be registered, and for this reason there has historically been > pushback on it. > > 2. DNS NAPTR records to discover dynamic ports for the protocol versions > over TLS/TCP and just TCP. SIP does this (RFC3263), though it also > defines a pair of well-known ports (approach 1). > > 3. STARTTLS procedures. SMTP and HTTP both have procedures that define > application layer messages that coordinate an upgrade to TLS. > > 4. Have the server figure out whether the first message is STUN or TLS, > and direct it appropriately. > > Getting this addresses is probably something that belongs in the core > STUn protocol. Generally, you don't want to mix the transport and > methods so tightly together as we have them today. > > I'm inclined to go with #2, with the caveat that there is already a > default stun udp and tcp port and those would remain valid (see open > issue #6 on applicability to turn). > > Thanks, > Jonathan R. From fluffy@cisco.com Tue, 13 Dec 2005 20:36:34 -0800 (PST) From: Cullen Jennings Date: Tue, 13 Dec 2005 20:36:34 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #4: TLS TURN requests In-Reply-To: <77E0B4E8-ECDB-4399-8F5D-9F01FAAEA9BA@csperkins.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Interesting - given that draft-ietf-avt-rtp-framing-contrans and draft-ietf-mmusic-comedia-tls both seem to be proceeding, I'm surprised to hear this. I would not be surprised to see more interest in RTP over TLS. On 12/6/05 10:16 AM, "Colin Perkins" wrote: > On 5 Dec 2005, at 16:29, Jonathan Rosenberg wrote: >> TURN allows TLS connectivity for the Shared Secret request, but not >> for the Allocate request itself. I have gotten a request to allow >> the Allocate request to run over TLS. Once you've swallowed the RTP- >> over-TCP pill, I don't think this one is a big jump from there. >> >> I'll note that there is currently no way in SDP that I know of to >> signal RTP over TLS; I seem to recall from meeting minutes last >> month in AVT this was discussed and rejected. > > AVT has an existing milestone to work on RTP-over-TLS, but it seems > no-one is interested in doing the work. The discussion in the meeting > was that we would remove the milestone when updating our charter, > unless there was interest. > > Colin > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Tue, 13 Dec 2005 20:36:38 -0800 (PST) From: Cullen Jennings Date: Tue, 13 Dec 2005 20:36:38 -0800 (PST) Subject: Re: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification In-Reply-To: <4395BA8E.2050802@acm.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I'm not aware of any deployments that would find #1 difficult to migrate to, so, #1 sounds best. On 12/6/05 8:21 AM, "Marc Petit-Huguenin" wrote: > I vote for #1. > > Jonathan Rosenberg wrote: >> As I mentioned during the IETF meeting, I am working on a revision of >> STUN that structures the protocol into a "framework" layer (though we >> agreed not to call it that per se), and various "usages" that can define >> extensions, define what messages and attributes get used, and define >> various security considerations. The plan is for TURN to become a STUn >> usage rather than a separate protocol. I think this is a good thing, >> since TURN repeats a lot of stun, and its relationship with it is unclear. >> >> One of the things I mentioned as a side benefit of this unification is >> that the TURN Allocate request could perform a stun check as a side >> effect. The Allocate response can include the source IP/port of the >> Allocate request (equivalent to the MAPPED-ADDRESS in the STUn Binding >> Response). This way, an ICE endpoint, for example, can issue just a >> single Allocate request to a turn server, and get back its stun-derived >> AND turn-derived addresses in one operation. This will reduce the >> overhead of ICE and simplify things. There seemed to be good support for >> doing this when I proposed it in the meeting last month. >> >> So, whats the issue? Syntax, unfortunately. >> >> The IDEAL solution for doing this is that the MAPPED-ADDRESS attribute >> always indicate the source IP/port as seen by the server in the request, >> and that it be usable with the existing STUN Binding Response and the >> TURN Allocate Response. Unfortunately, TURN redefined MAPPED-ADDRESS, >> and the meaning of MAPPED-ADDRESS in a TURN Allocate Response is the >> address allocated by the TURN server itself. >> >> So, there are several options: >> >> 1. break backwards compatibility with TURN, and define MAPPED-ADDRESS to >> be the source IP/port of the request. Define a new attribute, say >> RELAY-ADDRESS, that contains the allocated address on the TURN server, >> and use that in the Allocate response. >> >> 2. retain backwards compatibility with TURN, and define a new attribute, >> ALLOC-SOURCE-ADDR, which indicates the source IP/port of the Allocate >> request. Thus, we'd have two attributes with the same definition, and >> you'd need to use one of them with one request type (MAPPED-ADDRESS with >> Binding Request) and the other with the other request type >> (ALLOC-SOURCE-ADDR with Allocate Request). >> >> 3. Do (1), but only if the client indicates it supports this capability. >> If not, MAPPED-ADDRESS retains its current meaning and there is no way >> to get the source IP/port from the Allocate request. >> >> >> >> Technically speaking, in a greenfield environment, #1 is clearly the >> right solution. The problem is, there are now several deployments of >> TURN, some of them large in fact, and I want to be sensitive to >> backwards compatibility issues. >> >> So, I'd like to hear from folks on this, especially ones with >> implementations or deployments. >> >> Thanks, >> Jonathan R. > From audet@nortel.com Wed, 14 Dec 2005 08:26:06 -0800 (PST) From: "Francois Audet" Date: Wed, 14 Dec 2005 08:26:06 -0800 (PST) Subject: RE: [Ietf-behave] TURN Issue #6: port numbers Message-ID: <1ECE0EB50388174790F9694F77522CCF05BC9447@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain You mean the same signalling port, right, not the same tunnelled packets? Being on the same signalling port makes sense. For tunnelled packets, probably not. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Cullen Jennings > Sent: Tuesday, December 13, 2005 19:35 > To: Jonathan Rosenberg; Behave > Subject: Re: [Ietf-behave] TURN Issue #6: port numbers > > > > If STUN and TURN are on the same port, it make it much harder > to right rate limiting rules for them. I don't know if this > matters much but worth a bit of thought. > > > On 12/5/05 12:33 PM, "Jonathan Rosenberg" wrote: > > > Right now, TURN has no default port. Its marked as XXXX in > the spec. > > With the view that TURN would be a stun usage, its not > clear that it > > needs a separate port from the STUN port. The only reason > to have that > > is if folks think there is a desire from firewall admins to > block TURN > > by disabling its port, but allow STUN. There are a few options here: > > > > 1. TURN will reuse the STUN default port. DNS procedures > also exist to > > detect the udp, tcp, etc. ports for STUN/TURN, but they are always > > shared. > > > > 2. TURN has a separate default port. DNS procedures also exist to > > detect the udp, tcp, etc. ports for STUN, and there is also a > > procedure to detect them for TURN. This would be done by defining a > > separate NAPTR service for Allocate requests. > > > > 3. TURN will reuse the STUN default port. DNS procedures > also exist to > > detect the udp, tcp, etc. ports for STUN, and there is also a > > procedure to detect them for TURN. This would be done by defining a > > separate NAPTR service for Allocate requests. > > > > 4. TURN has a separate default port, and there are no DNS > procedures > > defined at all for STUN or TURN. This would imply a > specific solution > > to the TLS problem in Issue #5 (in particular, would imply no > > DNS-based solutions). Why do this? The only reason is to > force usage > > of TURN over a specific port since no discovery mechanism > would exist. > > This would facilitate firewall port-blocking. Of course, its easily > > circumvented through configuration of the TURN port (which > is what is > > done today), but its an option. > > > > > > I tend to prefer #1 for simplicity. Unless there is a compelling > > argument brought about why the TURN and STUN requests NEED > to run on > > different ports, I see no reason for anything else. > > > > -Jonathan R. > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From fluffy@cisco.com Wed, 14 Dec 2005 11:44:20 -0800 (PST) From: Cullen Jennings Date: Wed, 14 Dec 2005 11:44:20 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #6: port numbers In-Reply-To: <1ECE0EB50388174790F9694F77522CCF05BC9447@zrc2hxm0.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hmm - I might be missing what you are saying. The signaling would be over the same TCP flow as the media on that side of the turn server. On 12/14/05 8:25 AM, "Francois Audet" wrote: > You mean the same signalling port, right, not the same tunnelled > packets? > > Being on the same signalling port makes sense. For tunnelled packets, > probably not. > >> -----Original Message----- >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of >> Cullen Jennings >> Sent: Tuesday, December 13, 2005 19:35 >> To: Jonathan Rosenberg; Behave >> Subject: Re: [Ietf-behave] TURN Issue #6: port numbers >> >> >> >> If STUN and TURN are on the same port, it make it much harder >> to right rate limiting rules for them. I don't know if this >> matters much but worth a bit of thought. >> >> >> On 12/5/05 12:33 PM, "Jonathan Rosenberg" wrote: >> >>> Right now, TURN has no default port. Its marked as XXXX in >> the spec. >>> With the view that TURN would be a stun usage, its not >> clear that it >>> needs a separate port from the STUN port. The only reason >> to have that >>> is if folks think there is a desire from firewall admins to >> block TURN >>> by disabling its port, but allow STUN. There are a few options here: >>> >>> 1. TURN will reuse the STUN default port. DNS procedures >> also exist to >>> detect the udp, tcp, etc. ports for STUN/TURN, but they are always >>> shared. >>> >>> 2. TURN has a separate default port. DNS procedures also exist to >>> detect the udp, tcp, etc. ports for STUN, and there is also a >>> procedure to detect them for TURN. This would be done by defining a >>> separate NAPTR service for Allocate requests. >>> >>> 3. TURN will reuse the STUN default port. DNS procedures >> also exist to >>> detect the udp, tcp, etc. ports for STUN, and there is also a >>> procedure to detect them for TURN. This would be done by defining a >>> separate NAPTR service for Allocate requests. >>> >>> 4. TURN has a separate default port, and there are no DNS >> procedures >>> defined at all for STUN or TURN. This would imply a >> specific solution >>> to the TLS problem in Issue #5 (in particular, would imply no >>> DNS-based solutions). Why do this? The only reason is to >> force usage >>> of TURN over a specific port since no discovery mechanism >> would exist. >>> This would facilitate firewall port-blocking. Of course, its easily >>> circumvented through configuration of the TURN port (which >> is what is >>> done today), but its an option. >>> >>> >>> I tend to prefer #1 for simplicity. Unless there is a compelling >>> argument brought about why the TURN and STUN requests NEED >> to run on >>> different ports, I see no reason for anything else. >>> >>> -Jonathan R. >>> >>> >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> >> From audet@nortel.com Wed, 14 Dec 2005 12:07:12 -0800 (PST) From: "Francois Audet" Date: Wed, 14 Dec 2005 12:07:12 -0800 (PST) Subject: RE: [Ietf-behave] TURN Issue #6: port numbers Message-ID: <1ECE0EB50388174790F9694F77522CCF05C25741@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Yes, you are right. I keep forgetting TURN uses the same port on the server for signaling and media. I guess we'll have to use the magic cookie thing. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Wednesday, December 14, 2005 11:44 > To: Audet, Francois [SC100:9T51:EXCH]; Jonathan Rosenberg; Behave > Subject: Re: [Ietf-behave] TURN Issue #6: port numbers > > > > Hmm - I might be missing what you are saying. The signaling > would be over the same TCP flow as the media on that side of > the turn server. > > > On 12/14/05 8:25 AM, "Francois Audet" wrote: > > > You mean the same signalling port, right, not the same tunnelled > > packets? > > > > Being on the same signalling port makes sense. For > tunnelled packets, > > probably not. > > > >> -----Original Message----- > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf > Of Cullen > >> Jennings > >> Sent: Tuesday, December 13, 2005 19:35 > >> To: Jonathan Rosenberg; Behave > >> Subject: Re: [Ietf-behave] TURN Issue #6: port numbers > >> > >> > >> > >> If STUN and TURN are on the same port, it make it much harder to > >> right rate limiting rules for them. I don't know if this > matters much > >> but worth a bit of thought. > >> > >> > >> On 12/5/05 12:33 PM, "Jonathan Rosenberg" > wrote: > >> > >>> Right now, TURN has no default port. Its marked as XXXX in > >> the spec. > >>> With the view that TURN would be a stun usage, its not > >> clear that it > >>> needs a separate port from the STUN port. The only reason > >> to have that > >>> is if folks think there is a desire from firewall admins to > >> block TURN > >>> by disabling its port, but allow STUN. There are a few > options here: > >>> > >>> 1. TURN will reuse the STUN default port. DNS procedures > >> also exist to > >>> detect the udp, tcp, etc. ports for STUN/TURN, but they > are always > >>> shared. > >>> > >>> 2. TURN has a separate default port. DNS procedures also exist to > >>> detect the udp, tcp, etc. ports for STUN, and there is also a > >>> procedure to detect them for TURN. This would be done by > defining a > >>> separate NAPTR service for Allocate requests. > >>> > >>> 3. TURN will reuse the STUN default port. DNS procedures > >> also exist to > >>> detect the udp, tcp, etc. ports for STUN, and there is also a > >>> procedure to detect them for TURN. This would be done by > defining a > >>> separate NAPTR service for Allocate requests. > >>> > >>> 4. TURN has a separate default port, and there are no DNS > >> procedures > >>> defined at all for STUN or TURN. This would imply a > >> specific solution > >>> to the TLS problem in Issue #5 (in particular, would imply no > >>> DNS-based solutions). Why do this? The only reason is to > >> force usage > >>> of TURN over a specific port since no discovery mechanism > >> would exist. > >>> This would facilitate firewall port-blocking. Of course, > its easily > >>> circumvented through configuration of the TURN port (which > >> is what is > >>> done today), but its an option. > >>> > >>> > >>> I tend to prefer #1 for simplicity. Unless there is a compelling > >>> argument brought about why the TURN and STUN requests NEED > >> to run on > >>> different ports, I see no reason for anything else. > >>> > >>> -Jonathan R. > >>> > >>> > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > >> > > From magnus.westerlund@ericsson.com Thu, 15 Dec 2005 01:53:16 -0800 (PST) From: Magnus Westerlund Date: Thu, 15 Dec 2005 01:53:16 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #4: TLS TURN requests In-Reply-To: Message-ID: <43A13D08.7010707@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Cullen Jennings wrote: Interesting - given that draft-ietf-avt-rtp-framing-contrans and draft-ietf-mmusic-comedia-tls both seem to be proceeding, I'm surprised to hear this. I would not be surprised to see more interest in RTP over TLS. However neither of these drafts defines the procedure for TCP/TLS/RTP/AVP, etc. The comedia TLS author was willing to have it in his draft-ietf-mmusic-comedia-tls, however no one volunteered to write the text. Thus it got cut out of that draft. No one has so far started an separate draft. So unless a volunteer steps forward in AVT this milestone and charter item will be removed. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From dhudson@ubicom.com Sat, 17 Dec 2005 12:09:25 -0800 (PST) From: "Dave Hudson" Date: Sat, 17 Dec 2005 12:09:25 -0800 (PST) Subject: [Ietf-behave] Catalogue of problems with deployed NATs Message-ID: MIME-Version: 1.0 Content-Type: text/plain Does anyone have any pointers to documents/websites that describe problems seen by widely-deployed NATs? I've been looking into some very odd behaviour I've seen from systems using P2P file-sharing applications and it's not at all unusual for me to see 50 or 60 packets per minute arriving at my test system (around 0.5% of all packets) where there's very strong evidence of something wrong in the translations being applied by remote NATs. Many of these problems are leading to me seeing excessively high numbers of TCP connections left in effectively a half-open state (e.g. with a 2 hour timeout applied to traffic in Establish, Fin-Wait-1, Fin-Wait-2 and Close-Wait I can see 2k or 3k such connections after an hour or two even when only using at a slow DSL connection) with a consequent impact on overall performance. I'm investigating strategies that will help me reduce both the amount of bad traffic that I see arriving and the number of half-open connections but a more comprehensive list of possible failure modes would help (if there is one). Failing that I'll be happy to summarise problems I have observed if anyone's interested. Thanks, Dave From srisuresh@yahoo.com Sun, 18 Dec 2005 21:06:05 -0800 (PST) From: Pyda Srisuresh Date: Sun, 18 Dec 2005 21:06:05 -0800 (PST) Subject: Re: [Ietf-behave] Catalogue of problems with deployed NATs In-Reply-To: Message-ID: <20051219050605.7160.qmail@web33304.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Dave, RFC 3027 was done a while back documenting compliations with NATs. draft-ford-behave-top-00.txt documents complications with the use of NATs in certain topologies. The ID has expired. We will get a new rev out shortly. Outside of these, I dont know of any other. Additional comments inline below. cheers, suresh --- Dave Hudson wrote: > Does anyone have any pointers to documents/websites that describe > problems seen by widely-deployed NATs? I've been looking into some very > odd behaviour I've seen from systems using P2P file-sharing applications > and it's not at all unusual for me to see 50 or 60 packets per minute > arriving at my test system (around 0.5% of all packets) where there's > very strong evidence of something wrong in the translations being > applied by remote NATs. > > Many of these problems are leading to me seeing excessively high numbers > of TCP connections left in effectively a half-open state (e.g. with a 2 > hour timeout applied to traffic in Establish, Fin-Wait-1, Fin-Wait-2 and > Close-Wait I can see 2k or 3k such connections after an hour or two even > when only using at a slow DSL connection) with a consequent impact on > overall performance. > [suresh] Sounds like, you are saying you noticed a lot of half-open or half-close conenctions on the NATs. This may be specific to the file sharing Peer-to-peer (P2P) application you are using and the algorithm the application is using to traverse NATs. I dont know what the problem is. But, I suspect, the problem is to do with symmteric NATs being enroute. > I'm investigating strategies that will help me reduce both the amount of > bad traffic that I see arriving and the number of half-open connections > but a more comprehensive list of possible failure modes would help (if > there is one). > [suresh] You might want to take a look at draft-srisuresh-behave-p2p-state-01.txt for a description of the various algorithms in use by P2P apps for NAT traversal. > Failing that I'll be happy to summarise problems I have observed if > anyone's interested. > [suresh] That sounds good in any case. Thanks. cheers, suresh > > Thanks, > Dave > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From dhudson@ubicom.com Mon, 19 Dec 2005 05:59:41 -0800 (PST) From: "Dave Hudson" Date: Mon, 19 Dec 2005 05:59:41 -0800 (PST) Subject: RE: [Ietf-behave] Catalogue of problems with deployed NATs Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Suresh, Thanks for the pointers. I was familiar with most of the documents you mentioned but I'd not seen anything that specifically discussed many of the things I've been seeing. While I've seen a lot of discussion about general problems with NATs I concluded I was seeing other implementation-related problems but haven't been able to find so much discussion of this. Essentially much of what I've been seeing appear to be a consequence of the high volumes of NAT sessions that can be established by some P2P apps. I'm also seeing the effect of the high levels of flux seen in many of the P2P file-sharing networks where nodes in the network disappear (although in some cases I suspect this may be the result of symmetric NATs or NATs that exhibit symmetric behaviour under some circumstances). I normally find that after running for an hour or so (on a slow DSL link) I get more than 5 egressing and 5 ingressing new sessions per second (often this number is more than 20 in each direction for periods of a few seconds) so when coupled with a recommendation that TCP sessions in the Syn-Sent state hold state for 4 minutes and UDP sessions hold state for 5 minutes this can generate around 2500 sessions. Coupled with this I may have 700 to 800 live sessions and another 1000 or so half-open (or half-closed :-)) TCP sessions. At one point I was seeing far more half-open TCP sessions but I then adjusted the timings in the NAT I'm working with to 4 minutes for Syn-Sent, Syn-Received, Time-Wait, Last-Ack, while making them 130 minutes for Established, Fin-Wait-[1/2] and Close-Wait. I also modified the code to allow sessions that had seen a RST to stay in a "closed" state that would allow packets to pass for 4 minutes because it was amazing how many RST packets were apparently not being handled (I suspect many were being dropped in transit as a result of too much traffic being sent to remote peers in bursts), leading to situations where one peer would send a RST and then 2 or 3 minutes later the other peer would send (and then continue to resend FIN/ACK); The extra time in this closed state allows for RST packets to be resent in response to packets from the peer that didn't see the original RST. Anyway here are some of the things I've observed so far (I've seen all of these with a surprisingly high frequency - typically I see one of these every 4 to 5 seconds during tests where I send about 70 packets per second and typically receive 60 per second): 1) Bad ICMP destination (port) unreachable or redirect messages. These are messages where the remote peer is apparantly no longer running where it was but the remote NAT fails to translate the payload of the message. As a result the packet is sent from the remote NAT to my NAT but the ICMP message refers to a remote host that is clearly a private IP of some host behind that NAT (typically 192.168.x.y) or occasionally 0.0.0.0. These messages are usually for UDP sessions but I do see some for TCP too. 2) FIN/RST/ACK packets in response to SYN requests (this may just be odd behaviour from a remote TCP stack though). 3) RST packets being sent to the wrong local port. In these cases a remote NAT sends a FIN/ACK to close an existing session and follows it immediately with a RST but the RST ends up sent to a random port at my end despite the FIN/ACK having been sent the correct port (this double approach to closing sessions is surprisingly common but normally the port numbers are the same). All subsequent FIN/ACKs from my end get the same mismatched RST in response. 4) Remote NAT bindings change mid-session after some period of inactivity. My guess is that the remote NAT times-out its binding part way through a TCP session and suddenly traffic that was coming from one port suddenly starts to arrive from a different port (this is similar to 3 but in 3 the port binding for my host gets changed). I'd guess that these remote NATs aren't really tracking the TCP state transitions as anything stateful probably wouldn't allow a new session for anything other than SYN-related transactions. 5) Inconsistent port binding when remote systems use port forwarding. In these cases the remote NAT has a port forwarding rule to ensure that ingressing traffic will be sent to some specific service, however any egressing traffic from the remote NAT appears from a different (but consistent) port number (this effectively renders it symmetric even though it may nominally be a NAT that would normally employ a persistent port binding). This is particularly noticeable as a variant of 4. One problem here is that by not sending RST packets in response to some of the resulting bad TCP packets we avoid the possibility of being a reflector for a DDoS attack but do end up with far more bad traffic. I've experimented with a compromise that sends RSTs in response to bad packets from hosts with which we already have an active session and saw about a 25% drop in packets rejected at my end. Regards, Dave * -----Original Message----- * From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx * [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of * Pyda Srisuresh * Sent: 19 December 2005 05:06 * To: Dave Hudson; ietf-behave@xxxxxxxxxxxxxxxxxxx * Subject: Re: [Ietf-behave] Catalogue of problems with deployed NATs * * Dave, * * RFC 3027 was done a while back documenting compliations with NATs. * draft-ford-behave-top-00.txt documents complications with the * use of NATs in certain topologies. The ID has expired. We * will get a new rev out shortly. * Outside of these, I dont know of any other. * * Additional comments inline below. * * cheers, * suresh * * --- Dave Hudson wrote: * * > Does anyone have any pointers to documents/websites that describe * > problems seen by widely-deployed NATs? I've been looking into some * > very odd behaviour I've seen from systems using P2P file-sharing * > applications and it's not at all unusual for me to see 50 or 60 * > packets per minute arriving at my test system (around 0.5% of all * > packets) where there's very strong evidence of something * wrong in the * > translations being applied by remote NATs. * > * > Many of these problems are leading to me seeing excessively high * > numbers of TCP connections left in effectively a half-open * state (e.g. * > with a 2 hour timeout applied to traffic in Establish, Fin-Wait-1, * > Fin-Wait-2 and Close-Wait I can see 2k or 3k such * connections after an * > hour or two even when only using at a slow DSL connection) with a * > consequent impact on overall performance. * > * * [suresh] Sounds like, you are saying you noticed a lot of * half-open or half-close conenctions on the NATs. This may be * specific to the file sharing Peer-to-peer (P2P) application * you are using and the algorithm the application is using to * traverse NATs. I dont know what the problem is. But, I * suspect, the problem is to do with symmteric NATs being enroute. * * > I'm investigating strategies that will help me reduce both * the amount * > of bad traffic that I see arriving and the number of half-open * > connections but a more comprehensive list of possible failure modes * > would help (if there is one). * > * [suresh] You might want to take a look at * draft-srisuresh-behave-p2p-state-01.txt for a description of * the various algorithms in use by P2P apps for NAT traversal. * * > Failing that I'll be happy to summarise problems I have observed if * > anyone's interested. * > * [suresh] That sounds good in any case. Thanks. * * cheers, * suresh * * > * > Thanks, * > Dave * > _______________________________________________ * > Ietf-behave mailing list * > Ietf-behave@xxxxxxxxxxxxxxxxxxx * > https://list.sipfoundry.org/mailman/listinfo/ietf-behave * > * * * * _______________________________________________ * Ietf-behave mailing list * Ietf-behave@xxxxxxxxxxxxxxxxxxx * https://list.sipfoundry.org/mailman/listinfo/ietf-behave * From audet@nortel.com Mon, 19 Dec 2005 07:39:56 -0800 (PST) From: "Francois Audet" Date: Mon, 19 Dec 2005 07:39:56 -0800 (PST) Subject: RE: [Ietf-behave] Catalogue of problems with deployed NATs Message-ID: <1ECE0EB50388174790F9694F77522CCF05CF072F@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain This is quite interesting, and hardly surprising. We had find bizarre behaviors like this on UDP where it seemed to defy all logic. If you are seeing this in more than one NAT, it might be a good idea to document it: it might help people figuring out the root causes. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Dave Hudson > Sent: Monday, December 19, 2005 05:59 > To: Pyda Srisuresh; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] Catalogue of problems with deployed NATs > > > Hi Suresh, > > Thanks for the pointers. I was familiar with most of the > documents you mentioned but I'd not seen anything that > specifically discussed many of the things I've been seeing. > While I've seen a lot of discussion about general problems > with NATs I concluded I was seeing other > implementation-related problems but haven't been able to find > so much discussion of this. > > Essentially much of what I've been seeing appear to be a > consequence of the high volumes of NAT sessions that can be > established by some P2P apps. I'm also seeing the effect of > the high levels of flux seen in many of the P2P file-sharing > networks where nodes in the network disappear (although in > some cases I suspect this may be the result of symmetric NATs > or NATs that exhibit symmetric behaviour under some circumstances). > > I normally find that after running for an hour or so (on a slow DSL > link) I get more than 5 egressing and 5 ingressing new > sessions per second (often this number is more than 20 in > each direction for periods of a few seconds) so when coupled > with a recommendation that TCP sessions in the Syn-Sent state > hold state for 4 minutes and UDP sessions hold state for 5 > minutes this can generate around 2500 sessions. Coupled with > this I may have 700 to 800 live sessions and another 1000 or > so half-open (or half-closed :-)) TCP sessions. > > At one point I was seeing far more half-open TCP sessions but > I then adjusted the timings in the NAT I'm working with to 4 > minutes for Syn-Sent, Syn-Received, Time-Wait, Last-Ack, > while making them 130 minutes for Established, Fin-Wait-[1/2] > and Close-Wait. I also modified the code to allow sessions > that had seen a RST to stay in a "closed" state that would > allow packets to pass for 4 minutes because it was amazing > how many RST packets were apparently not being handled (I > suspect many were being dropped in transit as a result of too > much traffic being sent to remote peers in bursts), leading > to situations where one peer would send a RST and then 2 or 3 > minutes later the other peer would send (and then continue to > resend FIN/ACK); The extra time in this closed state allows > for RST packets to be resent in response to packets from the > peer that didn't see the original RST. > > Anyway here are some of the things I've observed so far (I've > seen all of these with a surprisingly high frequency - > typically I see one of these every 4 to 5 seconds during > tests where I send about 70 packets per second and typically > receive 60 per second): > > 1) Bad ICMP destination (port) unreachable or redirect > messages. These are messages where the remote peer is > apparantly no longer running where it was but the remote NAT > fails to translate the payload of the message. As a result > the packet is sent from the remote NAT to my NAT but the ICMP > message refers to a remote host that is clearly a private IP > of some host behind that NAT (typically 192.168.x.y) or > occasionally 0.0.0.0. These messages are usually for UDP > sessions but I do see some for TCP too. > > 2) FIN/RST/ACK packets in response to SYN requests (this may > just be odd behaviour from a remote TCP stack though). > > 3) RST packets being sent to the wrong local port. In these > cases a remote NAT sends a FIN/ACK to close an existing > session and follows it immediately with a RST but the RST > ends up sent to a random port at my end despite the FIN/ACK > having been sent the correct port (this double approach to > closing sessions is surprisingly common but normally the port > numbers are the same). All subsequent FIN/ACKs from my end > get the same mismatched RST in response. > > 4) Remote NAT bindings change mid-session after some period > of inactivity. My guess is that the remote NAT times-out its > binding part way through a TCP session and suddenly traffic > that was coming from one port suddenly starts to arrive from > a different port (this is similar to 3 but in 3 the port > binding for my host gets changed). I'd guess that these > remote NATs aren't really tracking the TCP state transitions > as anything stateful probably wouldn't allow a new session > for anything other than SYN-related transactions. > > 5) Inconsistent port binding when remote systems use port > forwarding. In these cases the remote NAT has a port > forwarding rule to ensure that ingressing traffic will be > sent to some specific service, however any egressing traffic > from the remote NAT appears from a different (but > consistent) port number (this effectively renders it > symmetric even though it may nominally be a NAT that would > normally employ a persistent port binding). This is > particularly noticeable as a variant of 4. > > One problem here is that by not sending RST packets in > response to some of the resulting bad TCP packets we avoid > the possibility of being a reflector for a DDoS attack but do > end up with far more bad traffic. I've experimented with a > compromise that sends RSTs in response to bad packets from > hosts with which we already have an active session and saw > about a 25% drop in packets rejected at my end. > > > Regards, > Dave > > * -----Original Message----- > * From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > * [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > * Pyda Srisuresh > * Sent: 19 December 2005 05:06 > * To: Dave Hudson; ietf-behave@xxxxxxxxxxxxxxxxxxx > * Subject: Re: [Ietf-behave] Catalogue of problems with deployed NATs > * > * Dave, > * > * RFC 3027 was done a while back documenting compliations with NATs. > * draft-ford-behave-top-00.txt documents complications with the > * use of NATs in certain topologies. The ID has expired. We > * will get a new rev out shortly. > * Outside of these, I dont know of any other. > * > * Additional comments inline below. > * > * cheers, > * suresh > * > * --- Dave Hudson wrote: > * > * > Does anyone have any pointers to documents/websites that describe > * > problems seen by widely-deployed NATs? I've been looking > into some > * > very odd behaviour I've seen from systems using P2P file-sharing > * > applications and it's not at all unusual for me to see 50 or 60 > * > packets per minute arriving at my test system (around 0.5% of all > * > packets) where there's very strong evidence of something > * wrong in the > * > translations being applied by remote NATs. > * > > * > Many of these problems are leading to me seeing excessively high > * > numbers of TCP connections left in effectively a half-open > * state (e.g. > * > with a 2 hour timeout applied to traffic in Establish, > Fin-Wait-1, > * > Fin-Wait-2 and Close-Wait I can see 2k or 3k such > * connections after an > * > hour or two even when only using at a slow DSL connection) with a > * > consequent impact on overall performance. > * > > * > * [suresh] Sounds like, you are saying you noticed a lot of > * half-open or half-close conenctions on the NATs. This may be > * specific to the file sharing Peer-to-peer (P2P) application > * you are using and the algorithm the application is using to > * traverse NATs. I dont know what the problem is. But, I > * suspect, the problem is to do with symmteric NATs being enroute. > * > * > I'm investigating strategies that will help me reduce both > * the amount > * > of bad traffic that I see arriving and the number of half-open > * > connections but a more comprehensive list of possible > failure modes > * > would help (if there is one). > * > > * [suresh] You might want to take a look at > * draft-srisuresh-behave-p2p-state-01.txt for a description of > * the various algorithms in use by P2P apps for NAT traversal. > * > * > Failing that I'll be happy to summarise problems I have > observed if > * > anyone's interested. > * > > * [suresh] That sounds good in any case. Thanks. > * > * cheers, > * suresh > * > * > > * > Thanks, > * > Dave > * > _______________________________________________ > * > Ietf-behave mailing list > * > Ietf-behave@xxxxxxxxxxxxxxxxxxx > * > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > * > > * > * > * > * _______________________________________________ > * Ietf-behave mailing list > * Ietf-behave@xxxxxxxxxxxxxxxxxxx > * https://list.sipfoundry.org/mailman/listinfo/ietf-behave > * > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From saikat@cs.cornell.edu Mon, 19 Dec 2005 09:55:40 -0800 (PST) From: Saikat Guha Date: Mon, 19 Dec 2005 09:55:40 -0800 (PST) Subject: Re: [Ietf-behave] Catalogue of problems with deployed NATs In-Reply-To: Message-ID: <1135014936.19848.24.camel@himalaya.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630135.multipart/signed" --Boundary..27398.1163630135.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2005-12-17 at 12:09 -0800, Dave Hudson wrote: > Does anyone have any pointers to documents/websites that describe > problems seen by widely-deployed NATs? We recently analyzed some problems in the following paper [1]: [1] "Characterization and Measurement of TCP Traversal through NATs and Firewalls", http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/ > something wrong in the translations being > applied by remote NATs. Interesting; this is TCP I am assuming? Do you mean the NAT is incorrectly translating a particular TCP-or-IP header field, or that it is mangling the data payload in the TCP packet? > Many of these problems are leading to me seeing excessively high numbers > of TCP connections left in effectively a half-open state I know a number of NATs break the connection right after they see the FIN packets, so the final ACKs may not always get delivered. This causes hanging zombie connections. As for half-open, I recall there being a problem in Windows XP SP1 and before where, if TCP simultaneous was triggered, one side would go into half-open while the other side wouldn't see the connection. This was discussed earlier on this list. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630135.multipart/signed Content-Type: application/octet-stream; name="pgp00091.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00091.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFCRHB2UVluRmx0cWk2OTEvb1JBcXdmQUo5Z3BidFgzTG5CQ2RoNi9kc2tD NGFQLzdSZTlBQ2VMTGN3Ckd3TS8zTTYzcWkxV251RGVUYnpxcGRVPQo9WVZhbQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630135.multipart/signed-- From saikat@cs.cornell.edu Mon, 19 Dec 2005 10:09:29 -0800 (PST) From: Saikat Guha Date: Mon, 19 Dec 2005 10:09:29 -0800 (PST) Subject: RE: [Ietf-behave] Catalogue of problems with deployed NATs In-Reply-To: Message-ID: <1135015767.19848.37.camel@himalaya.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630135.multipart/signed" --Boundary..27398.1163630135.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-12-19 at 05:59 -0800, Dave Hudson wrote: > 1) Bad ICMP destination (port) unreachable or redirect messages. I found a lot of NATs filter any ICMP message that is not a echo request/response, or frag-required. I've heard of NATs that mis/don't-translate ICMP payloads, but I never picked them up in my tests -- perhaps a bug in my test. > 2) FIN/RST/ACK packets in response to SYN requests (this may just be odd > behaviour from a remote TCP stack though). > 3) RST packets being sent to the wrong local port. Could possibly be the bug WindowsXP SP1 and earlier. Once (If) you trigger simultaneous open, the TCP state-machine jumps out of the window and the stack runs amok returning any packet it pleases. This could all to already broken NAT behavior. > 4) Remote NAT bindings change mid-session after some period of > inactivity. Some NATs have very short timers (<15min) for TCP connections in the established state. See http://nutss.net/stunt-results.php?sort=-33 > 5) Inconsistent port binding when remote systems use port forwarding. Static port mappings behavior is implemented differently by different vendors. Some use it only for inbound initiations, while others for both. David Barrett raised this issue earlier I think; the final resolution was to stay silent about it in the UDP NAT RFC. Consequently, this behavior will remain vendor specific. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630135.multipart/signed Content-Type: application/octet-stream; name="pgp00092.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00092.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFCRHB2ZFhuRmx0cWk2OTEvb1JBbUpYQUo0c25PUVQrb2tLbkswOVNJSjBE TXVqL3pMVmFRQ2Zhb1EvCjQ2SVJyQ2xDZ25jdFhTOVhTYTVnVFRZPQo9UWdnZwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630135.multipart/signed-- From jdrosen@cisco.com Mon, 19 Dec 2005 10:53:29 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 19 Dec 2005 10:53:29 -0800 (PST) Subject: Re: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification In-Reply-To: Message-ID: <43A7018F.50909@cisco.com> MIME-Version: 1.0 Content-Type: text/plain OK, it sounds like there is general consensus for #1, so I will do that. I'll call the new attribute RELAY-ADDRESS and use value 0x0016 for it. -Jonathan R. Cullen Jennings wrote: I'm not aware of any deployments that would find #1 difficult to migrate to, so, #1 sounds best. On 12/6/05 8:21 AM, "Marc Petit-Huguenin" wrote: I vote for #1. Jonathan Rosenberg wrote: As I mentioned during the IETF meeting, I am working on a revision of STUN that structures the protocol into a "framework" layer (though we agreed not to call it that per se), and various "usages" that can define extensions, define what messages and attributes get used, and define various security considerations. The plan is for TURN to become a STUn usage rather than a separate protocol. I think this is a good thing, since TURN repeats a lot of stun, and its relationship with it is unclear. One of the things I mentioned as a side benefit of this unification is that the TURN Allocate request could perform a stun check as a side effect. The Allocate response can include the source IP/port of the Allocate request (equivalent to the MAPPED-ADDRESS in the STUn Binding Response). This way, an ICE endpoint, for example, can issue just a single Allocate request to a turn server, and get back its stun-derived AND turn-derived addresses in one operation. This will reduce the overhead of ICE and simplify things. There seemed to be good support for doing this when I proposed it in the meeting last month. So, whats the issue? Syntax, unfortunately. The IDEAL solution for doing this is that the MAPPED-ADDRESS attribute always indicate the source IP/port as seen by the server in the request, and that it be usable with the existing STUN Binding Response and the TURN Allocate Response. Unfortunately, TURN redefined MAPPED-ADDRESS, and the meaning of MAPPED-ADDRESS in a TURN Allocate Response is the address allocated by the TURN server itself. So, there are several options: 1. break backwards compatibility with TURN, and define MAPPED-ADDRESS to be the source IP/port of the request. Define a new attribute, say RELAY-ADDRESS, that contains the allocated address on the TURN server, and use that in the Allocate response. 2. retain backwards compatibility with TURN, and define a new attribute, ALLOC-SOURCE-ADDR, which indicates the source IP/port of the Allocate request. Thus, we'd have two attributes with the same definition, and you'd need to use one of them with one request type (MAPPED-ADDRESS with Binding Request) and the other with the other request type (ALLOC-SOURCE-ADDR with Allocate Request). 3. Do (1), but only if the client indicates it supports this capability. If not, MAPPED-ADDRESS retains its current meaning and there is no way to get the source IP/port from the Allocate request. Technically speaking, in a greenfield environment, #1 is clearly the right solution. The problem is, there are now several deployments of TURN, some of them large in fact, and I want to be sensitive to backwards compatibility issues. So, I'd like to hear from folks on this, especially ones with implementations or deployments. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Mon, 19 Dec 2005 10:54:33 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 19 Dec 2005 10:54:33 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #2: Digest for Allocate directly In-Reply-To: <43946871.80702@cisco.com> Message-ID: <43A701E6.4020609@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I saw no public responses to this, though I did get a private reply supporting it. Barring objections, I will move forward with my proposal to make this change. Thanks, Jonathan R. Jonathan Rosenberg wrote: Currently, TURN security relies on a one-time-password approach. The client connects to the TURN server over TLS, and asks for a one time username and password. This request is itself authenticated using digest -over-TLS (using the same username/password structures as SIP). Then, the actual allocate request itself is authenticated using this one-time-password. This approach is reasonably secure, and is not susceptible to the dictionary attacks that regular digest authentication is susceptible too. The cost, however, is that TURN security is very complicated and expensive, processing wise. It will require many TCP/TLS connections to be established, and for them to see significant churn over time. I've also gotten some feedback that it makes TURN load balancing more complicated, since you would need to share these one time passwords between a load balancing element and the TURN server that does the actual allocations. I'm increasingly worried these days that complicated security, even when good, won't be deployed if the costs are too high. And that will mean TURN without any security at all, which is really bad. So, it has been suggested to me to allow the Allocate request itself to be authenticated using a Digest mechanism. The initial Allocate request is sent without credentials. Its rejected with a 401 that provides a nonce, and the request is retried with message-integrity that has an HMAC that includes the NONCE. (I'd likely do this by bringing in the digest authentication into the core stun protocol, and then allowing the TURN allocate to use it). This would vastly simplify TURN security, and make it on par with most existing SIP deployments which work the same way. The other option would continue to exist and be supported, I'd probably also add a way for the TURN server to reject the digest credentials and tell the user they need to obtain a one-time-password. This allows for server operators to change policies about whether this is allowed and still maintain interop with clients. I'd like to go ahead and make this change, but would like feedback from the group on it. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From juberti@aol.com Mon, 19 Dec 2005 13:27:23 -0800 (PST) From: "Justin Uberti" Date: Mon, 19 Dec 2005 13:27:23 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #2: Digest for Allocate directly In-Reply-To: <43946871.80702@cisco.com> Message-ID: <43A725B3.4000400@aol.com> MIME-Version: 1.0 Content-Type: text/plain I am in favor of this. We also found TURN security to be complex and expensive, and had to implement our own lightweight security. Thanks, Justin Uberti Chief Architect, AOL Jonathan Rosenberg wrote on 12/19/2005, 1:54 PM: > I saw no public responses to this, though I did get a private reply > supporting it. Barring objections, I will move forward with my proposal > to make this change. > > Thanks, > Jonathan R. > > Jonathan Rosenberg wrote: > > > Currently, TURN security relies on a one-time-password approach. The > > client connects to the TURN server over TLS, and asks for a one time > > username and password. This request is itself authenticated using > digest > > -over-TLS (using the same username/password structures as SIP). Then, > > the actual allocate request itself is authenticated using this > > one-time-password. This approach is reasonably secure, and is not > > susceptible to the dictionary attacks that regular digest > authentication > > is susceptible too. > > > > The cost, however, is that TURN security is very complicated and > > expensive, processing wise. It will require many TCP/TLS connections to > > be established, and for them to see significant churn over time. I've > > also gotten some feedback that it makes TURN load balancing more > > complicated, since you would need to share these one time passwords > > between a load balancing element and the TURN server that does the > > actual allocations. > > > > I'm increasingly worried these days that complicated security, even > when > > good, won't be deployed if the costs are too high. And that will mean > > TURN without any security at all, which is really bad. > > > > So, it has been suggested to me to allow the Allocate request itself to > > be authenticated using a Digest mechanism. The initial Allocate request > > is sent without credentials. Its rejected with a 401 that provides a > > nonce, and the request is retried with message-integrity that has an > > HMAC that includes the NONCE. (I'd likely do this by bringing in the > > digest authentication into the core stun protocol, and then allowing > the > > TURN allocate to use it). > > > > This would vastly simplify TURN security, and make it on par with most > > existing SIP deployments which work the same way. The other option > would > > continue to exist and be supported, I'd probably also add a way for the > > TURN server to reject the digest credentials and tell the user they > need > > to obtain a one-time-password. This allows for server operators to > > change policies about whether this is allowed and still maintain > interop > > with clients. > > > > I'd like to go ahead and make this change, but would like feedback from > > the group on it. > > > > Thanks, > > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Tue, 20 Dec 2005 08:45:11 -0800 (PST) From: Pyda Srisuresh Date: Tue, 20 Dec 2005 08:45:11 -0800 (PST) Subject: RE: [Ietf-behave] Catalogue of problems with deployed NATs In-Reply-To: Message-ID: <20051220164510.70540.qmail@web33314.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Hi Dave, It seems you can control some of the NAT devices enroute, but not all in this setup. Is that right? Results are not predictable when you change settings on just one of the NAT devices. Also, do you have know the NAT traversal algorithm being employed by the P2P application? If so, what is it? My comments below inline. cheers, suresh --- Dave Hudson wrote: > Hi Suresh, > > Thanks for the pointers. I was familiar with most of the documents you > mentioned but I'd not seen anything that specifically discussed many of > the things I've been seeing. While I've seen a lot of discussion about > general problems with NATs I concluded I was seeing other > implementation-related problems but haven't been able to find so much > discussion of this. > [suresh] OK. > Essentially much of what I've been seeing appear to be a consequence of > the high volumes of NAT sessions that can be established by some P2P > apps. I'm also seeing the effect of the high levels of flux seen in > many of the P2P file-sharing networks where nodes in the network > disappear (although in some cases I suspect this may be the result of > symmetric NATs or NATs that exhibit symmetric behaviour under some > circumstances). > [suresh] Right. It is possible that some of the NAT devices are hitting their resource limits (say, the number of NAT Sessions) with P2P applications, especially when the P2P apps are aggressive with multiple session initiations. > I normally find that after running for an hour or so (on a slow DSL > link) I get more than 5 egressing and 5 ingressing new sessions per > second (often this number is more than 20 in each direction for periods > of a few seconds) so when coupled with a recommendation that TCP > sessions in the Syn-Sent state hold state for 4 minutes and UDP sessions > hold state for 5 minutes this can generate around 2500 sessions. > Coupled with this I may have 700 to 800 live sessions and another 1000 > or so half-open (or half-closed :-)) TCP sessions. > [suresh] Right. The NAT devices could indeed be hitting resource limits, if the session initiation rate is high (say, 40 per second) and TCP session are being left in half-open state for long periods of time, without being established. What is the algorithm being used to setup ingress sessions? Is this simultaneous hole punch (or) a port prediction based algorithm? Saikat and Paul Francis had run several experiments under the NUTSS project and published their results in "Characterization & measurement of TCP traversal through NATs and Firewalls". You might want to take a look at this. As I recall, the best case for P2P session setup time was in the order of 200 msec (i.e, 5 sessions/sec). But, the median and average were much less - no more than 3 sessions per sec. > At one point I was seeing far more half-open TCP sessions but I then > adjusted the timings in the NAT I'm working with to 4 minutes for > Syn-Sent, Syn-Received, Time-Wait, Last-Ack, while making them 130 > minutes for Established, Fin-Wait-[1/2] and Close-Wait. I also modified > the code to allow sessions that had seen a RST to stay in a "closed" > state that would allow packets to pass for 4 minutes because it was > amazing how many RST packets were apparently not being handled (I > suspect many were being dropped in transit as a result of too much > traffic being sent to remote peers in bursts), leading to situations > where one peer would send a RST and then 2 or 3 minutes later the other > peer would send (and then continue to resend FIN/ACK); The extra time > in this closed state allows for RST packets to be resent in response to > packets from the peer that didn't see the original RST. > [suresh] Once a TCP session is established, RST handling for P2P sessions is same as for regular client-server sessions. The dropping of RST packets may be due to unusual traffic volume. Also, when you tune just one of the NAT devices enroute, the results are not necesaarily predictable. there may be different cascading effects. > Anyway here are some of the things I've observed so far (I've seen all > of these with a surprisingly high frequency - typically I see one of > these every 4 to 5 seconds during tests where I send about 70 packets > per second and typically receive 60 per second): > > 1) Bad ICMP destination (port) unreachable or redirect messages. These > are messages where the remote peer is apparantly no longer running where > it was but the remote NAT fails to translate the payload of the message. > As a result the packet is sent from the remote NAT to my NAT but the > ICMP message refers to a remote host that is clearly a private IP of > some host behind that NAT (typically 192.168.x.y) or occasionally > 0.0.0.0. These messages are usually for UDP sessions but I do see some > for TCP too. > [suresh] Couple of possibilities here. The NAT device may have bad code for translation of ICMP error packets (or) the NAT device retired the NAT Session too early and couldnt locate the NAT session to match when the ICMP error message came. The ICMP message may have come from an intermediate device, not necessarily the end node. > 2) FIN/RST/ACK packets in response to SYN requests (this may just be odd > behaviour from a remote TCP stack though). > [suresh] Is it possible these are coming from remote NAT instead of remote host? > 3) RST packets being sent to the wrong local port. In these cases a > remote NAT sends a FIN/ACK to close an existing session and follows it > immediately with a RST but the RST ends up sent to a random port at my > end despite the FIN/ACK having been sent the correct port (this double > approach to closing sessions is surprisingly common but normally the > port numbers are the same). All subsequent FIN/ACKs from my end get the > same mismatched RST in response. > [suresh] It is not normal for the NAT devices to directly engage in FIN/ACK 3-way handshake, unless the NAT device is doing transparant proxy (where the NAT device actually terminates the TCP session). Some vendors do implement transparant proxy on their NAT devices. But, transparant proxy is different and not an integral part of NAT, as IETF defines it. This characteristic may be specific to the particular NAT vendor. > 4) Remote NAT bindings change mid-session after some period of > inactivity. My guess is that the remote NAT times-out its binding part > way through a TCP session and suddenly traffic that was coming from one > port suddenly starts to arrive from a different port (this is similar to > 3 but in 3 the port binding for my host gets changed). I'd guess that > these remote NATs aren't really tracking the TCP state transitions as > anything stateful probably wouldn't allow a new session for anything > other than SYN-related transactions. > [suresh] Right, it is a problem if NAT drops the state (i.e., NAT Session) midway through the session. Usually this results in either silent dropping of the expired session packets or a RST being sent. As you said, most NAT device wait for a SYN to establish the next session state. > 5) Inconsistent port binding when remote systems use port forwarding. > In these cases the remote NAT has a port forwarding rule to ensure that > ingressing traffic will be sent to some specific service, however any > egressing traffic from the remote NAT appears from a different (but > consistent) port number (this effectively renders it symmetric even > though it may nominally be a NAT that would normally employ a persistent > port binding). This is particularly noticeable as a variant of 4. > [suresh] By port forwarding for an ingress session, let us say you are refering to the tuple of (Ext-node-ip, Ext-Node-port, NAT-IP, NAT-ingress-port) in the Internet realm. Now, when you say egress traffic, are you referign to the traffic emanating for this session (or) any session, but from the same endpoint that represents (NAT-IP, NAT-Ingress-Port)? Given that you are talking about P2P applications (with multiple simlutaneous sessions from the same endpoint), I suspect, you are refering to the latter. In that case, it is normal behavior for symmetric NATs. It sounds like, the NAT traversal algorithm being adapted by the application doesnt work for multiple simultaneous sessions. cheers, suresh > One problem here is that by not sending RST packets in response to some > of the resulting bad TCP packets we avoid the possibility of being a > reflector for a DDoS attack but do end up with far more bad traffic. > I've experimented with a compromise that sends RSTs in response to bad > packets from hosts with which we already have an active session and saw > about a 25% drop in packets rejected at my end. > > > Regards, > Dave > > * -----Original Message----- > * From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > * [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > * Pyda Srisuresh > * Sent: 19 December 2005 05:06 > * To: Dave Hudson; ietf-behave@xxxxxxxxxxxxxxxxxxx > * Subject: Re: [Ietf-behave] Catalogue of problems with deployed NATs > * > * Dave, > * > * RFC 3027 was done a while back documenting compliations with NATs. > * draft-ford-behave-top-00.txt documents complications with the > * use of NATs in certain topologies. The ID has expired. We > * will get a new rev out shortly. > * Outside of these, I dont know of any other. > * > * Additional comments inline below. > * > * cheers, > * suresh > * > * --- Dave Hudson wrote: > * > * > Does anyone have any pointers to documents/websites that describe > * > problems seen by widely-deployed NATs? I've been looking into some > * > very odd behaviour I've seen from systems using P2P file-sharing > * > applications and it's not at all unusual for me to see 50 or 60 > * > packets per minute arriving at my test system (around 0.5% of all > * > packets) where there's very strong evidence of something > * wrong in the > * > translations being applied by remote NATs. > * > > * > Many of these problems are leading to me seeing excessively high > * > numbers of TCP connections left in effectively a half-open > * state (e.g. > * > with a 2 hour timeout applied to traffic in Establish, Fin-Wait-1, > * > Fin-Wait-2 and Close-Wait I can see 2k or 3k such > * connections after an > * > hour or two even when only using at a slow DSL connection) with a > * > consequent impact on overall performance. > * > > * > * [suresh] Sounds like, you are saying you noticed a lot of > * half-open or half-close conenctions on the NATs. This may be > * specific to the file sharing Peer-to-peer (P2P) application > * you are using and the algorithm the application is using to > * traverse NATs. I dont know what the problem is. But, I > * suspect, the problem is to do with symmteric NATs being enroute. > * > * > I'm investigating strategies that will help me reduce both > * the amount > * > of bad traffic that I see arriving and the number of half-open > * > connections but a more comprehensive list of possible failure modes > * > would help (if there is one). > * > > * [suresh] You might want to take a look at > * draft-srisuresh-behave-p2p-state-01.txt for a description of > * the various algorithms in use by P2P apps for NAT traversal. > * > * > Failing that I'll be happy to summarise problems I have observed if > * > anyone's interested. > * > > * [suresh] That sounds good in any case. Thanks. > * > * cheers, > * suresh > * > * > > * > Thanks, > * > Dave From jdrosen@cisco.com Tue, 20 Dec 2005 09:38:11 -0800 (PST) From: Jonathan Rosenberg Date: Tue, 20 Dec 2005 09:38:11 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #3: TCP to UDP allocations In-Reply-To: Message-ID: <43A84174.3050601@cisco.com> MIME-Version: 1.0 Content-Type: text/plain There were only a few responses here, but seems like general support was to have this functionality, with a preference for putting it in the core spec. I'll do that. As a note - there are some complications in this. The TURN server has to do some additional work when taking UDP packets and shoving them over a TCP connection. It needs to frame them. This requires awareness of the protocols ontop of TCP. What I plan on doing is having an additional parameter of the Allocate verb, which indicates the framing algorithm for UDP to TCP encapsulation/de-capsulation. Initially, only one value would be supported, the one defined in draft-ietf-avt-rtp-framing-contrans-06.txt, but others could be signaled should they arise later. -Jonathan R. Derek MacDonald wrote: I vote #3. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave- bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jonathan Rosenberg Sent: Monday, December 05, 2005 8:24 AM To: Behave Subject: [Ietf-behave] TURN Issue #3: TCP to UDP allocations TURN currently provides TCP allocations and UDP allocations. You can open a TCP connection to the sevrer and get a TCP port, and you can open a "UDP connection" to the server and get a UDP port. However, you cannot open a TCP connection to the server and get a UDP port allocated. Such a capability would require the TURN server to apply framing (such as the AVT contrans spec) to push UDP contents over a TCP connection. The benefit to this kind of approach is that it allows for partial UDP transport in situations where one side is behind a nasty symmetric nat or direwall (and thus must have tcp), whereas the other side has UDP connectivity. I've spoken to several people who have deployed voip configurations with this split UDP/TCP RTP transport, and claim it is better than all TCP. I think this is a good idea and we should do it. There are three options here: 1. No, don't allow this. 2. Yes, allow this, but do it via an extension to TURN, rather than in the core spec. 3. Yes, allow it by adding some attributes to the core spec. My proposal is option 2. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Tue, 20 Dec 2005 09:44:05 -0800 (PST) From: Jonathan Rosenberg Date: Tue, 20 Dec 2005 09:44:05 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #4: TLS TURN requests In-Reply-To: Message-ID: <43A842DF.40107@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Right, that was my understanding. The main point, however, is that the feature here under discussion (TURN Allocate over TLS) would make sense in conjunction with the UDP conversion, in which case there is no need for TCP signaling in the SDP itself. Since there appears to be consensus for the UDP-to-TCP conversion thing, and since running over TLS is going to be made generic in the stun revision, this capability would come along for the ride, so I'll move forward with that. -Jonathan R. Magnus Westerlund wrote: Cullen Jennings wrote: Interesting - given that draft-ietf-avt-rtp-framing-contrans and draft-ietf-mmusic-comedia-tls both seem to be proceeding, I'm surprised to hear this. I would not be surprised to see more interest in RTP over TLS. However neither of these drafts defines the procedure for TCP/TLS/RTP/AVP, etc. The comedia TLS author was willing to have it in his draft-ietf-mmusic-comedia-tls, however no one volunteered to write the text. Thus it got cut out of that draft. No one has so far started an separate draft. So unless a volunteer steps forward in AVT this milestone and charter item will be removed. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Tue, 20 Dec 2005 09:49:13 -0800 (PST) From: Jonathan Rosenberg Date: Tue, 20 Dec 2005 09:49:13 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #5: the STARTTLS problem In-Reply-To: Message-ID: <43A8440E.3000009@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Cullen Jennings wrote: I would prefer a solution that was possible to deploy without using NAPTR (note, I'm ok if NAPTR is MUST implement just have problems with MUST deploy). NAPTR is still difficult to deploy in many situations. If you do a STARTTLS start TLS on a connection, you can not stop it so all the data traffic after that would have to be TLS encrypted. This is probably not a good thing. I think the combination of the above two makes me lean towards #1. My concern is that it would simply not be allowed, i.e., IESG would not permit it. My proposal was somewhat of a hybrid. The idea is, we already have default ports for STUN UDP/TCP. Those could be used, and it would be the case that there is no TLS on those ports. If a client wants to do something that requires TLS however, be it shared secret or allocate-over-tls, the client would need to use NAPTR to find the TLS port. So, if the client never does TLS stuff, it would never need NAPTR. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Tue, 20 Dec 2005 09:52:23 -0800 (PST) From: Jonathan Rosenberg Date: Tue, 20 Dec 2005 09:52:23 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #5: the STARTTLS problem In-Reply-To: <4394A1CF.1010109@cisco.com> Message-ID: <43A844C1.2050801@cisco.com> MIME-Version: 1.0 Content-Type: text/plain inline. Saikat Guha wrote: On Mon, 2005-12-05 at 15:23 -0500, Jonathan Rosenberg wrote: Right now, there is a single TCP port associated with TURN. 1. Different well-known ports [...] 2. DNS NAPTR records to discover dynamic ports [...] 3. STARTTLS procedures. [...] 4. Have the server figure out whether the first message is STUN or TLS[...] I'm inclined to go with #2, with the caveat that there is already a default stun udp and tcp port and those would remain valid (see open issue #6 on applicability to turn). Would #2 require that TURN servers (and potentially ICE endpoints) have some DNS server where they can advertise their dynamic ports, hopefully through some secure dynamic-DNS-update protocol? If so, is the presence of such a DNS-relationship already required? ICE endpoints, no, since the ICE usages don't require any STUN or TURN over TLS. It would reqiure TURN servers to advertise their ports through DNS. I doubt this would be through DDNS updates, since the ports are not generally dynamic, they're just not standardized. Thus, you'd typically configure the turn server to run on a specific port, and then configure that port into the DNS, and then leave it alone from there on. Given how hard it is to convince my IT department to add just a CNAME, #2 would be at the bottom of my preference list. #3 makes for a nice compromise between 1 and 4. I'm not a fan of START-TLS types of mechanisms since they are complicated. I would much prefer the hybrid model I proposed, which would only require NAPTR specifically for TLS cases. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Tue, 20 Dec 2005 09:58:04 -0800 (PST) From: Jonathan Rosenberg Date: Tue, 20 Dec 2005 09:58:04 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #6: port numbers In-Reply-To: Message-ID: <43A84622.3080609@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I'm not sure; when TURN is used it generates a LOT more traffic than stun because of the media relaying. So, if you design your firewall to rate limit at a rate equal to the max TURN rate + a small percentage for the stun, that would work, no? -Jonathan R. Cullen Jennings wrote: If STUN and TURN are on the same port, it make it much harder to right rate limiting rules for them. I don't know if this matters much but worth a bit of thought. On 12/5/05 12:33 PM, "Jonathan Rosenberg" wrote: Right now, TURN has no default port. Its marked as XXXX in the spec. With the view that TURN would be a stun usage, its not clear that it needs a separate port from the STUN port. The only reason to have that is if folks think there is a desire from firewall admins to block TURN by disabling its port, but allow STUN. There are a few options here: 1. TURN will reuse the STUN default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN/TURN, but they are always shared. 2. TURN has a separate default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN, and there is also a procedure to detect them for TURN. This would be done by defining a separate NAPTR service for Allocate requests. 3. TURN will reuse the STUN default port. DNS procedures also exist to detect the udp, tcp, etc. ports for STUN, and there is also a procedure to detect them for TURN. This would be done by defining a separate NAPTR service for Allocate requests. 4. TURN has a separate default port, and there are no DNS procedures defined at all for STUN or TURN. This would imply a specific solution to the TLS problem in Issue #5 (in particular, would imply no DNS-based solutions). Why do this? The only reason is to force usage of TURN over a specific port since no discovery mechanism would exist. This would facilitate firewall port-blocking. Of course, its easily circumvented through configuration of the TURN port (which is what is done today), but its an option. I tend to prefer #1 for simplicity. Unless there is a compelling argument brought about why the TURN and STUN requests NEED to run on different ports, I see no reason for anything else. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Tue, 20 Dec 2005 11:09:16 -0800 (PST) From: Jonathan Rosenberg Date: Tue, 20 Dec 2005 11:09:16 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #7: Forking interactions In-Reply-To: <1ECE0EB50388174790F9694F77522CCF059763EA@zrc2hxm0.corp.nortel.com> Message-ID: <43A856CC.2080105@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Yes, same problem. -Jonathan R. Francois Audet wrote: Don't we have the same problem with multiple 183s with SDP for early media? -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jonathan Rosenberg Sent: Monday, December 05, 2005 12:42 To: Behave Subject: [Ietf-behave] TURN Issue #7: Forking interactions The way TURN works right now, you can only have a single correspondent for media streams if you want to avoid the TURN encapsulations. This is because there can only be one active destination. This has interesting interactions with forking. If a SIP INVITE forks, and you get back multiple 200 OK, each with a single media stream, the caller has to handle that. To avoid encapsulation, it would have to do an additional TURN allocation for each forked branch after the first, and issue a re-invite to modify the media destination to use that new allocated address. Also, after the first 200 OK, it cannot immediately issue a set active destination; it needs to wait a little bit to see if there are any more 200 OK coming. There are a few options here: 1. change nothing; just document this use case in a section that talks specifically about SIP interactions 2. allow for multiple active destinations. This would be a sizeable change in the protocol, requiring that encapsulation always be used, and probably requiring a different encapsulation technique Given how common multiple 200 OK is in practice right now (not much), this strikes me as a corner case for which a non-optimal solution is OK. As such, I would propose #1. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Tue, 20 Dec 2005 11:29:11 -0800 (PST) From: Jonathan Rosenberg Date: Tue, 20 Dec 2005 11:29:11 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #7: Forking interactions In-Reply-To: Message-ID: <43A85B83.2010100@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Derek MacDonald wrote: I wasn't under impressions that setting an active destination restricted traffic to that destination only. No, it doesn't at the moment. Nor does it prohibit incoming packets from destinations that are not active. However, while pondering this topic, it has occurred to me that there is a bug in this area in the -08 spec. The TCP behavior works under the assumption that you never end up muxing TURN encapsulated and non-encapsulated data over the same connection. So, the idea was, the client would issue a Set Active Destination over TCP, and after that, there would never need to be TURN messages from client to server. This is true. However, it is still possible to have a mix of TURN and non-TURN traffic from server to client. In particular, if multiple TCP connections had been established from the turn server to remote destinations, data can arrive on either. Data from the active destination would be forwarded without encapsulation, but data from the inactive one would need to be encapsulated. Thats a problem. One way to fix this is to make it so that, once an active destination is set, you can ONLY receive incoming packets from that destination; others are discarded. If we make Send Request unreliable, it seems that we could use turn encapsulation for one of the targets with minimal overhead. The client needs to keep track of which of the multiple targets is active, and possibly optimize the current active destination when some call legs are removed but it shouldn't be too hard. Well, per above, if one makes it so that you only get packets from the active destination, this wouldn't quite work. It would work if you never set the active destination. Basically, if you reduce the send overhead by making it unreliable, you would not set the active destination at all, and encapsulate every packet. Indeed (thinking aloud here), a more radical approach is to simply drop the whole notion of active destination - always encapsulate in both directions. I'm not proposing this, as it would add a fair bit of packet overhead for the common case of no forking, but it would simplify things. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Tue, 20 Dec 2005 11:30:15 -0800 (PST) From: Jonathan Rosenberg Date: Tue, 20 Dec 2005 11:30:15 -0800 (PST) Subject: Re: [Ietf-behave] TURN Issue #8: Send Reliable or not? In-Reply-To: <4394A82F.2040207@cisco.com> Message-ID: <43A85BB2.7050300@cisco.com> MIME-Version: 1.0 Content-Type: text/plain OK, looks like there is consensus to make SEND unreliable. Thanks, Jonathan R. Marc Petit-Huguenin wrote: Jonathan Rosenberg wrote: Right now, the Send request is a reliable transaction. This is actually somewhat odd; the corresponding request from server to client, Data Indication, is not reliable. There is actually no reason why Send has to be reliable. I've gotten a proposal from an implementor to change Send to an unreliabel indication. The claim, which I can believe, is that it much simplified things. Any protocol riding about TURN that sends data (like STUn connectivity checks) has its own reliability mechanism anyway, making the mechanism redundant. In and of itself, I think this is a good idea, but it would break backwards compatibility with any existing implementations. As such, I'd like some input prior to making any kind of change. We also had a lot of problems with this and we chose to do not retransmit the SendRequest on the client side if no response is received. The solution of not having any response is even better. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Tue, 20 Dec 2005 11:32:13 -0800 (PST) From: Jonathan Rosenberg Date: Tue, 20 Dec 2005 11:32:13 -0800 (PST) Subject: [Ietf-behave] TURN Issue #9: UDP/TCP consolidation and simplification Message-ID: <43A85C2E.7010105@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Right now, there are a bunch of things that are different between TCP and UDP turn. The biggest one is that, with UDP, you can modify the active destination after its set. With TCP, you cannot. With TCP, once you perform a Set Active Destination, additional TURN traffic is basically forbidden. This produces a nice handoff between TURN control traffic and data traffic. This handover does not exist with UDP. With UDP, you need to use the MAGIC-COOKIE to disambiguate TURN and regular data traffic. With TCP, its still there but actually not needed. With TCP, there is no explicit tear down or keepalive; closure of the tcp connection or timeout cleans up the allocation. With UDP, there is a separate TURN keepalive. This difference is one of the ugly spots in TURN, and it leads to a bunch of complexity in the protocol. It will make it more challenging to build the stun framework, since it interleaves message processing with transport protocols, which is a bad idea. I've been striving to simplify TURN a bunch before it completes, as it seems overly complicated to me for the value it brings. As a consequence, I've been debating making the UDP operation closer to the TCp operation. This would involve a bunch of changes that would not be backwards compatible, so they require discussion definitely: 1. removal of the LIFETIME attribute. Rather, allocations are kept alive only by data traffic. Data traffic is going to be present all the time anyway to keep regular nat bindings open. Thus, keeping the TURN bindings open the same way makes sense. Over time, I have increasingly seen TURN as a protocol that "converts" a symmetric NAT to address restricted. 2. only one Set Active Destination allowed. Once done, you cannot do any more, and indeed, no other turn signaling is possible. Unlike TCP, where there is an immediate transition, with UDP, you'll need a window of like 10s where you need to disambiguate data and TURN/STUN packets based on magic cookie. This whole discussion intertwines somewhat with the one around open issue #6. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Tue, 20 Dec 2005 11:39:00 -0800 (PST) From: Jonathan Rosenberg Date: Tue, 20 Dec 2005 11:39:00 -0800 (PST) Subject: [Ietf-behave] TURN Issue #10: MAGIC-COOKIE in the framework Message-ID: <43A85DC9.9040409@cisco.com> MIME-Version: 1.0 Content-Type: text/plain The MAGIC-COOKIE attribute exists to disambiguate TURN and data traffic, since both are sent on the same port. We are now seeing a need to disambiguate STUN and data traffic too - note how RTP and STUN run over the same port in ICE, and STUN and SIP in sip-outbound. Today, this disambiguation is done in an ad-hoc fashion in the ICE and sip-outbound cases. One idea is to make disambiguation a feature of the core stun framework, rather than a turn specific thing. There are a couple of ways to do this: 1. Keep the MAGIC-COOKIE attribute, but use it for other request types as needed 2. Eliminate MAGIC-COOKIE attribute. Rather, "steal" 32 of the 128 bits from the transaction ID, and make them have a fixed, well-known value. These would be used for all stun/turn transactions. Approach #2 has a number of interesting benefits: a. reduces message overhead, since no separate attribute is needed for disambiguation b. provides a nice way to differentiate turn-pre-09 and turn-post-09 messages from each other, which would facilitate transition for turn servers in deployment today. In that way, its more or less identical to the idea in SIP, where use used the branch ID in the Via header field to indicate the same kind of thing c. places the disambiguating data close to the top of the message, in a fixed location, making it easier to do in hardware I'd propose #2. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From dhudson@ubicom.com Wed, 21 Dec 2005 03:59:26 -0800 (PST) From: "Dave Hudson" Date: Wed, 21 Dec 2005 03:59:26 -0800 (PST) Subject: RE: [Ietf-behave] Catalogue of problems with deployed NATs Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Suresh, Comments inline... Regards, Dave * -----Original Message----- * From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] * Sent: 20 December 2005 16:45 * To: Dave Hudson; ietf-behave@xxxxxxxxxxxxxxxxxxx * Subject: RE: [Ietf-behave] Catalogue of problems with deployed NATs * * Hi Dave, * * It seems you can control some of the NAT devices enroute, but * not all in this setup. Is that right? Results are not * predictable when you change settings on just one of the NAT devices. I have no control over anything but my own local NAT. I have, at times, removed that and watched the same behaviour with a PC directly connected in the P2P networks though (it's just easier to log things with my NAT and I was looking at changes I could make to it that would help improve its behaviour or to have it generate fewer "noise" log messages about packets received that it couldn't make sense of). Much as I'd like to have made this a more controlled test I don't have a network of a thousand systems available for me to test with (at any one time it's quite normal for some of these apps to be talking to over a thousand remote systems). The thing I was surprised about were the numbers of different remote systems (scattered all over the world when I checked the IP addresses I'd collected) that all exhibited the same set of quirks. This leads me to believe that the behaviour I've observed must be found in quite widely deployed systems. * Also, do you have know the NAT traversal algorithm being * employed by the P2P application? If so, what is it? The applications I've been looking at don't do hole punching for the TCP streams - they rely on using UPnP or having the user configure specific forwarding rules within the NAT to forward all traffic on a particular port to the P2P apps. This is one of the reasons I find them an interesting (and relatively simple) test case because I could discount hole-punching attempts as a cause of the behaviour I was seeing. * > Essentially much of what I've been seeing appear to be a * consequence * > of the high volumes of NAT sessions that can be established by some * > P2P apps. I'm also seeing the effect of the high levels of * flux seen * > in many of the P2P file-sharing networks where nodes in the network * > disappear (although in some cases I suspect this may be the * result of * > symmetric NATs or NATs that exhibit symmetric behaviour under some * > circumstances). * > * * [suresh] Right. It is possible that some of the NAT devices * are hitting their resource limits (say, the number of NAT * Sessions) with P2P applications, especially when the P2P apps * are aggressive with multiple session initiations. I'd be quite surprised if that wasn't the case. I know that many of the NATs deployed in SOHO routers have very limited session tables (say 1024 sessions). I tend to be very interested in how things behave under these sort of conditions though as that's often the cause of bad behaviour that systems I develop have to then handle :-) * [suresh] Once a TCP session is established, RST handling for * P2P sessions is same as for regular client-server sessions. * The dropping of RST packets may be due to unusual traffic volume. I'm pretty certain that's what's happening. The reason I note the RST issue is that I've seen suggestions that a NAT can delete a session mapping once it's seen a RST - just because it saw it doesn't mean the remote host did though. Given that we now don't want to mandate that a NAT send a RST in response to a packet that has no session mapping (and it will just silently discard the packet) then we end up with the NAT being the cause of half-open connections in hosts and half-open sessions in other NATs. When I made the session persist for 2 MSL after a RST I saw a significant reduction in the rate of half-open connections that I'd previously seen since this gave an opportunity for lost RSTs to be resent in response to traffic from the remote host that never saw the original. * Also, when you tune just one of the NAT devices enroute, the * results are not necesaarily predictable. there may be * different cascading effects. Agreed - I'd be happier if I could do my tests under more controlled conditions but the size of the network required precludes this. * > 1) Bad ICMP destination (port) unreachable or redirect messages. * > These are messages where the remote peer is apparantly no longer * > running where it was but the remote NAT fails to translate * the payload of the message. * > As a result the packet is sent from the remote NAT to my * NAT but the * > ICMP message refers to a remote host that is clearly a * private IP of * > some host behind that NAT (typically 192.168.x.y) or occasionally * > 0.0.0.0. These messages are usually for UDP sessions but I do see * > some for TCP too. * > * * [suresh] Couple of possibilities here. The NAT device may * have bad code for translation of ICMP error packets (or) the * NAT device retired the NAT Session too early and couldnt * locate the NAT session to match when the ICMP error message * came. The ICMP message may have come from an intermediate * device, not necessarily the end node. Hmm - I guess there could be a race here between my UDP packet and the error reply with the session timing out in between but then I'd expect the NAT in question to discard a packet for which there's no mapping. Forwarding it to me isn't helpful as I can't do anything with it. * > 2) FIN/RST/ACK packets in response to SYN requests (this * may just be * > odd behaviour from a remote TCP stack though). * > * * [suresh] Is it possible these are coming from remote NAT * instead of remote host? My original guess was that this was the remote NAT but it could also be odd behaviour from a remote host. I'm still trying to determine this. * > 3) RST packets being sent to the wrong local port. In * these cases a * > remote NAT sends a FIN/ACK to close an existing session and * follows it * > immediately with a RST but the RST ends up sent to a random * port at my * > end despite the FIN/ACK having been sent the correct port * (this double * > approach to closing sessions is surprisingly common but * normally the * > port numbers are the same). All subsequent FIN/ACKs from * my end get * > the same mismatched RST in response. * > * [suresh] It is not normal for the NAT devices to directly * engage in FIN/ACK 3-way handshake, unless the NAT device is * doing transparant proxy (where the NAT device actually * terminates the TCP session). Some vendors do implement * transparant proxy on their NAT devices. But, transparant * proxy is different and not an integral part of NAT, as IETF * defines it. In this particular case though I would have expected the NAT to retain the session until it saw a responding FIN at least. The quirk here though is that the RST is being sent to a different port on my side - I can understand how a deleted session could cause it to be sent from a different port but not to a different one. From dhudson@ubicom.com Wed, 21 Dec 2005 04:16:04 -0800 (PST) From: "Dave Hudson" Date: Wed, 21 Dec 2005 04:16:04 -0800 (PST) Subject: [Ietf-behave] Idealized UDP/TCP port bindings Message-ID: MIME-Version: 1.0 Content-Type: text/plain I can't recall having seen any discussion of this so I thought I'd ask the question... If I have a port mapping within a NAT where private address and port A:P maps to a public address and port A':P' is there any advantage to having the mapping of P -> P' be the same for both UDP and TCP? (e.g. if I have an private port 12345 which maps to a public port 9977 for UDP does it help if 12345 also maps to 9977 for TCP as opposed to some other mapping, say, 11111?). I'm assuming here that the NAT exhibits endpoint independent mapping. Thanks, Dave From matthewsp@avaya.com Wed, 21 Dec 2005 06:31:28 -0800 (PST) From: "Matthews, Philip (Philip)" Date: Wed, 21 Dec 2005 06:31:28 -0800 (PST) Subject: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in a P2P application Message-ID: MIME-Version: 1.0 Content-Type: text/plain Francois and Cullen: I have a question about the behavior of a NAT "N" that is compliant with draft-ietf-behave-nat-udp-04. Say that NAT N implements the more stringent filtering behaviour of "Address dependent filtering" (REQ-8), and say that, despite this, I am trying to write a peer-to-peer application A which is located behind NAT N and which maintains UDP connections with 20 other peers B,C,D,.... Application A uses the same address and port for all these connections. To maintain the appropriate bindings in NAT "N", so that application A can receive packets from each of these peers, must application A send a UDP packet to all 20 peers B,C,D,... every 2 minutes, or can application A send a UDP packet to just one of these peers every 2 minutes? (For simplicity, assume NAT "N" has a "NAT inbound refresh behavior" of False). I am hoping, of course, that a packet every 2 minutes to just ONE peer will be sufficient to maintain all these mappings. However, I cannot seem to find any words one way or another about this in the document. Am I missing something? - Philip From jdrosen@cisco.com Wed, 21 Dec 2005 07:43:41 -0800 (PST) From: Jonathan Rosenberg Date: Wed, 21 Dec 2005 07:43:41 -0800 (PST) Subject: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP Message-ID: <43A97822.1030709@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Several revisions ago, I removed the feature in TURN that allows an endpoint to request a specific port parity (odd/even) and to also reserve the next higher port. Such a situation allows for interop between a TURN/ICE enabled endpoint and an older RTP endpoint (SIP or MGCP) that assumes the port adjacency for RTP. I removed the capability in an attempt to simplify turn, and also based on the assumption that over time as endpoints implement rfc3605 and ICE the problem will disappear. However, I've gotten some private requests to put the feature back in the spec. The driver is to support seamless interop between large installed bases of RTP-based endpoints, which are not going away anytime soon. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From srisuresh@yahoo.com Wed, 21 Dec 2005 08:15:41 -0800 (PST) From: Pyda Srisuresh Date: Wed, 21 Dec 2005 08:15:41 -0800 (PST) Subject: Re: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in a P2P application In-Reply-To: Message-ID: <20051221161540.27130.qmail@web33305.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Philip, The application design guideline draft, has the following in section 3.1 to address your question. Hope this helps. REQ-6 Applications wishing to accept connections from other peers after registering via UDP with one or more rendezvous servers MUST send periodic outgoing UDP "keep-alive" packets to at least one rendezvous server, at least once within the BEHAVE-compliant NAT UDP timeout (2 minutes). cheers, suresh --- "Matthews, Philip (Philip)" wrote: > Francois and Cullen: > > I have a question about the behavior of a NAT "N" that is compliant > with draft-ietf-behave-nat-udp-04. > > Say that NAT N implements the more stringent filtering behaviour of > "Address dependent filtering" (REQ-8), and say that, despite this, > I am trying to write a peer-to-peer application A which is located > behind NAT N and which maintains UDP connections with 20 other peers > B,C,D,.... > Application A uses the same address and port for all these connections. > > To maintain the appropriate bindings in NAT "N", so that application A > can receive > packets from each of these peers, must application A send a UDP packet > to all 20 peers B,C,D,... every 2 minutes, or can application A send a > UDP packet > to just one of these peers every 2 minutes? > > (For simplicity, assume NAT "N" has a "NAT inbound refresh behavior" of > False). > > I am hoping, of course, that a packet every 2 minutes to just ONE peer > will be > sufficient to maintain all these mappings. However, I cannot seem to > find any > words one way or another about this in the document. Am I missing > something? > > - Philip > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From matthewsp@avaya.com Wed, 21 Dec 2005 08:28:42 -0800 (PST) From: "Matthews, Philip (Philip)" Date: Wed, 21 Dec 2005 08:28:42 -0800 (PST) Subject: RE: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in a P2P application Message-ID: MIME-Version: 1.0 Content-Type: text/plain Suresh: Thanks very much for replying with your pointer and reminding me about draft-ford-behave-app-01. I took a quick look through draft-ford-behave-app-01.txt and in addition to the text you quote below, I saw the following statement: BEHAVE-compliant NATs are required to support Address Restricted Cone NAT Behavior, which essentially resets the idle timer for ALL sessions for a particular binding (i.e., involving a particular private port) whenever outbound traffic is seen from that private port on ANY such session. What is the justification for this statement? That is, where in draft-ietf-behave-nat-udp-04 is a statement to this effect made? Given that draft-ford-behave-app-01 is not yet a WG document, I think it would be good to have some statement in draft-ietf-behave-nat-udp-04. - Philip > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > Sent: December 21, 2005 11:16 > To: Matthews, Philip (Philip) > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Question about > draft-ietf-behave-nat-udp-04 in a P2P application > > Philip, > > The application design guideline draft, > has the > following in section 3.1 to address your question. Hope this helps. > > REQ-6 Applications wishing to accept connections from other peers > after registering via UDP with one or more rendezvous servers > MUST send periodic outgoing UDP "keep-alive" packets to at > least one rendezvous server, at least once within the > BEHAVE-compliant NAT UDP timeout (2 minutes). > > cheers, > suresh > > --- "Matthews, Philip (Philip)" wrote: > > > Francois and Cullen: > > > > I have a question about the behavior of a NAT "N" that is compliant > > with draft-ietf-behave-nat-udp-04. > > > > Say that NAT N implements the more stringent filtering behaviour of > > "Address dependent filtering" (REQ-8), and say that, despite this, > > I am trying to write a peer-to-peer application A which is located > > behind NAT N and which maintains UDP connections with 20 other peers > > B,C,D,.... > > Application A uses the same address and port for all these > connections. > > > > To maintain the appropriate bindings in NAT "N", so that > application A > > can receive > > packets from each of these peers, must application A send a > UDP packet > > to all 20 peers B,C,D,... every 2 minutes, or can > application A send a > > UDP packet > > to just one of these peers every 2 minutes? > > > > (For simplicity, assume NAT "N" has a "NAT inbound refresh > behavior" of > > False). > > > > I am hoping, of course, that a packet every 2 minutes to > just ONE peer > > will be > > sufficient to maintain all these mappings. However, I cannot seem to > > find any > > words one way or another about this in the document. Am I missing > > something? > > > > - Philip > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > From srisuresh@yahoo.com Wed, 21 Dec 2005 08:47:16 -0800 (PST) From: Pyda Srisuresh Date: Wed, 21 Dec 2005 08:47:16 -0800 (PST) Subject: Re: [Ietf-behave] Idealized UDP/TCP port bindings In-Reply-To: Message-ID: <20051221164716.40180.qmail@web33305.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Hi Dave, Good question. I dont know of any applications that mandate this behavior. I dont believe, it should be required of NATs to correlate the port bindings between TCP and UDP. cheers, suresh --- Dave Hudson wrote: > I can't recall having seen any discussion of this so I thought I'd ask > the question... > > If I have a port mapping within a NAT where private address and port A:P > maps to a public address and port A':P' is there any advantage to having > the mapping of P -> P' be the same for both UDP and TCP? (e.g. if I > have an private port 12345 which maps to a public port 9977 for UDP does > it help if 12345 also maps to 9977 for TCP as opposed to some other > mapping, say, 11111?). I'm assuming here that the NAT exhibits endpoint > independent mapping. > > > Thanks, > Dave > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Wed, 21 Dec 2005 09:03:58 -0800 (PST) From: Pyda Srisuresh Date: Wed, 21 Dec 2005 09:03:58 -0800 (PST) Subject: RE: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in a P2P application In-Reply-To: Message-ID: <20051221170358.27744.qmail@web33314.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- "Matthews, Philip (Philip)" wrote: > Suresh: > > Thanks very much for replying with your pointer > and reminding me about draft-ford-behave-app-01. > [suresh] I wasnt reminding you. I was giving you a pointer. > I took a quick look through draft-ford-behave-app-01.txt and > in addition to the text you quote below, I saw the following > statement: > > BEHAVE-compliant NATs are required to support Address Restricted > Cone NAT Behavior, which essentially resets the idle timer for ALL > sessions for a particular binding (i.e., involving a particular > private port) whenever outbound traffic is seen from that private > port on ANY such session. > > What is the justification for this statement? > > That is, where in draft-ietf-behave-nat-udp-04 is a statement to this > effect made? > [suresh] Sure, It would be useful to have a statement to this effect or otherwise in the UDP draft. cheers, suresh > Given that draft-ford-behave-app-01 is not yet a WG document, > I think it would be good to have some statement in > draft-ietf-behave-nat-udp-04. > > - Philip > > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > Sent: December 21, 2005 11:16 > > To: Matthews, Philip (Philip) > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Ietf-behave] Question about > > draft-ietf-behave-nat-udp-04 in a P2P application > > > > Philip, > > > > The application design guideline draft, > > has the > > following in section 3.1 to address your question. Hope this helps. > > > > REQ-6 Applications wishing to accept connections from other peers > > after registering via UDP with one or more rendezvous servers > > MUST send periodic outgoing UDP "keep-alive" packets to at > > least one rendezvous server, at least once within the > > BEHAVE-compliant NAT UDP timeout (2 minutes). > > > > cheers, > > suresh > > > > --- "Matthews, Philip (Philip)" wrote: > > > > > Francois and Cullen: > > > > > > I have a question about the behavior of a NAT "N" that is compliant > > > with draft-ietf-behave-nat-udp-04. > > > > > > Say that NAT N implements the more stringent filtering behaviour of > > > "Address dependent filtering" (REQ-8), and say that, despite this, > > > I am trying to write a peer-to-peer application A which is located > > > behind NAT N and which maintains UDP connections with 20 other peers > > > B,C,D,.... > > > Application A uses the same address and port for all these > > connections. > > > > > > To maintain the appropriate bindings in NAT "N", so that > > application A > > > can receive > > > packets from each of these peers, must application A send a > > UDP packet > > > to all 20 peers B,C,D,... every 2 minutes, or can > > application A send a > > > UDP packet > > > to just one of these peers every 2 minutes? > > > > > > (For simplicity, assume NAT "N" has a "NAT inbound refresh > > behavior" of > > > False). > > > > > > I am hoping, of course, that a packet every 2 minutes to > > just ONE peer > > > will be > > > sufficient to maintain all these mappings. However, I cannot seem to > > > find any > > > words one way or another about this in the document. Am I missing > > > something? > > > > > > - Philip > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > From dwing@cisco.com Thu, 22 Dec 2005 06:24:43 -0800 (PST) From: "Dan Wing" Date: Thu, 22 Dec 2005 06:24:43 -0800 (PST) Subject: RE: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP In-Reply-To: <43A97822.1030709@cisco.com> Message-ID: <200512221424.jBMEOSMg028814@sj-core-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Seems like a reasonable idea, and allows TURN to provide good interop with RFC3605-unaware peers and still get RTCP. I read -01 and you required two TURN requests to do that. Why not just return both addresses in a single TURN response? If you require two TURN requests you're complicating the TURN server's state machine (it needs to withold that adjacent address from its pool, unless that particular client asks for it, and the TURN requests might be received out of their expected order). It's also more traffic on the network and you increase the chance that one of the four messages will be lost or delayed -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jonathan Rosenberg > Sent: Wednesday, December 21, 2005 7:44 AM > To: Behave > Subject: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP > > Several revisions ago, I removed the feature in TURN that allows an > endpoint to request a specific port parity (odd/even) and to also > reserve the next higher port. Such a situation allows for interop > between a TURN/ICE enabled endpoint and an older RTP endpoint (SIP or > MGCP) that assumes the port adjacency for RTP. > > I removed the capability in an attempt to simplify turn, and > also based > on the assumption that over time as endpoints implement > rfc3605 and ICE > the problem will disappear. > > However, I've gotten some private requests to put the feature back in > the spec. The driver is to support seamless interop between large > installed bases of RTP-based endpoints, which are not going > away anytime > soon. > > Comments? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From ssenthil@cisco.com Thu, 22 Dec 2005 08:22:25 -0800 (PST) From: "Senthil Sivakumar (ssenthil)" Date: Thu, 22 Dec 2005 08:22:25 -0800 (PST) Subject: RE: [Ietf-behave] Idealized UDP/TCP port bindings Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB010BB500@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain The port space for TCP and UDP are not shared from a NAT's perspective and I don't think there is any advantage of preserving the port mapping between the protocols. Also, if there are applications that require this then it would the Application Layer gateways that would be required to preserve the same port for both TCP and UDP. Senthil > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Dave Hudson > Sent: Wednesday, December 21, 2005 7:16 AM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] Idealized UDP/TCP port bindings > > I can't recall having seen any discussion of this so I > thought I'd ask the question... > > If I have a port mapping within a NAT where private address > and port A:P maps to a public address and port A':P' is there > any advantage to having the mapping of P -> P' be the same > for both UDP and TCP? (e.g. if I have an private port 12345 > which maps to a public port 9977 for UDP does it help if > 12345 also maps to 9977 for TCP as opposed to some other > mapping, say, 11111?). I'm assuming here that the NAT > exhibits endpoint independent mapping. > > > Thanks, > Dave > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From audet@nortel.com Tue, 3 Jan 2006 09:50:18 -0800 (PST) From: "Francois Audet" Date: Tue, 3 Jan 2006 09:50:18 -0800 (PST) Subject: RE: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP Message-ID: <1ECE0EB50388174790F9694F77522CCF05F59D41@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Sounds reasonable to me. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jonathan Rosenberg > Sent: Wednesday, December 21, 2005 07:44 > To: Behave > Subject: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP > > > Several revisions ago, I removed the feature in TURN that allows an > endpoint to request a specific port parity (odd/even) and to also > reserve the next higher port. Such a situation allows for interop > between a TURN/ICE enabled endpoint and an older RTP endpoint (SIP or > MGCP) that assumes the port adjacency for RTP. > > I removed the capability in an attempt to simplify turn, and > also based > on the assumption that over time as endpoints implement > rfc3605 and ICE > the problem will disappear. > > However, I've gotten some private requests to put the feature back in > the spec. The driver is to support seamless interop between large > installed bases of RTP-based endpoints, which are not going > away anytime > soon. > > Comments? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From audet@nortel.com Tue, 3 Jan 2006 11:05:44 -0800 (PST) From: "Francois Audet" Date: Tue, 3 Jan 2006 11:05:44 -0800 (PST) Subject: RE: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in aP2P application Message-ID: <1ECE0EB50388174790F9694F77522CCF05F59EBB@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain REQ-8 (and REQ-1) of draft-ietf-behave-nat-udp-04 is what the BEHAVE group agreed-to, and supercedes what is said in behave-app if there is a conflict. It does not mandate Address Restricted Cone NAT. So the statement you are refering to needs to be modified in the ford-behave draft. To answer your original question on refreshing the mapping by the application, it was out-of-scope of draft-behave-nat-udp to talk about applications. That's why we didn't mention it. In a much earlier version of the draft, we did talk about it and try to impose a "one packet refreshes all mapping" policy. We eventually came to the conclusion that unfortunatelly it would be impossible (we couldn't get everybody to agree). It is essentially a consequence of allowing for all "filtering" behaviors (see REQ-9). Therefore, I believe you need to refresh all ndividual mappinga. This particular statement is not made in the document because it is an application issue. Hope this helps. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Matthews, Philip (Philip) > Sent: Wednesday, December 21, 2005 08:29 > To: Pyda Srisuresh > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] Question about > draft-ietf-behave-nat-udp-04 in aP2P application > > > Suresh: > > Thanks very much for replying with your pointer > and reminding me about draft-ford-behave-app-01. > > I took a quick look through draft-ford-behave-app-01.txt and > in addition to the text you quote below, I saw the following > statement: > > BEHAVE-compliant NATs are required to support Address Restricted > Cone NAT Behavior, which essentially resets the idle timer for ALL > sessions for a particular binding (i.e., involving a particular > private port) whenever outbound traffic is seen from that private > port on ANY such session. > > What is the justification for this statement? > > That is, where in draft-ietf-behave-nat-udp-04 is a statement > to this effect made? > > Given that draft-ford-behave-app-01 is not yet a WG document, > I think it would be good to have some statement in > draft-ietf-behave-nat-udp-04. > > - Philip > > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > Sent: December 21, 2005 11:16 > > To: Matthews, Philip (Philip) > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Ietf-behave] Question about > > draft-ietf-behave-nat-udp-04 in a P2P application > > > > Philip, > > > > The application design guideline draft, > > has the > > following in section 3.1 to address your question. Hope this helps. > > > > REQ-6 Applications wishing to accept connections from other peers > > after registering via UDP with one or more rendezvous servers > > MUST send periodic outgoing UDP "keep-alive" packets to at > > least one rendezvous server, at least once within the > > BEHAVE-compliant NAT UDP timeout (2 minutes). > > > > cheers, > > suresh > > > > --- "Matthews, Philip (Philip)" wrote: > > > > > Francois and Cullen: > > > > > > I have a question about the behavior of a NAT "N" that is > compliant > > > with draft-ietf-behave-nat-udp-04. > > > > > > Say that NAT N implements the more stringent filtering > behaviour of > > > "Address dependent filtering" (REQ-8), and say that, > despite this, I > > > am trying to write a peer-to-peer application A which is located > > > behind NAT N and which maintains UDP connections with 20 > other peers > > > B,C,D,.... Application A uses the same address and port for all > > > these > > connections. > > > > > > To maintain the appropriate bindings in NAT "N", so that > > application A > > > can receive > > > packets from each of these peers, must application A send a > > UDP packet > > > to all 20 peers B,C,D,... every 2 minutes, or can > > application A send a > > > UDP packet > > > to just one of these peers every 2 minutes? > > > > > > (For simplicity, assume NAT "N" has a "NAT inbound refresh > > behavior" of > > > False). > > > > > > I am hoping, of course, that a packet every 2 minutes to > > just ONE peer > > > will be > > > sufficient to maintain all these mappings. However, I > cannot seem to > > > find any words one way or another about this in the > document. Am I > > > missing something? > > > > > > - Philip > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From matthewsp@avaya.com Tue, 3 Jan 2006 11:21:50 -0800 (PST) From: "Matthews, Philip (Philip)" Date: Tue, 3 Jan 2006 11:21:50 -0800 (PST) Subject: RE: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in aP2P application Message-ID: MIME-Version: 1.0 Content-Type: text/plain Francois: Thanks very much for your reply. > We eventually came to the conclusion that unfortunatelly it would be > impossible (we couldn't get everybody to agree). It is essentially a > consequence of allowing for all "filtering" behaviors (see REQ-9). Do you really mean REQ-9 "Hairpinning"? It sounds like this issue was already discussed on the mailing list. Can you give me a pointer so I can go back and read the discussion? - Philip > -----Original Message----- > From: Francois Audet [mailto:audet@xxxxxxxxxx] > Sent: January 3, 2006 14:06 > To: Matthews, Philip (Philip); Pyda Srisuresh; Cullen Jennings > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] Question about > draft-ietf-behave-nat-udp-04 in aP2P application > > REQ-8 (and REQ-1) of draft-ietf-behave-nat-udp-04 is what the BEHAVE > group agreed-to, and supercedes what is said in behave-app if there is > a conflict. It does not mandate Address Restricted Cone NAT. > > So the statement you are refering to needs to be modified in the > ford-behave draft. > > > > To answer your original question on refreshing the mapping by the > application, > it was out-of-scope of draft-behave-nat-udp to talk about > applications. > That's why we didn't mention it. In a much earlier version of > the draft, > we > did talk about it and try to impose a "one packet refreshes all > mapping" policy. > > We eventually came to the conclusion that unfortunatelly it would be > impossible (we couldn't get everybody to agree). It is essentially a > consequence of allowing for all "filtering" behaviors (see REQ-9). > > Therefore, I believe you need to refresh all ndividual mappinga. This > particular statement is not made in the document because it is an > application issue. > > Hope this helps. > > > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Matthews, Philip (Philip) > > Sent: Wednesday, December 21, 2005 08:29 > > To: Pyda Srisuresh > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] Question about > > draft-ietf-behave-nat-udp-04 in aP2P application > > > > > > Suresh: > > > > Thanks very much for replying with your pointer > > and reminding me about draft-ford-behave-app-01. > > > > I took a quick look through draft-ford-behave-app-01.txt and > > in addition to the text you quote below, I saw the following > > statement: > > > > BEHAVE-compliant NATs are required to support Address Restricted > > Cone NAT Behavior, which essentially resets the idle > timer for ALL > > sessions for a particular binding (i.e., involving a particular > > private port) whenever outbound traffic is seen from that private > > port on ANY such session. > > > > What is the justification for this statement? > > > > That is, where in draft-ietf-behave-nat-udp-04 is a statement > > to this effect made? > > > > Given that draft-ford-behave-app-01 is not yet a WG document, > > I think it would be good to have some statement in > > draft-ietf-behave-nat-udp-04. > > > > - Philip > > > > > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > Sent: December 21, 2005 11:16 > > > To: Matthews, Philip (Philip) > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: Re: [Ietf-behave] Question about > > > draft-ietf-behave-nat-udp-04 in a P2P application > > > > > > Philip, > > > > > > The application design guideline draft, > > > has the > > > following in section 3.1 to address your question. Hope > this helps. > > > > > > REQ-6 Applications wishing to accept connections from other peers > > > after registering via UDP with one or more > rendezvous servers > > > MUST send periodic outgoing UDP "keep-alive" packets to at > > > least one rendezvous server, at least once within the > > > BEHAVE-compliant NAT UDP timeout (2 minutes). > > > > > > cheers, > > > suresh > > > > > > --- "Matthews, Philip (Philip)" wrote: > > > > > > > Francois and Cullen: > > > > > > > > I have a question about the behavior of a NAT "N" that is > > compliant > > > > with draft-ietf-behave-nat-udp-04. > > > > > > > > Say that NAT N implements the more stringent filtering > > behaviour of > > > > "Address dependent filtering" (REQ-8), and say that, > > despite this, I > > > > am trying to write a peer-to-peer application A which > is located > > > > behind NAT N and which maintains UDP connections with 20 > > other peers > > > > B,C,D,.... Application A uses the same address and port for all > > > > these > > > connections. > > > > > > > > To maintain the appropriate bindings in NAT "N", so that > > > application A > > > > can receive > > > > packets from each of these peers, must application A send a > > > UDP packet > > > > to all 20 peers B,C,D,... every 2 minutes, or can > > > application A send a > > > > UDP packet > > > > to just one of these peers every 2 minutes? > > > > > > > > (For simplicity, assume NAT "N" has a "NAT inbound refresh > > > behavior" of > > > > False). > > > > > > > > I am hoping, of course, that a packet every 2 minutes to > > > just ONE peer > > > > will be > > > > sufficient to maintain all these mappings. However, I > > cannot seem to > > > > find any words one way or another about this in the > > document. Am I > > > > missing something? > > > > > > > > - Philip > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > From audet@nortel.com Tue, 3 Jan 2006 13:07:47 -0800 (PST) From: "Francois Audet" Date: Tue, 3 Jan 2006 13:07:47 -0800 (PST) Subject: RE: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in aP2P application Message-ID: <1ECE0EB50388174790F9694F77522CCF05F5A147@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain > Francois: > > Thanks very much for your reply. > > > We eventually came to the conclusion that unfortunatelly it > would be > > impossible (we couldn't get everybody to agree). It is > essentially a > > consequence of allowing for all "filtering" behaviors (see REQ-9). > > Do you really mean REQ-9 "Hairpinning"? Oops, I meant REQ-8. Sorry. > It sounds like this issue was already discussed on the > mailing list. Can you give me a pointer so I can go back and > read the discussion? Section 4.4 of draft-ietf-behave-nat-udp-01 (http://www.faqs.org/ftp/internet-drafts/draft-ietf-behave-nat-udp-01.tx t) talked about this. REQ-6b covered this particular point. The following archive shows when both 4.4 and 6b where removed: http://list.sipfoundry.org/archive/ietf-behave/msg00799.html > - Philip > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@xxxxxxxxxx] > > Sent: January 3, 2006 14:06 > > To: Matthews, Philip (Philip); Pyda Srisuresh; Cullen Jennings > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] Question about > > draft-ietf-behave-nat-udp-04 in aP2P application > > > > REQ-8 (and REQ-1) of draft-ietf-behave-nat-udp-04 is what the BEHAVE > > group agreed-to, and supercedes what is said in behave-app > if there is > > a conflict. It does not mandate Address Restricted Cone NAT. > > > > So the statement you are refering to needs to be modified in the > > ford-behave draft. > > > > > > > > To answer your original question on refreshing the mapping by the > > application, it was out-of-scope of draft-behave-nat-udp to > talk about > > applications. > > That's why we didn't mention it. In a much earlier version of > > the draft, > > we > > did talk about it and try to impose a "one packet refreshes all > > mapping" policy. > > > > We eventually came to the conclusion that unfortunatelly it > would be > > impossible (we couldn't get everybody to agree). It is > essentially a > > consequence of allowing for all "filtering" behaviors (see REQ-9). > > > > Therefore, I believe you need to refresh all ndividual > mappinga. This > > particular statement is not made in the document because it is an > > application issue. > > > > Hope this helps. > > > > > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > Matthews, Philip (Philip) > > > Sent: Wednesday, December 21, 2005 08:29 > > > To: Pyda Srisuresh > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: RE: [Ietf-behave] Question about > > > draft-ietf-behave-nat-udp-04 in aP2P application > > > > > > > > > Suresh: > > > > > > Thanks very much for replying with your pointer > > > and reminding me about draft-ford-behave-app-01. > > > > > > I took a quick look through draft-ford-behave-app-01.txt and in > > > addition to the text you quote below, I saw the following > > > statement: > > > > > > BEHAVE-compliant NATs are required to support Address > Restricted > > > Cone NAT Behavior, which essentially resets the idle > > timer for ALL > > > sessions for a particular binding (i.e., involving a particular > > > private port) whenever outbound traffic is seen from > that private > > > port on ANY such session. > > > > > > What is the justification for this statement? > > > > > > That is, where in draft-ietf-behave-nat-udp-04 is a statement > > > to this effect made? > > > > > > Given that draft-ford-behave-app-01 is not yet a WG document, I > > > think it would be good to have some statement in > > > draft-ietf-behave-nat-udp-04. > > > > > > - Philip > > > > > > > > > > -----Original Message----- > > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > > Sent: December 21, 2005 11:16 > > > > To: Matthews, Philip (Philip) > > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Subject: Re: [Ietf-behave] Question about > > > > draft-ietf-behave-nat-udp-04 in a P2P application > > > > > > > > Philip, > > > > > > > > The application design guideline draft, > > > > has the following in > section 3.1 to > > > > address your question. Hope > > this helps. > > > > > > > > REQ-6 Applications wishing to accept connections from > other peers > > > > after registering via UDP with one or more > > rendezvous servers > > > > MUST send periodic outgoing UDP "keep-alive" > packets to at > > > > least one rendezvous server, at least once within the > > > > BEHAVE-compliant NAT UDP timeout (2 minutes). > > > > > > > > cheers, > > > > suresh > > > > > > > > --- "Matthews, Philip (Philip)" wrote: > > > > > > > > > Francois and Cullen: > > > > > > > > > > I have a question about the behavior of a NAT "N" that is > > > compliant > > > > > with draft-ietf-behave-nat-udp-04. > > > > > > > > > > Say that NAT N implements the more stringent filtering > > > behaviour of > > > > > "Address dependent filtering" (REQ-8), and say that, > > > despite this, I > > > > > am trying to write a peer-to-peer application A which > > is located > > > > > behind NAT N and which maintains UDP connections with 20 > > > other peers > > > > > B,C,D,.... Application A uses the same address and > port for all > > > > > these > > > > connections. > > > > > > > > > > To maintain the appropriate bindings in NAT "N", so that > > > > application A > > > > > can receive > > > > > packets from each of these peers, must application A send a > > > > UDP packet > > > > > to all 20 peers B,C,D,... every 2 minutes, or can > > > > application A send a > > > > > UDP packet > > > > > to just one of these peers every 2 minutes? > > > > > > > > > > (For simplicity, assume NAT "N" has a "NAT inbound refresh > > > > behavior" of > > > > > False). > > > > > > > > > > I am hoping, of course, that a packet every 2 minutes to > > > > just ONE peer > > > > > will be > > > > > sufficient to maintain all these mappings. However, I > > > cannot seem to > > > > > find any words one way or another about this in the > > > document. Am I > > > > > missing something? > > > > > > > > > > - Philip > > > > > > > > > > _______________________________________________ > > > > > Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > From srisuresh@yahoo.com Wed, 4 Jan 2006 12:23:06 -0800 (PST) From: Pyda Srisuresh Date: Wed, 4 Jan 2006 12:23:06 -0800 (PST) Subject: RE: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in aP2P application In-Reply-To: <1ECE0EB50388174790F9694F77522CCF05F59EBB@zrc2hxm0.corp.nortel.com> Message-ID: <20060104202305.71467.qmail@web33312.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Francois Audet wrote: > REQ-8 (and REQ-1) of draft-ietf-behave-nat-udp-04 is what the BEHAVE > group agreed-to, and supercedes what is said in behave-app if there is > a conflict. It does not mandate Address Restricted Cone NAT. > > So the statement you are refering to needs to be modified in the > ford-behave draft. > [suresh] You are right. REQ-8, as it stands, does not mandate Address restricted Cone NAT. This need to be fixed. I.e., a statement that says that NAT MUST enforce one of "Endpoint independent filtering" behavior or "Address dependent filtering" behavior should be added to the current REQ-8. As I recall, there was a long discussion on whether to mandate Address restricted Cone NAT (EF=A) or Full Cone NAT (EF=I). But, I belive, everyone agreed it must be one of these two. The final text missed this subtility and implies that a minimally compliant NAT device doesnt have to be either of the two. As it stands, even a NAT device with EF=P would be behave compliant. That is not right. Below is how REQ-8 currently reads: REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address dependent filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. cheers, suresh > > > To answer your original question on refreshing the mapping by the > application, > it was out-of-scope of draft-behave-nat-udp to talk about applications. > That's why we didn't mention it. In a much earlier version of the draft, > we > did talk about it and try to impose a "one packet refreshes all > mapping" policy. > > We eventually came to the conclusion that unfortunatelly it would be > impossible (we couldn't get everybody to agree). It is essentially a > consequence of allowing for all "filtering" behaviors (see REQ-9). > > Therefore, I believe you need to refresh all ndividual mappinga. This > particular statement is not made in the document because it is an > application issue. > > Hope this helps. > > > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Matthews, Philip (Philip) > > Sent: Wednesday, December 21, 2005 08:29 > > To: Pyda Srisuresh > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] Question about > > draft-ietf-behave-nat-udp-04 in aP2P application > > > > > > Suresh: > > > > Thanks very much for replying with your pointer > > and reminding me about draft-ford-behave-app-01. > > > > I took a quick look through draft-ford-behave-app-01.txt and > > in addition to the text you quote below, I saw the following > > statement: > > > > BEHAVE-compliant NATs are required to support Address Restricted > > Cone NAT Behavior, which essentially resets the idle timer for ALL > > sessions for a particular binding (i.e., involving a particular > > private port) whenever outbound traffic is seen from that private > > port on ANY such session. > > > > What is the justification for this statement? > > > > That is, where in draft-ietf-behave-nat-udp-04 is a statement > > to this effect made? > > > > Given that draft-ford-behave-app-01 is not yet a WG document, > > I think it would be good to have some statement in > > draft-ietf-behave-nat-udp-04. > > > > - Philip > > > > > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > Sent: December 21, 2005 11:16 > > > To: Matthews, Philip (Philip) > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: Re: [Ietf-behave] Question about > > > draft-ietf-behave-nat-udp-04 in a P2P application > > > > > > Philip, > > > > > > The application design guideline draft, > > > has the > > > following in section 3.1 to address your question. Hope this helps. > > > > > > REQ-6 Applications wishing to accept connections from other peers > > > after registering via UDP with one or more rendezvous servers > > > MUST send periodic outgoing UDP "keep-alive" packets to at > > > least one rendezvous server, at least once within the > > > BEHAVE-compliant NAT UDP timeout (2 minutes). > > > > > > cheers, > > > suresh > > > > > > --- "Matthews, Philip (Philip)" wrote: > > > > > > > Francois and Cullen: > > > > > > > > I have a question about the behavior of a NAT "N" that is > > compliant > > > > with draft-ietf-behave-nat-udp-04. > > > > > > > > Say that NAT N implements the more stringent filtering > > behaviour of > > > > "Address dependent filtering" (REQ-8), and say that, > > despite this, I > > > > am trying to write a peer-to-peer application A which is located > > > > behind NAT N and which maintains UDP connections with 20 > > other peers > > > > B,C,D,.... Application A uses the same address and port for all > > > > these > > > connections. > > > > > > > > To maintain the appropriate bindings in NAT "N", so that > > > application A > > > > can receive > > > > packets from each of these peers, must application A send a > > > UDP packet > > > > to all 20 peers B,C,D,... every 2 minutes, or can > > > application A send a > > > > UDP packet > > > > to just one of these peers every 2 minutes? > > > > > > > > (For simplicity, assume NAT "N" has a "NAT inbound refresh > > > behavior" of > > > > False). > > > > > > > > I am hoping, of course, that a packet every 2 minutes to > > > just ONE peer > > > > will be > > > > sufficient to maintain all these mappings. However, I > > cannot seem to > > > > find any words one way or another about this in the > > document. Am I > > > > missing something? > > > > > > > > - Philip > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > From matthewsp@avaya.com Wed, 4 Jan 2006 13:32:07 -0800 (PST) From: "Matthews, Philip (Philip)" Date: Wed, 4 Jan 2006 13:32:07 -0800 (PST) Subject: RE: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in aP2P application Message-ID: MIME-Version: 1.0 Content-Type: text/plain Francois: Thanks for the pointer to the mailing list archives. I read through it, and have a better understanding now of why you took REQ-6b out. As you said, it seems like an application needs to refresh all the individual mappings. Thanks again for your help. - Philip > -----Original Message----- > From: Francois Audet [mailto:audet@xxxxxxxxxx] > Sent: January 3, 2006 16:08 > To: Matthews, Philip (Philip) > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx; Pyda Srisuresh; Cullen Jennings > Subject: RE: [Ietf-behave] Question about > draft-ietf-behave-nat-udp-04 in aP2P application > > > > Francois: > > > > Thanks very much for your reply. > > > > > We eventually came to the conclusion that unfortunatelly it > > would be > > > impossible (we couldn't get everybody to agree). It is > > essentially a > > > consequence of allowing for all "filtering" behaviors (see REQ-9). > > > > Do you really mean REQ-9 "Hairpinning"? > > Oops, I meant REQ-8. Sorry. > > > It sounds like this issue was already discussed on the > > mailing list. Can you give me a pointer so I can go back and > > read the discussion? > > Section 4.4 of draft-ietf-behave-nat-udp-01 > (http://www.faqs.org/ftp/internet-drafts/draft-ietf-behave-nat > -udp-01.tx > t) talked about this. REQ-6b covered > this particular point. > > The following archive shows when both 4.4 and 6b where removed: > http://list.sipfoundry.org/archive/ietf-behave/msg00799.html > > > > - Philip > > > > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@xxxxxxxxxx] > > > Sent: January 3, 2006 14:06 > > > To: Matthews, Philip (Philip); Pyda Srisuresh; Cullen Jennings > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: RE: [Ietf-behave] Question about > > > draft-ietf-behave-nat-udp-04 in aP2P application > > > > > > REQ-8 (and REQ-1) of draft-ietf-behave-nat-udp-04 is what > the BEHAVE > > > group agreed-to, and supercedes what is said in behave-app > > if there is > > > a conflict. It does not mandate Address Restricted Cone NAT. > > > > > > So the statement you are refering to needs to be modified in the > > > ford-behave draft. > > > > > > > > > > > > To answer your original question on refreshing the mapping by the > > > application, it was out-of-scope of draft-behave-nat-udp to > > talk about > > > applications. > > > That's why we didn't mention it. In a much earlier version of > > > the draft, > > > we > > > did talk about it and try to impose a "one packet refreshes all > > > mapping" policy. > > > > > > We eventually came to the conclusion that unfortunatelly it > > would be > > > impossible (we couldn't get everybody to agree). It is > > essentially a > > > consequence of allowing for all "filtering" behaviors (see REQ-9). > > > > > > Therefore, I believe you need to refresh all ndividual > > mappinga. This > > > particular statement is not made in the document because it is an > > > application issue. > > > > > > Hope this helps. > > > > > > > > > > > > > -----Original Message----- > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > > Matthews, Philip (Philip) > > > > Sent: Wednesday, December 21, 2005 08:29 > > > > To: Pyda Srisuresh > > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Subject: RE: [Ietf-behave] Question about > > > > draft-ietf-behave-nat-udp-04 in aP2P application > > > > > > > > > > > > Suresh: > > > > > > > > Thanks very much for replying with your pointer > > > > and reminding me about draft-ford-behave-app-01. > > > > > > > > I took a quick look through draft-ford-behave-app-01.txt and in > > > > addition to the text you quote below, I saw the following > > > > statement: > > > > > > > > BEHAVE-compliant NATs are required to support Address > > Restricted > > > > Cone NAT Behavior, which essentially resets the idle > > > timer for ALL > > > > sessions for a particular binding (i.e., involving a > particular > > > > private port) whenever outbound traffic is seen from > > that private > > > > port on ANY such session. > > > > > > > > What is the justification for this statement? > > > > > > > > That is, where in draft-ietf-behave-nat-udp-04 is a statement > > > > to this effect made? > > > > > > > > Given that draft-ford-behave-app-01 is not yet a WG document, I > > > > think it would be good to have some statement in > > > > draft-ietf-behave-nat-udp-04. > > > > > > > > - Philip > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > > > Sent: December 21, 2005 11:16 > > > > > To: Matthews, Philip (Philip) > > > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > Subject: Re: [Ietf-behave] Question about > > > > > draft-ietf-behave-nat-udp-04 in a P2P application > > > > > > > > > > Philip, > > > > > > > > > > The application design guideline draft, > > > > > has the following in > > section 3.1 to > > > > > address your question. Hope > > > this helps. > > > > > > > > > > REQ-6 Applications wishing to accept connections from > > other peers > > > > > after registering via UDP with one or more > > > rendezvous servers > > > > > MUST send periodic outgoing UDP "keep-alive" > > packets to at > > > > > least one rendezvous server, at least once within the > > > > > BEHAVE-compliant NAT UDP timeout (2 minutes). > > > > > > > > > > cheers, > > > > > suresh > > > > > > > > > > --- "Matthews, Philip (Philip)" wrote: > > > > > > > > > > > Francois and Cullen: > > > > > > > > > > > > I have a question about the behavior of a NAT "N" that is > > > > compliant > > > > > > with draft-ietf-behave-nat-udp-04. > > > > > > > > > > > > Say that NAT N implements the more stringent filtering > > > > behaviour of > > > > > > "Address dependent filtering" (REQ-8), and say that, > > > > despite this, I > > > > > > am trying to write a peer-to-peer application A which > > > is located > > > > > > behind NAT N and which maintains UDP connections with 20 > > > > other peers > > > > > > B,C,D,.... Application A uses the same address and > > port for all > > > > > > these > > > > > connections. > > > > > > > > > > > > To maintain the appropriate bindings in NAT "N", so that > > > > > application A > > > > > > can receive > > > > > > packets from each of these peers, must application A send a > > > > > UDP packet > > > > > > to all 20 peers B,C,D,... every 2 minutes, or can > > > > > application A send a > > > > > > UDP packet > > > > > > to just one of these peers every 2 minutes? > > > > > > > > > > > > (For simplicity, assume NAT "N" has a "NAT inbound refresh > > > > > behavior" of > > > > > > False). > > > > > > > > > > > > I am hoping, of course, that a packet every 2 minutes to > > > > > just ONE peer > > > > > > will be > > > > > > sufficient to maintain all these mappings. However, I > > > > cannot seem to > > > > > > find any words one way or another about this in the > > > > document. Am I > > > > > > missing something? > > > > > > > > > > > > - Philip > > > > > > > > > > > > _______________________________________________ > > > > > > Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > From audet@nortel.com Wed, 4 Jan 2006 13:37:47 -0800 (PST) From: "Francois Audet" Date: Wed, 4 Jan 2006 13:37:47 -0800 (PST) Subject: RE: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in aP2P application Message-ID: <1ECE0EB50388174790F9694F77522CCF05FB8431@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain The wording of REQ-8 reflects the agreement of IETF 63, and is what will be published. Please read the meeting report if not clear. > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > Sent: Wednesday, January 04, 2006 12:23 > To: Audet, Francois [SC100:9T51:EXCH]; Matthews, Philip > (Philip); Cullen Jennings > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] Question about > draft-ietf-behave-nat-udp-04 in aP2P application > > > > --- Francois Audet wrote: > > > REQ-8 (and REQ-1) of draft-ietf-behave-nat-udp-04 is what the BEHAVE > > group agreed-to, and supercedes what is said in behave-app > if there is > > a conflict. It does not mandate Address Restricted Cone NAT. > > > > So the statement you are refering to needs to be modified in the > > ford-behave draft. > > > > [suresh] You are right. REQ-8, as it stands, does not mandate > Address restricted Cone NAT. This need to be fixed. I.e., a > statement that says that NAT MUST enforce one of "Endpoint > independent filtering" behavior or "Address dependent > filtering" behavior should be added to the current REQ-8. As > I recall, there was a long discussion on whether to mandate > Address restricted Cone NAT (EF=A) or Full Cone NAT (EF=I). > But, I belive, everyone agreed it must be one of these two. > The final text missed this subtility and implies that a > minimally compliant NAT device doesnt have to be either of > the two. As it stands, even a NAT device with EF=P would be > behave compliant. That is not right. > > Below is how REQ-8 currently reads: > > REQ-8: If application transparency is most important, it is > RECOMMENDED that a NAT have an "Endpoint independent filtering" > behavior. If a more stringent filtering behavior is most > important, it is RECOMMENDED that a NAT have an > "Address dependent > filtering" behavior. > a) The filtering behavior MAY be an option configurable by the > administrator of the NAT. > > cheers, > suresh > > > > > > > > To answer your original question on refreshing the mapping by the > > application, it was out-of-scope of draft-behave-nat-udp to > talk about > > applications. That's why we didn't mention it. In a much earlier > > version of the draft, we > > did talk about it and try to impose a "one packet refreshes all > > mapping" policy. > > > > We eventually came to the conclusion that unfortunatelly it > would be > > impossible (we couldn't get everybody to agree). It is > essentially a > > consequence of allowing for all "filtering" behaviors (see REQ-9). > > > > Therefore, I believe you need to refresh all ndividual > mappinga. This > > particular statement is not made in the document because it is an > > application issue. > > > > Hope this helps. > > > > > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > Matthews, Philip (Philip) > > > Sent: Wednesday, December 21, 2005 08:29 > > > To: Pyda Srisuresh > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: RE: [Ietf-behave] Question about > > > draft-ietf-behave-nat-udp-04 in aP2P application > > > > > > > > > Suresh: > > > > > > Thanks very much for replying with your pointer > > > and reminding me about draft-ford-behave-app-01. > > > > > > I took a quick look through draft-ford-behave-app-01.txt and in > > > addition to the text you quote below, I saw the following > > > statement: > > > > > > BEHAVE-compliant NATs are required to support Address > Restricted > > > Cone NAT Behavior, which essentially resets the idle > timer for ALL > > > sessions for a particular binding (i.e., involving a particular > > > private port) whenever outbound traffic is seen from > that private > > > port on ANY such session. > > > > > > What is the justification for this statement? > > > > > > That is, where in draft-ietf-behave-nat-udp-04 is a statement > > > to this effect made? > > > > > > Given that draft-ford-behave-app-01 is not yet a WG document, I > > > think it would be good to have some statement in > > > draft-ietf-behave-nat-udp-04. > > > > > > - Philip > > > > > > > > > > -----Original Message----- > > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > > Sent: December 21, 2005 11:16 > > > > To: Matthews, Philip (Philip) > > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Subject: Re: [Ietf-behave] Question about > > > > draft-ietf-behave-nat-udp-04 in a P2P application > > > > > > > > Philip, > > > > > > > > The application design guideline draft, > > > > has the following in > section 3.1 to > > > > address your question. Hope this helps. > > > > > > > > REQ-6 Applications wishing to accept connections from > other peers > > > > after registering via UDP with one or more > rendezvous servers > > > > MUST send periodic outgoing UDP "keep-alive" > packets to at > > > > least one rendezvous server, at least once within the > > > > BEHAVE-compliant NAT UDP timeout (2 minutes). > > > > > > > > cheers, > > > > suresh > > > > > > > > --- "Matthews, Philip (Philip)" wrote: > > > > > > > > > Francois and Cullen: > > > > > > > > > > I have a question about the behavior of a NAT "N" that is > > > compliant > > > > > with draft-ietf-behave-nat-udp-04. > > > > > > > > > > Say that NAT N implements the more stringent filtering > > > behaviour of > > > > > "Address dependent filtering" (REQ-8), and say that, > > > despite this, I > > > > > am trying to write a peer-to-peer application A which > is located > > > > > behind NAT N and which maintains UDP connections with 20 > > > other peers > > > > > B,C,D,.... Application A uses the same address and > port for all > > > > > these > > > > connections. > > > > > > > > > > To maintain the appropriate bindings in NAT "N", so that > > > > application A > > > > > can receive > > > > > packets from each of these peers, must application A send a > > > > UDP packet > > > > > to all 20 peers B,C,D,... every 2 minutes, or can > > > > application A send a > > > > > UDP packet > > > > > to just one of these peers every 2 minutes? > > > > > > > > > > (For simplicity, assume NAT "N" has a "NAT inbound refresh > > > > behavior" of > > > > > False). > > > > > > > > > > I am hoping, of course, that a packet every 2 minutes to > > > > just ONE peer > > > > > will be > > > > > sufficient to maintain all these mappings. However, I > > > cannot seem to > > > > > find any words one way or another about this in the > > > document. Am I > > > > > missing something? > > > > > > > > > > - Philip > > > > > > > > > > _______________________________________________ > > > > > Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > From srisuresh@yahoo.com Wed, 4 Jan 2006 14:21:44 -0800 (PST) From: Pyda Srisuresh Date: Wed, 4 Jan 2006 14:21:44 -0800 (PST) Subject: RE: [Ietf-behave] Question about draft-ietf-behave-nat-udp-04 in aP2P application In-Reply-To: <1ECE0EB50388174790F9694F77522CCF05FB8431@zrc2hxm0.corp.nortel.com> Message-ID: <20060104222143.39978.qmail@web33310.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain I did read the IETF63 agreement and donot have a problem with that. I am refering to the implication from the wording of REQ-8 that a NAT device with a filtering behavior of EF=P is behave compliant. Question to the WG chairs and AD: Is the UDP rev 4 draft assumed to have been reviewed and approved by the WG and the IESG? cheers, suresh --- Francois Audet wrote: > The wording of REQ-8 reflects the agreement of IETF 63, and is what will > be published. > > Please read the meeting report if not clear. > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > Sent: Wednesday, January 04, 2006 12:23 > > To: Audet, Francois [SC100:9T51:EXCH]; Matthews, Philip > > (Philip); Cullen Jennings > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] Question about > > draft-ietf-behave-nat-udp-04 in aP2P application > > > > > > > > --- Francois Audet wrote: > > > > > REQ-8 (and REQ-1) of draft-ietf-behave-nat-udp-04 is what the BEHAVE > > > group agreed-to, and supercedes what is said in behave-app > > if there is > > > a conflict. It does not mandate Address Restricted Cone NAT. > > > > > > So the statement you are refering to needs to be modified in the > > > ford-behave draft. > > > > > > > [suresh] You are right. REQ-8, as it stands, does not mandate > > Address restricted Cone NAT. This need to be fixed. I.e., a > > statement that says that NAT MUST enforce one of "Endpoint > > independent filtering" behavior or "Address dependent > > filtering" behavior should be added to the current REQ-8. As > > I recall, there was a long discussion on whether to mandate > > Address restricted Cone NAT (EF=A) or Full Cone NAT (EF=I). > > But, I belive, everyone agreed it must be one of these two. > > The final text missed this subtility and implies that a > > minimally compliant NAT device doesnt have to be either of > > the two. As it stands, even a NAT device with EF=P would be > > behave compliant. That is not right. > > > > Below is how REQ-8 currently reads: > > > > REQ-8: If application transparency is most important, it is > > RECOMMENDED that a NAT have an "Endpoint independent filtering" > > behavior. If a more stringent filtering behavior is most > > important, it is RECOMMENDED that a NAT have an > > "Address dependent > > filtering" behavior. > > a) The filtering behavior MAY be an option configurable by the > > administrator of the NAT. > > > > cheers, > > suresh > > > > > > > > > > > > > To answer your original question on refreshing the mapping by the > > > application, it was out-of-scope of draft-behave-nat-udp to > > talk about > > > applications. That's why we didn't mention it. In a much earlier > > > version of the draft, we > > > did talk about it and try to impose a "one packet refreshes all > > > mapping" policy. > > > > > > We eventually came to the conclusion that unfortunatelly it > > would be > > > impossible (we couldn't get everybody to agree). It is > > essentially a > > > consequence of allowing for all "filtering" behaviors (see REQ-9). > > > > > > Therefore, I believe you need to refresh all ndividual > > mappinga. This > > > particular statement is not made in the document because it is an > > > application issue. > > > > > > Hope this helps. > > > > > > > > > > > > > -----Original Message----- > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > > Matthews, Philip (Philip) > > > > Sent: Wednesday, December 21, 2005 08:29 > > > > To: Pyda Srisuresh > > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Subject: RE: [Ietf-behave] Question about > > > > draft-ietf-behave-nat-udp-04 in aP2P application > > > > > > > > > > > > Suresh: > > > > > > > > Thanks very much for replying with your pointer > > > > and reminding me about draft-ford-behave-app-01. > > > > > > > > I took a quick look through draft-ford-behave-app-01.txt and in > > > > addition to the text you quote below, I saw the following > > > > statement: > > > > > > > > BEHAVE-compliant NATs are required to support Address > > Restricted > > > > Cone NAT Behavior, which essentially resets the idle > > timer for ALL > > > > sessions for a particular binding (i.e., involving a particular > > > > private port) whenever outbound traffic is seen from > > that private > > > > port on ANY such session. > > > > > > > > What is the justification for this statement? > > > > > > > > That is, where in draft-ietf-behave-nat-udp-04 is a statement > > > > to this effect made? > > > > > > > > Given that draft-ford-behave-app-01 is not yet a WG document, I > > > > think it would be good to have some statement in > > > > draft-ietf-behave-nat-udp-04. > > > > > > > > - Philip > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > > > Sent: December 21, 2005 11:16 > > > > > To: Matthews, Philip (Philip) > > > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > Subject: Re: [Ietf-behave] Question about > > > > > draft-ietf-behave-nat-udp-04 in a P2P application > > > > > > > > > > Philip, > > > > > > > > > > The application design guideline draft, > > > > > has the following in > > section 3.1 to > > > > > address your question. Hope this helps. > > > > > > > > > > REQ-6 Applications wishing to accept connections from > > other peers > > > > > after registering via UDP with one or more > > rendezvous servers > > > > > MUST send periodic outgoing UDP "keep-alive" > > packets to at > > > > > least one rendezvous server, at least once within the > > > > > BEHAVE-compliant NAT UDP timeout (2 minutes). > > > > > > > > > > cheers, > > > > > suresh > > > > > > > > > > --- "Matthews, Philip (Philip)" wrote: > > > > > > > > > > > Francois and Cullen: > > > > > > > > > > > > I have a question about the behavior of a NAT "N" that is > > > > compliant > > > > > > with draft-ietf-behave-nat-udp-04. > > > > > > > > > > > > Say that NAT N implements the more stringent filtering > > > > behaviour of > > > > > > "Address dependent filtering" (REQ-8), and say that, > > > > despite this, I > > > > > > am trying to write a peer-to-peer application A which > > is located > > > > > > behind NAT N and which maintains UDP connections with 20 > > > > other peers > > > > > > B,C,D,.... Application A uses the same address and > > port for all > > > > > > these > > > > > connections. > > > > > > > > > > > > To maintain the appropriate bindings in NAT "N", so that > > > > > application A > > > > > > can receive > > > > > > packets from each of these peers, must application A send a > > > > > UDP packet > > > > > > to all 20 peers B,C,D,... every 2 minutes, or can > > > > > application A send a > > > > > > UDP packet > > > > > > to just one of these peers every 2 minutes? > > > > > > > > > > > > (For simplicity, assume NAT "N" has a "NAT inbound refresh > > > > > behavior" of > > > > > > False). > > > > > > > > > > > > I am hoping, of course, that a packet every 2 minutes to > > > > > just ONE peer > > > > > > will be > > > > > > sufficient to maintain all these mappings. However, I > > > > cannot seem to > > > > > > find any words one way or another about this in the > > > > document. Am I > > > > > > missing something? > > > > > > > > > > > > - Philip > > > > > > > > > > > > _______________________________________________ > > > > > > Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > > > > > From fluffy@cisco.com Fri, 13 Jan 2006 11:45:03 -0800 (PST) From: Cullen Jennings Date: Fri, 13 Jan 2006 11:45:03 -0800 (PST) Subject: Re: [Ietf-behave] Idealized UDP/TCP port bindings In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB010BB500@xmb-sjc-236.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I agree with Pyda and Senthil here - I think UPD ports are a separate space from TCP ports and should not be related. As a side note, I have heard about a NAT that actually does this but most don't. On 12/22/05 8:22 AM, "Senthil Sivakumar (ssenthil)" wrote: > The port space for TCP and UDP are not shared from a NAT's perspective > and I don't think there is any advantage of preserving the port mapping > between the protocols. Also, if there are applications that require this > then it would the Application Layer gateways that would be required to > preserve the same port for both TCP and UDP. > > Senthil > >> -----Original Message----- >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of >> Dave Hudson >> Sent: Wednesday, December 21, 2005 7:16 AM >> To: ietf-behave@xxxxxxxxxxxxxxxxxxx >> Subject: [Ietf-behave] Idealized UDP/TCP port bindings >> >> I can't recall having seen any discussion of this so I >> thought I'd ask the question... >> >> If I have a port mapping within a NAT where private address >> and port A:P maps to a public address and port A':P' is there >> any advantage to having the mapping of P -> P' be the same >> for both UDP and TCP? (e.g. if I have an private port 12345 >> which maps to a public port 9977 for UDP does it help if >> 12345 also maps to 9977 for TCP as opposed to some other >> mapping, say, 11111?). I'm assuming here that the NAT >> exhibits endpoint independent mapping. >> >> >> Thanks, >> Dave >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From karlheinz.wurm@skype.net Wed, 25 Jan 2006 08:04:01 -0800 (PST) From: Karlheinz Wurm Date: Wed, 25 Jan 2006 08:04:01 -0800 (PST) Subject: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 In-Reply-To: Message-ID: <43D7A156.7050805@skype.net> MIME-Version: 1.0 Content-Type: text/plain Hi everyone, Since I recently got confronted with the following behavior, i think one definition is missing at point 4.1 ... The following address and port mapping behavior are defined: ... I would call it a Port Dependent Mapping which means: +------+ +------+ x | Y1 | | Y2 | t +--+---+ +---+--+ e | Y1:y1 Y2:y2 | r +----------+ +----------+ n | | a X1':x1' | | X2':x2' l +--+---+-+ ...........| NAT |............... +--+---+-+ I | | n X:x | | X:x t ++---++ e | X | r +-----+ n a Port Dependent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external Port address, regardless of the external IP. Specifically, X1':x1' equals X2':x2' if, and only if, y2 equals y1. Kind regards, -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 48 166 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. begin:vcard fn:Karlheinz Wurm n:Wurm;Karlheinz email;internet:karlheinz.wurm@xxxxxxxxx tel;work:+1 (415) 508-3653 tel;cell:+372 536 369 75 x-mozilla-html:FALSE version:2.1 end:vcard From audet@nortel.com Wed, 25 Jan 2006 20:29:08 -0800 (PST) From: "Francois Audet" Date: Wed, 25 Jan 2006 20:29:08 -0800 (PST) Subject: RE: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Message-ID: <1ECE0EB50388174790F9694F77522CCF0653860D@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain You mean when Y1 and Y2 are different???? Have you seen a NAT that actually does this? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Karlheinz Wurm > Sent: Wednesday, January 25, 2006 08:04 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] missing defintion in > draft-ietf-behave-nat-udp-04 > > > Hi everyone, > > Since I recently got confronted with the following behavior, > i think one > definition is missing at point 4.1 ... The following address > and port > mapping behavior are defined: ... > > > I would call it a Port Dependent Mapping which means: > > +------+ +------+ x > | Y1 | | Y2 | t > +--+---+ +---+--+ e > | Y1:y1 Y2:y2 | r > +----------+ +----------+ n > | | a > X1':x1' | | X2':x2' l > +--+---+-+ > ...........| NAT |............... > +--+---+-+ I > | | n > X:x | | X:x t > ++---++ e > | X | r > +-----+ n > a > > Port Dependent Mapping: > The NAT reuses the port mapping for subsequent packets sent > from the same internal IP address and port (X:x) to the same > external Port address, regardless of the external IP. > Specifically, X1':x1' equals X2':x2' if, and only > if, y2 equals > y1. > > > Kind regards, > > -- > Karlheinz Wurm, > Skype Technologies S.A. > > callto://wurm > +372 536 48 166 > > Get Skype from http://www.skype.net > We're hiring http://www.skype.net/company/jobs > -- > This electronic transmission and any attached files are > solely for the intended recipient and may contain information > that is privileged, confidential or otherwise protected from > disclosure. Any review, retransmission, dissemination or > other use, including taking any action concerning this > information by anyone other than the intended recipient, is > prohibited. If you are not the intended recipient or have > received this communication in error, please immediately > notify the sender and destroy this communication. > From saikat@cs.cornell.edu Wed, 25 Jan 2006 20:47:49 -0800 (PST) From: Saikat Guha Date: Wed, 25 Jan 2006 20:47:49 -0800 (PST) Subject: RE: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0653860D@zrc2hxm0.corp.nortel.com> Message-ID: <1138250886.22006.2.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630135.multipart/signed" --Boundary..27398.1163630135.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-01-25 at 22:28 -0600, Francois Audet wrote: > You mean when Y1 and Y2 are different???? > > Have you seen a NAT that actually does this? I have seen this sort of binding behavior for TCP (couple of Belkin and Westell NATs). Actually, I vaguely remember an old version of the UDP draft defining this sort of behavior as Port Dependent ... or NB=P or something like that. -- Saikat Attachment: signature.asc --Boundary..27398.1163630135.multipart/signed Content-Type: application/octet-stream; name="pgp00093.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00093.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFCRDJGU0ZuRmx0cWk2OTEvb1JBa0piQUp3TUJWekJsamluZFFOajZLeUVy QzMrVm1NQStnQ2JCWm05CndvQWhNVCtxUTgzV3RxaTJwRGFsZVRnPQo9dTFscAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630135.multipart/signed-- From karlheinz.wurm@skype.net Thu, 26 Jan 2006 00:07:11 -0800 (PST) From: Karlheinz Wurm Date: Thu, 26 Jan 2006 00:07:11 -0800 (PST) Subject: Re: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0653860D@zrc2hxm0.corp.nortel.com> Message-ID: <43D88325.9060400@skype.net> MIME-Version: 1.0 Content-Type: text/plain Francois Audet wrote: You mean when Y1 and Y2 are different???? Y1 and Y2 are different but y1 and y2 are the same. Than the NAT will bind it to the same external port. e.g. Local RemoteAddress External NAT address X:x Y1:1925 X1':33394 X:x Y2:1925 X1':33394 X:x Y3:34575 X1':32781 X:x Y4:5986 X1':33625 And the worse is that the external port binding is completely random. Have you seen a NAT that actually does this? Yes, i am just looking in one of this router. That's why i am missing that definition. I don't want to name the model since we are in business relation with them but it is the latest model of one of the very biggest router vendors and widely distributed. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Karlheinz Wurm Sent: Wednesday, January 25, 2006 08:04 To: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Hi everyone, Since I recently got confronted with the following behavior, i think one definition is missing at point 4.1 ... The following address and port mapping behavior are defined: ... I would call it a Port Dependent Mapping which means: +------+ +------+ x | Y1 | | Y2 | t +--+---+ +---+--+ e | Y1:y1 Y2:y2 | r +----------+ +----------+ n | | a X1':x1' | | X2':x2' l +--+---+-+ ...........| NAT |............... +--+---+-+ I | | n X:x | | X:x t ++---++ e | X | r +-----+ n a Port Dependent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external Port address, regardless of the external IP. Specifically, X1':x1' equals X2':x2' if, and only if, y2 equals y1. Kind regards, -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 48 166 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 48 166 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. begin:vcard fn:Karlheinz Wurm n:Wurm;Karlheinz email;internet:karlheinz.wurm@xxxxxxxxx tel;work:+1 (415) 508-3653 tel;cell:+372 536 369 75 x-mozilla-html:FALSE version:2.1 end:vcard From audet@nortel.com Thu, 26 Jan 2006 08:34:21 -0800 (PST) From: "Francois Audet" Date: Thu, 26 Jan 2006 08:34:21 -0800 (PST) Subject: RE: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Message-ID: <1ECE0EB50388174790F9694F77522CCF065389B9@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Hum, that would be very broken... It continues to amaze me that every possible broken scenario theoretically possible seems to be implemented somewhere by someone... This is essentially covered by the "Address and Port dependent mapping", but is a special case of where y1 and y2 are the same. Do you agree, or do you think it justifies having a special case? Either way, it is a "bad NAT"... > -----Original Message----- > From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] > Sent: Thursday, January 26, 2006 00:07 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] missing defintion in > draft-ietf-behave-nat-udp-04 > > > Francois Audet wrote: > > You mean when Y1 and Y2 are different???? > > > > Y1 and Y2 are different but y1 and y2 are the same. Than the NAT will > bind it to the same external port. > > e.g. > > Local RemoteAddress External NAT address > X:x Y1:1925 X1':33394 > X:x Y2:1925 X1':33394 > X:x Y3:34575 X1':32781 > X:x Y4:5986 X1':33625 > > And the worse is that the external port binding is completely random. > > > Have you seen a NAT that actually does this? > > > > Yes, i am just looking in one of this router. That's why i am missing > that definition. I don't want to name the model since we are > in business > relation with them but it is the latest model of one of the > very biggest > router vendors and widely distributed. > > > >> -----Original Message----- > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > >> Karlheinz Wurm > >> Sent: Wednesday, January 25, 2006 08:04 > >> To: ietf-behave@xxxxxxxxxxxxxxxxxxx > >> Subject: [Ietf-behave] missing defintion in > >> draft-ietf-behave-nat-udp-04 > >> > >> > >> Hi everyone, > >> > >> Since I recently got confronted with the following behavior, > >> i think one > >> definition is missing at point 4.1 ... The following address > >> and port > >> mapping behavior are defined: ... > >> > >> > >> I would call it a Port Dependent Mapping which means: > >> > >> +------+ +------+ x > >> | Y1 | | Y2 | t > >> +--+---+ +---+--+ e > >> | Y1:y1 Y2:y2 | r > >> +----------+ +----------+ n > >> | | a > >> X1':x1' | | X2':x2' l > >> +--+---+-+ > >> ...........| NAT |............... > >> +--+---+-+ I > >> | | n > >> X:x | | X:x t > >> ++---++ e > >> | X | r > >> +-----+ n > >> a > >> > >> Port Dependent Mapping: > >> The NAT reuses the port mapping for subsequent > packets sent > >> from the same internal IP address and port (X:x) > to the same > >> external Port address, regardless of the external IP. > >> Specifically, X1':x1' equals X2':x2' if, and only > >> if, y2 equals > >> y1. > >> > >> > >> Kind regards, > >> > >> -- > >> Karlheinz Wurm, > >> Skype Technologies S.A. > >> > >> callto://wurm > >> +372 536 48 166 > >> > >> Get Skype from http://www.skype.net > >> We're hiring http://www.skype.net/company/jobs > >> -- > >> This electronic transmission and any attached files are > >> solely for the intended recipient and may contain information > >> that is privileged, confidential or otherwise protected from > >> disclosure. Any review, retransmission, dissemination or > >> other use, including taking any action concerning this > >> information by anyone other than the intended recipient, is > >> prohibited. If you are not the intended recipient or have > >> received this communication in error, please immediately > >> notify the sender and destroy this communication. > >> > > -- > Karlheinz Wurm, > Skype Technologies S.A. > > callto://wurm > +372 536 48 166 > > Get Skype from http://www.skype.net > We're hiring http://www.skype.net/company/jobs > -- > This electronic transmission and any attached files are solely for the > intended recipient and may contain information that is privileged, > confidential or otherwise protected from disclosure. Any review, > retransmission, dissemination or other use, including taking any > action concerning this information by anyone other than the intended > recipient, is prohibited. If you are not the intended recipient or > have received this communication in error, please immediately notify > the sender and destroy this communication. > From kbiswas@cisco.com Thu, 26 Jan 2006 14:34:16 -0800 (PST) From: "Kaushik Biswas (kbiswas)" Date: Thu, 26 Jan 2006 14:34:16 -0800 (PST) Subject: RE: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Message-ID: <378E78E5F361564BB066432F6415764B013E1B96@xmb-sjc-228.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain My suggestion would be include this along with "Port overloading" discussion of Section 4.2.1. Yes this is a "bad NAT" no doubt. Thanks, Kaushik > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Francois Audet > Sent: Thursday, January 26, 2006 8:34 AM > To: Karlheinz Wurm > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] missing defintion in > draft-ietf-behave-nat-udp-04 > > Hum, that would be very broken... > > It continues to amaze me that every possible broken scenario > theoretically possible seems to be implemented somewhere by someone... > > This is essentially covered by the "Address and Port > dependent mapping", but is a special case of where y1 and y2 > are the same. > > Do you agree, or do you think it justifies having a special > case? Either way, it is a "bad NAT"... > > > -----Original Message----- > > From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] > > Sent: Thursday, January 26, 2006 00:07 > > To: Audet, Francois [SC100:9T51:EXCH] > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Ietf-behave] missing defintion in > > draft-ietf-behave-nat-udp-04 > > > > > > Francois Audet wrote: > > > You mean when Y1 and Y2 are different???? > > > > > > > Y1 and Y2 are different but y1 and y2 are the same. Than > the NAT will > > bind it to the same external port. > > > > e.g. > > > > Local RemoteAddress External NAT address > > X:x Y1:1925 X1':33394 > > X:x Y2:1925 X1':33394 > > X:x Y3:34575 X1':32781 > > X:x Y4:5986 X1':33625 > > > > And the worse is that the external port binding is > completely random. > > > > > Have you seen a NAT that actually does this? > > > > > > > Yes, i am just looking in one of this router. That's why i > am missing > > that definition. I don't want to name the model since we are in > > business relation with them but it is the latest model of > one of the > > very biggest router vendors and widely distributed. > > > > > > >> -----Original Message----- > > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > >> Karlheinz Wurm > > >> Sent: Wednesday, January 25, 2006 08:04 > > >> To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > >> Subject: [Ietf-behave] missing defintion in > > >> draft-ietf-behave-nat-udp-04 > > >> > > >> > > >> Hi everyone, > > >> > > >> Since I recently got confronted with the following behavior, i > > >> think one definition is missing at point 4.1 ... The following > > >> address and port mapping behavior are defined: ... > > >> > > >> > > >> I would call it a Port Dependent Mapping which means: > > >> > > >> +------+ +------+ x > > >> | Y1 | | Y2 | t > > >> +--+---+ +---+--+ e > > >> | Y1:y1 Y2:y2 | r > > >> +----------+ +----------+ n > > >> | | a > > >> X1':x1' | | X2':x2' l > > >> +--+---+-+ > > >> ...........| NAT |............... > > >> +--+---+-+ I > > >> | | n > > >> X:x | | X:x t > > >> ++---++ e > > >> | X | r > > >> +-----+ n > > >> a > > >> > > >> Port Dependent Mapping: > > >> The NAT reuses the port mapping for subsequent > > packets sent > > >> from the same internal IP address and port (X:x) > > to the same > > >> external Port address, regardless of the external IP. > > >> Specifically, X1':x1' equals X2':x2' if, and > only if, y2 > > >> equals > > >> y1. > > >> > > >> > > >> Kind regards, > > >> > > >> -- > > >> Karlheinz Wurm, > > >> Skype Technologies S.A. > > >> > > >> callto://wurm > > >> +372 536 48 166 > > >> > > >> Get Skype from http://www.skype.net We're hiring > > >> http://www.skype.net/company/jobs > > >> -- > > >> This electronic transmission and any attached files are > solely for > > >> the intended recipient and may contain information that is > > >> privileged, confidential or otherwise protected from disclosure. > > >> Any review, retransmission, dissemination or other use, > including > > >> taking any action concerning this information by anyone > other than > > >> the intended recipient, is prohibited. If you are not > the intended > > >> recipient or have received this communication in error, please > > >> immediately notify the sender and destroy this communication. > > >> > > > > -- > > Karlheinz Wurm, > > Skype Technologies S.A. > > > > callto://wurm > > +372 536 48 166 > > > > Get Skype from http://www.skype.net > > We're hiring http://www.skype.net/company/jobs > > -- > > This electronic transmission and any attached files are > solely for the > > intended recipient and may contain information that is privileged, > > confidential or otherwise protected from disclosure. Any review, > > retransmission, dissemination or other use, including taking any > > action concerning this information by anyone other than the > intended > > recipient, is prohibited. If you are not the intended recipient or > > have received this communication in error, please > immediately notify > > the sender and destroy this communication. > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From audet@nortel.com Thu, 26 Jan 2006 14:38:32 -0800 (PST) From: "Francois Audet" Date: Thu, 26 Jan 2006 14:38:32 -0800 (PST) Subject: RE: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Message-ID: <1ECE0EB50388174790F9694F77522CCF06539277@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Guys, The document is finished. In is awaiting publication. If there is ever a revision to it, we can look for minor clarifications like this to be added, but in the meanwhile, it will stay as is... > -----Original Message----- > From: Kaushik Biswas (kbiswas) [mailto:kbiswas@xxxxxxxxx] > Sent: Thursday, January 26, 2006 14:34 > To: Audet, Francois [SC100:9T51:EXCH]; Karlheinz Wurm > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] missing defintion in > draft-ietf-behave-nat-udp-04 > > > My suggestion would be include this along with "Port > overloading" discussion of Section 4.2.1. Yes this is a "bad > NAT" no doubt. > > Thanks, > Kaushik > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Francois Audet > > Sent: Thursday, January 26, 2006 8:34 AM > > To: Karlheinz Wurm > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] missing defintion in > > draft-ietf-behave-nat-udp-04 > > > > Hum, that would be very broken... > > > > It continues to amaze me that every possible broken scenario > > theoretically possible seems to be implemented somewhere by > someone... > > > > This is essentially covered by the "Address and Port > > dependent mapping", but is a special case of where y1 and y2 > > are the same. > > > > Do you agree, or do you think it justifies having a special > > case? Either way, it is a "bad NAT"... > > > > > -----Original Message----- > > > From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] > > > Sent: Thursday, January 26, 2006 00:07 > > > To: Audet, Francois [SC100:9T51:EXCH] > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: Re: [Ietf-behave] missing defintion in > > > draft-ietf-behave-nat-udp-04 > > > > > > > > > Francois Audet wrote: > > > > You mean when Y1 and Y2 are different???? > > > > > > > > > > Y1 and Y2 are different but y1 and y2 are the same. Than > > the NAT will > > > bind it to the same external port. > > > > > > e.g. > > > > > > Local RemoteAddress External NAT address > > > X:x Y1:1925 X1':33394 > > > X:x Y2:1925 X1':33394 > > > X:x Y3:34575 X1':32781 > > > X:x Y4:5986 X1':33625 > > > > > > And the worse is that the external port binding is > > completely random. > > > > > > > Have you seen a NAT that actually does this? > > > > > > > > > > Yes, i am just looking in one of this router. That's why i > > am missing > > > that definition. I don't want to name the model since we are in > > > business relation with them but it is the latest model of > > one of the > > > very biggest router vendors and widely distributed. > > > > > > > > > >> -----Original Message----- > > > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > >> Karlheinz Wurm > > > >> Sent: Wednesday, January 25, 2006 08:04 > > > >> To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > >> Subject: [Ietf-behave] missing defintion in > > > >> draft-ietf-behave-nat-udp-04 > > > >> > > > >> > > > >> Hi everyone, > > > >> > > > >> Since I recently got confronted with the following behavior, i > > > >> think one definition is missing at point 4.1 ... The > following > > > >> address and port mapping behavior are defined: ... > > > >> > > > >> > > > >> I would call it a Port Dependent Mapping which means: > > > >> > > > >> +------+ +------+ x > > > >> | Y1 | | Y2 | t > > > >> +--+---+ +---+--+ e > > > >> | Y1:y1 Y2:y2 | r > > > >> +----------+ +----------+ n > > > >> | | a > > > >> X1':x1' | | X2':x2' l > > > >> +--+---+-+ > > > >> ...........| NAT |............... > > > >> +--+---+-+ I > > > >> | | n > > > >> X:x | | X:x t > > > >> ++---++ e > > > >> | X | r > > > >> +-----+ n > > > >> a > > > >> > > > >> Port Dependent Mapping: > > > >> The NAT reuses the port mapping for subsequent > > > packets sent > > > >> from the same internal IP address and port (X:x) > > > to the same > > > >> external Port address, regardless of the external IP. > > > >> Specifically, X1':x1' equals X2':x2' if, and > > only if, y2 > > > >> equals > > > >> y1. > > > >> > > > >> > > > >> Kind regards, > > > >> > > > >> -- > > > >> Karlheinz Wurm, > > > >> Skype Technologies S.A. > > > >> > > > >> callto://wurm > > > >> +372 536 48 166 > > > >> > > > >> Get Skype from http://www.skype.net We're hiring > > > >> http://www.skype.net/company/jobs > > > >> -- > > > >> This electronic transmission and any attached files are > > solely for > > > >> the intended recipient and may contain information that is > > > >> privileged, confidential or otherwise protected from > disclosure. > > > >> Any review, retransmission, dissemination or other use, > > including > > > >> taking any action concerning this information by anyone > > other than > > > >> the intended recipient, is prohibited. If you are not > > the intended > > > >> recipient or have received this communication in error, please > > > >> immediately notify the sender and destroy this communication. > > > >> > > > > > > -- > > > Karlheinz Wurm, > > > Skype Technologies S.A. > > > > > > callto://wurm > > > +372 536 48 166 > > > > > > Get Skype from http://www.skype.net > > > We're hiring http://www.skype.net/company/jobs > > > -- > > > This electronic transmission and any attached files are > > solely for the > > > intended recipient and may contain information that is privileged, > > > confidential or otherwise protected from disclosure. Any review, > > > retransmission, dissemination or other use, including taking any > > > action concerning this information by anyone other than the > > intended > > > recipient, is prohibited. If you are not the intended recipient or > > > have received this communication in error, please > > immediately notify > > > the sender and destroy this communication. > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > From karlheinz.wurm@skype.net Fri, 27 Jan 2006 00:37:47 -0800 (PST) From: Karlheinz Wurm Date: Fri, 27 Jan 2006 00:37:47 -0800 (PST) Subject: Re: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF06539277@zrc2hxm0.corp.nortel.com> Message-ID: <43D9DBD2.1040503@skype.net> MIME-Version: 1.0 Content-Type: text/plain btw., there is also a typo in Address and Port Dependent Mapping. its written ...(X:x) to the same external and port while ... I am not native English speaker but i thought there is a "IP" missing like ...(X:x) to the same external IP and port while ... Thanks, Karlheinz Francois Audet wrote: Guys, The document is finished. In is awaiting publication. If there is ever a revision to it, we can look for minor clarifications like this to be added, but in the meanwhile, it will stay as is... -----Original Message----- From: Kaushik Biswas (kbiswas) [mailto:kbiswas@xxxxxxxxx] Sent: Thursday, January 26, 2006 14:34 To: Audet, Francois [SC100:9T51:EXCH]; Karlheinz Wurm Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 My suggestion would be include this along with "Port overloading" discussion of Section 4.2.1. Yes this is a "bad NAT" no doubt. Thanks, Kaushik -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Francois Audet Sent: Thursday, January 26, 2006 8:34 AM To: Karlheinz Wurm Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Hum, that would be very broken... It continues to amaze me that every possible broken scenario theoretically possible seems to be implemented somewhere by someone... This is essentially covered by the "Address and Port dependent mapping", but is a special case of where y1 and y2 are the same. Do you agree, or do you think it justifies having a special case? Either way, it is a "bad NAT"... -----Original Message----- From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] Sent: Thursday, January 26, 2006 00:07 To: Audet, Francois [SC100:9T51:EXCH] Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Francois Audet wrote: You mean when Y1 and Y2 are different???? Y1 and Y2 are different but y1 and y2 are the same. Than the NAT will bind it to the same external port. e.g. Local RemoteAddress External NAT address X:x Y1:1925 X1':33394 X:x Y2:1925 X1':33394 X:x Y3:34575 X1':32781 X:x Y4:5986 X1':33625 And the worse is that the external port binding is completely random. Have you seen a NAT that actually does this? Yes, i am just looking in one of this router. That's why i am missing that definition. I don't want to name the model since we are in business relation with them but it is the latest model of one of the very biggest router vendors and widely distributed. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Karlheinz Wurm Sent: Wednesday, January 25, 2006 08:04 To: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Hi everyone, Since I recently got confronted with the following behavior, i think one definition is missing at point 4.1 ... The following address and port mapping behavior are defined: ... I would call it a Port Dependent Mapping which means: +------+ +------+ x | Y1 | | Y2 | t +--+---+ +---+--+ e | Y1:y1 Y2:y2 | r +----------+ +----------+ n | | a X1':x1' | | X2':x2' l +--+---+-+ ...........| NAT |............... +--+---+-+ I | | n X:x | | X:x t ++---++ e | X | r +-----+ n a Port Dependent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external Port address, regardless of the external IP. Specifically, X1':x1' equals X2':x2' if, and only if, y2 equals y1. Kind regards, -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 48 166 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 48 166 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 48 166 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. begin:vcard fn:Karlheinz Wurm n:Wurm;Karlheinz email;internet:karlheinz.wurm@xxxxxxxxx tel;work:+1 (415) 508-3653 tel;cell:+372 536 369 75 x-mozilla-html:FALSE version:2.1 end:vcard From audet@nortel.com Fri, 27 Jan 2006 10:05:26 -0800 (PST) From: "Francois Audet" Date: Fri, 27 Jan 2006 10:05:26 -0800 (PST) Subject: RE: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Message-ID: <1ECE0EB50388174790F9694F77522CCF0658DF18@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Thanks, we will make that editorial correction in Author's 48 hours. > -----Original Message----- > From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] > Sent: Friday, January 27, 2006 00:38 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: Kaushik Biswas (kbiswas); ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] missing defintion in > draft-ietf-behave-nat-udp-04 > > > btw., there is also a typo in Address and Port Dependent Mapping. > > its written > > ...(X:x) to the same external and port while ... > > I am not native English speaker but i thought there is a "IP" > missing like > > ...(X:x) to the same external IP and port while ... > > Thanks, > > Karlheinz > > > Francois Audet wrote: > > Guys, > > > > The document is finished. In is awaiting publication. > > > > If there is ever a revision to it, we can look for minor > > clarifications like this to be added, but in the meanwhile, it > > will stay as is... > > > >> -----Original Message----- > >> From: Kaushik Biswas (kbiswas) [mailto:kbiswas@xxxxxxxxx] > >> Sent: Thursday, January 26, 2006 14:34 > >> To: Audet, Francois [SC100:9T51:EXCH]; Karlheinz Wurm > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >> Subject: RE: [Ietf-behave] missing defintion in > >> draft-ietf-behave-nat-udp-04 > >> > >> > >> My suggestion would be include this along with "Port > >> overloading" discussion of Section 4.2.1. Yes this is a "bad > >> NAT" no doubt. > >> > >> Thanks, > >> Kaushik > >> > >>> -----Original Message----- > >>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > >>> Francois Audet > >>> Sent: Thursday, January 26, 2006 8:34 AM > >>> To: Karlheinz Wurm > >>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> Subject: RE: [Ietf-behave] missing defintion in > >>> draft-ietf-behave-nat-udp-04 > >>> > >>> Hum, that would be very broken... > >>> > >>> It continues to amaze me that every possible broken scenario > >>> theoretically possible seems to be implemented somewhere by > >> someone... > >>> This is essentially covered by the "Address and Port dependent > >>> mapping", but is a special case of where y1 and y2 are the same. > >>> > >>> Do you agree, or do you think it justifies having a special case? > >>> Either way, it is a "bad NAT"... > >>> > >>>> -----Original Message----- > >>>> From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] > >>>> Sent: Thursday, January 26, 2006 00:07 > >>>> To: Audet, Francois [SC100:9T51:EXCH] > >>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>> Subject: Re: [Ietf-behave] missing defintion in > >>>> draft-ietf-behave-nat-udp-04 > >>>> > >>>> > >>>> Francois Audet wrote: > >>>>> You mean when Y1 and Y2 are different???? > >>>>> > >>>> Y1 and Y2 are different but y1 and y2 are the same. Than > >>> the NAT will > >>>> bind it to the same external port. > >>>> > >>>> e.g. > >>>> > >>>> Local RemoteAddress External NAT address > >>>> X:x Y1:1925 X1':33394 > >>>> X:x Y2:1925 X1':33394 > >>>> X:x Y3:34575 X1':32781 > >>>> X:x Y4:5986 X1':33625 > >>>> > >>>> And the worse is that the external port binding is > >>> completely random. > >>>>> Have you seen a NAT that actually does this? > >>>>> > >>>> Yes, i am just looking in one of this router. That's why i > >>> am missing > >>>> that definition. I don't want to name the model since we are in > >>>> business relation with them but it is the latest model of > >>> one of the > >>>> very biggest router vendors and widely distributed. > >>>> > >>>> > >>>>>> -----Original Message----- > >>>>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > >>>>>> Karlheinz Wurm > >>>>>> Sent: Wednesday, January 25, 2006 08:04 > >>>>>> To: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>> Subject: [Ietf-behave] missing defintion in > >>>>>> draft-ietf-behave-nat-udp-04 > >>>>>> > >>>>>> > >>>>>> Hi everyone, > >>>>>> > >>>>>> Since I recently got confronted with the following behavior, i > >>>>>> think one definition is missing at point 4.1 ... The > >> following > >>>>>> address and port mapping behavior are defined: ... > >>>>>> > >>>>>> > >>>>>> I would call it a Port Dependent Mapping which means: > >>>>>> > >>>>>> +------+ +------+ x > >>>>>> | Y1 | | Y2 | t > >>>>>> +--+---+ +---+--+ e > >>>>>> | Y1:y1 Y2:y2 | r > >>>>>> +----------+ +----------+ n > >>>>>> | | a > >>>>>> X1':x1' | | X2':x2' l > >>>>>> +--+---+-+ > >>>>>> ...........| NAT |............... > >>>>>> +--+---+-+ I > >>>>>> | | n > >>>>>> X:x | | X:x t > >>>>>> ++---++ e > >>>>>> | X | r > >>>>>> +-----+ n > >>>>>> a > >>>>>> > >>>>>> Port Dependent Mapping: > >>>>>> The NAT reuses the port mapping for subsequent > >>>> packets sent > >>>>>> from the same internal IP address and port (X:x) > >>>> to the same > >>>>>> external Port address, regardless of the external IP. > >>>>>> Specifically, X1':x1' equals X2':x2' if, and > >>> only if, y2 > >>>>>> equals > >>>>>> y1. > >>>>>> > >>>>>> > >>>>>> Kind regards, > >>>>>> > >>>>>> -- > >>>>>> Karlheinz Wurm, > >>>>>> Skype Technologies S.A. > >>>>>> > >>>>>> callto://wurm > >>>>>> +372 536 48 166 > >>>>>> > >>>>>> Get Skype from http://www.skype.net We're hiring > >>>>>> http://www.skype.net/company/jobs > >>>>>> -- > >>>>>> This electronic transmission and any attached files are > >>> solely for > >>>>>> the intended recipient and may contain information that is > >>>>>> privileged, confidential or otherwise protected from > >> disclosure. > >>>>>> Any review, retransmission, dissemination or other use, > >>> including > >>>>>> taking any action concerning this information by anyone > >>> other than > >>>>>> the intended recipient, is prohibited. If you are not > >>> the intended > >>>>>> recipient or have received this communication in error, please > >>>>>> immediately notify the sender and destroy this communication. > >>>>>> > >>>> -- > >>>> Karlheinz Wurm, > >>>> Skype Technologies S.A. > >>>> > >>>> callto://wurm > >>>> +372 536 48 166 > >>>> > >>>> Get Skype from http://www.skype.net > >>>> We're hiring http://www.skype.net/company/jobs > >>>> -- > >>>> This electronic transmission and any attached files are > >>> solely for the > >>>> intended recipient and may contain information that is > privileged, > >>>> confidential or otherwise protected from disclosure. Any review, > >>>> retransmission, dissemination or other use, including taking any > >>>> action concerning this information by anyone other than the > >>> intended > >>>> recipient, is prohibited. If you are not the intended > recipient or > >>>> have received this communication in error, please > >>> immediately notify > >>>> the sender and destroy this communication. > >>>> > >>> _______________________________________________ > >>> Ietf-behave mailing list > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>> > >> > > -- > Karlheinz Wurm, > Skype Technologies S.A. > > callto://wurm > +372 536 48 166 > > Get Skype from http://www.skype.net > We're hiring http://www.skype.net/company/jobs > -- > This electronic transmission and any attached files are > solely for the intended recipient and may contain information > that is privileged, confidential or otherwise protected from > disclosure. Any review, retransmission, dissemination or > other use, including taking any action concerning this > information by anyone other than the intended recipient, is > prohibited. If you are not the intended recipient or have > received this communication in error, please immediately > notify the sender and destroy this communication. > From fluffy@cisco.com Fri, 27 Jan 2006 16:36:10 -0800 (PST) From: Cullen Jennings Date: Fri, 27 Jan 2006 16:36:10 -0800 (PST) Subject: [Ietf-behave] Re: Question about draft-ietf-behave-nat-udp-04 in a P2P application In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Well, this is not a very IETF comment but ignoring all theory and just talking about practice.... Based on the testing I have done of residential NATs, if I was writing an application today that did this, I would send to all 20 every 25 seconds. On 12/21/05 6:31 AM, "Matthews, Philip (Philip)" wrote: > Francois and Cullen: > > I have a question about the behavior of a NAT "N" that is compliant > with draft-ietf-behave-nat-udp-04. > > Say that NAT N implements the more stringent filtering behaviour of > "Address dependent filtering" (REQ-8), and say that, despite this, > I am trying to write a peer-to-peer application A which is located > behind NAT N and which maintains UDP connections with 20 other peers > B,C,D,.... > Application A uses the same address and port for all these connections. > > To maintain the appropriate bindings in NAT "N", so that application A > can receive > packets from each of these peers, must application A send a UDP packet > to all 20 peers B,C,D,... every 2 minutes, or can application A send a > UDP packet > to just one of these peers every 2 minutes? > > (For simplicity, assume NAT "N" has a "NAT inbound refresh behavior" of > False). > > I am hoping, of course, that a packet every 2 minutes to just ONE peer > will be > sufficient to maintain all these mappings. However, I cannot seem to > find any > words one way or another about this in the document. Am I missing > something? > > - Philip From audet@nortel.com Sat, 28 Jan 2006 12:44:16 -0800 (PST) From: "Francois Audet" Date: Sat, 28 Jan 2006 12:44:16 -0800 (PST) Subject: [Ietf-behave] Re: Question about draft-ietf-behave-nat-udp-04 in a P2P application In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Yep, I agree. It's the safest route. On Jan 27, 2006, at 16:36 , Cullen Jennings wrote: Well, this is not a very IETF comment but ignoring all theory and just talking about practice.... Based on the testing I have done of residential NATs, if I was writing an application today that did this, I would send to all 20 every 25 seconds. On 12/21/05 6:31 AM, "Matthews, Philip (Philip)" wrote: Francois and Cullen: I have a question about the behavior of a NAT "N" that is compliant with draft-ietf-behave-nat-udp-04. Say that NAT N implements the more stringent filtering behaviour of "Address dependent filtering" (REQ-8), and say that, despite this, I am trying to write a peer-to-peer application A which is located behind NAT N and which maintains UDP connections with 20 other peers B,C,D,.... Application A uses the same address and port for all these connections. To maintain the appropriate bindings in NAT "N", so that application A can receive packets from each of these peers, must application A send a UDP packet to all 20 peers B,C,D,... every 2 minutes, or can application A send a UDP packet to just one of these peers every 2 minutes? (For simplicity, assume NAT "N" has a "NAT inbound refresh behavior" of False). I am hoping, of course, that a packet every 2 minutes to just ONE peer will be sufficient to maintain all these mappings. However, I cannot seem to find any words one way or another about this in the document. Am I missing something? - Philip From karlheinz.wurm@skype.net Mon, 30 Jan 2006 01:21:03 -0800 (PST) From: Karlheinz Wurm Date: Mon, 30 Jan 2006 01:21:03 -0800 (PST) Subject: Re: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF065389B9@zrc2hxm0.corp.nortel.com> Message-ID: <43DDDA7C.4010607@skype.net> MIME-Version: 1.0 Content-Type: text/plain Francois Audet wrote: Hum, that would be very broken... It continues to amaze me that every possible broken scenario theoretically possible seems to be implemented somewhere by someone... This is essentially covered by the "Address and Port dependent mapping", but is a special case of where y1 and y2 are the same. Do you agree, or do you think it justifies having a special case? I still think that this special case should be documented since all other cases are defined. In addition, it would be easier to explain/refer router vendors why it is a bad NAT. Additional question: What is the roadmap to build the RFC out of this paper? Either way, it is a "bad NAT"... -----Original Message----- From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] Sent: Thursday, January 26, 2006 00:07 To: Audet, Francois [SC100:9T51:EXCH] Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Francois Audet wrote: You mean when Y1 and Y2 are different???? Y1 and Y2 are different but y1 and y2 are the same. Than the NAT will bind it to the same external port. e.g. Local RemoteAddress External NAT address X:x Y1:1925 X1':33394 X:x Y2:1925 X1':33394 X:x Y3:34575 X1':32781 X:x Y4:5986 X1':33625 And the worse is that the external port binding is completely random. Have you seen a NAT that actually does this? Yes, i am just looking in one of this router. That's why i am missing that definition. I don't want to name the model since we are in business relation with them but it is the latest model of one of the very biggest router vendors and widely distributed. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Karlheinz Wurm Sent: Wednesday, January 25, 2006 08:04 To: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Hi everyone, Since I recently got confronted with the following behavior, i think one definition is missing at point 4.1 ... The following address and port mapping behavior are defined: ... I would call it a Port Dependent Mapping which means: +------+ +------+ x | Y1 | | Y2 | t +--+---+ +---+--+ e | Y1:y1 Y2:y2 | r +----------+ +----------+ n | | a X1':x1' | | X2':x2' l +--+---+-+ ...........| NAT |............... +--+---+-+ I | | n X:x | | X:x t ++---++ e | X | r +-----+ n a Port Dependent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external Port address, regardless of the external IP. Specifically, X1':x1' equals X2':x2' if, and only if, y2 equals y1. Kind regards, -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 48 166 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 48 166 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 36 975 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. begin:vcard fn:Karlheinz Wurm n:Wurm;Karlheinz email;internet:karlheinz.wurm@xxxxxxxxx tel;work:+1 (415) 508-3653 tel;cell:+372 536 369 75 x-mozilla-html:FALSE version:2.1 end:vcard From audet@nortel.com Mon, 30 Jan 2006 16:56:27 -0800 (PST) From: "Francois Audet" Date: Mon, 30 Jan 2006 16:56:27 -0800 (PST) Subject: RE: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Message-ID: <1ECE0EB50388174790F9694F77522CCF0660C171@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain What is the filtering behavior of these evil NATs? > -----Original Message----- > From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] > Sent: Monday, January 30, 2006 01:21 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] missing defintion in > draft-ietf-behave-nat-udp-04 > > > > > Francois Audet wrote: > > Hum, that would be very broken... > > > > It continues to amaze me that every possible broken scenario > > theoretically possible seems to be implemented somewhere by > > someone... > > > > This is essentially covered by the "Address and Port dependent > > mapping", but is a special case of where y1 and y2 are the same. > > > > Do you agree, or do you think it justifies having a > > special case? > > I still think that this special case should be documented since all > other cases are defined. In addition, it would be easier to > explain/refer router vendors why it is a bad NAT. > > Additional question: What is the roadmap to build the RFC out > of this paper? > > > Either way, it is a "bad NAT"... > > > >> -----Original Message----- > >> From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] > >> Sent: Thursday, January 26, 2006 00:07 > >> To: Audet, Francois [SC100:9T51:EXCH] > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >> Subject: Re: [Ietf-behave] missing defintion in > >> draft-ietf-behave-nat-udp-04 > >> > >> > >> Francois Audet wrote: > >>> You mean when Y1 and Y2 are different???? > >>> > >> Y1 and Y2 are different but y1 and y2 are the same. Than > the NAT will > >> bind it to the same external port. > >> > >> e.g. > >> > >> Local RemoteAddress External NAT address > >> X:x Y1:1925 X1':33394 > >> X:x Y2:1925 X1':33394 > >> X:x Y3:34575 X1':32781 > >> X:x Y4:5986 X1':33625 > >> > >> And the worse is that the external port binding is > completely random. > >> > >>> Have you seen a NAT that actually does this? > >>> > >> Yes, i am just looking in one of this router. That's why i > am missing > >> that definition. I don't want to name the model since we are > >> in business > >> relation with them but it is the latest model of one of the > >> very biggest > >> router vendors and widely distributed. > >> > >> > >>>> -----Original Message----- > >>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > >>>> Karlheinz Wurm > >>>> Sent: Wednesday, January 25, 2006 08:04 > >>>> To: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>> Subject: [Ietf-behave] missing defintion in > >>>> draft-ietf-behave-nat-udp-04 > >>>> > >>>> > >>>> Hi everyone, > >>>> > >>>> Since I recently got confronted with the following behavior, i > >>>> think one definition is missing at point 4.1 ... The following > >>>> address and port > >>>> mapping behavior are defined: ... > >>>> > >>>> > >>>> I would call it a Port Dependent Mapping which means: > >>>> > >>>> +------+ +------+ x > >>>> | Y1 | | Y2 | t > >>>> +--+---+ +---+--+ e > >>>> | Y1:y1 Y2:y2 | r > >>>> +----------+ +----------+ n > >>>> | | a > >>>> X1':x1' | | X2':x2' l > >>>> +--+---+-+ > >>>> ...........| NAT |............... > >>>> +--+---+-+ I > >>>> | | n > >>>> X:x | | X:x t > >>>> ++---++ e > >>>> | X | r > >>>> +-----+ n > >>>> a > >>>> > >>>> Port Dependent Mapping: > >>>> The NAT reuses the port mapping for subsequent > >> packets sent > >>>> from the same internal IP address and port (X:x) > >> to the same > >>>> external Port address, regardless of the external IP. > >>>> Specifically, X1':x1' equals X2':x2' if, and > only if, y2 > >>>> equals > >>>> y1. > >>>> > >>>> > >>>> Kind regards, > >>>> > >>>> -- > >>>> Karlheinz Wurm, > >>>> Skype Technologies S.A. > >>>> > >>>> callto://wurm > >>>> +372 536 48 166 > >>>> > >>>> Get Skype from http://www.skype.net > >>>> We're hiring http://www.skype.net/company/jobs > >>>> -- > >>>> This electronic transmission and any attached files are > solely for > >>>> the intended recipient and may contain information that is > >>>> privileged, confidential or otherwise protected from disclosure. > >>>> Any review, retransmission, dissemination or other use, > including > >>>> taking any action concerning this information by anyone > other than > >>>> the intended recipient, is prohibited. If you are not > the intended > >>>> recipient or have received this communication in error, please > >>>> immediately notify the sender and destroy this communication. > >>>> > >> -- > >> Karlheinz Wurm, > >> Skype Technologies S.A. > >> > >> callto://wurm > >> +372 536 48 166 > >> > >> Get Skype from http://www.skype.net > >> We're hiring http://www.skype.net/company/jobs > >> -- > >> This electronic transmission and any attached files are solely for > >> the intended recipient and may contain information that is > >> privileged, confidential or otherwise protected from > disclosure. Any > >> review, retransmission, dissemination or other use, > including taking > >> any action concerning this information by anyone other than the > >> intended recipient, is prohibited. If you are not the intended > >> recipient or have received this communication in error, please > >> immediately notify the sender and destroy this communication. > >> > > -- > Karlheinz Wurm, > Skype Technologies S.A. > > callto://wurm > +372 536 36 975 > > Get Skype from http://www.skype.net > We're hiring http://www.skype.net/company/jobs > -- > This electronic transmission and any attached files are > solely for the intended recipient and may contain information > that is privileged, confidential or otherwise protected from > disclosure. Any review, retransmission, dissemination or > other use, including taking any action concerning this > information by anyone other than the intended recipient, is > prohibited. If you are not the intended recipient or have > received this communication in error, please immediately > notify the sender and destroy this communication. > From karlheinz.wurm@skype.net Tue, 31 Jan 2006 03:20:18 -0800 (PST) From: Karlheinz Wurm Date: Tue, 31 Jan 2006 03:20:18 -0800 (PST) Subject: Re: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0660C171@zrc2hxm0.corp.nortel.com> Message-ID: <43DF47EF.2090405@skype.net> MIME-Version: 1.0 Content-Type: text/plain Did not check. Do you need it? -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 36 975 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. Francois Audet wrote: What is the filtering behavior of these evil NATs? -----Original Message----- From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] Sent: Monday, January 30, 2006 01:21 To: Audet, Francois [SC100:9T51:EXCH] Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Francois Audet wrote: Hum, that would be very broken... It continues to amaze me that every possible broken scenario theoretically possible seems to be implemented somewhere by someone... This is essentially covered by the "Address and Port dependent mapping", but is a special case of where y1 and y2 are the same. Do you agree, or do you think it justifies having a special case? I still think that this special case should be documented since all other cases are defined. In addition, it would be easier to explain/refer router vendors why it is a bad NAT. Additional question: What is the roadmap to build the RFC out of this paper? Either way, it is a "bad NAT"... -----Original Message----- From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] Sent: Thursday, January 26, 2006 00:07 To: Audet, Francois [SC100:9T51:EXCH] Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Francois Audet wrote: You mean when Y1 and Y2 are different???? Y1 and Y2 are different but y1 and y2 are the same. Than the NAT will bind it to the same external port. e.g. Local RemoteAddress External NAT address X:x Y1:1925 X1':33394 X:x Y2:1925 X1':33394 X:x Y3:34575 X1':32781 X:x Y4:5986 X1':33625 And the worse is that the external port binding is completely random. Have you seen a NAT that actually does this? Yes, i am just looking in one of this router. That's why i am missing that definition. I don't want to name the model since we are in business relation with them but it is the latest model of one of the very biggest router vendors and widely distributed. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Karlheinz Wurm Sent: Wednesday, January 25, 2006 08:04 To: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Hi everyone, Since I recently got confronted with the following behavior, i think one definition is missing at point 4.1 ... The following address and port mapping behavior are defined: ... I would call it a Port Dependent Mapping which means: +------+ +------+ x | Y1 | | Y2 | t +--+---+ +---+--+ e | Y1:y1 Y2:y2 | r +----------+ +----------+ n | | a X1':x1' | | X2':x2' l +--+---+-+ ...........| NAT |............... +--+---+-+ I | | n X:x | | X:x t ++---++ e | X | r +-----+ n a Port Dependent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external Port address, regardless of the external IP. Specifically, X1':x1' equals X2':x2' if, and only if, y2 equals y1. Kind regards, -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 48 166 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 48 166 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. -- Karlheinz Wurm, Skype Technologies S.A. callto://wurm +372 536 36 975 Get Skype from http://www.skype.net We're hiring http://www.skype.net/company/jobs -- This electronic transmission and any attached files are solely for the intended recipient and may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, retransmission, dissemination or other use, including taking any action concerning this information by anyone other than the intended recipient, is prohibited. If you are not the intended recipient or have received this communication in error, please immediately notify the sender and destroy this communication. begin:vcard fn:Karlheinz Wurm n:Wurm;Karlheinz email;internet:karlheinz.wurm@xxxxxxxxx tel;work:+1 (415) 508-3653 tel;cell:+372 536 369 75 x-mozilla-html:FALSE version:2.1 end:vcard From audet@nortel.com Tue, 31 Jan 2006 14:56:14 -0800 (PST) From: "Francois Audet" Date: Tue, 31 Jan 2006 14:56:14 -0800 (PST) Subject: RE: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 Message-ID: <1ECE0EB50388174790F9694F77522CCF06683033@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain My main worry about this is that it could open a can of worms... If such a thing as "Port-only dependent mapping" is described, then we may need to describe a "Port-only dependent filtering". This means non-trivial changes to the document, which is awfuly late... > -----Original Message----- > From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] > Sent: Tuesday, January 31, 2006 03:20 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] missing defintion in > draft-ietf-behave-nat-udp-04 > > > Did not check. Do you need it? > > -- > Karlheinz Wurm, > Skype Technologies S.A. > > callto://wurm > +372 536 36 975 > > Get Skype from http://www.skype.net > We're hiring http://www.skype.net/company/jobs > -- > This electronic transmission and any attached files are > solely for the intended recipient and may contain information > that is privileged, confidential or otherwise protected from > disclosure. Any review, retransmission, dissemination or > other use, including taking any action concerning this > information by anyone other than the intended recipient, is > prohibited. If you are not the intended recipient or have > received this communication in error, please immediately > notify the sender and destroy this communication. > > Francois Audet wrote: > > What is the filtering behavior of these evil NATs? > > > > > > > >> -----Original Message----- > >> From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] > >> Sent: Monday, January 30, 2006 01:21 > >> To: Audet, Francois [SC100:9T51:EXCH] > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >> Subject: Re: [Ietf-behave] missing defintion in > >> draft-ietf-behave-nat-udp-04 > >> > >> > >> > >> > >> Francois Audet wrote: > >>> Hum, that would be very broken... > >>> > >>> It continues to amaze me that every possible broken scenario > >>> theoretically possible seems to be implemented somewhere by > >>> someone... > >>> > >>> This is essentially covered by the "Address and Port dependent > >>> mapping", but is a special case of where y1 and y2 are the same. > >>> > >>> Do you agree, or do you think it justifies having a > >>> special case? > >> I still think that this special case should be documented since all > >> other cases are defined. In addition, it would be easier to > >> explain/refer router vendors why it is a bad NAT. > >> > >> Additional question: What is the roadmap to build the RFC out > >> of this paper? > >> > >> > >> Either way, it is a "bad NAT"... > >>>> -----Original Message----- > >>>> From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] > >>>> Sent: Thursday, January 26, 2006 00:07 > >>>> To: Audet, Francois [SC100:9T51:EXCH] > >>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>> Subject: Re: [Ietf-behave] missing defintion in > >>>> draft-ietf-behave-nat-udp-04 > >>>> > >>>> > >>>> Francois Audet wrote: > >>>>> You mean when Y1 and Y2 are different???? > >>>>> > >>>> Y1 and Y2 are different but y1 and y2 are the same. Than > >> the NAT will > >>>> bind it to the same external port. > >>>> > >>>> e.g. > >>>> > >>>> Local RemoteAddress External NAT address > >>>> X:x Y1:1925 X1':33394 > >>>> X:x Y2:1925 X1':33394 > >>>> X:x Y3:34575 X1':32781 > >>>> X:x Y4:5986 X1':33625 > >>>> > >>>> And the worse is that the external port binding is > >> completely random. > >>>>> Have you seen a NAT that actually does this? > >>>>> > >>>> Yes, i am just looking in one of this router. That's why i > >> am missing > >>>> that definition. I don't want to name the model since we are > >>>> in business > >>>> relation with them but it is the latest model of one of the > >>>> very biggest > >>>> router vendors and widely distributed. > >>>> > >>>> > >>>>>> -----Original Message----- > >>>>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > >>>>>> Karlheinz Wurm > >>>>>> Sent: Wednesday, January 25, 2006 08:04 > >>>>>> To: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>> Subject: [Ietf-behave] missing defintion in > >>>>>> draft-ietf-behave-nat-udp-04 > >>>>>> > >>>>>> > >>>>>> Hi everyone, > >>>>>> > >>>>>> Since I recently got confronted with the following behavior, i > >>>>>> think one definition is missing at point 4.1 ... The > following > >>>>>> address and port > >>>>>> mapping behavior are defined: ... > >>>>>> > >>>>>> > >>>>>> I would call it a Port Dependent Mapping which means: > >>>>>> > >>>>>> +------+ +------+ x > >>>>>> | Y1 | | Y2 | t > >>>>>> +--+---+ +---+--+ e > >>>>>> | Y1:y1 Y2:y2 | r > >>>>>> +----------+ +----------+ n > >>>>>> | | a > >>>>>> X1':x1' | | X2':x2' l > >>>>>> +--+---+-+ > >>>>>> ...........| NAT |............... > >>>>>> +--+---+-+ I > >>>>>> | | n > >>>>>> X:x | | X:x t > >>>>>> ++---++ e > >>>>>> | X | r > >>>>>> +-----+ n > >>>>>> a > >>>>>> > >>>>>> Port Dependent Mapping: > >>>>>> The NAT reuses the port mapping for subsequent > >>>> packets sent > >>>>>> from the same internal IP address and port (X:x) > >>>> to the same > >>>>>> external Port address, regardless of the external IP. > >>>>>> Specifically, X1':x1' equals X2':x2' if, and > >> only if, y2 > >>>>>> equals > >>>>>> y1. > >>>>>> > >>>>>> > >>>>>> Kind regards, > >>>>>> > >>>>>> -- > >>>>>> Karlheinz Wurm, > >>>>>> Skype Technologies S.A. > >>>>>> > >>>>>> callto://wurm > >>>>>> +372 536 48 166 > >>>>>> > >>>>>> Get Skype from http://www.skype.net > >>>>>> We're hiring http://www.skype.net/company/jobs > >>>>>> -- > >>>>>> This electronic transmission and any attached files are > >> solely for > >>>>>> the intended recipient and may contain information that is > >>>>>> privileged, confidential or otherwise protected from > disclosure. > >>>>>> Any review, retransmission, dissemination or other use, > >> including > >>>>>> taking any action concerning this information by anyone > >> other than > >>>>>> the intended recipient, is prohibited. If you are not > >> the intended > >>>>>> recipient or have received this communication in error, please > >>>>>> immediately notify the sender and destroy this communication. > >>>>>> > >>>> -- > >>>> Karlheinz Wurm, > >>>> Skype Technologies S.A. > >>>> > >>>> callto://wurm > >>>> +372 536 48 166 > >>>> > >>>> Get Skype from http://www.skype.net > >>>> We're hiring http://www.skype.net/company/jobs > >>>> -- > >>>> This electronic transmission and any attached files are > solely for > >>>> the intended recipient and may contain information that is > >>>> privileged, confidential or otherwise protected from > >> disclosure. Any > >>>> review, retransmission, dissemination or other use, > >> including taking > >>>> any action concerning this information by anyone other than the > >>>> intended recipient, is prohibited. If you are not the intended > >>>> recipient or have received this communication in error, please > >>>> immediately notify the sender and destroy this communication. > >>>> > >> -- > >> Karlheinz Wurm, > >> Skype Technologies S.A. > >> > >> callto://wurm > >> +372 536 36 975 > >> > >> Get Skype from http://www.skype.net > >> We're hiring http://www.skype.net/company/jobs > >> -- > >> This electronic transmission and any attached files are > >> solely for the intended recipient and may contain information > >> that is privileged, confidential or otherwise protected from > >> disclosure. Any review, retransmission, dissemination or > >> other use, including taking any action concerning this > >> information by anyone other than the intended recipient, is > >> prohibited. If you are not the intended recipient or have > >> received this communication in error, please immediately > >> notify the sender and destroy this communication. > >> > From fluffy@cisco.com Wed, 1 Feb 2006 20:16:34 -0800 (PST) From: Cullen Jennings Date: Wed, 1 Feb 2006 20:16:34 -0800 (PST) Subject: Re: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04 In-Reply-To: <43DDDA7C.4010607@skype.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 1/30/06 1:21 AM, "Karlheinz Wurm" wrote: > Additional question: What is the roadmap to build the RFC out of this paper? The abridged version is ... We have sent it to the IESG for review. They look at it, sometime they ask for changes. Then they send it to the RFC Editor and it becomes an RFC. From ayang@apple.com Fri, 10 Feb 2006 19:25:10 -0800 (PST) From: Andy Yang Date: Fri, 10 Feb 2006 19:25:10 -0800 (PST) Subject: [Ietf-behave] TURN help !!! Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi All, I am new to this board but your help will be greatly appreciated. I have a doubt regarding the two TURN clients both behind a symmetric NAT can communicate with each other using a TURN server. Please help me Scenario: A-----NAT 1------TURN SERVER-----NAT 2-----B A: (a.a.a.a:1234) B: (b.b.b.b:1234) TURN Server: (x.x.x.x:3478) NAT 1 and NAT 2 are both symmetric. My understanding: 1. A, B will both send ALLOCATE to TURN server (x.x.x.x:3478), and get response. Suppose A is allocated x.x.x.x:11111, B is allocated x.x.x.x:22222. 2. A send SEND request to TURN server (x.x.x.x:3478), set REMOE_ADDRESS(b.b.b.b:1234); TURN server will use A's allocated address (x.x.x.x:1111) to send DATA to B (b.b.b.b.b:1234). It cannot go through NAT 2. 3. B send SEND request to TURN server(x.x.x.x:3478), set REMOTE_ADDRESS(a.a.a.a:1234); TURN server will use B's allocated address (x.x.x.x:2222) to send DATA to A (a.a.a.a:1234). It cannot go through NAT 1, either. Is there anything wrong here? Thanks, a From juberti@aol.com Fri, 10 Feb 2006 19:52:55 -0800 (PST) From: Justin Uberti Date: Fri, 10 Feb 2006 19:52:55 -0800 (PST) Subject: Re: [Ietf-behave] TURN help !!! In-Reply-To: Message-ID: <43ED5F90.90705@aol.com> MIME-Version: 1.0 Content-Type: text/plain Andy, In the simplest case, when A wants to send data to B, it will make a TURN send request to send to B's TURN address x.x.x.x:22222. A's TURN server will send this data from x.x.x.x:11111 to B at x.x.x.x:22222, which will be forwarded to B at b.b.b.b:1234. In the real world, TURN will typically be used with ICE, where A will send to B's TURN address, B's STUN-derived address, and b.b.b.b:1234, and will use the best address that works. Hope this helps, --justin ayang@xxxxxxxxx wrote: Hi All, I am new to this board but your help will be greatly appreciated. I have a doubt regarding the two TURN clients both behind a symmetric NAT can communicate with each other using a TURN server. Please help me Scenario: A-----NAT 1------TURN SERVER-----NAT 2-----B A: (a.a.a.a:1234) B: (b.b.b.b:1234) TURN Server: (x.x.x.x:3478) NAT 1 and NAT 2 are both symmetric. My understanding: 1. A, B will both send ALLOCATE to TURN server (x.x.x.x:3478), and get response. Suppose A is allocated x.x.x.x:11111, B is allocated x.x.x.x:22222. 2. A send SEND request to TURN server (x.x.x.x:3478), set REMOE_ADDRESS(b.b.b.b:1234); TURN server will use A's allocated address (x.x.x.x:1111) to send DATA to B (b.b.b.b.b:1234). It cannot go through NAT 2. 3. B send SEND request to TURN server(x.x.x.x:3478), set REMOTE_ADDRESS(a.a.a.a:1234); TURN server will use B's allocated address (x.x.x.x:2222) to send DATA to A (a.a.a.a:1234). It cannot go through NAT 1, either. Is there anything wrong here? Thanks, a _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Wed, 15 Feb 2006 16:32:04 -0800 (PST) From: Cullen Jennings Date: Wed, 15 Feb 2006 16:32:04 -0800 (PST) Subject: [Ietf-behave] Adoption of WG documents Message-ID: MIME-Version: 1.0 Content-Type: text/plain The chairs and ADs are in the process of updating the charter to include the media relay work. At the last meeting we discussed the topic of adopting the following drafts as working group drafts: http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-08.txt http://www.ietf.org/internet-drafts/draft-camarillo-midcom-turn-ipv6-00.txt There was strong support in the room for using these as the starting point for this work. If anyone on the list has objections, please let us know, otherwise I will declare consensus on adopting them. Please let us know by February 19. Thanks, Cullen & Jiri From fluffy@cisco.com Fri, 17 Feb 2006 17:04:33 -0800 (PST) From: Cullen Jennings Date: Fri, 17 Feb 2006 17:04:33 -0800 (PST) Subject: [Ietf-behave] WGLC of draft-ietf-behave-multicast Message-ID: MIME-Version: 1.0 Content-Type: text/plain I would like to begin working group last call of: draft-ietf-behave-multicast-01 Please have all your comments in by March 3rd. Thanks, Cullen & Jiri From srisuresh@yahoo.com Mon, 20 Feb 2006 10:52:24 -0800 (PST) From: Pyda Srisuresh Date: Mon, 20 Feb 2006 10:52:24 -0800 (PST) Subject: Re: [Ietf-behave] Adoption of WG documents In-Reply-To: Message-ID: <20060220185224.41896.qmail@web33301.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, Back in 11/05, I requested to initiate the procedure to adapt the following as WG documents and consider adding a related draft to the milestones. draft-srisuresh-behave-nat-icmp-00.txt draft-ford-behave-app-01.txt Both these drafts have a matching WG milestones. I havent heard anything as yet on these. It seems a bit premature to talk about revising the chapter and milestones before addressing what is already on the WG plate. If there is large support to add the items below, that is fine. However, before revising the charter and milestones, I would suggest getting feedback from folks on what else they would like to see added to the charter and milestones. Thanks. regards, suresh ----- Original Message ---- From: Cullen Jennings To: Behave Sent: Wednesday, February 15, 2006 4:31:57 PM Subject: [Ietf-behave] Adoption of WG documents The chairs and ADs are in the process of updating the charter to include the media relay work. At the last meeting we discussed the topic of adopting the following drafts as working group drafts: http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-08.txt http://www.ietf.org/internet-drafts/draft-camarillo-midcom-turn-ipv6-00.txt There was strong support in the room for using these as the starting point for this work. If anyone on the list has objections, please let us know, otherwise I will declare consensus on adopting them. Please let us know by February 19. Thanks, Cullen & Jiri _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Mon, 20 Feb 2006 15:37:56 -0800 (PST) From: Cullen Jennings Date: Mon, 20 Feb 2006 15:37:56 -0800 (PST) Subject: Re: [Ietf-behave] Adoption of WG documents In-Reply-To: <20060220185224.41896.qmail@web33301.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 2/20/06 10:52 AM, "Pyda Srisuresh" wrote: > Cullen, > Back in 11/05, I requested to initiate the procedure to adapt the following as > WG documents and consider adding a related draft to the milestones. > draft-srisuresh-behave-nat-icmp-00.txt > draft-ford-behave-app-01.txt > > Both these drafts have a matching WG milestones. I havent heard anything as > yet on these. It seems a bit premature to talk about revising the chapter and > milestones before addressing what is already on the WG plate. > If there is large support to add the items below, that is fine. However, > before revising the charter and milestones, I would suggest getting feedback > from folks on what else they would like to see added to the charter and > milestones. > > Thanks. > > regards, > suresh Hi, Few separate issues here. On the ford-behave-app. I was sort of working on the assumption that this had good odds of becoming a WG draft but it has had very little "air time" or comments yet. Most the WG has not read it. This is partially because the UDP and TCP stuff is sequenced ahead of it and the UDP took so long. I would hope we would end up with agenda time this at the upcoming meeting. On the ICMP, the stuff in this document that people seemed willing to agree to got included into the UDP document. I think that several people felt that much of the stuff seemed to go well beyond the minimal changes that the WG wanted to specify and move into the advice on how to build a NAT instead of the minimal definitions we need to make applications that can work through NATs. On the topic of would we do any relay work before everything else was done, well at the last meeting and on the list there has been many people willing to work on that while there has been fairly limited comment on the application advice stuff. I would like to see both get moving if possible. Cullen From srisuresh@yahoo.com Mon, 20 Feb 2006 18:33:54 -0800 (PST) From: Pyda Srisuresh Date: Mon, 20 Feb 2006 18:33:54 -0800 (PST) Subject: Re: [Ietf-behave] Adoption of WG documents In-Reply-To: Message-ID: <20060221023350.28076.qmail@web33305.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > On 2/20/06 10:52 AM, "Pyda Srisuresh" wrote: > > > Cullen, > > Back in 11/05, I requested to initiate the procedure to adapt the following > as > > WG documents and consider adding a related draft to the milestones. > > draft-srisuresh-behave-nat-icmp-00.txt > > draft-ford-behave-app-01.txt > > > > Both these drafts have a matching WG milestones. I havent heard anything as > > yet on these. It seems a bit premature to talk about revising the chapter > and > > milestones before addressing what is already on the WG plate. > > If there is large support to add the items below, that is fine. However, > > before revising the charter and milestones, I would suggest getting > feedback > > from folks on what else they would like to see added to the charter and > > milestones. > > > > Thanks. > > > > regards, > > suresh > > Hi, > > Few separate issues here. > > On the ford-behave-app. I was sort of working on the assumption that this > had good odds of becoming a WG draft but it has had very little "air time" > or comments yet. Most the WG has not read it. This is partially because the > UDP and TCP stuff is sequenced ahead of it and the UDP took so long. I would > hope we would end up with agenda time this at the upcoming meeting. > [suresh] There is a good likelihood the authors may not be present at the next WG meeting. I doubt, if this will be presented in the WG meeting. I was hoping the draft can become a WG document without it having to be presented in a WG meeting. What is the procedure to get air time/comments on the draft to turn this into a WG draft? Can you intiate the process? > On the ICMP, the stuff in this document that people seemed willing to agree > to got included into the UDP document. I think that several people felt that > much of the stuff seemed to go well beyond the minimal changes that the WG > wanted to specify and move into the advice on how to build a NAT instead of > the minimal definitions we need to make applications that can work through > NATs. > [suresh] It is true that the UDP draft carried ICMP stuff in some cases. But, the UDP draft is not a replacement for ICMP recommendations. Now that the UDP draft seems to have gone past IESG approval, we are working on a revised rev of the ICMP draft. Can we have a discussion in the WG on whether or not to adapt the revised draft as WG document? (or) are you saying that you propose to abandon the milestone for "ICMP recomemndations draft" altogether as part of the "revised milestones"? > On the topic of would we do any relay work before everything else was done, > well at the last meeting and on the list there has been many people willing > to work on that while there has been fairly limited comment on the > application advice stuff. I would like to see both get moving if possible. > [suresh] If you are going to expand the charter and add milestones to include drafts on TURN, it makes sense to seek wider input from the list. It is not fair to do this without reviewing the several independent drafts (within the perview of the current WG charter, IMHO) that have been languishing without being considered as WG milestones. I know, I have a few that have been collecting dust. Why is it more important to add TURN drafts as milestones than to review the drafts already out there and consider their validity for milestones. I would like to either see the independent drafts adapted as WG milestones (or) be told as being out of the scope of the WG charter. regards, suresh > Cullen > > > From fluffy@cisco.com Thu, 23 Feb 2006 12:33:45 -0800 (PST) From: Cullen Jennings Date: Thu, 23 Feb 2006 12:33:45 -0800 (PST) Subject: [Ietf-behave] Agenda Requests Message-ID: MIME-Version: 1.0 Content-Type: text/plain If people have requests for agenda time at the next meetings, please email Jiri and I. Thanks, Cullen From fluffy@cisco.com Sun, 26 Feb 2006 08:50:58 -0800 (PST) From: Cullen Jennings Date: Sun, 26 Feb 2006 08:50:58 -0800 (PST) Subject: Re: [Ietf-behave] Adoption of WG documents In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain At the last meeting, we had a very large number of people request we add theses as WG documents. I have had a very small number of people express concerns around doing this. Mostly the concerns have centered on "what about other work". The other work is largely orthogonal to the TURN work and being done by different people so I don't expect TURN to have any impact on the schedule of the other work. The charter changes are expected to happen. Because of this, I have requested the authors of the two documents below to submit them as WG items. I don't know if this will happen in time for the next meeting or not but we will see. I would like to point out that by doing this, we are just saying some people in the WG will work on theses and we will use them as a starting point. It's not like I am requesting publication of these - if anyone things these documents are the wrong path forward, there is still plenty of time to comment on that. Cullen On 2/15/06 4:31 PM, "Cullen Jennings" wrote: > > The chairs and ADs are in the process of updating the charter to include the > media relay work. At the last meeting we discussed the topic of adopting the > following drafts as working group drafts: > > http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-08.txt > > http://www.ietf.org/internet-drafts/draft-camarillo-midcom-turn-ipv6-00.txt > > There was strong support in the room for using these as the starting point > for this work. If anyone on the list has objections, please let us know, > otherwise I will declare consensus on adopting them. Please let us know by > February 19. > > Thanks, Cullen & Jiri > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From jdrosen@cisco.com Wed, 1 Mar 2006 19:59:19 -0800 (PST) From: Jonathan Rosenberg Date: Wed, 1 Mar 2006 19:59:19 -0800 (PST) Subject: [Ietf-behave] Re: I-D ACTION:draft-ietf-behave-turn-00.txt In-Reply-To: Message-ID: <44066D95.9020808@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Here you have the new and much improved TURN specification. The biggest change is that turn is now a 'stun usage', rather than being a separate protocol. It defines some new request types and attributes, but otherwise inherits is base processing from stun. It depends a lot on the revised stun draft, which will be out shortly, but you can probably follow turn without it if you are familiar with the previous stun draft. Besides this change (which was a big one), there were many functional and other improvements. These include: * Removed terms symmetric, port-restricted, etc. and use behave terminology. * Substantial movemenet of text between STUN and TURN. Much of what was only in TURN is now in the STUn draft, including digest authentication, the concept of a magic cookie, ALTERNATE-SERVER and the 300 response. TURN is now described as a usage of STUN, and repeats nothing that is in the STUN specification. Previously, turn repeated many concepts from stun, * Change in handling of authentication. TURN previously said that the credentials learned from the shared secret request last a long time, over 30m, in contrast to stun where its 9m. Instead of working this way, the allocate request itself is challenged using digest, and the username/password is either the long-lived provisioned credential between the client and server, or a short-term shared secret created from a Shared Secret Request. This allows unification of the shared secret mechanism, and also allows regular digest authentication to apply to stun, without the shared secret request at all. While less secure than the shared secret, it is as secure as basic SIP is, and much more easily deployable. (most of this is in stun) * Active destination section now includes an explicit state machine which substnatially clarifies how this works, along with an explanation of the race condition that the state machine is trying to solve. Behavior between UDP and TCP is now unified; the difference is handled through a timer setting which is zero for TCP and three seconds for UDP. The value of the timer is communicated to the client in the response. The mecahnism also now allows the client to unset the active destination; this was forbidden previously. * Send is now an indication, not a request. Thus, it generates no response. Message integrity and authentication services are not provided for it (there is no point; sending unencapsulated data provides the same function and that is never authenticated). * Unified tcp and udp processing. Both now allow turn messaging after the active destination is set. Previously, this was only allowed for udp. * Removed the 440 error case. Set Active destination is now allowed for destinations that have not been contacted with a Send. * Allocate requests, like all stun requests, can now include a MAPPED-ADDRESS, which allows the client to obtain reflexive and relayed addresses in one request. This is really, really nice with ICE. * Added the ability to ask for a specific port parity (odd or even), to request contiguous ports, or to request a specific port. Contiguous port requests are more like hints that the client will ask for the next higher port; they are not guaranteed. * Added the ability to ask for a specific IP address. This is needed with ice-tcp, for example * Added the ability to ask for a specific transport protocol, so that TURN can convert between UDP and TCP or vice a versa. Since TURN can also do tls, this allows a client to connect to the turn server over tls and request a udp port. Text mentions that, in this conversion, packets may be lost if the throughput of the incoming packets (say, over UDP) exceed the througput of the tcp connection towards the client. No attempt is made to do traffic shaping; the server just tries to the deliver the packets. * Permissions for an allocation (which define when the server will relay packets towards the client) are now set by both a Send indication and a set active destination. Previously, it was just with a send request. * Previously, a send request that opened a tcp connection caused an ephemeral port to be opened on the server. THis was done to avoid simultaneous opens. Now, the server opens from the the allocated transport address. This allows the client to request a simultaneous open if desired. If one is not desired, the client can perform another allocation on the same interface and open from there. This logic is in ice-tcp now. * Closures of tcp connections from external clients to the server no longer clear the allocation. This used to be a consequence of the fact that, for tcp, you couldn't change the active destination once set. Now, you can. * Allocation lifetimes are now refreshed only with allocate requests, not data packets. THis was done to facilitate implementations where there is a separate data plane and turn signaling processing plane. * Added a new request - Connect. This is used by the client to open a tcp connectoin towards an external client. Previously, this was done as a byproduct of Send. However, now that Send is an indication, it genreates no response. As such, the client could not figure out whether the connection setup succeeded. It needs to know this for proper operation of ICE. As such, a separate Connect request is used, and it genreates a success response when the connection succeeds. The mechanism has somewhat of a hack in it to deal with the fact that a tcp connection attempt may take longer than the stun transction timeout. * added a long overdue example * small update to security considerations section, rewrite of overview of operation Thanks, Jonathan R. Internet-Drafts@xxxxxxxx wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-turn-00.txt Pages : 47 Date : 2006-3-1 This specification defines a usage of the Simple Traversal of UDP Through NAT (STUN) Protocol for asking the STUN server to relay packets towards a client. This usage is useful for elements behind NATs whose mapping behavior is address and port dependent. The extension purposefully restricts the ways in which the relayed address can be used. In particular, it prevents users from running well general purpose servers from ports obtained from the STUN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-turn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-turn-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------------------------ _______________________________________________ I-D-Announce mailing list I-D-Announce@xxxxxxxx https://www1.ietf.org/mailman/listinfo/i-d-announce -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From saikat@cs.cornell.edu Fri, 3 Mar 2006 15:55:20 -0800 (PST) From: Saikat Guha Date: Fri, 3 Mar 2006 15:55:20 -0800 (PST) Subject: [Ietf-behave] Announcing draft-ietf-behave-tcp-00.txt Message-ID: <1141430118.19294.15.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630135.multipart/signed" --Boundary..27398.1163630135.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi folks, Just wanted to draw your attention to draft-ietf-behave-tcp-00.txt (http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-00.txt) This is the TCP adjunct to the UDP draft. It is based on draft-hoffman-behave-tcp-03.txt (diff here: http://tinyurl.com/n7dmf). It incorporates all the feedback from the last meeting, and discussions on the mailing list. I believe there is working group consensus on most (if not all) the stuff in there. I'd appreciate more feedback on it ahead of the meeting. Thanks. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630135.multipart/signed Content-Type: application/octet-stream; name="pgp00094.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00094.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yIChHTlUv TGludXgpCgppRDhEQlFCRUNOZG1uRmx0cWk2OTEvb1JBbDV3QUowZG9BcnM2N0RRa1hpZjZ5V29q YzRWeXpjaWp3Q2ZSU1pzCnFSd1lPSVhxSi9FNXRxellURUVQWVhJPQo9VjBKcQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630135.multipart/signed-- From srisuresh@yahoo.com Wed, 8 Mar 2006 13:31:30 -0800 (PST) From: Pyda Srisuresh Date: Wed, 8 Mar 2006 13:31:30 -0800 (PST) Subject: [Ietf-behave] ICMP Behave draft Message-ID: <20060308213129.19447.qmail@web33306.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Folks, New rev of the ICMP behave draft (draft-srisuresh-behave-nat-icmp-01.txt) is now available for review. Please give this a read and provide your feedback. One key objective is to understand if there is interest in pursuing the ICMP work in this draft as a WG item. We also requested for a slot in the upcoming WG meeting for this draft. Thanks. The ICMP draft lists 5 requirements and do not conflict with the ICMP requirements listed in the UDP draft (or the TCP draft). The ICMP requirements in the UDP draft require NATs to a) forward ICMP detination unreachable messages, and, b) be able to generate "Fragementation needed and DF set" messages. Both are covered by the requirements listed in the ICMP draft. Thanks. regards, suresh From fluffy@cisco.com Thu, 9 Mar 2006 08:32:46 -0800 (PST) From: Cullen Jennings Date: Thu, 9 Mar 2006 08:32:46 -0800 (PST) Subject: [Ietf-behave] Re: ICMP behave draft In-Reply-To: <20060305192403.70993.qmail@web33311.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 3/5/06 11:24 AM, "Pyda Srisuresh" wrote: > Cullen & Jiri, > > We just submitted a new rev of ICMP behave draft. We would like to have a slot > to present the draft in the IETF meeting. I believe, 15 to 20 min. slot should > be adequate to discuss this. Saikat will present this in the meeting. > > The ICMP draft has 5 requirements and these requirments do not conflict with > the UDP draft. The main goal of the presentation would be to find out if there > is interest in pursuing the ICMP milestone and the draft in the WG. > > Thanks. > > regards, > suresh At a casual glance (and I may be very wrong...) Some of these requirements are already covered in the UDP draft. Some of these requirements were discussed in the formation of the UDP draft and it was clear that the WG would not agree to them so they were removed from UDP. Some of these requirements conflict with things people have expressed a strong preference for in dealing with the TCP draft. I'm amazed that this draft has received no comments but unless someone steps up with exactly what parts of it we want to move forward with and why we need theses, I'm having a hard time seeing what what the issues are that the working group needs to spend agenda time to solve. In the past I have put stuff like this at the end of the agenda as a time permitting item but we never get those items so I'm reluctant to do that. It's the usual scope issue. This document may be great advice on how to build a NAT. The question is, which of these items do we need NATs to do differently from what they do today so that applications can work better behind NATs. And what applications would take advantage of the new behavior. If people think there are key things here, and can say what application needs them and that NATs currently do the wrong thing, I glad to set priorities accordingly but right now I am unclear on how to prioritize this. Thanks, Cullen (with my behave chair hat on) From Meir.Leshem@veraznetworks.com Thu, 9 Mar 2006 08:40:07 -0800 (PST) From: "Meir Leshem" Date: Thu, 9 Mar 2006 08:40:07 -0800 (PST) Subject: RE: [Ietf-behave] ICMP Behave draft Message-ID: <30F0D7625E0DEC4E83A2A94596BC18B7930F23@VRZIL-EX01.il.veraznetworks.com> MIME-Version: 1.0 Content-Type: text/plain Hi, According to draft-srisuresh-behave-nat-icmp-01, "A NAT device MUST transparently forward ICMP error packets to the target end node, so long as the NAT has active mapping for the embedded payload" (REQ-2). In the case of NAPT device (defined in RFC 3022), some ICMP error messages might cause problems if transferred transparently by a NAPT device. For example, if instead of figure 1 in the nat-icmp draft we put 3 hosts in the private realm Y (y1,y2,y3). An ICMP host unreachable message from Router-y upon a packet from Host-x to host-y1 will be transferred to host-x as host unreachable (host-y'). As a result host-x will stop sending packets to y1,y2,y3 although only y1 has a problem. So my understanding is that in this case, for ICMP (host unreachable, net unreachable) messages from Router-y, the NAPT device must send ICMP (port unreachable) messages to Host-x instead. Please advise! Host-x | ---------------+------------------- | +-------------+ | Router-x | +-------------+ External Network | --------------------+--------+------------------- | ^ | | | (Host-y', Host-x) | | | v +-------------+ | NAPT-xy | +-------------+ | | Private Network ----------------+------------+---------------- | +-------------+ | Router-y | +-------------+ | ------+---------+-------+-------- | | | ^ | | | | | (Host-y1, Host-x)| | | | | v Host y3 Host y2 Host-y1 Regards Meir Leshem -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Pyda Srisuresh Sent: Wednesday, March 08, 2006 11:31 PM To: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: [Ietf-behave] ICMP Behave draft Folks, New rev of the ICMP behave draft (draft-srisuresh-behave-nat-icmp-01.txt) is now available for review. Please give this a read and provide your feedback. One key objective is to understand if there is interest in pursuing the ICMP work in this draft as a WG item. We also requested for a slot in the upcoming WG meeting for this draft. Thanks. The ICMP draft lists 5 requirements and do not conflict with the ICMP requirements listed in the UDP draft (or the TCP draft). The ICMP requirements in the UDP draft require NATs to a) forward ICMP detination unreachable messages, and, b) be able to generate "Fragementation needed and DF set" messages. Both are covered by the requirements listed in the ICMP draft. Thanks. regards, suresh _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Thu, 9 Mar 2006 09:21:03 -0800 (PST) From: Pyda Srisuresh Date: Thu, 9 Mar 2006 09:21:03 -0800 (PST) Subject: RE: [Ietf-behave] ICMP Behave draft In-Reply-To: <30F0D7625E0DEC4E83A2A94596BC18B7930F23@VRZIL-EX01.il.veraznetworks.com> Message-ID: <20060309172102.70497.qmail@web33302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Hi Meir, Good catch. Thanks for pointing this out. We will fix this in the next rev. Please see my responses inline below. regards, suresh --- Meir Leshem wrote: > Hi, > According to draft-srisuresh-behave-nat-icmp-01, "A NAT device MUST > transparently forward ICMP error packets to the target end node, so > long as the NAT has active mapping for the embedded payload" (REQ-2). > In the case of NAPT device (defined in RFC 3022), some ICMP error > messages might cause problems if transferred transparently by a NAPT > device. > > For example, if instead of figure 1 in the nat-icmp draft we put 3 hosts > in the private realm Y (y1,y2,y3). > An ICMP host unreachable message from Router-y upon a packet from Host-x > to host-y1 will be transferred to host-x as host unreachable (host-y'). > [suresh] The ICMP host unreachable message does embed the first 8 bytes of the session that could not be forwarded. This includes the TCP/UDP port numbers that form the session tuple. As such, that should indicate to the originating host that the destination is not reachable on the specific session tuple. > As a result host-x will stop sending packets to y1,y2,y3 although > only y1 has a problem. > So my understanding is that in this case, for ICMP (host unreachable, > net unreachable) messages from Router-y, the NAPT device must send > ICMP (port unreachable) messages to Host-x instead. > > Please advise! > [suresh] You are abosolutely right. There is that danger that end hosts could misinterpret the "ICMP destination unreachable message" (especially, host unreachable and net unreachable) and stop sending packets to Y1, Y2, Y3, although only Y1 has a problem. As you say, the NAPT device SHOULD fix the "ICMP destination unreachable message" to be port unreachable. In the specific case you mention, most likely, the inside host-y1 had originated a session to Host-X and was disconnected later on. This is analogous to a case where you have a process start on a public host, initiate connections and abort at some point. In the case of the the public host aborting, the host woudl send ICMP (port unreachable) message to host-X. This is what the NAPT device should do as well. regards, suresh > > Host-x > | > ---------------+------------------- > | > +-------------+ > | Router-x | > +-------------+ > External Network | > --------------------+--------+------------------- > | ^ | > | | (Host-y', Host-x) | > | | v > +-------------+ > | NAPT-xy | > +-------------+ > | > | Private Network > ----------------+------------+---------------- > | > +-------------+ > | Router-y | > +-------------+ > | > ------+---------+-------+-------- > | | | ^ | > | | | | (Host-y1, Host-x)| > | | | | v > Host y3 Host y2 Host-y1 > > Regards > Meir Leshem > > > > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Pyda > Srisuresh > Sent: Wednesday, March 08, 2006 11:31 PM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] ICMP Behave draft > > > Folks, > > New rev of the ICMP behave draft > (draft-srisuresh-behave-nat-icmp-01.txt) is now available for review. > Please give this a read and provide your feedback. One key objective is > to understand if there is interest in pursuing the ICMP work in this > draft as a WG item. We also requested for a slot in the upcoming WG > meeting for this draft. Thanks. > > The ICMP draft lists 5 requirements and do not conflict with the ICMP > requirements listed in the UDP draft (or the TCP draft). The ICMP > requirements in the UDP draft require NATs to a) forward ICMP detination > unreachable messages, and, b) be able to generate "Fragementation > needed and DF set" messages. Both are covered by the requirements listed > in the ICMP draft. > > Thanks. > > regards, > suresh > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Thu, 9 Mar 2006 09:32:26 -0800 (PST) From: Pyda Srisuresh Date: Thu, 9 Mar 2006 09:32:26 -0800 (PST) Subject: [Ietf-behave] Application behave draft Message-ID: <20060309173226.50569.qmail@web33308.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Folks, We sent an updated rev of the application behave draft before the deadline, but apparently didnt make it to the drafts archive because the copyright statement did not say 2006. The draft is however available for your reading pleasure at the following URL. This will be resubmitted after the IETF meeting. http://kegel.com/drafts/draft-ford-behave-app-02.txt Please give this a read and provide your feedback. A key objective would be to understand the interest level in adapting this as WG draft. Thanks. regards, suresh From dwing@cisco.com Thu, 9 Mar 2006 09:46:19 -0800 (PST) From: "Dan Wing" Date: Thu, 9 Mar 2006 09:46:19 -0800 (PST) Subject: RE: [Ietf-behave] Re: ICMP behave draft In-Reply-To: Message-ID: <073f01c643a1$602b3d80$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > At a casual glance (and I may be very wrong...) Some of these > requirements are already covered in the UDP draft. I made some comments on this draft to the authors so I'll throw in a few thoughts on where there is some requirement overlap that I noticed: 1. ietf-behave-nat-udp-04.txt, section 9, discusses ICMP behavior. In that section is REQ-12 which says: REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping. a) The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address. b) It is RECOMMENDED that a NAT support ICMP Destination Unreachable messages. which seems to overlap partially with REQ-2 in srisuresh-behave-nat-icmp-01: REQ-2: A NAT device MUST transparently forward ICMP error packets to the target end node, so long as the NAT has active mapping for for the embedded payload. If the NAT does not have an active mapping for the embedded payload, the NAT should silently drop the ICMP error packet. In the case the ICMP error packet is originated by a node in the private realm for which the NAT device has no mapping, the NAT device MUST use its own IP address in the public realm to translate the originating node IP address in the outer IP header. and overlaps completely with REQ-3 in srisuresh-behave-nat-icmp-01: REQ-3: While processing an ICMP error packet, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP error packet. 2. ICMP Don't Fragment handling. ietf-behave-nat-udp-04 says: If the packet has DF=1, the NAT SHOULD send back an ICMP message "fragmentation needed and DF set" message to the host as described in RFC 792 [2]. If the packet has DF=0, the NAT SHOULD fragment the packet and send the fragments, in order. This is the same function a router performs in a similar situation RFC 1812 [5]. and ietf-behave-nat-udp-04 also says: REQ-13: A NAT MUST support fragmentation of packets larger than link MTU. compared to srisuresh-behave-nat-icmp-01 which says: REQ-5: If DF bit is set on a transit IP packet and the NAT device cannot forward the packet without fragmentation, the NAT device MUST send a "Packet too big" ICMP message (ICMP type 3, Code 4) with a suggested MTU back to the sender and drop the original IP packet. What is interesting is that draft-srisuresh-behave-nat-icmp-01.txt has a different scope and applies to both TCP, UDP, and ICMP bindings (an ICMP binding is one that exists while you're doing a ping or an ICMP-based traceroute (which is what Windows' "tracert" does)), whereas -behave-nat-udp only applies to UDP bindings. I expect the TCP BEHAVE document will discuss ICMP behavior for ICMPs that are associated with TCP flows in a manner similar to what is in ietf-behave-nat-udp-04. Would it be valuable to scope an ICMP draft to discuss only ICMP sessions -- that is, ICMP bindings that are created as a result of running the ping utility or an ICMP-based traceroute utility (such as "tracert.exe" on Windows)? -d From audet@nortel.com Thu, 9 Mar 2006 10:06:13 -0800 (PST) From: "Francois Audet" Date: Thu, 9 Mar 2006 10:06:13 -0800 (PST) Subject: RE: [Ietf-behave] Re: ICMP behave draft Message-ID: <1ECE0EB50388174790F9694F77522CCF077D01F1@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain My suggestion would be that the authors clean up the drafts of any overlapping material with completed work (i.e., draft-ietf-behave-nat-udp-04). Otherwise, this is not helpful. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wing > Sent: Thursday, March 09, 2006 09:46 > To: 'Cullen Jennings'; 'Pyda Srisuresh'; 'Jiri Kuthan'; 'Behave' > Subject: RE: [Ietf-behave] Re: ICMP behave draft > > > > > At a casual glance (and I may be very wrong...) Some of these > > requirements are already covered in the UDP draft. > > I made some comments on this draft to the authors so I'll > throw in a few thoughts on where there is some requirement > overlap that I noticed: > > > 1. ietf-behave-nat-udp-04.txt, section 9, discusses ICMP > behavior. In that section is REQ-12 which says: > > REQ-12: Receipt of any sort of ICMP message MUST NOT > destroy the NAT > mapping. > a) The NAT's default configuration SHOULD NOT filter > ICMP messages > based on their source IP address. > b) It is RECOMMENDED that a NAT support ICMP Destination > Unreachable messages. > > which seems to overlap partially with REQ-2 in > srisuresh-behave-nat-icmp-01: > > REQ-2: A NAT device MUST transparently forward ICMP error packets > to the target end node, so long as the NAT has active mapping for > for the embedded payload. If the NAT does not have an active > mapping for the embedded payload, the NAT should silently drop the > ICMP error packet. In the case the ICMP error packet is originated > by a node in the private realm for which the NAT device has no > mapping, the NAT device MUST use its own IP address in the public > realm to translate the originating node IP address in the outer > IP header. > > and overlaps completely with REQ-3 in srisuresh-behave-nat-icmp-01: > > REQ-3: While processing an ICMP error packet, a NAT device > MUST NOT > refresh or delete the NAT Session that pertains to the embedded > payload within the ICMP error packet. > > > 2. ICMP Don't Fragment handling. ietf-behave-nat-udp-04 says: > > If the packet has DF=1, the NAT SHOULD send back an ICMP message > "fragmentation needed and DF set" message to the host as > described in > RFC 792 [2]. > > If the packet has DF=0, the NAT SHOULD fragment the packet and send > the fragments, in order. This is the same function a > router performs > in a similar situation RFC 1812 [5]. > > and ietf-behave-nat-udp-04 also says: > > REQ-13: A NAT MUST support fragmentation of packets larger > than link > MTU. > > compared to srisuresh-behave-nat-icmp-01 which says: > > REQ-5: If DF bit is set on a transit IP packet and the NAT > device cannot forward the packet without fragmentation, the > NAT device MUST send a "Packet too big" ICMP message (ICMP > type 3, Code 4) with a suggested MTU back to the sender and > drop the original IP packet. > > > > What is interesting is that > draft-srisuresh-behave-nat-icmp-01.txt has a different scope > and applies to both TCP, UDP, and ICMP bindings (an ICMP > binding is one that exists while you're doing a ping or an > ICMP-based traceroute (which is what Windows' "tracert" > does)), whereas -behave-nat-udp only applies to UDP bindings. > > I expect the TCP BEHAVE document will discuss ICMP behavior > for ICMPs that are associated with TCP flows in a manner > similar to what is in ietf-behave-nat-udp-04. > > > Would it be valuable to scope an ICMP draft to discuss only > ICMP sessions -- that is, ICMP bindings that are created as a > result of running the ping utility or an ICMP-based > traceroute utility (such as "tracert.exe" on Windows)? > > -d > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From ft@it.su.se Fri, 10 Mar 2006 06:34:51 -0800 (PST) From: Fredrik Thulin Date: Fri, 10 Mar 2006 06:34:51 -0800 (PST) Subject: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 Message-ID: <200603101534.46519.ft@it.su.se> MIME-Version: 1.0 Content-Type: text/plain Hi I have some comments on draft-ietf-behave-rfc3489bis-03. For me, who don't know RFC3489, some of these comments are on stuff that seems to be just plain errors where I have no idea what the correct text would be. 7.1. Request Transaction Reliability "If a failure occurs and the SRV query indicated other STUN servers are available," DNS SRV querying for STUN servers haven't been defined/explained at this point in the document. 15.1. STUN Message Type Registry 0x0002 : Shared Secret Request 0x0102 : Shared Secret Response 0x0112 : Shared Secret Error Response 0x0002 : Shared Secret Request 0x0102 : Shared Secret Responsed 0x0112 : Shared Secret Error Response three duplicate types 15.2. STUN Attribute Registry 0X0005: CHANGED-ADDRESS ^ nit: capital X in this one 0x000E: ALTERNATE-SERVER 0x8023: ALTERNATE-SERVER which one is erroneous? If they are actually just two values for the same thing, then I have missed the text explaining that. 11. STUN Attributes XOR-ONLY O - - What is XOR-ONLY? This is the only occurance of XOR-ONLY in the whole document. 11.8. MESSAGE-INTEGRITY However, STUN clients MUST be able to successfully parse and process STUN messages which have additional attributes after the MESSAGE-INTEGRITY attribute. STUN clients that are compliant with this specification SHOULD ignore attributes that are after the MESSAGE-INTEGRITY attribute. Isn't it contradictory to say that clients should a) parse and process, and b) ignore attributes after the MESSAGE-INTEGRITY attribute? 11.11. ALTERNATE-SERVER The alternate server represents an alternate IP address and port for a different TURN server to try. It is encoded in the same way as MAPPED-ADDRESS. TURN server? What TURN server? Is this perhaps related to my question above about the duplicate ALTERNATE-SERVER attributes? 12.5.3. Server Determination of Usage ... For example, the server could advertise The example is missing. 13.2.3. Approach III: Rogue Router or NAT Todo: RESPONSE-ADDRESS has been removed from this version of the specification. Reword or remove above paragraph accordingly. It might be true that none of the usage describing paragraph includes the RESPONSE-ADDRESS, but section 11.12 is still there so someone might implement it by mistake. /Fredrik From narten@us.ibm.com Fri, 10 Mar 2006 08:07:28 -0800 (PST) From: Thomas Narten Date: Fri, 10 Mar 2006 08:07:28 -0800 (PST) Subject: Re: [Ietf-behave] ICMP Behave draft In-Reply-To: <20060309172102.70497.qmail@web33302.mail.mud.yahoo.com> Message-ID: <200603101607.k2AG73YE028064@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain Pyda Srisuresh writes: > > For example, if instead of figure 1 in the nat-icmp draft we put 3 hosts > > in the private realm Y (y1,y2,y3). > > An ICMP host unreachable message from Router-y upon a packet from Host-x > > to host-y1 will be transferred to host-x as host unreachable (host-y'). > [suresh] The ICMP host unreachable message does embed the first 8 > bytes of the session that could not be forwarded. This includes the > TCP/UDP port numbers that form the session tuple. As such, that > should indicate to the originating host that the destination is not > reachable on the specific session tuple. However, that would change the semantics of ICMP "dest unreachable" as it is defined today, and has been defined for 25 years. This is simply a non starter.. > [suresh] You are abosolutely right. There is that danger that end > hosts could misinterpret the "ICMP destination unreachable message" > (especially, host unreachable and net unreachable) and stop sending > packets to Y1, Y2, Y3, although only Y1 has a problem. As you say, > the NAPT device SHOULD fix the "ICMP destination unreachable > message" to be port unreachable. Again, this would be incorrect. "port unreachable" is not the same thing as "dest unreachable". The former means there is no process (or other entity) listening at that port on the specific machine, and is in essence a different kind of error than "there is no working path to the target at the moment". Again, I don't see that as an appropriate "fix". > In the specific case you mention, most likely, the inside host-y1 > had originated a session to Host-X and was disconnected later > on. This is analogous to a case where you have a process start on a > public host, initiate connections and abort at some point. In the > case of the the public host aborting, the host woudl send ICMP (port > unreachable) message to host-X. This is what the NAPT device should > do as well. Except, in the "analagous case" you mention, the sending process has really gone away and there is no possible recovery. In the case of a temporary path failure, the sending process is still there and it would be possible to have the communication recover once the path problem clears up. Dest unreachable != port unreachable. I don't see it being appropriate to map one type error into the other. Thomas From dwing@cisco.com Fri, 10 Mar 2006 09:17:33 -0800 (PST) From: "Dan Wing" Date: Fri, 10 Mar 2006 09:17:33 -0800 (PST) Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 In-Reply-To: <200603101534.46519.ft@it.su.se> Message-ID: <17bd01c64466$84eb1670$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > I have some comments on draft-ietf-behave-rfc3489bis-03. For me, who > don't know RFC3489, some of these comments are on stuff that > seems to be just plain errors where I have no idea what the correct > text would be. Thanks for your review. Comments inline. > 7.1. Request Transaction Reliability > > "If a failure occurs and the SRV query > indicated other STUN servers are available," > > DNS SRV querying for STUN servers haven't been > defined/explained at this point in the document. I can add a forward reference. I'll fix that in -04. > 15.1. STUN Message Type Registry > > 0x0002 : Shared Secret Request > 0x0102 : Shared Secret Response > 0x0112 : Shared Secret Error Response > 0x0002 : Shared Secret Request > 0x0102 : Shared Secret Responsed > 0x0112 : Shared Secret Error Response > > three duplicate types Editing error, thanks for catching that. I'll fix this in -04. > 15.2. STUN Attribute Registry > > 0X0005: CHANGED-ADDRESS > ^ nit: capital X in this one > > 0x000E: ALTERNATE-SERVER > 0x8023: ALTERNATE-SERVER > > which one is erroneous? If they are actually just two values for the > same thing, then I have missed the text explaining that. 0x000e is correct. I'll fix this in -04. > 11. STUN Attributes > > > XOR-ONLY O - - > > What is XOR-ONLY? This is the only occurance of XOR-ONLY in the whole > document. XOR-ONLY was in rfc3489bis-02 (and earlier version), and was how a STUN client asked to _not_ get a MAPPED-ADDRESS. In -03, we changed how the STUN client and STUN server determine if a MAPPED-ADDRESS or an XOR-MAPPED-ADDRESS is returned so that XOR-ONLY is no longer necessary. This latent XOR-ONLY is a mistake and will be removed in -04. Thanks. > 11.8. MESSAGE-INTEGRITY > However, STUN > clients MUST be able to successfully parse and process > STUN messages > which have additional attributes after the MESSAGE-INTEGRITY > attribute. STUN clients that are compliant with this specification > SHOULD ignore attributes that are after the MESSAGE-INTEGRITY > attribute. > > > Isn't it contradictory to say that clients should a) parse > and process, > and b) ignore attributes after the MESSAGE-INTEGRITY attribute? The text should be more clear; the intent is that STUN clients (and servers, actually) be able to parse and process the portion of the message protected by MESSAGE-INTEGRITY, but also to not get upset if there happens to be additional STUN attributes after the MESSAGE-INTEGRITY attribute. Any attributes which appear after MESSAGE-INTEGRITY are ignored. We want this for extensibility. I will clarify that sentence in -04. Thanks. > 11.11. ALTERNATE-SERVER > > The alternate server represents an alternate IP address > and port for > a different TURN server to try. It is encoded in the same way as > MAPPED-ADDRESS. > > TURN server? What TURN server? Is this perhaps related to my question > above about the duplicate ALTERNATE-SERVER attributes? Sorry, I pulled that text from the TURN document and neglected to generalize it. Please note that the ALTERNATE-SERVER attribute isn't used in any of the usages defined in RFC3489bis; the only usage that currently uses that attribute is TURN (draft-ietf-behave-turn-00.txt). I will generalize that text so that instead of saying TURN it says "for a different STUN server to try." > 12.5.3. Server Determination of Usage > > ... > For example, the server could advertise > > The example is missing. Thanks for catching that. I will add an example in -04. > 13.2.3. Approach III: Rogue Router or NAT > > Todo: RESPONSE-ADDRESS has been removed from this > version of the > specification. Reword or remove above paragraph accordingly. > > It might be true that none of the usage describing paragraph includes > the RESPONSE-ADDRESS, but section 11.12 is still there so > someone might implement it by mistake. Yes, that's true. That's why we have an Issue raised in the document: Issue: should this attribute be made specific to Binding Discovery or moved to another document entirely. for the RESPONSE-ADDRESS, CHANGED-ADDRESS, CHANGE-REQUEST, SOURCE-ADDRESS, and REFLECTED-FROM attributes. Those five attributes are only useful if a STUN client is attempting to determine the 'type' of NAT it is behind. In RFC3489 four types of NATs were defined (see section 5 of RFC3489). This was known at the time to be brittle. Since then we have found it not useful to know what kind of NAT you're behind. The authors haven't reached consensus about what to do with these five attributes. We will be asking the BEHAVE WG to help decide if those five attributes stay in the document somehow (perhaps with strict warnings to not implement them) or are removed from the document entirely (and maybe placed into another document or just allowed to exist in RFC3489). There are issues with backwards compatibility with removing them outright, and the issue you raised with leaving them in (such as someone inadvertantly and unnecessarily implementing support for these attributes). Thanks again for your detailed review of this document. -d From srisuresh@yahoo.com Fri, 10 Mar 2006 09:56:24 -0800 (PST) From: Pyda Srisuresh Date: Fri, 10 Mar 2006 09:56:24 -0800 (PST) Subject: Destination Unreachable message handling (Was Re: [Ietf-behave] ICMP Behave draft) In-Reply-To: <200603101607.k2AG73YE028064@cichlid.raleigh.ibm.com> Message-ID: <20060310175624.22166.qmail@web33314.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Thomas, Thank you for your comments. Plese see my responses below inline. regards, suresh --- Thomas Narten wrote: > Pyda Srisuresh writes: > > > > For example, if instead of figure 1 in the nat-icmp draft we put 3 hosts > > > in the private realm Y (y1,y2,y3). > > > An ICMP host unreachable message from Router-y upon a packet from Host-x > > > to host-y1 will be transferred to host-x as host unreachable (host-y'). > > > [suresh] The ICMP host unreachable message does embed the first 8 > > bytes of the session that could not be forwarded. This includes the > > TCP/UDP port numbers that form the session tuple. As such, that > > should indicate to the originating host that the destination is not > > reachable on the specific session tuple. > > However, that would change the semantics of ICMP "dest unreachable" as > it is defined today, and has been defined for 25 years. This is simply > a non starter.. > > > [suresh] You are abosolutely right. There is that danger that end > > hosts could misinterpret the "ICMP destination unreachable message" > > (especially, host unreachable and net unreachable) and stop sending > > packets to Y1, Y2, Y3, although only Y1 has a problem. As you say, > > the NAPT device SHOULD fix the "ICMP destination unreachable > > message" to be port unreachable. > > Again, this would be incorrect. "port unreachable" is not the same > thing as "dest unreachable". The former means there is no process (or > other entity) listening at that port on the specific machine, and is > in essence a different kind of error than "there is no working path > to the target at the moment". > > Again, I don't see that as an appropriate "fix". > [suresh] Thomas - As you know, it is still "Destination Unreachable" message (i.e., ICMP type 3). We were not suggesting to change the ICMP type. We were just sugesting to change the ICMP code - I.e., "Host unreachable" (code 0) or "Net unreachable" (code 1) to "Port unreachable" (code 3). The NAPT is mapping the specific public endpoint to the private host Y1 that originated the session. If Y1 had a multiple sessions initiated before it got disconnected, every one of those sessions from Y1 may generate a distinct port unreachable message. As such, the "Port unreachable" messages will effect only the sessions associated with host Y1, and does not effect other private hosts. If the host Y1 or the connectivity path from Y1 did recover and the processes on Y1 initiated new sessions, they will have new NAT mappings and the sessions will go throuhg. Essentially, the fix ensure that connectivity to the entire set of private hosts behind NAPT is not lost. If you have an alternate suggestion to fix, please do suggest. Thanks. > > In the specific case you mention, most likely, the inside host-y1 > > had originated a session to Host-X and was disconnected later > > on. This is analogous to a case where you have a process start on a > > public host, initiate connections and abort at some point. In the > > case of the the public host aborting, the host woudl send ICMP (port > > unreachable) message to host-X. This is what the NAPT device should > > do as well. > > Except, in the "analagous case" you mention, the sending process has > really gone away and there is no possible recovery. In the case of a > temporary path failure, the sending process is still there and it > would be possible to have the communication recover once the path > problem clears up. > [suresh] In the "Analogous case", there is no recovery until the same or another process binds to that port again at some time. In the NAPT case, with the fix suggested, the recovery is gone on the specific port, until NAT recycles the port to the same or another host behind it. In the case of temporary path failure, You are right. The process on Y1 still exists, but when the path failure recovers and the process on Y1 attempts to send data, it would not succeed. The process on Y1 would have to restart the session. If the path failure lasted through the NAT idle period, the process would also have had to restart the session, irrespective whether was an ICMP Destination unreachable message was exchanged or not. Aplications that are adaptive to NATs know they have to retry the session, when a failure occurs. As you correctly point out, there are pros and cons to both approaches. In one case (not changing the ICMP code), connectivity is denied to all hosts behind NAPT. In another case, connectivity is denied to a specific process on a host in some scenarios (as in temporary path failure). That said, it seems to me, the former is the lesser of the two evils. Do you agree? Would it work for you if I included the negative repercussion of changing the ICMP code (as you articulate) in the draft along with the suggested recommendation? Thanks. regards, suresh > Dest unreachable != port unreachable. I don't see it being appropriate > to map one type error into the other. > > Thomas > From srisuresh@yahoo.com Fri, 10 Mar 2006 10:44:16 -0800 (PST) From: Pyda Srisuresh Date: Fri, 10 Mar 2006 10:44:16 -0800 (PST) Subject: Scope of ICMP draft (WAS RE: [Ietf-behave] Re: ICMP behave draft) In-Reply-To: <073f01c643a1$602b3d80$c5f0200a@amer.cisco.com> Message-ID: <20060310184416.65689.qmail@web33315.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Dan, Thank you for the detailed comments. Thanks also for the comments you sent in private e-mails. I will share some of that material (from private e-mails) here, as appropriate. I hope, you dont mind. At its core, I believe, your comments refer to the scope of the ICMP draft. I changed the subject line accordingly. Below are my thoughts on the scope. I responded to your specific comments inline. Broadly, ICMP has Query messages and Error messages. The ICMP query messages are strictly ICMP specific, unrelated to TCP or UDP. Req-1 of the ICMP draft addresses this. However, the ICMP error messages that transit NATs or the ICMP error messages that NAT generates are generic and may be triggered by any of the TCP/UDP/ICMP packets that traverse NATs. Take for example, the new requirement you brought up (in a private e-mail) about requiring NATs to generate "TTL exceeded" ICMP error message when TTL goes to 0. This applies to any IP packet - UDP or ICMP or what have you. NATs should send this message. But, as you know, not all NATs do. This requirement is not covered in UDP or TCP draft. Rightly so, in my opinion. Take the "Destination unreachable" message handling that Meir had brought up recently (in another thread). The specific ICMP error message handling is not covered in UDP or TCP draft. Rightly so, in my opinion. Take the case of outer header processing requirement in REQ-2 of the ICMP draft. This is generic to all ICMP errors and not covered in UDP or TCP draft. Rightly so, in my opinion. Take Req-4 of the ICMP draft, which refers to NAT generating an error message when it runs out of resources. This can happen when processing TCP or UDP new flows. This is not covered in UDP or TCP drafts. Right so, in my opinion. The overlap with the UDP draft was not avoidable in some cases. Take the case of ICMP destination unreachanble message. The UDP draft states that ICMP destination unreachanvble messages should be supported by the NAT, but says nothing about forwarding other ICMP error messages. Likewise, the UDP draft talks about fragment processing, but the requirement doesnt reflect the genration or forwarding of the "Packet too big" error message. As such, the overlap is unavoidable. However, it does make sense to add a statement in the ICMP draft to the effect that ICMP requirements in the TCP or UDP drafts should take precedence over the general ICMP requirements stated in the ICMP draft. Does this work for you? What do others think? Thanks. regards, suresh --- Dan Wing wrote: > > > At a casual glance (and I may be very wrong...) Some of these > > requirements are already covered in the UDP draft. > > I made some comments on this draft to the authors so I'll throw in a few [suresh] Thanks. They were helpful, especilaly the comment about some NATs behaving insanely with traceroute. We will update the next rev of the draft to add the requirement that NATs SHOULD generate "TTL exceeded" ICMP message when TTL goes to 0. > thoughts on where there is some requirement overlap that I noticed: > > > 1. ietf-behave-nat-udp-04.txt, section 9, discusses ICMP behavior. In that > section is REQ-12 which says: > > REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT > mapping. > a) The NAT's default configuration SHOULD NOT filter ICMP messages > based on their source IP address. > b) It is RECOMMENDED that a NAT support ICMP Destination > Unreachable messages. > > which seems to overlap partially with REQ-2 in srisuresh-behave-nat-icmp-01: > > REQ-2: A NAT device MUST transparently forward ICMP error packets > to the target end node, so long as the NAT has active mapping for > for the embedded payload. If the NAT does not have an active > mapping for the embedded payload, the NAT should silently drop the > ICMP error packet. In the case the ICMP error packet is originated > by a node in the private realm for which the NAT device has no > mapping, the NAT device MUST use its own IP address in the public > realm to translate the originating node IP address in the outer > IP header. > > and overlaps completely with REQ-3 in srisuresh-behave-nat-icmp-01: > > REQ-3: While processing an ICMP error packet, a NAT device MUST NOT > refresh or delete the NAT Session that pertains to the embedded > payload within the ICMP error packet. > [suresh] The overlap is not a conflict, I might add. Please see my comments below. Req-2 of ICMP draft mandates that all ICMP error messages be forwarded, not just "destination unreachable" error message. Req-12 of the UDP draft RECOMMENDS that NATs should support ICMP destination unreachable message. By "support", I assume "support forwarding" as the UDP draft discusses at length about forwarding ICMP destination unreachable messages in the explanation text that precedes it. Further, Req-2 of ICMP draft states how the ICMP error message SHOULD be encapsulated. This is not covered by the UDP draft. As for Req-3 of the ICMP draft being a complete overlap of Req-12 of UDP, I didnt see it that way. The UDP draft makes the statement "Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping", but does not state why. Furthr, the UDP draft only refers to NOT destroying the NAT maaping and says nothing about refreshing. Req-3 of the ICMP draft states that NAT should not refresh or delete NAT mapping and explains why. > > 2. ICMP Don't Fragment handling. ietf-behave-nat-udp-04 says: > > If the packet has DF=1, the NAT SHOULD send back an ICMP message > "fragmentation needed and DF set" message to the host as described in > RFC 792 [2]. > > If the packet has DF=0, the NAT SHOULD fragment the packet and send > the fragments, in order. This is the same function a router performs > in a similar situation RFC 1812 [5]. > > and ietf-behave-nat-udp-04 also says: > > REQ-13: A NAT MUST support fragmentation of packets larger than link > MTU. > > compared to srisuresh-behave-nat-icmp-01 which says: > > REQ-5: If DF bit is set on a transit IP packet and the NAT > device cannot forward the packet without fragmentation, the > NAT device MUST send a "Packet too big" ICMP message (ICMP > type 3, Code 4) with a suggested MTU back to the sender and > drop the original IP packet. > [suresh] Req-5 of the ICMP draft states that a NAT should generate "Packet too big" ICMP message when it cannot enforce the "DF" bit. Section 2.4.2 of the ICMP draft also states that a NAT should forward "Packet too big" messages (reinforcing Req-2 of ICMP draft). Req-13 of the UDP draft does not say anything about NAT generating an ICMP error message. This is in spite of the fact that the text that preceds it does discuss DF processing. Basically, the focus of the ICMP draft is on ICMP messages, wehreas the UDP draft was focusing on fragmentation. > > > What is interesting is that draft-srisuresh-behave-nat-icmp-01.txt has a > different scope and applies to both TCP, UDP, and ICMP bindings (an ICMP > binding is one that exists while you're doing a ping or an ICMP-based > traceroute (which is what Windows' "tracert" does)), whereas -behave-nat-udp > only applies to UDP bindings. > > I expect the TCP BEHAVE document will discuss ICMP behavior for ICMPs that > are associated with TCP flows in a manner similar to what is in > ietf-behave-nat-udp-04. > > > Would it be valuable to scope an ICMP draft to discuss only ICMP sessions -- > that is, ICMP bindings that are created as a result of running the ping > utility or an ICMP-based traceroute utility (such as "tracert.exe" on > Windows)? [suresh] Please see my comments at the outset on the scope. Thanks. regards, suresh > > -d > From srisuresh@yahoo.com Fri, 10 Mar 2006 10:57:23 -0800 (PST) From: Pyda Srisuresh Date: Fri, 10 Mar 2006 10:57:23 -0800 (PST) Subject: RE: [Ietf-behave] Re: ICMP behave draft In-Reply-To: <1ECE0EB50388174790F9694F77522CCF077D01F1@zrc2hxm0.corp.nortel.com> Message-ID: <20060310185723.52609.qmail@web33313.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Francois, Please see my response to Dan on the Scope. In that I mentioned that I would be happy to add a statement in the ICMP draft to the effect that ICMP requirements in the TCP or UDP drafts should take precedence over the general ICMP requirements stated in the ICMP draft. Hope that works for you. Please respond if this would work for for you in the other thread (labelled "Scope of ICMP draft"). Thanks. regards, suresh --- Francois Audet wrote: > My suggestion would be that the authors clean up the drafts of any > overlapping material with completed work (i.e., > draft-ietf-behave-nat-udp-04). > > Otherwise, this is not helpful. > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wing > > Sent: Thursday, March 09, 2006 09:46 > > To: 'Cullen Jennings'; 'Pyda Srisuresh'; 'Jiri Kuthan'; 'Behave' > > Subject: RE: [Ietf-behave] Re: ICMP behave draft > > > > > > > > > At a casual glance (and I may be very wrong...) Some of these > > > requirements are already covered in the UDP draft. > > > > I made some comments on this draft to the authors so I'll > > throw in a few thoughts on where there is some requirement > > overlap that I noticed: > > > > > > 1. ietf-behave-nat-udp-04.txt, section 9, discusses ICMP > > behavior. In that section is REQ-12 which says: > > > > REQ-12: Receipt of any sort of ICMP message MUST NOT > > destroy the NAT > > mapping. > > a) The NAT's default configuration SHOULD NOT filter > > ICMP messages > > based on their source IP address. > > b) It is RECOMMENDED that a NAT support ICMP Destination > > Unreachable messages. > > > > which seems to overlap partially with REQ-2 in > > srisuresh-behave-nat-icmp-01: > > > > REQ-2: A NAT device MUST transparently forward ICMP error packets > > to the target end node, so long as the NAT has active mapping for > > for the embedded payload. If the NAT does not have an active > > mapping for the embedded payload, the NAT should silently drop the > > ICMP error packet. In the case the ICMP error packet is originated > > by a node in the private realm for which the NAT device has no > > mapping, the NAT device MUST use its own IP address in the public > > realm to translate the originating node IP address in the outer > > IP header. > > > > and overlaps completely with REQ-3 in srisuresh-behave-nat-icmp-01: > > > > REQ-3: While processing an ICMP error packet, a NAT device > > MUST NOT > > refresh or delete the NAT Session that pertains to the embedded > > payload within the ICMP error packet. > > > > > > 2. ICMP Don't Fragment handling. ietf-behave-nat-udp-04 says: > > > > If the packet has DF=1, the NAT SHOULD send back an ICMP message > > "fragmentation needed and DF set" message to the host as > > described in > > RFC 792 [2]. > > > > If the packet has DF=0, the NAT SHOULD fragment the packet and send > > the fragments, in order. This is the same function a > > router performs > > in a similar situation RFC 1812 [5]. > > > > and ietf-behave-nat-udp-04 also says: > > > > REQ-13: A NAT MUST support fragmentation of packets larger > > than link > > MTU. > > > > compared to srisuresh-behave-nat-icmp-01 which says: > > > > REQ-5: If DF bit is set on a transit IP packet and the NAT > > device cannot forward the packet without fragmentation, the > > NAT device MUST send a "Packet too big" ICMP message (ICMP > > type 3, Code 4) with a suggested MTU back to the sender and > > drop the original IP packet. > > > > > > > > What is interesting is that > > draft-srisuresh-behave-nat-icmp-01.txt has a different scope > > and applies to both TCP, UDP, and ICMP bindings (an ICMP > > binding is one that exists while you're doing a ping or an > > ICMP-based traceroute (which is what Windows' "tracert" > > does)), whereas -behave-nat-udp only applies to UDP bindings. > > > > I expect the TCP BEHAVE document will discuss ICMP behavior > > for ICMPs that are associated with TCP flows in a manner > > similar to what is in ietf-behave-nat-udp-04. > > > > > > Would it be valuable to scope an ICMP draft to discuss only > > ICMP sessions -- that is, ICMP bindings that are created as a > > result of running the ping utility or an ICMP-based > > traceroute utility (such as "tracert.exe" on Windows)? > > > > -d > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > From fernando@gont.com.ar Fri, 10 Mar 2006 11:09:53 -0800 (PST) From: Fernando Gont Date: Fri, 10 Mar 2006 11:09:53 -0800 (PST) Subject: Re: [Ietf-behave] Re: ICMP behave draft In-Reply-To: <20060305192403.70993.qmail@web33311.mail.mud.yahoo.com> Message-ID: <7.0.1.0.0.20060310151115.06b42bd0@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain At 12:00 a.m. 09/03/2006, Cullen Jennings wrote: It's the usual scope issue. This document may be great advice on how to build a NAT. The question is, which of these items do we need NATs to do differently from what they do today so that applications can work better behind NATs. And what applications would take advantage of the new behavior. If people think there are key things here, and can say what application needs them and that NATs currently do the wrong thing, I glad to set priorities accordingly but right now I am unclear on how to prioritize this. How about this: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-00.txt ? The document describes a work around for long delays between connection-establishment attempts, based on an alternative processing of the so-called ICMP "soft errors". It's already implemented in a variety of TCP/IP stacks. The slides used at IETF 64 for the presentation of this document may be a good companion to the actual internet-draft. Kindest regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx From fernando@gont.com.ar Fri, 10 Mar 2006 11:10:11 -0800 (PST) From: Fernando Gont Date: Fri, 10 Mar 2006 11:10:11 -0800 (PST) Subject: RE: [Ietf-behave] ICMP Behave draft In-Reply-To: <30F0D7625E0DEC4E83A2A94596BC18B7930F23@VRZIL-EX01.il.veraznetworks.com> Message-ID: <7.0.1.0.0.20060310151124.0262f3f0@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain At 01:50 p.m. 09/03/2006, Meir Leshem wrote: According to draft-srisuresh-behave-nat-icmp-01, "A NAT device MUST transparently forward ICMP error packets to the target end node, so long as the NAT has active mapping for the embedded payload" (REQ-2). In the case of NAPT device (defined in RFC 3022), some ICMP error messages might cause problems if transferred transparently by a NAPT device. For example, if instead of figure 1 in the nat-icmp draft we put 3 hosts in the private realm Y (y1,y2,y3). An ICMP host unreachable message from Router-y upon a packet from Host-x to host-y1 will be transferred to host-x as host unreachable (host-y'). As a result host-x will stop sending packets to y1,y2,y3 although only y1 has a problem. So my understanding is that in this case, for ICMP (host unreachable, net unreachable) messages from Router-y, the NAPT device must send ICMP (port unreachable) messages to Host-x instead. Host and net unreachables are considered "soft errors". Thus, RFC1122-compliant implementations won't stop sending packets to those hosts. Also, the receiving system will use the four-tuple included in the ICMP payload to match the error message to the corresponding TCP connection. Kindest regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx From fernando@gont.com.ar Fri, 10 Mar 2006 11:10:14 -0800 (PST) From: Fernando Gont Date: Fri, 10 Mar 2006 11:10:14 -0800 (PST) Subject: RE: [Ietf-behave] ICMP Behave draft In-Reply-To: <30F0D7625E0DEC4E83A2A94596BC18B7930F23@VRZIL-EX01.il.veraznetworks.com> Message-ID: <7.0.1.0.0.20060310151251.055b1d40@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain At 02:21 p.m. 09/03/2006, Pyda Srisuresh wrote: > For example, if instead of figure 1 in the nat-icmp draft we put 3 hosts > in the private realm Y (y1,y2,y3). > An ICMP host unreachable message from Router-y upon a packet from Host-x > to host-y1 will be transferred to host-x as host unreachable (host-y'). > [suresh] The ICMP host unreachable message does embed the first 8 bytes of the session that could not be forwarded. This includes the TCP/UDP port numbers that form the session tuple. As such, that should indicate to the originating host that the destination is not reachable on the specific session tuple. Thinking out loud, there may be cases in which, due to use of tunnels, you may not get the TCP/UDP ports. Kindest regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx From fernando@gont.com.ar Fri, 10 Mar 2006 11:10:32 -0800 (PST) From: Fernando Gont Date: Fri, 10 Mar 2006 11:10:32 -0800 (PST) Subject: Re: [Ietf-behave] ICMP Behave draft In-Reply-To: <200603101607.k2AG73YE028064@cichlid.raleigh.ibm.com> Message-ID: <7.0.1.0.0.20060310151627.0263e008@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain At 01:07 p.m. 10/03/2006, Thomas Narten wrote: > > For example, if instead of figure 1 in the nat-icmp draft we put 3 hosts > > in the private realm Y (y1,y2,y3). > > An ICMP host unreachable message from Router-y upon a packet from Host-x > > to host-y1 will be transferred to host-x as host unreachable (host-y'). > [suresh] The ICMP host unreachable message does embed the first 8 > bytes of the session that could not be forwarded. This includes the > TCP/UDP port numbers that form the session tuple. As such, that > should indicate to the originating host that the destination is not > reachable on the specific session tuple. However, that would change the semantics of ICMP "dest unreachable" as it is defined today, and has been defined for 25 years. This is simply a non starter.. RFC1122 says that the ICMP error messages will be demultiplexed based on the ICMP payload. I don't see where the semantics would be changing. > [suresh] You are abosolutely right. There is that danger that end > hosts could misinterpret the "ICMP destination unreachable message" > (especially, host unreachable and net unreachable) and stop sending > packets to Y1, Y2, Y3, although only Y1 has a problem. As you say, > the NAPT device SHOULD fix the "ICMP destination unreachable > message" to be port unreachable. Again, this would be incorrect. "port unreachable" is not the same thing as "dest unreachable". The former means there is no process (or other entity) listening at that port on the specific machine, and is in essence a different kind of error than "there is no working path to the target at the moment". Fair enough if we are thinking about RFC1122. But TCP has its own mechanism for indicating "port unreachables" (namely, RST segments). I guess processing of ICMP port unreachables as "hard errors" (i.e., aborting connections) had to do with compatibility with old TCP/IP stacks. All Mentat-derived and BSD-derived implementations treat the so-called ICMP hard errors (such as port unreachables) as soft errors when they are meant for connections in any of the synchronized states. Kindest regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx From fernando@gont.com.ar Fri, 10 Mar 2006 11:10:47 -0800 (PST) From: Fernando Gont Date: Fri, 10 Mar 2006 11:10:47 -0800 (PST) Subject: Re: [Ietf-behave] ICMP Behave draft In-Reply-To: <20060308213129.19447.qmail@web33306.mail.mud.yahoo.com> Message-ID: <7.0.1.0.0.20060310153918.06a07998@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain At 06:31 p.m. 08/03/2006, Pyda Srisuresh wrote: New rev of the ICMP behave draft (draft-srisuresh-behave-nat-icmp-01.txt) is now available for review. Please give this a read and provide your feedback. One key objective is to understand if there is interest in pursuing the ICMP work in this draft as a WG item. We also requested for a slot in the upcoming WG meeting for this draft. Thanks. Have a look at the Appendix in http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-00.txt about "Additional checks". The IP checksum of the ICMP payload should be checked. If possible, so should the TCP checksum contained in the ICMP payload, etc. Kindest regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx From audet@nortel.com Fri, 10 Mar 2006 11:34:06 -0800 (PST) From: "Francois Audet" Date: Fri, 10 Mar 2006 11:34:06 -0800 (PST) Subject: RE: [Ietf-behave] Re: ICMP behave draft Message-ID: <1ECE0EB50388174790F9694F77522CCF0787F25A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain That's fine with me. But if there are specific statements that need to be altered to avoid conflict altogether, we should do it. I don't have specific proposals on that. > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > Sent: Friday, March 10, 2006 10:57 > To: Audet, Francois [SC100:3055:EXCH]; Dan Wing; Cullen > Jennings; Jiri Kuthan; Behave > Subject: RE: [Ietf-behave] Re: ICMP behave draft > > > Francois, > > Please see my response to Dan on the Scope. In that I > mentioned that I would be happy to add a statement in the > ICMP draft to the effect that ICMP requirements in the TCP or > UDP drafts should take precedence over the general ICMP > requirements stated in the ICMP draft. Hope that works for > you. Please respond if this would work for for you in the > other thread (labelled "Scope of ICMP draft"). Thanks. > > regards, > suresh > > --- Francois Audet wrote: > > > My suggestion would be that the authors clean up the drafts of any > > overlapping material with completed work (i.e., > > draft-ietf-behave-nat-udp-04). > > > > Otherwise, this is not helpful. > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > Behalf Of Dan Wing > > > Sent: Thursday, March 09, 2006 09:46 > > > To: 'Cullen Jennings'; 'Pyda Srisuresh'; 'Jiri Kuthan'; 'Behave' > > > Subject: RE: [Ietf-behave] Re: ICMP behave draft > > > > > > > > > > > > > At a casual glance (and I may be very wrong...) Some of these > > > > requirements are already covered in the UDP draft. > > > > > > I made some comments on this draft to the authors so I'll > > > throw in a few thoughts on where there is some requirement > > > overlap that I noticed: > > > > > > > > > 1. ietf-behave-nat-udp-04.txt, section 9, discusses ICMP > > > behavior. In that section is REQ-12 which says: > > > > > > REQ-12: Receipt of any sort of ICMP message MUST NOT > > > destroy the NAT > > > mapping. > > > a) The NAT's default configuration SHOULD NOT filter > > > ICMP messages > > > based on their source IP address. > > > b) It is RECOMMENDED that a NAT support ICMP Destination > > > Unreachable messages. > > > > > > which seems to overlap partially with REQ-2 in > > > srisuresh-behave-nat-icmp-01: > > > > > > REQ-2: A NAT device MUST transparently forward ICMP > error packets > > > to the target end node, so long as the NAT has active > mapping for > > > for the embedded payload. If the NAT does not have an active > > > mapping for the embedded payload, the NAT should > silently drop the > > > ICMP error packet. In the case the ICMP error packet > is originated > > > by a node in the private realm for which the NAT device has no > > > mapping, the NAT device MUST use its own IP address in > the public > > > realm to translate the originating node IP address in the outer > > > IP header. > > > > > > and overlaps completely with REQ-3 in > srisuresh-behave-nat-icmp-01: > > > > > > REQ-3: While processing an ICMP error packet, a NAT device > > > MUST NOT > > > refresh or delete the NAT Session that pertains to the embedded > > > payload within the ICMP error packet. > > > > > > > > > 2. ICMP Don't Fragment handling. ietf-behave-nat-udp-04 says: > > > > > > If the packet has DF=1, the NAT SHOULD send back an > ICMP message > > > "fragmentation needed and DF set" message to the host as > > > described in > > > RFC 792 [2]. > > > > > > If the packet has DF=0, the NAT SHOULD fragment the > packet and send > > > the fragments, in order. This is the same function a > > > router performs > > > in a similar situation RFC 1812 [5]. > > > > > > and ietf-behave-nat-udp-04 also says: > > > > > > REQ-13: A NAT MUST support fragmentation of packets larger > > > than link > > > MTU. > > > > > > compared to srisuresh-behave-nat-icmp-01 which says: > > > > > > REQ-5: If DF bit is set on a transit IP packet and the NAT > > > device cannot forward the packet without fragmentation, the > > > NAT device MUST send a "Packet too big" ICMP message (ICMP > > > type 3, Code 4) with a suggested MTU back to the sender and > > > drop the original IP packet. > > > > > > > > > > > > What is interesting is that > > > draft-srisuresh-behave-nat-icmp-01.txt has a different scope > > > and applies to both TCP, UDP, and ICMP bindings (an ICMP > > > binding is one that exists while you're doing a ping or an > > > ICMP-based traceroute (which is what Windows' "tracert" > > > does)), whereas -behave-nat-udp only applies to UDP bindings. > > > > > > I expect the TCP BEHAVE document will discuss ICMP behavior > > > for ICMPs that are associated with TCP flows in a manner > > > similar to what is in ietf-behave-nat-udp-04. > > > > > > > > > Would it be valuable to scope an ICMP draft to discuss only > > > ICMP sessions -- that is, ICMP bindings that are created as a > > > result of running the ping utility or an ICMP-based > > > traceroute utility (such as "tracert.exe" on Windows)? > > > > > > -d > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > From srisuresh@yahoo.com Fri, 10 Mar 2006 11:43:18 -0800 (PST) From: Pyda Srisuresh Date: Fri, 10 Mar 2006 11:43:18 -0800 (PST) Subject: RE: [Ietf-behave] Re: ICMP behave draft In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0787F25A@zrc2hxm0.corp.nortel.com> Message-ID: <20060310194317.91502.qmail@web33315.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain OK. I am not aware of any statements that conflict. But, if there are, I agree, that should be avoided. regards, suresh --- Francois Audet wrote: > That's fine with me. > > But if there are specific statements that need to be altered to avoid > conflict > altogether, we should do it. > > I don't have specific proposals on that. > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > Sent: Friday, March 10, 2006 10:57 > > To: Audet, Francois [SC100:3055:EXCH]; Dan Wing; Cullen > > Jennings; Jiri Kuthan; Behave > > Subject: RE: [Ietf-behave] Re: ICMP behave draft > > > > > > Francois, > > > > Please see my response to Dan on the Scope. In that I > > mentioned that I would be happy to add a statement in the > > ICMP draft to the effect that ICMP requirements in the TCP or > > UDP drafts should take precedence over the general ICMP > > requirements stated in the ICMP draft. Hope that works for > > you. Please respond if this would work for for you in the > > other thread (labelled "Scope of ICMP draft"). Thanks. > > > > regards, > > suresh > > > > --- Francois Audet wrote: > > > > > My suggestion would be that the authors clean up the drafts of any > > > overlapping material with completed work (i.e., > > > draft-ietf-behave-nat-udp-04). > > > > > > Otherwise, this is not helpful. > > > > > > > -----Original Message----- > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > > Behalf Of Dan Wing > > > > Sent: Thursday, March 09, 2006 09:46 > > > > To: 'Cullen Jennings'; 'Pyda Srisuresh'; 'Jiri Kuthan'; 'Behave' > > > > Subject: RE: [Ietf-behave] Re: ICMP behave draft > > > > > > > > > > > > > > > > > At a casual glance (and I may be very wrong...) Some of these > > > > > requirements are already covered in the UDP draft. > > > > > > > > I made some comments on this draft to the authors so I'll > > > > throw in a few thoughts on where there is some requirement > > > > overlap that I noticed: > > > > > > > > > > > > 1. ietf-behave-nat-udp-04.txt, section 9, discusses ICMP > > > > behavior. In that section is REQ-12 which says: > > > > > > > > REQ-12: Receipt of any sort of ICMP message MUST NOT > > > > destroy the NAT > > > > mapping. > > > > a) The NAT's default configuration SHOULD NOT filter > > > > ICMP messages > > > > based on their source IP address. > > > > b) It is RECOMMENDED that a NAT support ICMP Destination > > > > Unreachable messages. > > > > > > > > which seems to overlap partially with REQ-2 in > > > > srisuresh-behave-nat-icmp-01: > > > > > > > > REQ-2: A NAT device MUST transparently forward ICMP > > error packets > > > > to the target end node, so long as the NAT has active > > mapping for > > > > for the embedded payload. If the NAT does not have an active > > > > mapping for the embedded payload, the NAT should > > silently drop the > > > > ICMP error packet. In the case the ICMP error packet > > is originated > > > > by a node in the private realm for which the NAT device has no > > > > mapping, the NAT device MUST use its own IP address in > > the public > > > > realm to translate the originating node IP address in the outer > > > > IP header. > > > > > > > > and overlaps completely with REQ-3 in > > srisuresh-behave-nat-icmp-01: > > > > > > > > REQ-3: While processing an ICMP error packet, a NAT device > > > > MUST NOT > > > > refresh or delete the NAT Session that pertains to the embedded > > > > payload within the ICMP error packet. > > > > > > > > > > > > 2. ICMP Don't Fragment handling. ietf-behave-nat-udp-04 says: > > > > > > > > If the packet has DF=1, the NAT SHOULD send back an > > ICMP message > > > > "fragmentation needed and DF set" message to the host as > > > > described in > > > > RFC 792 [2]. > > > > > > > > If the packet has DF=0, the NAT SHOULD fragment the > > packet and send > > > > the fragments, in order. This is the same function a > > > > router performs > > > > in a similar situation RFC 1812 [5]. > > > > > > > > and ietf-behave-nat-udp-04 also says: > > > > > > > > REQ-13: A NAT MUST support fragmentation of packets larger > > > > than link > > > > MTU. > > > > > > > > compared to srisuresh-behave-nat-icmp-01 which says: > > > > > > > > REQ-5: If DF bit is set on a transit IP packet and the NAT > > > > device cannot forward the packet without fragmentation, the > > > > NAT device MUST send a "Packet too big" ICMP message (ICMP > > > > type 3, Code 4) with a suggested MTU back to the sender and > > > > drop the original IP packet. > > > > > > > > > > > > > > > > What is interesting is that > > > > draft-srisuresh-behave-nat-icmp-01.txt has a different scope > > > > and applies to both TCP, UDP, and ICMP bindings (an ICMP > > > > binding is one that exists while you're doing a ping or an > > > > ICMP-based traceroute (which is what Windows' "tracert" > > > > does)), whereas -behave-nat-udp only applies to UDP bindings. > > > > > > > > I expect the TCP BEHAVE document will discuss ICMP behavior > > > > for ICMPs that are associated with TCP flows in a manner > > > > similar to what is in ietf-behave-nat-udp-04. > > > > > > > > > > > > Would it be valuable to scope an ICMP draft to discuss only > > > > ICMP sessions -- that is, ICMP bindings that are created as a > > > > result of running the ping utility or an ICMP-based > > > > traceroute utility (such as "tracert.exe" on Windows)? > > > > > > > > -d > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > > > > > From srisuresh@yahoo.com Fri, 10 Mar 2006 16:37:09 -0800 (PST) From: Pyda Srisuresh Date: Fri, 10 Mar 2006 16:37:09 -0800 (PST) Subject: RE: [Ietf-behave] ICMP Behave draft In-Reply-To: <7.0.1.0.0.20060310151124.0262f3f0@gont.com.ar> Message-ID: <20060311003709.76874.qmail@web33303.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Fernando, You are right, RFC1122 does say that ICMP codes 0 (network unreachable), and 1 (host unreachable) are soft errors and ICMP code 3 (Port unreachable) is a hard error. In case of soft error, the application will retry, whereas the application will simply abort upon a hard error. I was assuming all ICMP codes for the destination unreachable message to be hard error and was concerned about connectivity loss. That is incorrect. I imagine, that may be what Meir thought as well. Thanks for clarifying. Sounds like, what you are saying is that it is not a good idea to convert a soft error (codes 0 or 1 ) into a hard error (code 3). Instead leave the ICMP error message unchanged on NAPT. I imagine, that is what Thomas intends as well. I agree. Unless I hear a counter argument for the above, we will leave the text in the draft unchanged on this. Thanks. regards, suresh --- Fernando Gont wrote: > At 01:50 p.m. 09/03/2006, Meir Leshem wrote: > > >According to draft-srisuresh-behave-nat-icmp-01, "A NAT device MUST > >transparently forward ICMP error packets to the target end node, so > >long as the NAT has active mapping for the embedded payload" (REQ-2). > >In the case of NAPT device (defined in RFC 3022), some ICMP error > >messages might cause problems if transferred transparently by a NAPT > >device. > > > >For example, if instead of figure 1 in the nat-icmp draft we put 3 hosts > >in the private realm Y (y1,y2,y3). > >An ICMP host unreachable message from Router-y upon a packet from Host-x > >to host-y1 will be transferred to host-x as host unreachable (host-y'). > > > >As a result host-x will stop sending packets to y1,y2,y3 although > >only y1 has a problem. > >So my understanding is that in this case, for ICMP (host unreachable, > >net unreachable) messages from Router-y, the NAPT device must send > >ICMP (port unreachable) messages to Host-x instead. > > Host and net unreachables are considered "soft errors". Thus, > RFC1122-compliant implementations won't stop sending packets to those > hosts. Also, the receiving system will use the four-tuple included in > the ICMP payload to match the error message to the corresponding TCP > connection. > > Kindest regards, > > > -- > Fernando Gont > e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx > > > > > > From srisuresh@yahoo.com Fri, 10 Mar 2006 16:58:00 -0800 (PST) From: Pyda Srisuresh Date: Fri, 10 Mar 2006 16:58:00 -0800 (PST) Subject: Re: [Ietf-behave] ICMP Behave draft In-Reply-To: <7.0.1.0.0.20060310151627.0263e008@gont.com.ar> Message-ID: <20060311005800.1823.qmail@web33310.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Fernando Gont wrote: > At 01:07 p.m. 10/03/2006, Thomas Narten wrote: > > > > > For example, if instead of figure 1 in the nat-icmp draft we put 3 > hosts > > > > in the private realm Y (y1,y2,y3). > > > > An ICMP host unreachable message from Router-y upon a packet from > Host-x > > > > to host-y1 will be transferred to host-x as host unreachable (host-y'). > > > > > [suresh] The ICMP host unreachable message does embed the first 8 > > > bytes of the session that could not be forwarded. This includes the > > > TCP/UDP port numbers that form the session tuple. As such, that > > > should indicate to the originating host that the destination is not > > > reachable on the specific session tuple. > > > >However, that would change the semantics of ICMP "dest unreachable" as > >it is defined today, and has been defined for 25 years. This is simply > >a non starter.. > > RFC1122 says that the ICMP error messages will be demultiplexed based > on the ICMP payload. I don't see where the semantics would be changing. > > > > > [suresh] You are abosolutely right. There is that danger that end > > > hosts could misinterpret the "ICMP destination unreachable message" > > > (especially, host unreachable and net unreachable) and stop sending > > > packets to Y1, Y2, Y3, although only Y1 has a problem. As you say, > > > the NAPT device SHOULD fix the "ICMP destination unreachable > > > message" to be port unreachable. > > > >Again, this would be incorrect. "port unreachable" is not the same > >thing as "dest unreachable". The former means there is no process (or > >other entity) listening at that port on the specific machine, and is > >in essence a different kind of error than "there is no working path > >to the target at the moment". > > Fair enough if we are thinking about RFC1122. But TCP has its own > mechanism for indicating "port unreachables" (namely, RST segments). > I guess processing of ICMP port unreachables as "hard errors" (i.e., > aborting connections) had to do with compatibility with old TCP/IP stacks. > [suresh] You are right about TCP using RST to indicate unreachable ports. Perhaps, the port unreachable is more prevalent with UDP apps. > All Mentat-derived and BSD-derived implementations treat the > so-called ICMP hard errors (such as port unreachables) as soft errors > when they are meant for connections in any of the synchronized states. > [suresh] My initial assumption was that ICMP codes 0 and 1 were hard errors and was afraid the end system would simply abort upon seeing this. But, that is not the case. Both these codes are soft errors. So the end nodes will retry upon seeing ICMP codes 0 and 1. So, I am OK with leaving the codes unchanged. It is not a problem if many of the stacks process port unreachable (hard error) as soft error. Thanks. regards, suresh > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx > > > > > > From srisuresh@yahoo.com Fri, 10 Mar 2006 17:17:03 -0800 (PST) From: Pyda Srisuresh Date: Fri, 10 Mar 2006 17:17:03 -0800 (PST) Subject: Re: [Ietf-behave] ICMP Behave draft In-Reply-To: <7.0.1.0.0.20060310153918.06a07998@gont.com.ar> Message-ID: <20060311011703.97721.qmail@web33309.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Hi Fernando, You are right about checking and updating the IP and UDP checksums of the embedded IP packet. However, checking the TCP checksum would not work, as the ICMP error message include just 8 bytes of TCP header. The TCP checksum is past 8 bytes. regards, suresh --- Fernando Gont wrote: > At 06:31 p.m. 08/03/2006, Pyda Srisuresh wrote: > > >New rev of the ICMP behave draft (draft-srisuresh-behave-nat-icmp-01.txt) is > >now available for review. Please give this a read and provide your feedback. > >One key objective is to understand if there is interest in pursuing the ICMP > >work in this draft as a WG item. We also requested for a slot in the > upcoming > >WG meeting for this draft. Thanks. > > Have a look at the Appendix in > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-00.txt > about "Additional checks". The IP checksum of the ICMP payload should > be checked. If possible, so should the TCP checksum contained in the > ICMP payload, etc. > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx > > > > > > From srisuresh@yahoo.com Sat, 11 Mar 2006 08:35:45 -0800 (PST) From: Pyda Srisuresh Date: Sat, 11 Mar 2006 08:35:45 -0800 (PST) Subject: [Ietf-behave] Re: ICMP behave draft In-Reply-To: Message-ID: <20060311163544.10325.qmail@web33308.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, The objective of the ICMP draft is to make NATs predictable concerning ICMP messages. This falls right in the core of Behave WG charter. We have had some discussion on the list recently. I want to hear more feedback - Do we see the requirements conflicting with existing docs? Is the scope agreeable? Do we have WG consensus on the requirements listed? What is missing? Newer requirements? These are things we like to get feedback on in the WG meeting. Please reconsider your decision. Specific responses to your comments inline below. Thanks. regards, suresh --- Cullen Jennings wrote: > On 3/5/06 11:24 AM, "Pyda Srisuresh" wrote: > > > Cullen & Jiri, > > > > We just submitted a new rev of ICMP behave draft. We would like to have a > slot > > to present the draft in the IETF meeting. I believe, 15 to 20 min. slot > should > > be adequate to discuss this. Saikat will present this in the meeting. > > > > The ICMP draft has 5 requirements and these requirments do not conflict > with > > the UDP draft. The main goal of the presentation would be to find out if > there > > is interest in pursuing the ICMP milestone and the draft in the WG. > > > > Thanks. > > > > regards, > > suresh > > At a casual glance (and I may be very wrong...) Some of these requirements > are already covered in the UDP draft. Some of these requirements were > discussed in the formation of the UDP draft and it was clear that the WG > would not agree to them so they were removed from UDP. Some of these > requirements conflict with things people have expressed a strong preference > for in dealing with the TCP draft. > [suresh] I follow your comment about overlap with the UDP draft. The rest I do not follow. Dan wing sent an e-mail about overlap with the UDP draft. AFAIK, there is overlap, but no conflicts. As for the rest, can you specifically state what you believe the WG would not agree to or is in conflict with the UDP or TCP drafts? > I'm amazed that this draft has received no comments but unless someone steps > up with exactly what parts of it we want to move forward with and why we > need theses, I'm having a hard time seeing what what the issues are that the > working group needs to spend agenda time to solve. > [suresh] Well, there has been activity. Several issues are in discussion. > In the past I have put stuff like this at the end of the agenda as a time > permitting item but we never get those items so I'm reluctant to do that. > [suresh] Cullen - There are concrente issues to discuss. Please see my note at the outset. This is not vague. > It's the usual scope issue. This document may be great advice on how to > build a NAT. The question is, which of these items do we need NATs to do > differently from what they do today so that applications can work better > behind NATs. And what applications would take advantage of the new behavior. > [suresh] What specifically in the draft makes you believe, this is an advice on how to build a NAT? What is the new behavior you are alluding to? The draft lists concrete set of requirements to make NATs predictable with regard to ICMP messages and is awaiting feedback from the WG. All applications and end host stacks that need to deal with ICMP Query and Error messages benefit from the draft. regards, suresh > If people think there are key things here, and can say what application > needs them and that NATs currently do the wrong thing, I glad to set > priorities accordingly but right now I am unclear on how to prioritize this. > > Thanks, > Cullen (with my behave chair hat on) > > > > > > From petithug@acm.org Sat, 11 Mar 2006 10:19:50 -0800 (PST) From: Marc Petit-Huguenin Date: Sat, 11 Mar 2006 10:19:50 -0800 (PST) Subject: Re: [Ietf-behave] Re: I-D ACTION:draft-ietf-behave-turn-00.txt In-Reply-To: Message-ID: <441314C2.1060003@acm.org> MIME-Version: 1.0 Content-Type: text/plain One comment on this draft: REQUESTED-IP in this draft and XOR-MAPPED-ADDRESS in RFC3489bis-03 share the same definition (0x0020). -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx From fluffy@cisco.com Sun, 12 Mar 2006 10:32:11 -0800 (PST) From: Cullen Jennings Date: Sun, 12 Mar 2006 10:32:11 -0800 (PST) Subject: [Ietf-behave] Re: ICMP behave draft In-Reply-To: <20060311163544.10325.qmail@web33308.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain The goal of the WG is not to mandate the one and only one way to build a NAT. The goal is to remove the non deterministic behavior that makes it hard to build applications. It would really help the WG if you could say 1) what are the applications that get messed up by poor handling of ICMP 2) what parts of this are not covered in UDP or TCP documents 3) what would we need to change in the way that some NATs handle ICMP to fix this Note that variants of "A NAT device MUST transparently forward ICMP error packets" have been discussed widely before and the WG rejected them because this would make many firewalls (which are out of scope) no longer behave compliant. Req 3 was discussed and not used due to lack of compatibility with standard FW practices and unclear what it would help. Req 4 has also been discussed in the TCP case and the UDP case with STUN. Srisuresh et. al. [Page 7] Internet-Draft NAT Behavioral requirements for ICMP March 2006 to the target end node, so long as the NAT has active mapping for for the embedded payload. On 3/11/06 8:35 AM, "Pyda Srisuresh" wrote: > Cullen, > > The objective of the ICMP draft is to make NATs predictable concerning ICMP > messages. This falls right in the core of Behave WG charter. We have had some > discussion on the list recently. I want to hear more feedback - Do we see the > requirements conflicting with existing docs? Is the scope agreeable? Do we > have > WG consensus on the requirements listed? What is missing? Newer requirements? > These are things we like to get feedback on in the WG meeting. Please > reconsider your decision. Specific responses to your comments inline below. > > Thanks. > > regards, > suresh > > --- Cullen Jennings wrote: > >> On 3/5/06 11:24 AM, "Pyda Srisuresh" wrote: >> >>> Cullen & Jiri, >>> >>> We just submitted a new rev of ICMP behave draft. We would like to have a >> slot >>> to present the draft in the IETF meeting. I believe, 15 to 20 min. slot >> should >>> be adequate to discuss this. Saikat will present this in the meeting. >>> >>> The ICMP draft has 5 requirements and these requirments do not conflict >> with >>> the UDP draft. The main goal of the presentation would be to find out if >> there >>> is interest in pursuing the ICMP milestone and the draft in the WG. >>> >>> Thanks. >>> >>> regards, >>> suresh >> >> At a casual glance (and I may be very wrong...) Some of these requirements >> are already covered in the UDP draft. Some of these requirements were >> discussed in the formation of the UDP draft and it was clear that the WG >> would not agree to them so they were removed from UDP. Some of these >> requirements conflict with things people have expressed a strong preference >> for in dealing with the TCP draft. >> > [suresh] I follow your comment about overlap with the UDP draft. The rest I do > not follow. Dan wing sent an e-mail about overlap with the UDP draft. AFAIK, > there is overlap, but no conflicts. As for the rest, can you specifically > state > what you believe the WG would not agree to or is in conflict with the UDP or > TCP drafts? > >> I'm amazed that this draft has received no comments but unless someone steps >> up with exactly what parts of it we want to move forward with and why we >> need theses, I'm having a hard time seeing what what the issues are that the >> working group needs to spend agenda time to solve. >> > [suresh] Well, there has been activity. Several issues are in discussion. > >> In the past I have put stuff like this at the end of the agenda as a time >> permitting item but we never get those items so I'm reluctant to do that. >> > [suresh] Cullen - There are concrente issues to discuss. Please see my note at > the outset. This is not vague. > >> It's the usual scope issue. This document may be great advice on how to >> build a NAT. The question is, which of these items do we need NATs to do >> differently from what they do today so that applications can work better >> behind NATs. And what applications would take advantage of the new behavior. >> > > [suresh] What specifically in the draft makes you believe, this is an advice > on > how to build a NAT? What is the new behavior you are alluding to? > The draft lists concrete set of requirements to make NATs predictable with > regard to ICMP messages and is awaiting feedback from the WG. All applications > and end host stacks that need to deal with ICMP Query and Error messages > benefit from the draft. > > regards, > suresh > >> If people think there are key things here, and can say what application >> needs them and that NATs currently do the wrong thing, I glad to set >> priorities accordingly but right now I am unclear on how to prioritize this. >> >> Thanks, >> Cullen (with my behave chair hat on) >> >> >> >> >> >> From jdrosen@cisco.com Mon, 13 Mar 2006 08:17:18 -0800 (PST) From: Jonathan Rosenberg Date: Mon, 13 Mar 2006 08:17:18 -0800 (PST) Subject: Re: [Ietf-behave] Re: I-D ACTION:draft-ietf-behave-turn-00.txt In-Reply-To: Message-ID: <44159B0D.4060807@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Good catch. Changed REQUESTED-IP to 0x0022. Thanks, Jonathan R. Marc Petit-Huguenin wrote: One comment on this draft: REQUESTED-IP in this draft and XOR-MAPPED-ADDRESS in RFC3489bis-03 share the same definition (0x0020). -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From srisuresh@yahoo.com Mon, 13 Mar 2006 09:42:03 -0800 (PST) From: Pyda Srisuresh Date: Mon, 13 Mar 2006 09:42:03 -0800 (PST) Subject: Destination Unreachable ICMP message processing (WAS:: RE: [Ietf-behave] ICMP Behave draft) In-Reply-To: <20060311003709.76874.qmail@web33303.mail.mud.yahoo.com> Message-ID: <20060313174202.60520.qmail@web33302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Meir, Thomas, and Fernando - Please let me know if you see any issue with the closure below. In the next rev of the draft, I will also add text that indicates why a change of ICMP code is not desirable for "Destination unreachable" message. Others - Please let me know your comments as well, specifically, if you see any issue with the proposed closure below. Thanks. If I do not hear from anyone before the end of the week, I will consider the issue closed. Thanks. regards, suresh --- Pyda Srisuresh wrote: > Fernando, > > You are right, RFC1122 does say that ICMP codes 0 (network unreachable), and > 1 > (host unreachable) are soft errors and ICMP code 3 (Port unreachable) is a > hard > error. In case of soft error, the application will retry, whereas the > application will simply abort upon a hard error. I was assuming all ICMP > codes > for the destination unreachable message to be hard error and was concerned > about connectivity loss. That is incorrect. I imagine, that may be what Meir > thought as well. Thanks for clarifying. > > Sounds like, what you are saying is that it is not a good idea to convert a > soft error (codes 0 or 1 ) into a hard error (code 3). Instead leave the ICMP > error message unchanged on NAPT. I imagine, that is what Thomas intends as > well. > > I agree. Unless I hear a counter argument for the above, we will leave the > text > in the draft unchanged on this. Thanks. > > regards, > suresh > > --- Fernando Gont wrote: > > > At 01:50 p.m. 09/03/2006, Meir Leshem wrote: > > > > >According to draft-srisuresh-behave-nat-icmp-01, "A NAT device MUST > > >transparently forward ICMP error packets to the target end node, so > > >long as the NAT has active mapping for the embedded payload" (REQ-2). > > >In the case of NAPT device (defined in RFC 3022), some ICMP error > > >messages might cause problems if transferred transparently by a NAPT > > >device. > > > > > >For example, if instead of figure 1 in the nat-icmp draft we put 3 hosts > > >in the private realm Y (y1,y2,y3). > > >An ICMP host unreachable message from Router-y upon a packet from Host-x > > >to host-y1 will be transferred to host-x as host unreachable (host-y'). > > > > > >As a result host-x will stop sending packets to y1,y2,y3 although > > >only y1 has a problem. > > >So my understanding is that in this case, for ICMP (host unreachable, > > >net unreachable) messages from Router-y, the NAPT device must send > > >ICMP (port unreachable) messages to Host-x instead. > > > > Host and net unreachables are considered "soft errors". Thus, > > RFC1122-compliant implementations won't stop sending packets to those > > hosts. Also, the receiving system will use the four-tuple included in > > the ICMP payload to match the error message to the corresponding TCP > > connection. > > > > Kindest regards, > > > > > > -- > > Fernando Gont > > e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx > > > > > > > > > > > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Mon, 13 Mar 2006 10:04:58 -0800 (PST) From: Pyda Srisuresh Date: Mon, 13 Mar 2006 10:04:58 -0800 (PST) Subject: [Ietf-behave] REQ-1 of the ICMP draft In-Reply-To: <20060313174202.60520.qmail@web33302.mail.mud.yahoo.com> Message-ID: <20060313180457.19667.qmail@web33301.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Folks, REQ-1 of the ICMP draft (rev 1) says, "It is RECOMMENDED that the administrator be allowed to configure the ICMP session timeout." Within section 2.1, the draft also says that 30 secs. is the typical ICMP NAT Session timeout. REQ-5 of the UDP draft states that NAT mapping timer MUST NOT expire in less than 2 minutes, and a default value of 5 mins is RECOMMENDED. It also says, the value of the NAT UDP mapping timer MAY be configurable. Question: Should the ICMP draft adapt similar wording as the UDP draft(minimum timeout mandate, default timeout recommendation and configurability option)? Also, Does anyone on the list have any comments on the ICMP timeout setting suggested? Is there statistical evidence to require this to be longer or shorter timeout? Any other thoughts? Thanks. regards, suresh From srisuresh@yahoo.com Mon, 13 Mar 2006 10:44:43 -0800 (PST) From: Pyda Srisuresh Date: Mon, 13 Mar 2006 10:44:43 -0800 (PST) Subject: [Ietf-behave] NAT mapping for ICMP queries In-Reply-To: <20060313180457.19667.qmail@web33301.mail.mud.yahoo.com> Message-ID: <20060313184442.4662.qmail@web33304.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Folks, Both UDP & TCP drafts state the following about NAT mapping - A NAT MUST have an "External NAT mapping is endpoint independent" behavior. Should the ICMP draft make a similar requirement for ICMP queries? Here is a little background. The ICMP Queries (types 0, 8, 13, 14, 15, 16) have an identfier field, which is used by NAPT devices for multiplexing across multiple private hosts behind the NAPT device. The NAPT assigns a new Identifier mapping for each tuple of (private-node IP, Identifier, External-node IP). I believe, most NAPT devices assign the mapping similar to that of a Symmetric NAT, I.e., external endpoint dependent. Should the ICMP draft recommend a NAT mapping that is endpoint independent? I.e., based just on the tuple of (private-node IP, Identifier), no matter what the external node IP address is? I am not aware of ICMP based Peer-to-Peer applications that reuse the same query identifier to connect to multiple external nodes. Even if there arent any now, there is no reason to believe, there wont be such apps in the future. If any of you are aware of such applications, do let us know on the list. Shoudl we take a proactive approach and recommend endpoint independent mapping fro ICMP as well? What are your thoughts? regards, suresh From fluffy@cisco.com Mon, 13 Mar 2006 13:00:53 -0800 (PST) From: Cullen Jennings Date: Mon, 13 Mar 2006 13:00:53 -0800 (PST) Subject: [Ietf-behave] Draft agenda for IETF 65 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Latest copy can be found at http://www3.ietf.org/proceedings/06mar/agenda/behave.txt And the current copy is ------------------------------------------------------ Draft Version 2 Agenda Bashing (Chairs, 5 min) Bluesheets Scribes Chair Update (Chairs, 10 min) TCP Issues (Saikat Guha, 30 min) draft-ietf-behave-tcp-00 STUN Issues (TBD, 25 min) draft-ietf-behave-rfc3489bis-03 TURN Issues (Jonathan Rosenberg, 20 min) draft-ietf-behave-turn-00 draft-camarillo-midcom-turn-ipv6-00 Multicast Draft (Dan Wing, 15 min) draft-ietf-behave-multicast-01 draft-ietf-magma-igmp-proxy-06 ICMP Draft ---- Time Permitting --- (TBD, 10 min) draft-srisuresh-behave-nat-icmp-01 From srisuresh@yahoo.com Mon, 13 Mar 2006 13:13:15 -0800 (PST) From: Pyda Srisuresh Date: Mon, 13 Mar 2006 13:13:15 -0800 (PST) Subject: [Ietf-behave] Re: ICMP behave draft In-Reply-To: Message-ID: <20060313211314.48197.qmail@web33309.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, It is apparent, you have preconceived notions about the draft that are simply not true. Your refusal to assign a time slot is colored by your notions, not shared by the list, IMHO. One of the objectives of discussing the draft in the meeting is precisely to clear up the misconceptions and obtain feedback. It is not like this is WGLC for the draft. Enuf said. specific comments inline below. regards, suresh --- Cullen Jennings wrote: > > The goal of the WG is not to mandate the one and only one way to build a > NAT. The goal is to remove the non deterministic behavior that makes it hard > to build applications. It would really help the WG if you could say > [suresh] The draft is not about mandating a one and only one way to build a NAT. You keep insinuating this in your mesasages. I would appreciate, if you stopped making the insinuations, unless you have a specific text in the draft that you can point to. I will be happy to fix the text, if such a comment was made, knowingly or unknowingly. > 1) what are the applications that get messed up by poor handling of ICMP > [suresh] I had already indicated this in my previous messages. All ICMP-query based application and applications that depend on ICMP errors are effected by poor handling of ICMP by NAT devices Take for example, the header processing in REQ-2 of the ICMP draft. When the ICMP error packet from intermediate nodes is not correctly updated by NAT, the error packet might either be dropped or the intended recipent may not be able to debug the error message (say, Destination unreachable error message) and take the necessary follow-on action. This can be a severe impediment to applications. Take the traceroute command as another example. A NAT device is expected to respond with a "TTL exceeded message" when the packet has a TTL of 0 prior to forwarding. Not all NAT devices do this. Traceroute commands do not work without this support. > 2) what parts of this are not covered in UDP or TCP documents > [suresh] Take a look at the following e-mail I sent on the scope and overlap with TCP/UDP drafts. http://list.sipfoundry.org/archive/ietf-behave/msg01144.html > 3) what would we need to change in the way that some NATs handle ICMP to fix > this > [suresh] That is what the draft is about. > Note that variants of "A NAT device MUST transparently forward ICMP error > packets" have been discussed widely before and the WG rejected them because > this would make many firewalls (which are out of scope) no longer behave > compliant. [suresh] Is this a discussion on the list? I am not aware of this. If true, that would be very strange. Can you point me to a specific email message on the list that comes to the above conclusion? What is the firewall requirement that mandates NATs to not forward all ICMP error messages? If this is firewall specific issue, why is this being imposed on NATs? In either case, this should not be left vague and unspecified as guess work for NAT vendors. Applications depend on ICMP error messages from end-nodes and intermediate nodes being forwarded reliably by NAT devices. > Req 3 was discussed and not used due to lack of compatibility > with standard FW practices and unclear what it would help. [suresh] Once again, I donot recall this discussion on the list. Would you have a pointer to an e-mail that concludes the above. I certainly donot recall concluding that NAT session (associated with the embedded payload) should be refreshed when an ICMP error message is received. The rationale for the drafts's requiremwnt is in the draft. What is your rationale? What is your source for the standard practices of firewall. Is this some private/corridor discussion or somethign concrete in a document? > Req 4 has also > been discussed in the TCP case and the UDP case with STUN. > [suresh] I think, you may be confused. We talked about how to process inbound connections and agreed to silently drop the inbound packets (REQ-4 of TCP). The requirement listed here is concerning outbound packets. Thats all for now. regards, suresh > > > Srisuresh et. al. [Page 7] > > Internet-Draft NAT Behavioral requirements for ICMP March 2006 > > > to the target end node, so long as the NAT has active mapping for > for the embedded payload. > > > > On 3/11/06 8:35 AM, "Pyda Srisuresh" wrote: > > > Cullen, > > > > The objective of the ICMP draft is to make NATs predictable concerning ICMP > > messages. This falls right in the core of Behave WG charter. We have had > some > > discussion on the list recently. I want to hear more feedback - Do we see > the > > requirements conflicting with existing docs? Is the scope agreeable? Do we > > have > > WG consensus on the requirements listed? What is missing? Newer > requirements? > > These are things we like to get feedback on in the WG meeting. Please > > reconsider your decision. Specific responses to your comments inline below. > > > > Thanks. > > > > regards, > > suresh > > > > --- Cullen Jennings wrote: > > > >> On 3/5/06 11:24 AM, "Pyda Srisuresh" wrote: > >> > >>> Cullen & Jiri, > >>> > >>> We just submitted a new rev of ICMP behave draft. We would like to have a > >> slot > >>> to present the draft in the IETF meeting. I believe, 15 to 20 min. slot > >> should > >>> be adequate to discuss this. Saikat will present this in the meeting. > >>> > >>> The ICMP draft has 5 requirements and these requirments do not conflict > >> with > >>> the UDP draft. The main goal of the presentation would be to find out if > >> there > >>> is interest in pursuing the ICMP milestone and the draft in the WG. > >>> > >>> Thanks. > >>> > >>> regards, > >>> suresh > >> > >> At a casual glance (and I may be very wrong...) Some of these requirements > >> are already covered in the UDP draft. Some of these requirements were > >> discussed in the formation of the UDP draft and it was clear that the WG > >> would not agree to them so they were removed from UDP. Some of these > >> requirements conflict with things people have expressed a strong > preference > >> for in dealing with the TCP draft. > >> > > [suresh] I follow your comment about overlap with the UDP draft. The rest I > do > > not follow. Dan wing sent an e-mail about overlap with the UDP draft. > AFAIK, > > there is overlap, but no conflicts. As for the rest, can you specifically > > state > > what you believe the WG would not agree to or is in conflict with the UDP > or > > TCP drafts? > > > >> I'm amazed that this draft has received no comments but unless someone > steps > >> up with exactly what parts of it we want to move forward with and why we > >> need theses, I'm having a hard time seeing what what the issues are that > the > >> working group needs to spend agenda time to solve. > >> > > [suresh] Well, there has been activity. Several issues are in discussion. > > > >> In the past I have put stuff like this at the end of the agenda as a time > >> permitting item but we never get those items so I'm reluctant to do that. > >> > > [suresh] Cullen - There are concrente issues to discuss. Please see my note > at > > the outset. This is not vague. > > > >> It's the usual scope issue. This document may be great advice on how to > >> build a NAT. The question is, which of these items do we need NATs to do > >> differently from what they do today so that applications can work better > >> behind NATs. And what applications would take advantage of the new > behavior. > >> > > > > [suresh] What specifically in the draft makes you believe, this is an > advice > > on > > how to build a NAT? What is the new behavior you are alluding to? > > The draft lists concrete set of requirements to make NATs predictable with > > regard to ICMP messages and is awaiting feedback from the WG. All > applications > > and end host stacks that need to deal with ICMP Query and Error messages > > benefit from the draft. > > > > regards, > > suresh > > > >> If people think there are key things here, and can say what application > >> needs them and that NATs currently do the wrong thing, I glad to set > >> priorities accordingly but right now I am unclear on how to prioritize > this. > >> > >> Thanks, > >> Cullen (with my behave chair hat on) > >> > >> > >> > >> > >> > >> > From fernando@gont.com.ar Mon, 13 Mar 2006 14:37:13 -0800 (PST) From: Fernando Gont Date: Mon, 13 Mar 2006 14:37:13 -0800 (PST) Subject: RE: [Ietf-behave] ICMP Behave draft In-Reply-To: <7.0.1.0.0.20060310151124.0262f3f0@gont.com.ar> Message-ID: <7.0.1.0.0.20060311034019.0403d598@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain At 09:37 p.m. 10/03/2006, Pyda Srisuresh wrote: Sounds like, what you are saying is that it is not a good idea to convert a soft error (codes 0 or 1 ) into a hard error (code 3). Instead leave the ICMP error message unchanged on NAPT. I imagine, that is what Thomas intends as well. Correct. I would even argue that in the case of TCP, all ICMP error messages should be considered "soft" when they are received for connections in any of the synchronized states. For the non-synchronized states, it may make sense to treat all of them as hard errors. (For a rationale of this see http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-00.txt , and RFC 816). The slides of my presentation of that internet-draft at the 64th IETF Meeting is available at: http://www3.ietf.org/proceedings/05nov/slides/tcpm-5.pdf Kindest regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx From fernando@gont.com.ar Mon, 13 Mar 2006 16:29:12 -0800 (PST) From: Fernando Gont Date: Mon, 13 Mar 2006 16:29:12 -0800 (PST) Subject: Re: [Ietf-behave] ICMP Behave draft In-Reply-To: <7.0.1.0.0.20060310153918.06a07998@gont.com.ar> Message-ID: <7.0.1.0.0.20060313200113.0261fc10@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain At 10:17 p.m. 10/03/2006, Pyda Srisuresh wrote: You are right about checking and updating the IP and UDP checksums of the embedded IP packet. However, checking the TCP checksum would not work, as the ICMP error message include just 8 bytes of TCP header. The TCP checksum is past 8 bytes. Need not be the case. The original ICMP spec stated that the first 8 octets of the transport protocol header should be included. RFC 1122 states that more information MAY be included. And RFC 1812 states that more information SHOULD be included. Section 3 of http://www.gont.com.ar/drafts/draft-ietf-tcpm-icmp-attacks-00.txt has a sum up of the relevant stuff. That said, in the event you got a full TCP segment, you should check the TCP checksum. Also, if you get the TCP timestamp, you should check it Kindest regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx From fernando@gont.com.ar Mon, 13 Mar 2006 16:29:14 -0800 (PST) From: Fernando Gont Date: Mon, 13 Mar 2006 16:29:14 -0800 (PST) Subject: Re: [Ietf-behave] Re: ICMP behave draft In-Reply-To: <20060311163544.10325.qmail@web33308.mail.mud.yahoo.com> Message-ID: <7.0.1.0.0.20060313205821.064065b8@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain At 03:32 p.m. 12/03/2006, Cullen Jennings wrote: The goal of the WG is not to mandate the one and only one way to build a NAT. The goal is to remove the non deterministic behavior that makes it hard to build applications. It would really help the WG if you could say 1) what are the applications that get messed up by poor handling of ICMP RFC 1122 mandates that ICMP messages should be handled to the corresponding transport protocol instance/application. That said, any application which currently depends on that, will be affected by poor handling of ICMP messages. It's not just TCP or UDP: It's anything that runs over IP that will be affected. Other than that, have a look at *BSD's and Linux handling of ICMP error messages. One way or the other, they depend on correct ICMP processing. http://www.gont.com.ar/drafts/draft-ietf-tcpm-tcp-soft-errors-00.txt discusses all that. As to to what extent they are affected, have a look at: [Guynes] Guynes, J., "Impact of System Response Time on State Anxiety", Communications of the ACM , 1988. [Thadani] Thadani, A., "Interactive User Productivity", IBM Systems Journal No. 1, 1981. Note that variants of "A NAT device MUST transparently forward ICMP error packets" have been discussed widely before and the WG rejected them because this would make many firewalls (which are out of scope) no longer behave compliant. It's okay to have Informational documents describe current practice. However, shaping Standards track documents so that existing implementations remain compliant, is, IMHO, a big mistake. Req 3 was discussed and not used due to lack of compatibility with standard FW practices and unclear what it would help. Firewalls are out of scope when it comes to creating documents, but they "in scope" when it comes to deciding when to make something a requirement? How come? Kindest regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx From fluffy@cisco.com Mon, 13 Mar 2006 19:56:53 -0800 (PST) From: Cullen Jennings Date: Mon, 13 Mar 2006 19:56:53 -0800 (PST) Subject: [Ietf-behave] Re: ICMP behave draft In-Reply-To: <20060313211314.48197.qmail@web33309.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 3/13/06 1:13 PM, "Pyda Srisuresh" wrote: > Cullen, > > It is apparent, you have preconceived notions about the draft that are simply > not true. Your refusal to assign a time slot is colored by your notions, not > shared by the list, Pydra, ironically a few hours before your email was sent, I had assigned a slot on the draft agenda for this. It did not get posted to this list until slightly before you sent your message but you can find it at http://list.sipfoundry.org/archive/ietf-behave/msg01163.html Let us know who will be presenting. Part of the reason that it is a "draft agenda" is so that the WG can comment on it and let us know if the chairs need to adjust the agenda. That is also the point of the first item on nearly every IETF agenda labeled "Agenda Bashing". From srisuresh@yahoo.com Tue, 14 Mar 2006 11:10:25 -0800 (PST) From: Pyda Srisuresh Date: Tue, 14 Mar 2006 11:10:25 -0800 (PST) Subject: RE: [Ietf-behave] ICMP Behave draft In-Reply-To: <7.0.1.0.0.20060311034019.0403d598@gont.com.ar> Message-ID: <20060314191025.48966.qmail@web33311.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain OK, Thanks. This may be a good advice to add in the application behavior draft as well. However, this seems like a general application behavior recommended, not specific to the context of NATs. Right? Thanks. regards, suresh --- Fernando Gont wrote: > At 09:37 p.m. 10/03/2006, Pyda Srisuresh wrote: > > >Sounds like, what you are saying is that it is not a good idea to convert a > >soft error (codes 0 or 1 ) into a hard error (code 3). Instead leave the > ICMP > >error message unchanged on NAPT. I imagine, that is what Thomas intends as > >well. > > Correct. > > I would even argue that in the case of TCP, all ICMP error messages > should be considered "soft" when they are received for connections in > any of the synchronized states. > > For the non-synchronized states, it may make sense to treat all of > them as hard errors. (For a rationale of this see > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-00.txt > , and RFC 816). > > The slides of my presentation of that internet-draft at the 64th IETF > Meeting is available at: > http://www3.ietf.org/proceedings/05nov/slides/tcpm-5.pdf > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx > > > > > > From srisuresh@yahoo.com Tue, 14 Mar 2006 13:33:36 -0800 (PST) From: Pyda Srisuresh Date: Tue, 14 Mar 2006 13:33:36 -0800 (PST) Subject: [Ietf-behave] Re: ICMP behave draft In-Reply-To: Message-ID: <20060314213335.94662.qmail@web33306.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, Saikat will present the ICMP draft. As for the agenda, I do not like the ICMP draft in hte "time permitting" bin at the end. I am afraid, it will fall off the discussion list, as had happened in the past for items under that bin. I would like the ICMP draft fully scheduled in to permit its discussion in the meeting. Based on the comments and responses I had seen so far, the discussion might take longer than the 20 mins I had originally asked for. I request a 30 min. time slot to discuss the ICMP draft. Thanks. regards, suresh --- Cullen Jennings wrote: > On 3/13/06 1:13 PM, "Pyda Srisuresh" wrote: > > > Cullen, > > > > It is apparent, you have preconceived notions about the draft that are > simply > > not true. Your refusal to assign a time slot is colored by your notions, > not > > shared by the list, > > Pydra, ironically a few hours before your email was sent, I had assigned a > slot on the draft agenda for this. It did not get posted to this list until > slightly before you sent your message but you can find it at > > http://list.sipfoundry.org/archive/ietf-behave/msg01163.html > > Let us know who will be presenting. > > Part of the reason that it is a "draft agenda" is so that the WG can comment > on it and let us know if the chairs need to adjust the agenda. That is also > the point of the first item on nearly every IETF agenda labeled "Agenda > Bashing". > > > From fluffy@cisco.com Tue, 14 Mar 2006 19:12:19 -0800 (PST) From: Cullen Jennings Date: Tue, 14 Mar 2006 19:12:19 -0800 (PST) Subject: [Ietf-behave] Re: ICMP behave draft In-Reply-To: <20060314213335.94662.qmail@web33306.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Fair enough. Jiri and I will run the meeting to make sure that whatever time we allocate for this is available and does not get taken up by other things. Can other on the list please provide input on how much time they would like to spend in the meeting on discussing draft-srisuresh-behave-nat-icmp-01. Thanks On 3/14/06 1:33 PM, "Pyda Srisuresh" wrote: > Cullen, > > Saikat will present the ICMP draft. As for the agenda, I do not like the ICMP > draft in hte "time permitting" bin at the end. I am afraid, it will fall off > the discussion list, as had happened in the past for items under that bin. I > would like the ICMP draft fully scheduled in to permit its discussion in the > meeting. Based on the comments and responses I had seen so far, the discussion > might take longer than the 20 mins I had originally asked for. I request a 30 > min. time slot to discuss the ICMP draft. Thanks. > > regards, > suresh > > --- Cullen Jennings wrote: > >> On 3/13/06 1:13 PM, "Pyda Srisuresh" wrote: >> >>> Cullen, >>> >>> It is apparent, you have preconceived notions about the draft that are >> simply >>> not true. Your refusal to assign a time slot is colored by your notions, >> not >>> shared by the list, >> >> Pydra, ironically a few hours before your email was sent, I had assigned a >> slot on the draft agenda for this. It did not get posted to this list until >> slightly before you sent your message but you can find it at >> >> http://list.sipfoundry.org/archive/ietf-behave/msg01163.html >> >> Let us know who will be presenting. >> >> Part of the reason that it is a "draft agenda" is so that the WG can comment >> on it and let us know if the chairs need to adjust the agenda. That is also >> the point of the first item on nearly every IETF agenda labeled "Agenda >> Bashing". >> >> >> From fluffy@cisco.com Tue, 14 Mar 2006 19:14:40 -0800 (PST) From: Cullen Jennings Date: Tue, 14 Mar 2006 19:14:40 -0800 (PST) Subject: [Ietf-behave] Agenda update Message-ID: MIME-Version: 1.0 Content-Type: text/plain Slight update of agenda ... Lasted copy at http://www3.ietf.org/proceedings/06mar/agenda/behave.txt ---------------------------------------- Draft Version 3 Agenda Bashing (Chairs, 5 min) Bluesheets Scribes Chair Update (Chairs, 10 min) TCP Issues (Saikat Guha, 30 min) draft-ietf-behave-tcp-00 STUN Issues (TBD, 25 min) draft-ietf-behave-rfc3489bis-03 TURN Issues (Jonathan Rosenberg, 20 min) draft-ietf-behave-turn-00 draft-camarillo-midcom-turn-ipv6-00 Multicast Draft (Dan Wing, 15 min) draft-ietf-behave-multicast-01 draft-ietf-magma-igmp-proxy-06 ICMP Draft (Saikat , TBD min) draft-srisuresh-behave-nat-icmp-01 (note other times will change based on time here) From ft@it.su.se Wed, 15 Mar 2006 04:45:17 -0800 (PST) From: Fredrik Thulin Date: Wed, 15 Mar 2006 04:45:17 -0800 (PST) Subject: Re: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 In-Reply-To: <17bd01c64466$84eb1670$c5f0200a@amer.cisco.com> Message-ID: <200603151344.24663.ft@it.su.se> MIME-Version: 1.0 Content-Type: text/plain Hi Thank you very much for your response. I have one clarifying question, and two additional comments =) (see below). On Friday 10 March 2006 18:17, Dan Wing wrote: ... > > 11.11. ALTERNATE-SERVER > > > > The alternate server represents an alternate IP address > > and port for > > a different TURN server to try. It is encoded in the same way > > as MAPPED-ADDRESS. > > > > TURN server? What TURN server? Is this perhaps related to my > > question above about the duplicate ALTERNATE-SERVER attributes? > > Sorry, I pulled that text from the TURN document and neglected to > generalize it. Please note that the ALTERNATE-SERVER attribute isn't > used in any of the usages defined in RFC3489bis; the only usage that > currently uses that attribute is TURN > (draft-ietf-behave-turn-00.txt). > > I will generalize that text so that instead of saying TURN it says > "for a different STUN server to try." I'm still a bit confused about this. There are two sub-sections to section 11 that describe ALTERNATE-SERVER attributes (11.11 and 11.17). Are you saying that 11.11 should really read ALTERNATE-TURN-SERVER or something? From an extremely brief look at draft-ietf-behave-turn-00, I don't find any such attribute there. New comments : 11.15. XOR-MAPPED-ADDRESS The example results for IPv4 is really helpfull. I think it would be very valuable to have such examples for IPv6 as well, to make sure everyone gets this right as well. By the way, I haven't been able to find a IPv6 capable STUN client to try my server with, does anyone know of one? Section 11 says that attributes MUST be aligned to word boundaries, and for example section 11.9 (ERROR-CODE) describes how pad with spaces to accomplish this with the reason phrase in errors. I can't find anything in the following sections that describe how to align those attributes : 11.6. USERNAME 11.7. PASSWORD 11.12. REALM 11.13. NONCE Sections 11.6 and 11.7 even says the value is of variable length. Surely they must be encoded aligned to word boundries in some way? /Fredrik From dwing@cisco.com Wed, 15 Mar 2006 16:30:49 -0800 (PST) From: "Dan Wing" Date: Wed, 15 Mar 2006 16:30:49 -0800 (PST) Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 In-Reply-To: <200603151344.24663.ft@it.su.se> Message-ID: <04f901c64890$de6f89a0$8b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > > Sorry, I pulled that text from the TURN document and neglected to > > generalize it. Please note that the ALTERNATE-SERVER > > attribute isn't > > used in any of the usages defined in RFC3489bis; the only usage that > > currently uses that attribute is TURN > > (draft-ietf-behave-turn-00.txt). > > > > I will generalize that text so that instead of saying TURN it says > > "for a different STUN server to try." > > I'm still a bit confused about this. There are two sub-sections to > section 11 that describe ALTERNATE-SERVER attributes (11.11 > and 11.17). > > Are you saying that 11.11 should really read ALTERNATE-TURN-SERVER or > something? No, just ALTERNATE-SERVER. There is no reason for a STUN server, using any of the usages defined in RFC3489bis, to send back an ALTERNATE-SERVER. And there is no reason for a STUN client to expect it. That's why I'm saying the ALTERNATE-SERVER attribute isn't used by any usages defined in RFC3489bis -- very much like the other latent attributes from RFC3489 that are no longer used by usages defined in RFC3489bis (REFLECTED-FROM, SOURCE-ADDRESS, CHANGE-REQUEST, CHANGED-ADDRESS, RESPONSE-ADDRESS). > From an extremely brief look at draft-ietf-behave-turn-00, I > don't find any such attribute there. Right; it is no longer defined in TURN. ALTERNATE-SERVER was in the immediately-preceeding version of TURN . Jonathan and I wanted all of the general stuff, which is applicable to a variety of usages, to be in the base STUN specification (RFC3489bis). ALTERNATE-SERVER seems like it could very much be useful for other usages, not just TURN. So we pulled it out of TURN and put it into RFC3489bis. As both RFC3489bis and TURN are documents of the BEHAVE working group, we are seeking consensus on this change. We will be presenting these changes at the WG meeting. Feedback regarding this change (and our other changes) on the mailing list (or at meeting) is helpful. > New comments : > > > 11.15. XOR-MAPPED-ADDRESS > > The example results for IPv4 is really helpfull. I think it would be > very valuable to have such examples for IPv6 as well, to make sure > everyone gets this right as well. Alright. > By the way, I haven't been able to > find a IPv6 capable STUN client to try my server with, does > anyone know of one? Gonzalo co-authored draft-camarillo-midcom-turn-ipv6-00.txt so he may know of one, . > Section 11 says that attributes MUST be aligned to word > boundaries, and > for example section 11.9 (ERROR-CODE) describes how pad with > spaces to > accomplish this with the reason phrase in errors. > > I can't find anything in the following sections that describe how to > align those attributes : > > 11.6. USERNAME > 11.7. PASSWORD > 11.12. REALM > 11.13. NONCE > > Sections 11.6 and 11.7 even says the value is of variable > length. Surely > they must be encoded aligned to word boundries in some way? RFC3489 defined USERNAME and PASSWORD but also failed to describe this situation. Hm. My first reaction is that the USERNAME, PASSWORD, and NONCE are all computer generated -- that is, they have no relationship to the username or password you use for authentication (by typing a username into a keyboard, for example). Thus, those can all reasonably be required to just be a multiple of 32 bits long. I can add text to that effect in -04 if folks concur. The REALM might reasonably be a string such as "cisco.com", though, and I agree it needs a standard for aligning it. Perhaps use should use spaces like with the error codes just for consistency, or maybe pad with 0x00. -d From juberti@aol.com Wed, 15 Mar 2006 17:24:24 -0800 (PST) From: Justin Uberti Date: Wed, 15 Mar 2006 17:24:24 -0800 (PST) Subject: Re: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 In-Reply-To: <04f901c64890$de6f89a0$8b82200a@amer.cisco.com> Message-ID: <4418BE37.4020704@aol.com> MIME-Version: 1.0 Content-Type: text/plain RFC3489 defined USERNAME and PASSWORD but also failed to describe this situation. Hm. My first reaction is that the USERNAME, PASSWORD, and NONCE are all computer generated -- that is, they have no relationship to the username or password you use for authentication (by typing a username into a keyboard, for example). Thus, those can all reasonably be required to just be a multiple of 32 bits long. I can add text to that effect in -04 if folks concur. I thought that with the new support for long-term passwords in TURN, this might not be the case for USERNAME. The REALM might reasonably be a string such as "cisco.com", though, and I agree it needs a standard for aligning it. Perhaps use should use spaces like with the error codes just for consistency, or maybe pad with 0x00. I was thinking we would use spaces for REALM and USERNAME, for consistency. Thanks, --justin From aki.niemi@nokia.com Sun, 19 Mar 2006 14:44:09 -0800 (PST) From: Aki Niemi Date: Sun, 19 Mar 2006 14:44:09 -0800 (PST) Subject: Re: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 In-Reply-To: <17bd01c64466$84eb1670$c5f0200a@amer.cisco.com> Message-ID: <441DCE77.6070702@nokia.com> MIME-Version: 1.0 Content-Type: text/plain ext Fredrik Thulin wrote: > 11.15. XOR-MAPPED-ADDRESS > > The example results for IPv4 is really helpfull. I think it would be > very valuable to have such examples for IPv6 as well, to make sure > everyone gets this right as well. By the way, I haven't been able to > find a IPv6 capable STUN client to try my server with, does anyone know > of one? Hmm... Why would you need to get an IPv6 address in MAPPED-ADDRESS anyway? This makes me feel very uneasy; is the purpose to be able to traverse a NAT-PT that maps private IPv4 to IPv6? That's not cool. Cheers, Aki From dwing@cisco.com Sun, 19 Mar 2006 20:33:49 -0800 (PST) From: "Dan Wing" Date: Sun, 19 Mar 2006 20:33:49 -0800 (PST) Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 In-Reply-To: <441DCE77.6070702@nokia.com> Message-ID: <010001c64bd7$7bff0440$a793150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > ext Fredrik Thulin wrote: > > 11.15. XOR-MAPPED-ADDRESS > > > > The example results for IPv4 is really helpfull. I think it > > would be > > very valuable to have such examples for IPv6 as well, to make sure > > everyone gets this right as well. By the way, I haven't > > been able to > > find a IPv6 capable STUN client to try my server with, does > > anyone know of one? > > Hmm... Why would you need to get an IPv6 address in MAPPED-ADDRESS > anyway? This makes me feel very uneasy; is the purpose to be able to > traverse a NAT-PT that maps private IPv4 to IPv6? That's not cool. STUN has many uses, and only one of them (Binding Discovery) is is useful for learning your NATted IP address. One of its other significant uses is the connectivity check which is now defined in rfc3489bis-03. The connectivity check is used by ICE (draft-ietf-mmusic-ice). Another significant use is TURN (media relaying) where the media might be relayed between v4 and v6. See also draft-ietf-sipping-v6-transition-02.txt which describes how ICE is useful in a mixed v6/v4 environment. -d From audet@nortel.com Mon, 20 Mar 2006 07:33:04 -0800 (PST) From: "Francois Audet" Date: Mon, 20 Mar 2006 07:33:04 -0800 (PST) Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 Message-ID: <1ECE0EB50388174790F9694F77522CCF07CFB47E@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain An IPv4 address could be mapped to IPv6 perhaps? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Aki Niemi > Sent: Sunday, March 19, 2006 13:35 > To: ext Fredrik Thulin > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 > > > > ext Fredrik Thulin wrote: > > 11.15. XOR-MAPPED-ADDRESS > > > > The example results for IPv4 is really helpfull. I think it would be > > very valuable to have such examples for IPv6 as well, to make sure > > everyone gets this right as well. By the way, I haven't > been able to > > find a IPv6 capable STUN client to try my server with, does > anyone know > > of one? > > Hmm... Why would you need to get an IPv6 address in > MAPPED-ADDRESS anyway? This makes me feel very uneasy; is the > purpose to be able to traverse a NAT-PT that maps private > IPv4 to IPv6? That's not cool. > > Cheers, > Aki > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From aki.niemi@nokia.com Mon, 20 Mar 2006 12:57:14 -0800 (PST) From: Aki Niemi Date: Mon, 20 Mar 2006 12:57:14 -0800 (PST) Subject: Re: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF07CFB47E@zrc2hxm0.corp.nortel.com> Message-ID: <441F1722.2080800@nokia.com> MIME-Version: 1.0 Content-Type: text/plain ext Francois Audet wrote: > An IPv4 address could be mapped to IPv6 perhaps? Can you walk me through how this works? In other words, what transition scenario is this covering? Cheers, Aki From audet@nortel.com Mon, 20 Mar 2006 13:01:22 -0800 (PST) From: "Francois Audet" Date: Mon, 20 Mar 2006 13:01:22 -0800 (PST) Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 Message-ID: <1ECE0EB50388174790F9694F77522CCF07CFBC9D@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain NAT-PT. Ugly of course. > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@xxxxxxxxx] > Sent: Monday, March 20, 2006 12:57 > To: Audet, Francois [SC100:3055:EXCH] > Cc: ext Fredrik Thulin; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 > > > > ext Francois Audet wrote: > > An IPv4 address could be mapped to IPv6 perhaps? > > Can you walk me through how this works? In other words, what > transition scenario is this covering? > > Cheers, > Aki > > From Erkki.Koivusalo@nokia.com Tue, 21 Mar 2006 08:16:15 -0800 (PST) From: Date: Tue, 21 Mar 2006 08:16:15 -0800 (PST) Subject: Re: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0219B17A@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain Hi, I have a few rather minor comments for the STUN bis-03: 5. Overview of Operation This section is descriptive only. Normative behavior is described in Section 8 and Section . Section number is missing from the second reference. 8.1.4. Processing Responses the response as described in Section 11.8. The key to use depends on the shared secret mechanism. If the STUN Shared Secret Request was used, the key MUST be same as used to compute the MESSAGE-INTEGRITY attribute in the request. What if the Shared Secret Request was not used ? I believe also that should be mentioned here for completeness. SHOULD obtain a new one-time username and password, and retry the Allocate Request with a new transaction. Allocate Request is not defined in this spec. 9.2. Indication Message Types Indication messages cause the server to change its state. What does that mean ? How does the server change its state ? 11.11. ALTERNATE-SERVER 11.17. ALTERNATE-SERVER There are two sub-sections to section 11 that describe ALTERNATE-SERVER attributes (11.11 and 11.17). I think they are redundant. (Fredrik Thulin already mentioned this but Dan did not answer to this point, so I decided to repeat the comment) Regards, Erkki ____________________________________ Erkki Koivusalo Nokia Mobile Software tel:+358 40 7571197 mailto:erkki.koivusalo@xxxxxxxxx ____________________________________ From dwing@cisco.com Tue, 21 Mar 2006 08:34:36 -0800 (PST) From: "Dan Wing" Date: Tue, 21 Mar 2006 08:34:36 -0800 (PST) Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0219B17A@esebe103.NOE.Nokia.com> Message-ID: <03cd01c64d05$57be6ab0$3b5b150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Erkki.Koivusalo@xxxxxxxxx > Sent: Tuesday, March 21, 2006 8:16 AM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 > > > Hi, > > I have a few rather minor comments for the STUN bis-03: > > 5. Overview of Operation > > This section is descriptive only. Normative behavior is > described in > Section 8 and Section . > > Section number is missing from the second reference. Thanks. Will be fixed in -04. > 8.1.4. Processing Responses > > the response as described in Section 11.8. The key to use > depends on > the shared secret mechanism. If the STUN Shared Secret Request was > used, the key MUST be same as used to compute the MESSAGE-INTEGRITY > attribute in the request. > > What if the Shared Secret Request was not used ? I believe also that > should be mentioned here for completeness. Ok. I propose adding the following text: If the STUN client and STUN server do not share a secret (obtained for example via the STUN shared secret request), it isn't possible to protect the message using the MESSAGE-INTEGRITY attribute. Let me know if that is satisfactory. > SHOULD obtain a new one-time username and password, and retry the > Allocate Request with a new transaction. > > Allocate Request is not defined in this spec. Ok, will fix. That's a bug when we merged text from TURN. > 9.2. Indication Message Types > > Indication messages cause the server to change its state. > > What does that mean ? How does the server change its state ? Right now, only TURN is using indication messages (send indication). TURN's send indication causes the TURN server to actually start forwarding data to the remote endpoint. The reason Indications are in STUN is to describe them in general. I'll add more text in -04 so the purpose of indication messages is clearer. > 11.11. ALTERNATE-SERVER > 11.17. ALTERNATE-SERVER > > There are two sub-sections to section 11 that describe > ALTERNATE-SERVER > attributes (11.11 and 11.17). I think they are redundant. > (Fredrik Thulin already mentioned this but Dan did not answer to this > point, so I decided to repeat the comment) Yes, they're redundant. Will be fixed in -04. -d > Regards, > > Erkki > ____________________________________ > > Erkki Koivusalo > Nokia Mobile Software > tel:+358 40 7571197 > mailto:erkki.koivusalo@xxxxxxxxx > ____________________________________ > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Erkki.Koivusalo@nokia.com Tue, 21 Mar 2006 08:36:24 -0800 (PST) From: Date: Tue, 21 Mar 2006 08:36:24 -0800 (PST) Subject: Re: [Ietf-behave] Re: I-D ACTION:draft-ietf-behave-turn-00.txt Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0219B187@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain Hi, I have a few comments for the TURN-00: For TURN usage of STUN the text within this spec does not yet use consistent terminology. Somewhere it refers the server as STUN server but in a number of sections as TURN server. Further on it mentions TURN clients a number of times. I am not totally sure how the terminology should be harmonized but I suggest consistently referring to STUN servers and clients. The protocol (as STUN usage) might still be referred as TURN. 8.1.1 Server Behavior The behavior of the server when receiving an Allocate Request depends on whether the request is an initial one, or a subsequent one. An initial request is one whose source and destination transport address matches the internal remote and local transport addresses of an existing internal 5-tuple. A subsequent request is one whose source and destination transport address do not match the internal remote and local transport address of an existing internal 5-tuple. It should be the other way round: Initial request can not yet match to any existing 5-tuple, while the subsequent request does. 8.1.1.1 Initial Requests If the Allocate request was authenticated using a shared secret between the client and server, this credential MUST be associated with the allocation. If the request was authenticated using a short term password derived from a shared secret, that shared secret MUST be associated with the allocation. Please clarify the text above. I find the references to "credential" and "shared secret" to be associated with the allocation as obscure. My interpreation is that the following formulation would be equivalent... If the Allocate request was authenticated using a shared secret between the client and server, this shared secret MUST be associated with the allocation. If the request was authenticated using a short term password derived from a shared secret, that short term password MUST be associated with the allocation. ... but did I understand it correctly ? Allocate Response using the general procedures defined in [1]. The transport address allocated to the client MUST be included in the RELAY-ADDRESS attribute in the response. In addition, this response MUST contain the MAPPED-ADDRESS attribute. Processing of the response follows the general procedures of [1]. A successful response will include both a RELAY-ADDRESS and MAPPED- ADDRESS attribute, providing both a relayed transport address and a reflexive transport address, respectively, to the client. reflects the source IP address and port of the request into the MAPPED-ADDRESS (denoted by MA) in the response. This passes through the NAT to the client (8). Once again I believe that Allocate Response should contain XOR-MAPPED-ADDRESS attribute instead of MAPPED-ADDRESS, to avoid NAT to overwrite its contents. Regards, Erkki ____________________________________ Erkki Koivusalo Nokia Mobile Software tel:+358 40 7571197 mailto:erkki.koivusalo@xxxxxxxxx ____________________________________ From Erkki.Koivusalo@nokia.com Tue, 21 Mar 2006 08:56:18 -0800 (PST) From: Date: Tue, 21 Mar 2006 08:56:18 -0800 (PST) Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 In-Reply-To: <03cd01c64d05$57be6ab0$3b5b150a@amer.cisco.com> Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0219B198@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain Hi, >> 8.1.4. Processing Responses >> >> the response as described in Section 11.8. The key to use >> depends on >> the shared secret mechanism. If the STUN Shared Secret >Request was >> used, the key MUST be same as used to compute the >MESSAGE-INTEGRITY >> attribute in the request. >> >> What if the Shared Secret Request was not used ? I believe also that >> should be mentioned here for completeness. > >Ok. I propose adding the following text: > > If the STUN client and STUN server do not share a secret (obtained > for example via the STUN shared secret request), it isn't possible > to protect the message using the MESSAGE-INTEGRITY attribute. > >Let me know if that is satisfactory. Sorry, not quite. You extended it for the case where there is no message integrity check like in NAT keepalive usage like described in draft-ietf-sip-outbound-02. But it would still lack the Connectivity Check usage where message integrity check will be done based on password got from a=ice-pwd SDP attribute, instead of getting it with STUN Shared Secret Response. I believe all those three cases are worth mentioning after the "The key to use depends on the shared secret mechanism" statement. Maybe you should make it to appear as a bulleted list of three cases ? Regards, Erkki >-----Original Message----- >From: ext Dan Wing [mailto:dwing@xxxxxxxxx] >Sent: 21.March.2006 18:35 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); >ietf-behave@xxxxxxxxxxxxxxxxxxx >Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 > >> -----Original Message----- >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of >> Erkki.Koivusalo@xxxxxxxxx >> Sent: Tuesday, March 21, 2006 8:16 AM >> To: ietf-behave@xxxxxxxxxxxxxxxxxxx >> Subject: Re: [Ietf-behave] Comments on >draft-ietf-behave-rfc3489bis-03 >> >> >> Hi, >> >> I have a few rather minor comments for the STUN bis-03: >> >> 5. Overview of Operation >> >> This section is descriptive only. Normative behavior is >> described in >> Section 8 and Section . >> >> Section number is missing from the second reference. > >Thanks. Will be fixed in -04. > >> 8.1.4. Processing Responses >> >> the response as described in Section 11.8. The key to use >> depends on >> the shared secret mechanism. If the STUN Shared Secret >Request was >> used, the key MUST be same as used to compute the >MESSAGE-INTEGRITY >> attribute in the request. >> >> What if the Shared Secret Request was not used ? I believe also that >> should be mentioned here for completeness. > >Ok. I propose adding the following text: > > If the STUN client and STUN server do not share a secret (obtained > for example via the STUN shared secret request), it isn't possible > to protect the message using the MESSAGE-INTEGRITY attribute. > >Let me know if that is satisfactory. > >> SHOULD obtain a new one-time username and password, and retry the >> Allocate Request with a new transaction. >> >> Allocate Request is not defined in this spec. > >Ok, will fix. That's a bug when we merged text from TURN. > >> 9.2. Indication Message Types >> >> Indication messages cause the server to change its state. >> >> What does that mean ? How does the server change its state ? > >Right now, only TURN is using indication messages (send >indication). TURN's >send indication causes the TURN server to actually start >forwarding data to >the remote endpoint. > >The reason Indications are in STUN is to describe them in general. > >I'll add more text in -04 so the purpose of indication >messages is clearer. > >> 11.11. ALTERNATE-SERVER >> 11.17. ALTERNATE-SERVER >> >> There are two sub-sections to section 11 that describe >> ALTERNATE-SERVER >> attributes (11.11 and 11.17). I think they are redundant. >> (Fredrik Thulin already mentioned this but Dan did not answer to this >> point, so I decided to repeat the comment) > >Yes, they're redundant. Will be fixed in -04. > >-d > >> Regards, >> >> Erkki >> ____________________________________ >> >> Erkki Koivusalo >> Nokia Mobile Software >> tel:+358 40 7571197 >> mailto:erkki.koivusalo@xxxxxxxxx >> ____________________________________ >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From jdrosen@cisco.com Thu, 23 Mar 2006 11:29:15 -0800 (PST) From: Jonathan Rosenberg Date: Thu, 23 Mar 2006 11:29:15 -0800 (PST) Subject: [Ietf-behave] Re: prior TURN draft In-Reply-To: <200603032115.k23LFH52027575@GATE01.NEXLINK.CH> Message-ID: <4422F709.1060709@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Good point. I've sent a note to the I-D editor requesting this change. Thanks, Jonathan R. Jol Repiquet wrote: Hi, To avoid a confusion, you should remove "draft-rosenberg-midcom-turn-08" that is in the state "AD is watching". See https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8033&rfc_flag=0 Regards Jol -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From spencer@mcsr-labs.org Thu, 23 Mar 2006 13:07:24 -0800 (PST) From: "Spencer Dawkins" Date: Thu, 23 Mar 2006 13:07:24 -0800 (PST) Subject: [Ietf-behave] My notes from BEHAVE Message-ID: <042401c64ebd$7d03bbe0$e5858182@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain Behavior Engineering for Hindrance Avoidance (behave)Agenda Version #4Chairs: Dan Wing Thursday, March 23, 13:00 to 15:00 ==================================Agenda Bashing (Chairs, 5 min)BluesheetsScribesChair Update (Chairs, 10 min) Dan Wing is new working group chair Magnus and Lars are new ADs Cullen - "complete change of management is bound to help..."TCP Issues (Saikat Guha, 30 min)draft-ietf-behave-tcp-00 Revision of hoffman-03 draft, including comments from last meeting and list Requirements - allow simultaneous open, specify unsolicited SYN, name dependable timer values REQ-2 - MUST support full TCP state machine ("standards-compliant stacks should always work") REQ-3 - MUST support inbounc SYN/3-way from specific endpoints (handle full cone or restrictive cone behavior) Jonathan - this is just for SYN, right? right Philip Matthews - Same filtering behaviors for TCP and UDP? Jonathan - may treat these differently because applications are different, but we should make a specific recommendation Cullen - must not use cone terminology, that just confuses us. Filtering can be anything, mapping behavior must be consistent Francois - don't think we need a rule to align with UDP draft unless there's a reason. When we went through the questions, the natural reaction was, "of course", but there were cases that didn't make sense. TCP people make informed decision, look at UDP draft, but not constrained. Jonathan - use case - one side is a bad NAT, bindings are endpoint-dependent, but NAT has single IP address on public side - works only if NAT implements endpoint-only filtering Philip - same recommendations for TCP and UDP - not using address and port, right? Seems correct (Cullen also supports) Francois - can this be the last meeting where we use the word "cone"? REQ-4 - SHOULD silently discard unhandled inbound SYN - helps TCP NAT traversal - violates host requirements spec because we don't send ICMP REQ-5 - RECOMMENDED 2 hour idle timeout, 4 minutes for unestablished sessions, MAY be configurable. Cullen - UDP draft had a "must be greater than" value - MUST of 2 minutes. If we don't do this, we'll all do keepalives Magnus - what was security problem with unestablished connections? If you have server with lots of established connections behind a NAT that crashes, NAT is wedged until timeout (2 hours) Philip - omission from UDP draft - NAT behavior when it does "get filled up" - what gets dropped? least recently used is exactly the wrong behavior from application view since failures look random. Hoffman draft did have recommendations on this - could say this, if it matters. Cullen - NAT is either full or is't not, so recommendations didn't make sense, turned into a vendor-defined thing. Magnus - must consider security implications of any such behavior Philip - not saying my recommendation is the right one, but we need a recommendation that gives consistent behavior Francois - too late to recommend behavior for UDP, but TCP may be different - need to discuss this on list Lars? - principle of least astonishment would be good. Also - 2 hours is keepalives, which are optional - if you don't use keepalives, connection could be open and silent for years. No good answer that gives consistent behavior Are ALGs in-scope? They are for UDP. Francois - really don't want to go into ALG behaviors, want everything off unless there's a strong reason to turn something on. Especially don't want SIP ALGs on by default. Should FTP be on by default? Dan - IE FTP client doesn't use PASV mode (it's the only one) Lars - Lots of stuff runs over TCP, FTP isn't special. Recommendation that FTP ALG is turned on by default? Hums were "yes", with some opposed. What else on by default? Nothing, everything else defaults to offSTUN Issues (Jonathan Rosenberg, 25 min)draft-ietf-behave-rfc3489bis-03 Dan now a co-author, more than minor revision. TURN is now a usage of STUN Magic-Cookie determines RFC3489 or RFC3489bis behavior XOR or non-XOR mapped address - a lot like branch cookie in SIP Created "usage" concept and defined four (discover, connectivity check, NAT keepalives, short-term password) A small number of people have implemented shared secret mechanism, short-term password would be simpler Removed attributes to determine NAT types Francois - NAT keepalive is in this version? Yes - SIP Outbound will match this? Doesn't align yet, of course. Added clarification, IPv6 support, removed attempt to detect STUN attacks (had to be on-path, so are probably on-path to see RTP anyway) Moved things from TURN to STUN - Magic-Cookie, STUN indications, digest authentication framework, attributes (ALTERNATE -SERVER, REALM, NONCE) Adding BINDING-LIFETIME attributes as placeholder for STUN keepalives Open issue - fate of type-determination attributes? proposal is to create separate "diagnostic usage" I-D, if we can find a stuckee, alternative is to back-reference RFC 3489. Cullen - original charter was more ambitious, could just define what STUN server would do with diagnostics, don't tell how to build a client. Dan - implementers not going to go into a lot of detail, will implement everything anyway. Put strong note at the top of this usage. Derek McDonald agreed to author this draft. Philip - might want to keep diagnostics for P2P-SIP, even if it's not entirely accurate Dan - but some NATs change behavior as they run out of resources... Cullen - all devices need two IP addresses - that's what killed this material previously Jonathan - ICE is the right answer for P2P-SIP, but we'll talk later Open issue - whether to send/receive TLS - use NAPTR? SIP used NAPTR, but client knows exactly what it needs in this case - factor in usages (different ports for relays, etc.) Proposal - SRV record looks like _useage_.transport.domain Geoff - NAPTR records are so cool, couldn't we use them for something besides ENUM? Derek - just getting shared secret? No, can request binding for UDP over TLS, etc. Not trying to make a moral decision, what do people want to do? Different ports for different usages Jonathan will write this up and post it. Jonathan needs help on failover behavior - usage-specific (NAT keepalive behavior is different from connectivity check) Dan - this creates assumptions about what is sharing what secrets Cullen - server that is "half up" seems unlikely, don't use this as a requirement (although it will happen). Who has read? About half the room. Wondering about DNS usage - default STUN port, in which direction? three options (inbound, outbound, neither) Jonathan doesn't see reason to remove default port - new default port for turn? If you do SRV, this is non-sensical anyway Dan - SRV required in SIP, but do not have 100 implementation Aki - Why was IPv6 added? For Gonzalo's draft. Is there a transition scenario where it's needed? For TURN, but not for STUN? Cullen - need this to migrate ICE client to IPv6, but this makes IPv6 NATs work... Cullen - still think default number is good for configuration purposes. Philip - same port for TURN and STUN? Kind of meaningless (use of ports for firewall policy). Jonathan will request from IANATURN Issues (Jonathan Rosenberg, 20 min)draft-ietf-behave-turn-00draft-camarillo-midcom-turn-ipv6-00 "More changes than STUN", reflecting relative maturity Many things moved to STUN Set Active Destination rewritten, unified TCP and UDP, Send is an indication, not a request, allow set active destination even if you've never been there. MAPPED-ADDRESS is server-reflexive, added RELAY-ADDRESS for relayed address, added requests for port attributes (specific port, port parity, contiguity port requests) Francois - why not get two ports at once? protocol relays to requesting port (want two connections, need two requests from two different ports) Francois - how bad is this for TURN server? No worse than what client does for RTP port parity today. It's a hint. Requests for specific IP addresses (tcp stun, more than 64K clients), specific transports, permissions set on send and set active destination operations (biggest change requested) RTCP attribute now removes parity requirement - why are we doing this? LARGE existing deployments - please say "this is a backwards-compatibility thing" - Jonathan will do so Other changes - New Connect request for opening TCP connections, TCP connections NOT opened from ephemeral ports, closing TCP connections from external host do not release allocation (open multiple connections from an allocated address). Allocated lifetimes refreshed ONLY by Allocate request, not data flow. Hokey mechanism for dealing with connection setups that take longer than STUN transaction Added example, overview of operations "Close one connection"? Jonathan will think about this, may make sense. Lars - why don't I just wait until something succeeds or fails? If timeouts were set correctly, this wouldn't be an issue. Open issue - disambiguation (but we skipped over this) Open issue - XOR of other addresses? Jonathan doesn't think this is needed, because NATs are looking for their own addresses Philip - don't do this because there are already deployments of this draft? IETF policy is to ignore deployments. Cullen - this was the only address that was getting messed up. Philip - is XOR the default? For mapped address only, with Magic-Cookie, you always get the XOR mapped-address. Philip - for STUN? Magic-cookie isn't an attribute anymore. Chances of XOR screw-up is 2**32. "Backward compatible". Open issue - allocate identification. Problem is when NATs reboot. If refresh comes over new flow, will update mapping to point to new flow. Open issue - demux over TCP. Server needs to look at bytes 5-8 (magic cookie), and server doesn't know framing protocol, doesn't actually know how to do demux when you don't know framing protocols (ex. Jabber requires full XML parsing to identify start/end). Could signal this, but it's a non-starter. "Do cookie hunt" in TCP until you find the cookie? Not at line rate, need timers (so introduce more jitter), danger of four-byte collisions (2**32 collisions in gigabyte files not too unlikely). Always use send and indication? Problem is overhead - no unencapsulated data. Lightweight demux (32-bits, 8 bit type, 24-bit length)? STUN and Data types. Propose that we use this for UDP, too, and evoid need for cookie check. "TURN is sickly stepchild of ICE, it's ugly, I hope we never use it in a real network" Adam - framing doesn't need to be lock-stepped - assume that you're sending two frames at once, you can send multiple within one frame. 8-bit only? Sure, but this skews protocols by one byte, changing alignment (or lack thereof). TCP is a no-brainer - discussion is on UDP. Derek - (missed comment here - sorry!) Sense of room - looks good for TCP, we're not sure about UDP. Open issue - 32-bit alignment - TURN is 32-bit aligned, but data isn't - pad for 32-bit alignment? Will put this in. (Missed last slide comment - sorry!)Multicast Draft (Dan Wing, 10 min)draft-ietf-behave-multicast-01draft-ietf-magma-igmp-proxy-06 Magma draft has already passed IESG review. Will drop the behave draft and let it expire. Cullen - looks close, but if we give MAGMA draft to NAT vendors they will be confused. Make behave draft just point to MAGMA draft, point-by-point? Francois - how would anyone else figure this out in the first place. Is there an existing document where we can include the pointer? Philip - MAGMA draft is in RFC Editor queue, can't squeeze in a change of this size in AUTH-48.ICMP Draft (Saikat Guha, 20 min)draft-srisuresh-behave-nat-icmp-01 Has five requirements, intention is to make ICMP processing determinate without overlapping with TCP and UDP drafts Cullen - what applications does this fix? Beyond PING and TRACEROUTE? Francois - not clear that we need to look for work. If we can't figure out that something's broken, maybe we don't need to do this work at all. Philip - can a NAT vendor screw something up with ICMP? This is more likely than it should be... Discussion topics: Recommend allowing administrators to configure ICMP query session timeout? Magnus - maximum segment lifetime? Do we have consensus on not changing ICMP hard errors to soft errors (or vice versa)? Lars - should not change, don't know what the effect would be. Say this in the draft. Cullen - have never seen a NAT that does this. Francois - are we just saying "must not block ICMP?" Needs to be clarified. Need to put this in the document? Discuss on mailing list. Src IP of ICMP packet with no mapping - NAT must use its own IP address to translate Src IP in the outer IP header - fix checksums if we do? Dan - RPF will cause these packets to be dropped, if we don't. Don't refresh or delete the NAT session while processing an ICMP error packet? Dan - just a little too protocol-specific for us. TCPM has proposal to change soft error (code 10) to a hard error - but this is only a proposal now. Send Fragment Too Big errors when processing ICMP messages with DF set? Lars - RFC 1812 should be the baseline here - "NATs should look like routers". Only show the baseline. From petithug@acm.org Thu, 23 Mar 2006 16:58:57 -0800 (PST) From: Marc Petit-Huguenin Date: Thu, 23 Mar 2006 16:58:57 -0800 (PST) Subject: [Ietf-behave] UDP/TCP in STUN-relay Message-ID: <44234457.8040408@acm.org> MIME-Version: 1.0 Content-Type: text/plain There is one case I do not really understand with STUN-relay. Let say that the STUN client sends an AllocateRequest over UDP, with a REQUESTED-TRANSPORT of TCP. How the STUN-relay server knows what framing to use to relay the data received on the allocated TCP transport to the UDP linkage (see 12.1.1)? Thanks. From derek@counterpath.com Fri, 24 Mar 2006 00:29:45 -0800 (PST) From: derek@counterpath.com Date: Fri, 24 Mar 2006 00:29:45 -0800 (PST) Subject: RE: [Ietf-behave] UDP/TCP in STUN-relay In-Reply-To: <44234457.8040408@acm.org> Message-ID: <2357.204.96.112.231.1143188984.webmail@204.96.112.231> MIME-Version: 1.0 Content-Type: text/plain AFAIK, this is not handled by the draft, but do we need to support this use case? One of the main motivations for cross-protol tuneling was to use TCP/TLS to tunnels through a NAT, and present UDP to the outside world. Unless we can come up with a use case for UDP internally, TCP externally I would recommend removing support for it. Has anyone seen a NAT that allows UDP but blocks TCP? OTOH we definetly need to nail down framing in the TCP->TURN->UDP scenario. I think we can use the TCP framing mechanism that Jonthan proposed at the behave meeting; the server would emit every TCP 'chunk' as a UDP packet. --Derek From dwing@cisco.com Fri, 24 Mar 2006 08:07:12 -0800 (PST) From: "Dan Wing" Date: Fri, 24 Mar 2006 08:07:12 -0800 (PST) Subject: RE: [Ietf-behave] UDP/TCP in STUN-relay In-Reply-To: <2357.204.96.112.231.1143188984.webmail@204.96.112.231> Message-ID: <0d8101c64f5d$02c84530$4d79150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > AFAIK, this is not handled by the draft, but do we need to support > this use case? One of the main motivations for cross-protol > tuneling was to use TCP/TLS to tunnels through a NAT, and present > UDP to the outside world. Unless we can come up with a use case for > UDP internally, TCP externally I would recommend removing support > for it. Has anyone seen a NAT that allows UDP but blocks TCP? That isn't quite the scenario. The scenario where the UDP/TCP interworking is useful is this: Alice---[NAT/firewall]---[TURN]------------[NAT]---Bob <-------TCP---------------->|<-----------UDP--------> Where Alice's NAT/firewall device blocks UDP. Many company firewalls have that behavior, which cause applications such as Skype and Yahoo Voice to send their traffic over TCP. Bob, on the other hand, has a 'normal' NAT, however Bob's endpoint has no support for framing RTP over TCP. This is pretty common -- many endpoints have no ability to send their RTP traffic over TCP. So, this functionality provides a way for Alice and Bob to communicate where they couldn't communicate if they were both forced to use UDP (because Alice's firewall blocks UDP). > OTOH we definetly need to nail down framing in the TCP->TURN->UDP > scenario. I think we can use the TCP framing mechanism that Jonthan > proposed at the behave meeting; the server would emit every > TCP 'chunk' as a UDP packet. -d From derek@counterpath.com Sat, 25 Mar 2006 15:33:13 -0800 (PST) From: derek@counterpath.com Date: Sat, 25 Mar 2006 15:33:13 -0800 (PST) Subject: RE: [Ietf-behave] UDP/TCP in STUN-relay In-Reply-To: <2357.204.96.112.231.1143188984.webmail@204.96.112.231> Message-ID: <6435.208.54.95.129.1143329592.webmail@208.54.95.129> MIME-Version: 1.0 Content-Type: text/plain Dan & I talked about this and realized that one or both may have flipped something in the question. Here's what we agree on, w/ ascii art for clarification. Case #1: Alice---Tcp(or TLS)----[Nat/Firewall]----->Turn---Udp---->Public Network This case will be supported by TURN. The TURN server should turn the TCP stream into UDP packets based on the framing mechanism Jonathan proposed at IETF. Briefly, there is an integer which intidates wheteher or not this is a turn control message + the length of the data if it isn't STUN. UDP packets will be emitted based on this length. Alice----Udp----[Nat/Firewall]----->Turn---Tcp(or TLS)---->Public Network We think this case will not be supported by TURN. It would require implementing the TCP state machine over UDP between alice & the TURN server. Unless someone find a common case where a NAT/FW blocks TCP and allows UDP this should remain out of scope as the implementation cost is very high. Hopefully this clears things up. --Derek From petithug@acm.org Sun, 26 Mar 2006 07:58:42 -0800 (PST) From: Marc Petit-Huguenin Date: Sun, 26 Mar 2006 07:58:42 -0800 (PST) Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay In-Reply-To: <2357.204.96.112.231.1143188984.webmail@204.96.112.231> Message-ID: <4426BA2F.7090205@acm.org> MIME-Version: 1.0 Content-Type: text/plain derek@xxxxxxxxxxxxxxx wrote: > Dan & I talked about this and realized that one or both may have flipped > something in the question. Here's what we agree on, w/ ascii art for > clarification. > > Case #1: > > Alice---Tcp(or TLS)----[Nat/Firewall]----->Turn---Udp---->Public Network > > This case will be supported by TURN. The TURN server should turn the TCP > stream into UDP packets based on the framing mechanism Jonathan proposed > at IETF. Briefly, there is an integer which intidates wheteher or not > this is a turn control message + the length of the data if it isn't STUN. > UDP packets will be emitted based on this length. Yes, this was what Jonathan presented at the BEHAVE meeting, I understand this solution, but my question was not about this. > > Alice----Udp----[Nat/Firewall]----->Turn---Tcp(or TLS)---->Public Network > > We think this case will not be supported by TURN. It would require > implementing the TCP state machine over UDP between alice & the TURN > server. Unless someone find a common case where a NAT/FW blocks TCP and > allows UDP this should remain out of scope as the implementation cost is > very high. The text in the draft explicitly permits to do it: "As a consequence of the REQUESTED-TRANSPORT attribute, it is possible for a client to connect to the server over UDP and request a TCP transport address, and for it to connect to the server over TCP (and TLS, which uses TCP) and request a UDP transport address. In such a case, the server will relay data between them." So from here there is two solutions: Remove the UDP-->TCP case from the draft or explain what TCP framing is used on the relay. It is not implementable as it is. For the TCP framing, one solution would be to define a list of well known TCP framing (contrans, Content-Length), and to pass it as an attribute in the AllocateRequest. But I agree that there is a very limited number of use cases that will use this configuration, so that it can be removed from the draft. -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx From derek@counterpath.com Mon, 27 Mar 2006 13:14:16 -0800 (PST) From: "Derek MacDonald" Date: Mon, 27 Mar 2006 13:14:16 -0800 (PST) Subject: [Ietf-behave] Qeustion about A1(using MD5) as HMAC key in 3489bis-03 Message-ID: <20060327211414.9D25A45BBB2@relay1.r1.iad.emailsrvr.com> MIME-Version: 1.0 Content-Type: text/plain In Section 8.1.2 point 3 the draft states:   The key for MESSAGE-INTEGRITY is MD5(unq(USERNAME-value) ":" unq(REALM-value) ":" password).   What isn’t clear is what MD5 is defined as, is it:   the 128 bit MD5 digest the 32 ASCII printable characters representing the MD5 digest, as defined in rfc2617.   I have seen both implemented; #2 is prob. intended, as that is what SIP element will store for 2617.   --Derek From adam@estacado.net Mon, 27 Mar 2006 15:56:17 -0800 (PST) From: Adam Roach Date: Mon, 27 Mar 2006 15:56:17 -0800 (PST) Subject: [Ietf-behave] TURN/STUN Interoperability Issues Message-ID: <44287B98.6020407@estacado.net> MIME-Version: 1.0 Content-Type: text/plain In trying to implement TURN and STUN, our engineers have discovered a couple of places in the current set of drafts that could be clearer. Below, I describe the ambiguities and propose clarifying text. 1. USERNAME AND PASSWORD LENGTHS -------------------------------- RFC 3489 rather clearly constrained usernames and passwords to be multiples of 4 [sections 11.2.6 and 11.2.7]. This was a perfectly sensible constraint when they were temporary. 3489bis has removed the sentences that specifically constrain usernames and passwords; however, section 11 clearly states that the length of "attributes values MUST be 0 or a multiple of 4 bytes." We assume that the removal of the constraint on username and password lengths is to accommodate the fact that long-term, user-selected usernames and passwords can't be reasonably constrained to multiples of 4 bytes. However, this removal creates an ambiguity in the specification. There is similar ambiguity around REALM. Specifically: If I want to encode a 5-byte username (e.g. "test1"), what is this supposed to look like? With the current specification, there are at least four incompatible encodings that reasonable designers could implement after reading the specification: 1. 00 06 00 08 74 65 73 74 31 00 00 00 2. 00 06 00 08 74 65 73 74 31 20 20 20 3. 00 06 00 05 74 65 73 74 31 4. 00 06 00 05 74 65 73 74 31 00 00 00 Number 1 is based on null-padding of the name to fit into a multiple of 4. This kind of makes sense because C strings are null terminated, and null padding just kind of "feels right." Number 2 is based on the fact that reason phrases are padded with spaces to be a multiple of 4. This is the only mechanism described in the document that talks about *how* to pad fields to be a multiple of 4. It is almost certainly not what we intend. Number 3 kind of misses the point that attributes need to be a multiple of 4; however, it is the encoding that TWO DIFFERENT, INDEPENDENT implementation teams at two different companies implemented, based on the current document. Number 4 takes the BFCP approach of encoding the actual attribute length, but padding out to an even multiple of 4 bytes. I think all of these can work, but we need to pick one and make sure the encoding is described in a clear way that cannot be misconstrued. My personal vote is for method 1. An example would be useful here. I would propose adding text to section 11, at the end of the paragraph starting "In order to align attributes on word boundaries...", to the effect of: In order to align attributes on word boundaries, the length of the all message attributes values MUST be 0 or a multiple of 4 bytes. Extensions to this specification MUST also follow this requirement. Variable-length fields, such as USERNAME and PASSWORD, MUST be padded with ASCII NUL (0x00) characters so as to be a multiple of four bytes in length. For example, a USERNAME of "test1" would be encoded as 00 06 00 08 74 65 73 74 31 00 00 00. I would also put reminder text in the USERNAME, PASSWORD, and REALM entries along the lines of: The value of USERNAME is a variable length opaque value. Like all variable-length fields, USERNAME must be padded with ASCII NUL (0x00) characters so as to be a multiple of four bytes in length. 2. FORMAL DEFINITION OF HMAC KEY CALCULATION -------------------------------------------- Section 8.1.2 of the stun draft starts talking about HMAC key calculation without first defining the syntax being used to define things. While implementors familiar with RFC 2617 will probably recognize the operations and tend to do something sensible, others are likely to be confused. In particular, the operation unq() isn't defined in the STUN draft, and there's no explicit statement that implementors should look to RFC 2617 for its definition. Similarly, the use of quotes around the colons and the implied string concatenation isn't particularly well defined in STUN. Finally -- and this is causing *severe* headaches in our attempts to interop with other implementations -- it is unclear whether the result of hashing this string (to be fed into the HMAC as a key) is the raw 16-byte result of the MD5 hash, or whether it is the 32-byte text hex representation of this hash. The former is a somewhat more obvious implementation choice for people unfamiliar with RFC 2617, while the latter is more consistent with RFC 2617 encoding (from which the TURN draft obviously borrows the mechanism). I would propose removing the final sentence of the first item #3 in section 8.1.2, and replacing it with: The 16-byte key for the MESSAGE-INTEGRITY HMAC is formed by taking the MD5 hash of the result of concatenating the following five fields: - The username, with any trailing nulls removed - A single colon - The realm, with any quotes and trailing nulls removed - A single colon - The password, with any trailing nulls removed For example, if the USERNAME field were 'user', the REALM field were '"realm"', and the PASSWORD field were 'pass', then the 16-byte HMAC key would be the result of performing an MD5 hash on the string 'user:realm:pass', or 0x8493fbc53ba582fb4c044c456bdc40eb. I would also strike the text in section 9.1.1 that re-specifies how to perform the hash, and instead refer to the earlier description: If the USERNAME attribute was present, the server computes the HMAC over the request as described in Section 11.8. The HMAC key is computed as described in section 8.1.2. If the server does not have a record for that username within that realm, the server generates an error response. That error response MUST include an ERROR-CODE attribute with a response code of 436. That error response MUST include a NONCE attribute and a REALM attribute. /a From petithug@acm.org Mon, 27 Mar 2006 16:57:46 -0800 (PST) From: Marc Petit-Huguenin Date: Mon, 27 Mar 2006 16:57:46 -0800 (PST) Subject: Re: [Ietf-behave] TURN/STUN Interoperability Issues In-Reply-To: <44287B98.6020407@estacado.net> Message-ID: <44288A09.6070709@acm.org> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For issue #1, my understanding after the BEHAVE meeting (see slide 11 of the TURN slides) is that the length is the real length of the value of the attribute, but the attribute itself is padded to be a multiple of four. This means that the number of bytes to skip when reading an unknown attribute is (((((int)length) + 3) / 4) * 4), and not ((int)length). This means that in fact the byte value used for padding is irrelevant. I never understood why the attributes had to be 32 bit aligned, now it makes sense. All the implementations I know of, mine and Ethereal included, are incorrect. Adam Roach wrote: > In trying to implement TURN and STUN, our engineers have discovered a > couple of places in the current set of drafts that could be clearer. > Below, I describe the ambiguities and propose clarifying text. > > > 1. USERNAME AND PASSWORD LENGTHS > -------------------------------- > > RFC 3489 rather clearly constrained usernames and passwords to be > multiples of 4 [sections 11.2.6 and 11.2.7]. This was a perfectly > sensible constraint when they were temporary. 3489bis has removed the > sentences that specifically constrain usernames and passwords; however, > section 11 clearly states that the length of "attributes values MUST be > 0 or a multiple of 4 bytes." > > We assume that the removal of the constraint on username and password > lengths is to accommodate the fact that long-term, user-selected > usernames and passwords can't be reasonably constrained to multiples of > 4 bytes. However, this removal creates an ambiguity in the > specification. There is similar ambiguity around REALM. > > Specifically: If I want to encode a 5-byte username (e.g. "test1"), what > is this supposed to look like? With the current specification, there are > at least four incompatible encodings that reasonable designers could > implement after reading the specification: > > 1. 00 06 00 08 74 65 73 74 31 00 00 00 > 2. 00 06 00 08 74 65 73 74 31 20 20 20 > 3. 00 06 00 05 74 65 73 74 31 > 4. 00 06 00 05 74 65 73 74 31 00 00 00 > > Number 1 is based on null-padding of the name to fit into a multiple of > 4. This kind of makes sense because C strings are null terminated, and > null padding just kind of "feels right." > > Number 2 is based on the fact that reason phrases are padded with spaces > to be a multiple of 4. This is the only mechanism described in the > document that talks about *how* to pad fields to be a multiple of 4. It > is almost certainly not what we intend. > > Number 3 kind of misses the point that attributes need to be a multiple > of 4; however, it is the encoding that TWO DIFFERENT, INDEPENDENT > implementation teams at two different companies implemented, based on > the current document. > > Number 4 takes the BFCP approach of encoding the actual attribute > length, but padding out to an even multiple of 4 bytes. > > I think all of these can work, but we need to pick one and make sure the > encoding is described in a clear way that cannot be misconstrued. My > personal vote is for method 1. An example would be useful here. > > I would propose adding text to section 11, at the end of the paragraph > starting "In order to align attributes on word boundaries...", to the > effect of: > > In order to align attributes on word boundaries, the length of the > all message attributes values MUST be 0 or a multiple of 4 bytes. > Extensions to this specification MUST also follow this requirement. > Variable-length fields, such as USERNAME and PASSWORD, MUST be > padded with ASCII NUL (0x00) characters so as to be a multiple of > four bytes in length. For example, a USERNAME of "test1" would be > encoded as 00 06 00 08 74 65 73 74 31 00 00 00. > > I would also put reminder text in the USERNAME, PASSWORD, and REALM > entries along the lines of: > > The value of USERNAME is a variable length opaque value. Like all > variable-length fields, USERNAME must be padded with ASCII NUL > (0x00) characters so as to be a multiple of four bytes in length. > > > > 2. FORMAL DEFINITION OF HMAC KEY CALCULATION > -------------------------------------------- > > Section 8.1.2 of the stun draft starts talking about HMAC key > calculation without first defining the syntax being used to define > things. While implementors familiar with RFC 2617 will probably > recognize the operations and tend to do something sensible, others are > likely to be confused. > > In particular, the operation unq() isn't defined in the STUN draft, and > there's no explicit statement that implementors should look to RFC 2617 > for its definition. Similarly, the use of quotes around the colons and > the implied string concatenation isn't particularly well defined in STUN. > > Finally -- and this is causing *severe* headaches in our attempts to > interop with other implementations -- it is unclear whether the result > of hashing this string (to be fed into the HMAC as a key) is the raw > 16-byte result of the MD5 hash, or whether it is the 32-byte text hex > representation of this hash. The former is a somewhat more obvious > implementation choice for people unfamiliar with RFC 2617, while the > latter is more consistent with RFC 2617 encoding (from which the TURN > draft obviously borrows the mechanism). > > I would propose removing the final sentence of the first item #3 in > section 8.1.2, and replacing it with: > > The 16-byte key for the MESSAGE-INTEGRITY HMAC is formed by taking > the MD5 hash of the result of concatenating the following five fields: > > - The username, with any trailing nulls removed > - A single colon > - The realm, with any quotes and trailing nulls removed > - A single colon > - The password, with any trailing nulls removed > > For example, if the USERNAME field were 'user', the REALM field were > '"realm"', and the PASSWORD field were 'pass', then the 16-byte HMAC > key would be the result of performing an MD5 hash on the string > 'user:realm:pass', or 0x8493fbc53ba582fb4c044c456bdc40eb. > > > I would also strike the text in section 9.1.1 that re-specifies how to > perform the hash, and instead refer to the earlier description: > > If the USERNAME attribute was present, the server computes the HMAC > over the request as described in Section 11.8. The HMAC key is > computed as described in section 8.1.2. If the server does not have > a record for that username within that realm, the server generates > an error response. That error response MUST include an ERROR-CODE > attribute with a response code of 436. That error response MUST > include a NONCE attribute and a REALM attribute. > > /a > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > - -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEKInM9RoMZyVa61cRAl1VAJ9NnxhdGjnSG6n0YL+26Sb92XzWYwCdHDpV zhMcFtTITnAlgXux/xSJfZE= =GLLh -----END PGP SIGNATURE----- -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx From derek@counterpath.com Mon, 27 Mar 2006 16:58:24 -0800 (PST) From: "Derek MacDonald" Date: Mon, 27 Mar 2006 16:58:24 -0800 (PST) Subject: RE: [Ietf-behave] TURN/STUN Interoperability Issues In-Reply-To: <44287B98.6020407@estacado.net> Message-ID: <20060328005822.9FD234C8ADA@relay3.r3.iad.emailsrvr.com> MIME-Version: 1.0 Content-Type: text/plain See Inline. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave- > bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Adam Roach > Sent: Monday, March 27, 2006 3:56 PM > To: Behave; Jonathan Rosenberg; Christian Huitema; Rohan Mahy; Dan Wing > Cc: Robert Sparks > Subject: [Ietf-behave] TURN/STUN Interoperability Issues > > In trying to implement TURN and STUN, our engineers have discovered a > couple of places in the current set of drafts that could be clearer. > Below, I describe the ambiguities and propose clarifying text. > > > 1. USERNAME AND PASSWORD LENGTHS > -------------------------------- > > RFC 3489 rather clearly constrained usernames and passwords to be > multiples of 4 [sections 11.2.6 and 11.2.7]. This was a perfectly > sensible constraint when they were temporary. 3489bis has removed the > sentences that specifically constrain usernames and passwords; however, > section 11 clearly states that the length of "attributes values MUST be > 0 or a multiple of 4 bytes." > > We assume that the removal of the constraint on username and password > lengths is to accommodate the fact that long-term, user-selected > usernames and passwords can't be reasonably constrained to multiples of > 4 bytes. However, this removal creates an ambiguity in the > specification. There is similar ambiguity around REALM. > > Specifically: If I want to encode a 5-byte username (e.g. "test1"), what > is this supposed to look like? With the current specification, there are > at least four incompatible encodings that reasonable designers could > implement after reading the specification: > > 1. 00 06 00 08 74 65 73 74 31 00 00 00 > 2. 00 06 00 08 74 65 73 74 31 20 20 20 > 3. 00 06 00 05 74 65 73 74 31 > 4. 00 06 00 05 74 65 73 74 31 00 00 00 > > Number 1 is based on null-padding of the name to fit into a multiple of > 4. This kind of makes sense because C strings are null terminated, and > null padding just kind of "feels right." > > Number 2 is based on the fact that reason phrases are padded with spaces > to be a multiple of 4. This is the only mechanism described in the > document that talks about *how* to pad fields to be a multiple of 4. It > is almost certainly not what we intend. > > Number 3 kind of misses the point that attributes need to be a multiple > of 4; however, it is the encoding that TWO DIFFERENT, INDEPENDENT > implementation teams at two different companies implemented, based on > the current document. > > Number 4 takes the BFCP approach of encoding the actual attribute > length, but padding out to an even multiple of 4 bytes. > > I think all of these can work, but we need to pick one and make sure the > encoding is described in a clear way that cannot be misconstrued. My > personal vote is for method 1. An example would be useful here. I also vote for method 1. > > I would propose adding text to section 11, at the end of the paragraph > starting "In order to align attributes on word boundaries...", to the > effect of: > > In order to align attributes on word boundaries, the length of the > all message attributes values MUST be 0 or a multiple of 4 bytes. > Extensions to this specification MUST also follow this requirement. > Variable-length fields, such as USERNAME and PASSWORD, MUST be > padded with ASCII NUL (0x00) characters so as to be a multiple of > four bytes in length. For example, a USERNAME of "test1" would be > encoded as 00 06 00 08 74 65 73 74 31 00 00 00. > > I would also put reminder text in the USERNAME, PASSWORD, and REALM > entries along the lines of: > > The value of USERNAME is a variable length opaque value. Like all > variable-length fields, USERNAME must be padded with ASCII NUL > (0x00) characters so as to be a multiple of four bytes in length. > > > > 2. FORMAL DEFINITION OF HMAC KEY CALCULATION > -------------------------------------------- > > Section 8.1.2 of the stun draft starts talking about HMAC key > calculation without first defining the syntax being used to define > things. While implementors familiar with RFC 2617 will probably > recognize the operations and tend to do something sensible, others are > likely to be confused. > > In particular, the operation unq() isn't defined in the STUN draft, and > there's no explicit statement that implementors should look to RFC 2617 > for its definition. Similarly, the use of quotes around the colons and > the implied string concatenation isn't particularly well defined in STUN. > > Finally -- and this is causing *severe* headaches in our attempts to > interop with other implementations -- it is unclear whether the result > of hashing this string (to be fed into the HMAC as a key) is the raw > 16-byte result of the MD5 hash, or whether it is the 32-byte text hex > representation of this hash. The former is a somewhat more obvious > implementation choice for people unfamiliar with RFC 2617, while the > latter is more consistent with RFC 2617 encoding (from which the TURN > draft obviously borrows the mechanism). > > I would propose removing the final sentence of the first item #3 in > section 8.1.2, and replacing it with: > > The 16-byte key for the MESSAGE-INTEGRITY HMAC is formed by taking > the MD5 hash of the result of concatenating the following five fields: > > - The username, with any trailing nulls removed > - A single colon > - The realm, with any quotes and trailing nulls removed > - A single colon > - The password, with any trailing nulls removed > > For example, if the USERNAME field were 'user', the REALM field were > '"realm"', and the PASSWORD field were 'pass', then the 16-byte HMAC > key would be the result of performing an MD5 hash on the string > 'user:realm:pass', or 0x8493fbc53ba582fb4c044c456bdc40eb. After talking to Adam, I have been swayed to the 16-byte HMAC key camp. > > > I would also strike the text in section 9.1.1 that re-specifies how to > perform the hash, and instead refer to the earlier description: > > If the USERNAME attribute was present, the server computes the HMAC > over the request as described in Section 11.8. The HMAC key is > computed as described in section 8.1.2. If the server does not have > a record for that username within that realm, the server generates > an error response. That error response MUST include an ERROR-CODE > attribute with a response code of 436. That error response MUST > include a NONCE attribute and a REALM attribute. > > /a > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From juberti@aol.com Mon, 27 Mar 2006 18:30:38 -0800 (PST) From: Justin Uberti Date: Mon, 27 Mar 2006 18:30:38 -0800 (PST) Subject: Re: [Ietf-behave] TURN/STUN Interoperability Issues In-Reply-To: <44287B98.6020407@estacado.net> Message-ID: <44289FC8.8000300@aol.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Thanks for the clarification; should it be the case that a multiple of 4 bytes is read for every attribute (not just unknown ones)? Also, I assume the requirement for 4-byte alignment is a performance optimization for CPUs that require integers to be aligned - is this correct? Thanks, --justin petithug@xxxxxxx wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For issue #1, my understanding after the BEHAVE meeting (see slide 11 of the TURN slides) is that the length is the real length of the value of the attribute, but the attribute itself is padded to be a multiple of four. This means that the number of bytes to skip when reading an unknown attribute is (((((int)length) + 3) / 4) * 4), and not ((int)length). This means that in fact the byte value used for padding is irrelevant. I never understood why the attributes had to be 32 bit aligned, now it makes sense. All the implementations I know of, mine and Ethereal included, are incorrect. From petithug@acm.org Tue, 28 Mar 2006 03:14:47 -0800 (PST) From: Marc Petit-Huguenin Date: Tue, 28 Mar 2006 03:14:47 -0800 (PST) Subject: Re: [Ietf-behave] TURN/STUN Interoperability Issues In-Reply-To: <44287B98.6020407@estacado.net> Message-ID: <44291AA4.3000803@acm.org> MIME-Version: 1.0 Content-Type: text/plain Justin Uberti wrote: > Hi, > > Thanks for the clarification; should it be the case that a multiple of 4 > bytes is read for every attribute (not just unknown ones)? Yes. This was just an example. > > Also, I assume the requirement for 4-byte alignment is a performance > optimization for CPUs that require integers to be aligned - is this > correct? I do not know. > > Thanks, > --justin > > petithug@xxxxxxx wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> For issue #1, my understanding after the BEHAVE meeting (see slide 11 of >> the TURN slides) is that the length is the real length of the value of >> the attribute, but the attribute itself is padded to be a multiple of >> four. This means that the number of bytes to skip when reading an >> unknown attribute is (((((int)length) + 3) / 4) * 4), and not >> ((int)length). >> >> This means that in fact the byte value used for padding is irrelevant. I >> never understood why the attributes had to be 32 bit aligned, now it >> makes sense. >> >> All the implementations I know of, mine and Ethereal included, are >> incorrect. >> >> >> > > -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx From Erkki.Koivusalo@nokia.com Tue, 28 Mar 2006 04:26:02 -0800 (PST) From: Date: Tue, 28 Mar 2006 04:26:02 -0800 (PST) Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 In-Reply-To: <05b101c64d20$2472bfb0$3b5b150a@amer.cisco.com> Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F022022F5@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain Hi Dan, I found another inconsistency in rfc3489bis-03: 8.1.1. Discovery The DNS SRV service name is "stun". The protocol is "udp" for sending Binding Requests, or "tcp" for sending Shared Secret Requests. 12.5.2. Client Discovery of Server The client follows the procedures in Section 8.1.1, except the SRV protocol is TCP rather than UDP and the service name "stun-tls". For example a client would look up "_stun-tls._tcp.example.com" in DNS. So what is the service name for discovering STUN server supporting Shared Secret requests over TLS: "stun" or "stun-tls" ? I would prefer "stun" unless there is a really good reason to introduce a new service name for this usage. What was the reason for introducing "stun-tls" ? Regards, Erkki >-----Original Message----- >From: ext Dan Wing [mailto:dwing@xxxxxxxxx] >Sent: 21.March.2006 21:46 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 > >You're right. Let me play with some text and reply back, >probably later >tonight. > >-d > > >> -----Original Message----- >> From: Erkki.Koivusalo@xxxxxxxxx [mailto:Erkki.Koivusalo@xxxxxxxxx] >> Sent: Tuesday, March 21, 2006 8:56 AM >> To: dwing@xxxxxxxxx; ietf-behave@xxxxxxxxxxxxxxxxxxx >> Subject: RE: [Ietf-behave] Comments on >draft-ietf-behave-rfc3489bis-03 >> >> >> Hi, >> >> >> 8.1.4. Processing Responses >> >> >> >> the response as described in Section 11.8. The key to use >> >> depends on >> >> the shared secret mechanism. If the STUN Shared Secret >> >Request was >> >> used, the key MUST be same as used to compute the >> >MESSAGE-INTEGRITY >> >> attribute in the request. >> >> >> >> What if the Shared Secret Request was not used ? I believe >> also that >> >> should be mentioned here for completeness. >> > >> >Ok. I propose adding the following text: >> > >> > If the STUN client and STUN server do not share a secret (obtained >> > for example via the STUN shared secret request), it isn't possible >> > to protect the message using the MESSAGE-INTEGRITY attribute. >> > >> >Let me know if that is satisfactory. >> >> Sorry, not quite. You extended it for the case where there is no >> message integrity check like in NAT keepalive usage like described >> in draft-ietf-sip-outbound-02. But it would still lack the >> Connectivity >> Check usage where message integrity check will be done based on >> password got from a=ice-pwd SDP attribute, instead of getting it with >> STUN Shared Secret Response. >> >> I believe all those three cases are worth mentioning after the >> "The key to use depends on the shared secret mechanism" statement. >> Maybe you should make it to appear as a bulleted list of >three cases ? >> >> Regards, >> >> Erkki >> >> >-----Original Message----- >> >From: ext Dan Wing [mailto:dwing@xxxxxxxxx] >> >Sent: 21.March.2006 18:35 >> >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); >> >ietf-behave@xxxxxxxxxxxxxxxxxxx >> >Subject: RE: [Ietf-behave] Comments on >> draft-ietf-behave-rfc3489bis-03 >> > >> >> -----Original Message----- >> >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >> >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of >> >> Erkki.Koivusalo@xxxxxxxxx >> >> Sent: Tuesday, March 21, 2006 8:16 AM >> >> To: ietf-behave@xxxxxxxxxxxxxxxxxxx >> >> Subject: Re: [Ietf-behave] Comments on >> >draft-ietf-behave-rfc3489bis-03 >> >> >> >> >> >> Hi, >> >> >> >> I have a few rather minor comments for the STUN bis-03: >> >> >> >> 5. Overview of Operation >> >> >> >> This section is descriptive only. Normative behavior is >> >> described in >> >> Section 8 and Section . >> >> >> >> Section number is missing from the second reference. >> > >> >Thanks. Will be fixed in -04. >> > >> >> 8.1.4. Processing Responses >> >> >> >> the response as described in Section 11.8. The key to use >> >> depends on >> >> the shared secret mechanism. If the STUN Shared Secret >> >Request was >> >> used, the key MUST be same as used to compute the >> >MESSAGE-INTEGRITY >> >> attribute in the request. >> >> >> >> What if the Shared Secret Request was not used ? I believe >> also that >> >> should be mentioned here for completeness. >> > >> >Ok. I propose adding the following text: >> > >> > If the STUN client and STUN server do not share a secret (obtained >> > for example via the STUN shared secret request), it isn't possible >> > to protect the message using the MESSAGE-INTEGRITY attribute. >> > >> >Let me know if that is satisfactory. >> > >> >> SHOULD obtain a new one-time username and password, and >> retry the >> >> Allocate Request with a new transaction. >> >> >> >> Allocate Request is not defined in this spec. >> > >> >Ok, will fix. That's a bug when we merged text from TURN. >> > >> >> 9.2. Indication Message Types >> >> >> >> Indication messages cause the server to change its state. >> >> >> >> What does that mean ? How does the server change its state ? >> > >> >Right now, only TURN is using indication messages (send >> >indication). TURN's >> >send indication causes the TURN server to actually start >> >forwarding data to >> >the remote endpoint. >> > >> >The reason Indications are in STUN is to describe them in general. >> > >> >I'll add more text in -04 so the purpose of indication >> >messages is clearer. >> > >> >> 11.11. ALTERNATE-SERVER >> >> 11.17. ALTERNATE-SERVER >> >> >> >> There are two sub-sections to section 11 that describe >> >> ALTERNATE-SERVER >> >> attributes (11.11 and 11.17). I think they are redundant. >> >> (Fredrik Thulin already mentioned this but Dan did not >> answer to this >> >> point, so I decided to repeat the comment) >> > >> >Yes, they're redundant. Will be fixed in -04. >> > >> >-d >> > >> >> Regards, >> >> >> >> Erkki >> >> ____________________________________ >> >> >> >> Erkki Koivusalo >> >> Nokia Mobile Software >> >> tel:+358 40 7571197 >> >> mailto:erkki.koivusalo@xxxxxxxxx >> >> ____________________________________ >> >> _______________________________________________ >> >> Ietf-behave mailing list >> >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> > > From pete.cordell@tech-know-ware.com Tue, 28 Mar 2006 06:44:04 -0800 (PST) From: "Pete Cordell" Date: Tue, 28 Mar 2006 06:44:04 -0800 (PST) Subject: Re: [Ietf-behave] TURN/STUN Interoperability Issues In-Reply-To: <44287B98.6020407@estacado.net> Message-ID: <00eb01c65276$0e613cf0$0600a8c0@RW> MIME-Version: 1.0 Content-Type: text/plain ----- Original Message ----- From: "Justin Uberti" Also, I assume the requirement for 4-byte alignment is a performance optimization for CPUs that require integers to be aligned - is this correct? It seems that IETF binary protocols are historically done that way (see IP, TCP etc.). It helps processors such as 68000 and maybe Sparc and maybe ARM etc. Mind you, even the 68020 could read integers starting at non-aligned boundaries. As a colleague once told me, "It's an optimization for a minority architecture!" (e.g. in some cases you can use the trick of crafting a C struct that overlays the actual message bytes.) Personally, for portability I'd recommend treating such messages as byte streams but I may be in the minority! The only real advantage of it now is that it potentially makes the ASCII art pictures of messages more precise. HTH, Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= From dwing@cisco.com Tue, 28 Mar 2006 08:07:12 -0800 (PST) From: "Dan Wing" Date: Tue, 28 Mar 2006 08:07:12 -0800 (PST) Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F022022F5@esebe103.NOE.Nokia.com> Message-ID: <176601c65281$acbdda60$1e73150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > So what is the service name for discovering STUN server supporting > Shared Secret requests over TLS: "stun" or "stun-tls" ? I would > prefer "stun" unless there is a really good reason to introduce > a new service name for this usage. What was the reason for > introducing "stun-tls" ? Many server implementations need to know if they're going to receive a TCP SYN (and subsequent TCP connection establishment) and then a TLS client hello (and subsequent TLS setup) and then a STUN Request message, or if they're going to receive a TCP SYN (and TCP connection establishment) followed immediately by a STUN Request. With most protocols (HTTP/HTTPS, POP3/POP3S, IMAP/IMAPS) this is done with separate ports. Using different SRV records for STUN and STUN-over-TLS allows the same separation if the server wants separate ports. If the server is capable of multiplexing TLS and non-TLS connections on the same port, the DNS SRV record can be pointed to the same port. -d From adam@estacado.net Tue, 28 Mar 2006 09:08:43 -0800 (PST) From: Adam Roach Date: Tue, 28 Mar 2006 09:08:43 -0800 (PST) Subject: Re: [Ietf-behave] TURN/STUN Interoperability Issues In-Reply-To: <44287B98.6020407@estacado.net> Message-ID: <44296D93.3030809@estacado.net> MIME-Version: 1.0 Content-Type: text/plain Pete Cordell wrote: > ----- Original Message ----- From: "Justin Uberti" > > >> Also, I assume the requirement for 4-byte alignment is a performance >> optimization for CPUs that require integers to be aligned - is this >> correct? > > > It seems that IETF binary protocols are historically done that way > (see IP, > TCP etc.). It helps processors such as 68000 and maybe Sparc and > maybe ARM > etc. Mind you, even the 68020 could read integers starting at > non-aligned > boundaries. As a colleague once told me, "It's an optimization for a > minority architecture!" Minority perhaps, but not antiquated (as you imply). Even modern ultrasparc processors will SIGBUS if you try to access a 32-bit value that isn't 32-bit aligned. Without backing data, I would be hesitant to construe the use of Sun servers in data centers as a minority. I would guess they make up a nontrivial fraction of such servers, in fact. /a From adam@estacado.net Tue, 28 Mar 2006 14:20:47 -0800 (PST) From: Adam Roach Date: Tue, 28 Mar 2006 14:20:47 -0800 (PST) Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay In-Reply-To: <2357.204.96.112.231.1143188984.webmail@204.96.112.231> Message-ID: <4429B6B4.6060801@estacado.net> MIME-Version: 1.0 Content-Type: text/plain Marc Petit-Huguenin wrote: >The text in the draft explicitly permits to do it: > >"As a consequence of the REQUESTED-TRANSPORT attribute, it is possible > for a client to connect to the server over UDP and request a TCP > transport address, and for it to connect to the server over TCP (and > TLS, which uses TCP) and request a UDP transport address. In such a > case, the server will relay data between them." > >... > >But I agree that there is a very limited number of use cases that will >use this configuration, so that it can be removed from the draft. > > > I also vote for removing this from the draft. Specifying it will be a lot of work; implementing it will be even more; and no one has come up with a situation in which it is useful. /a From juberti@aol.com Tue, 28 Mar 2006 14:36:35 -0800 (PST) From: "Justin Uberti" Date: Tue, 28 Mar 2006 14:36:35 -0800 (PST) Subject: [Ietf-behave] Lightweight framing Message-ID: <4429BA75.30308@aol.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Is the new lightweight framing to be used only in passthru mode (i.e. to/from active destination), and for both UDP and TCP? And as a result, the magic cookie now is only used for differentiating between old and new STUN/TURN clients? Just making sure my assumptions are correct. Thanks, --justin From manjur@eyeball.com Tue, 28 Mar 2006 14:45:12 -0800 (PST) From: "Manjur" Date: Tue, 28 Mar 2006 14:45:12 -0800 (PST) Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay In-Reply-To: <2357.204.96.112.231.1143188984.webmail@204.96.112.231> Message-ID: <003301c652b9$447937a0$f901020a@eyeball.com> MIME-Version: 1.0 Content-Type: text/plain Comment is inlined ----- Original Message ----- From: "Adam Roach" To: "Marc Petit-Huguenin" Cc: Sent: Tuesday, March 28, 2006 2:20 PM Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay > Marc Petit-Huguenin wrote: > > >The text in the draft explicitly permits to do it: > > > >"As a consequence of the REQUESTED-TRANSPORT attribute, it is possible > > for a client to connect to the server over UDP and request a TCP > > transport address, and for it to connect to the server over TCP (and > > TLS, which uses TCP) and request a UDP transport address. In such a > > case, the server will relay data between them." > > > >... > > > >But I agree that there is a very limited number of use cases that will > >use this configuration, so that it can be removed from the draft. > > > > > > > > I also vote for removing this from the draft. Specifying it will be a > lot of work; implementing it will be even more; and no one has come up > with a situation in which it is useful. I would like to say that it should be fine to keep this flexibility of the REQUESTED-TRANSPORT attribute. STUN-relayed server comes to help the problem with NAT traversal and we should not ignore the limited number of case as well. Moreover, it gives more control to the client and the STUN-server to use not only media but also file-transfer and other signaling communication. It makes a bridge/tunnel to tcp and udp clinets/servers. I found it very much useful when a tcp client(say udp is block) wants to communicate to a udp server(server has only udp support) through the STUN-relayed server. > > /a > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From adam@estacado.net Tue, 28 Mar 2006 14:56:43 -0800 (PST) From: Adam Roach Date: Tue, 28 Mar 2006 14:56:43 -0800 (PST) Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay In-Reply-To: <2357.204.96.112.231.1143188984.webmail@204.96.112.231> Message-ID: <4429BF1B.2090706@estacado.net> MIME-Version: 1.0 Content-Type: text/plain Manjur wrote: >I would like to say that it should be fine to keep this flexibility of the >REQUESTED-TRANSPORT attribute. >STUN-relayed server comes to help the problem with NAT traversal and we >should not ignore the limited number of case as well. >Moreover, it gives more control to the client and the STUN-server to use not >only media but also file-transfer and other signaling communication. >It makes a bridge/tunnel to tcp and udp clinets/servers. >I found it very much useful when a tcp client(say udp is block) wants to >communicate to a udp server(server has only udp support) through the >STUN-relayed server. > Derek tried to clear this up, but apparently confusion continues to reign. No one is proposing that the use case you describe should be removed. Currently, the TURN draft allows four combinations: TO CLIENT TO NETWORK --------- ---------- 1. TCP TCP 2. UDP UDP 3. TCP UDP 4. UDP TCP What you want to do is handled by #3. As far as I can tell, everyone wants to keep #3. No one has proposed removing #3. What is being proposed is that #4 be removed. The problem is that #4 is currently underspecified, will be difficult to specify, will be very difficult to implement, and will not actually be useful. /a From jdrosen@cisco.com Wed, 29 Mar 2006 11:03:37 -0800 (PST) From: Jonathan Rosenberg Date: Wed, 29 Mar 2006 11:03:37 -0800 (PST) Subject: [Ietf-behave] Re: TURN/STUN Interoperability Issues In-Reply-To: <44287B98.6020407@estacado.net> Message-ID: <442AD9FC.9090501@cisco.com> MIME-Version: 1.0 Content-Type: text/plain To be clear, on the first issue, we discussed this at IETF and agreed on approach 4, which says that the attribute length value encodes the length of the actual data, but it is padded out when placed into the packet in order to equal a multiple of 32 bits. In such a case, the value of the pad is irrelevant. Unless someone says this gives them real heartburn I plan on proceeding with that approach. On the second issue, thanks for pointing out this (big) ambiguity. I am fine with the 16 byte binary value and am happy to incorporate your proposed text. Thanks much for sending it. -Jonathan R. Rohan Mahy wrote: Hi Adam, Personally I like #3 and would be happy to abandon alignment in general, however I do not feel strongly about this. If we insist on preserving alignment, I vote for #4. I think this is much "safer" should someone send an embedded null in the middle of a value. thanks, -rohan On Mar 27, 2006, at 15:56, Adam Roach wrote: In trying to implement TURN and STUN, our engineers have discovered a couple of places in the current set of drafts that could be clearer. Below, I describe the ambiguities and propose clarifying text. 1. USERNAME AND PASSWORD LENGTHS -------------------------------- RFC 3489 rather clearly constrained usernames and passwords to be multiples of 4 [sections 11.2.6 and 11.2.7]. This was a perfectly sensible constraint when they were temporary. 3489bis has removed the sentences that specifically constrain usernames and passwords; however, section 11 clearly states that the length of "attributes values MUST be 0 or a multiple of 4 bytes." We assume that the removal of the constraint on username and password lengths is to accommodate the fact that long-term, user-selected usernames and passwords can't be reasonably constrained to multiples of 4 bytes. However, this removal creates an ambiguity in the specification. There is similar ambiguity around REALM. Specifically: If I want to encode a 5-byte username (e.g. "test1"), what is this supposed to look like? With the current specification, there are at least four incompatible encodings that reasonable designers could implement after reading the specification: 1. 00 06 00 08 74 65 73 74 31 00 00 00 2. 00 06 00 08 74 65 73 74 31 20 20 20 3. 00 06 00 05 74 65 73 74 31 4. 00 06 00 05 74 65 73 74 31 00 00 00 Number 1 is based on null-padding of the name to fit into a multiple of 4. This kind of makes sense because C strings are null terminated, and null padding just kind of "feels right." Number 2 is based on the fact that reason phrases are padded with spaces to be a multiple of 4. This is the only mechanism described in the document that talks about *how* to pad fields to be a multiple of 4. It is almost certainly not what we intend. Number 3 kind of misses the point that attributes need to be a multiple of 4; however, it is the encoding that TWO DIFFERENT, INDEPENDENT implementation teams at two different companies implemented, based on the current document. Number 4 takes the BFCP approach of encoding the actual attribute length, but padding out to an even multiple of 4 bytes. I think all of these can work, but we need to pick one and make sure the encoding is described in a clear way that cannot be misconstrued. My personal vote is for method 1. An example would be useful here. I would propose adding text to section 11, at the end of the paragraph starting "In order to align attributes on word boundaries...", to the effect of: In order to align attributes on word boundaries, the length of the all message attributes values MUST be 0 or a multiple of 4 bytes. Extensions to this specification MUST also follow this requirement. Variable-length fields, such as USERNAME and PASSWORD, MUST be padded with ASCII NUL (0x00) characters so as to be a multiple of four bytes in length. For example, a USERNAME of "test1" would be encoded as 00 06 00 08 74 65 73 74 31 00 00 00. I would also put reminder text in the USERNAME, PASSWORD, and REALM entries along the lines of: The value of USERNAME is a variable length opaque value. Like all variable-length fields, USERNAME must be padded with ASCII NUL (0x00) characters so as to be a multiple of four bytes in length. 2. FORMAL DEFINITION OF HMAC KEY CALCULATION -------------------------------------------- Section 8.1.2 of the stun draft starts talking about HMAC key calculation without first defining the syntax being used to define things. While implementors familiar with RFC 2617 will probably recognize the operations and tend to do something sensible, others are likely to be confused. In particular, the operation unq() isn't defined in the STUN draft, and there's no explicit statement that implementors should look to RFC 2617 for its definition. Similarly, the use of quotes around the colons and the implied string concatenation isn't particularly well defined in STUN. Finally -- and this is causing *severe* headaches in our attempts to interop with other implementations -- it is unclear whether the result of hashing this string (to be fed into the HMAC as a key) is the raw 16-byte result of the MD5 hash, or whether it is the 32-byte text hex representation of this hash. The former is a somewhat more obvious implementation choice for people unfamiliar with RFC 2617, while the latter is more consistent with RFC 2617 encoding (from which the TURN draft obviously borrows the mechanism). I would propose removing the final sentence of the first item #3 in section 8.1.2, and replacing it with: The 16-byte key for the MESSAGE-INTEGRITY HMAC is formed by taking the MD5 hash of the result of concatenating the following five fields: - The username, with any trailing nulls removed - A single colon - The realm, with any quotes and trailing nulls removed - A single colon - The password, with any trailing nulls removed For example, if the USERNAME field were 'user', the REALM field were '"realm"', and the PASSWORD field were 'pass', then the 16-byte HMAC key would be the result of performing an MD5 hash on the string 'user:realm:pass', or 0x8493fbc53ba582fb4c044c456bdc40eb. I would also strike the text in section 9.1.1 that re-specifies how to perform the hash, and instead refer to the earlier description: If the USERNAME attribute was present, the server computes the HMAC over the request as described in Section 11.8. The HMAC key is computed as described in section 8.1.2. If the server does not have a record for that username within that realm, the server generates an error response. That error response MUST include an ERROR-CODE attribute with a response code of 436. That error response MUST include a NONCE attribute and a REALM attribute. /a -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Wed, 29 Mar 2006 11:27:11 -0800 (PST) From: Jonathan Rosenberg Date: Wed, 29 Mar 2006 11:27:11 -0800 (PST) Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay In-Reply-To: <2357.204.96.112.231.1143188984.webmail@204.96.112.231> Message-ID: <442ADF8D.10007@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I'm not opposed to removing #4, but I can at least say what I had in mind. Whether it works or is useful, is a different question. The idea is that the TURN server would be receiving TCP segments from the public network. As it receives each segment, it places the content into a UDP packet and passes it on to the client. Thus, the TURN server is not assuming any framing at all; the UDP datagrams merely carry the TCP data without regard to any kind of framing. now, the problem here is that this is going to break horribly in cases where there is UDP packet loss or reordering. Thats because the tcp framing mechanism most likely assumes reliable in order delivery, and if this is violated, the framing mechanism probably won't be useful to the client. Now, there are potential TCP framing mechanisms which can work when translated to UDP; namely ones that rely on start codes for framing, along with embedded sequence numbers. How common is that? probably not too much. Certainly not useful for RTP over TCP. As such, I would agree with the current proposal to remove this capability from the draft, unless someone can provide a use case and solution that works (since mine doesnt). To specify this, I wouldn't change any syntax, but have the turn server reject a request for TCP transport if the request arrived over UDP. Likely this requires a new error code. Thanks, Jonathan R. Adam Roach wrote: Manjur wrote: I would like to say that it should be fine to keep this flexibility of the REQUESTED-TRANSPORT attribute. STUN-relayed server comes to help the problem with NAT traversal and we should not ignore the limited number of case as well. Moreover, it gives more control to the client and the STUN-server to use not only media but also file-transfer and other signaling communication. It makes a bridge/tunnel to tcp and udp clinets/servers. I found it very much useful when a tcp client(say udp is block) wants to communicate to a udp server(server has only udp support) through the STUN-relayed server. Derek tried to clear this up, but apparently confusion continues to reign. No one is proposing that the use case you describe should be removed. Currently, the TURN draft allows four combinations: TO CLIENT TO NETWORK --------- ---------- 1. TCP TCP 2. UDP UDP 3. TCP UDP 4. UDP TCP What you want to do is handled by #3. As far as I can tell, everyone wants to keep #3. No one has proposed removing #3. What is being proposed is that #4 be removed. The problem is that #4 is currently underspecified, will be difficult to specify, will be very difficult to implement, and will not actually be useful. /a _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From manjur@eyeball.com Wed, 29 Mar 2006 11:56:06 -0800 (PST) From: "Manjur" Date: Wed, 29 Mar 2006 11:56:06 -0800 (PST) Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay In-Reply-To: <2357.204.96.112.231.1143188984.webmail@204.96.112.231> Message-ID: <006301c6536a$cefb91f0$f901020a@eyeball.com> MIME-Version: 1.0 Content-Type: text/plain I want to keep #4. I am thinking of the flexibility issue of client and STUN-relay server with #1 to #4. I believe STUN-relay will not have limited usage with media traversal only. It can use to make a tunneling/bridge with UDP and TCP protocol. Why I support #4 is that a UDP client can connect to a TCP server through the STUN-relay server. ----- Original Message ----- From: "Jonathan Rosenberg" To: "Adam Roach" Cc: "Manjur" ; Sent: Wednesday, March 29, 2006 11:27 AM Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay > I'm not opposed to removing #4, but I can at least say what I had in > mind. Whether it works or is useful, is a different question. > > The idea is that the TURN server would be receiving TCP segments from > the public network. As it receives each segment, it places the content > into a UDP packet and passes it on to the client. Thus, the TURN server > is not assuming any framing at all; the UDP datagrams merely carry the > TCP data without regard to any kind of framing. > > now, the problem here is that this is going to break horribly in cases > where there is UDP packet loss or reordering. Thats because the tcp > framing mechanism most likely assumes reliable in order delivery, and if > this is violated, the framing mechanism probably won't be useful to the > client. > > Now, there are potential TCP framing mechanisms which can work when > translated to UDP; namely ones that rely on start codes for framing, > along with embedded sequence numbers. How common is that? probably not > too much. Certainly not useful for RTP over TCP. > > As such, I would agree with the current proposal to remove this > capability from the draft, unless someone can provide a use case and > solution that works (since mine doesnt). > > To specify this, I wouldn't change any syntax, but have the turn server > reject a request for TCP transport if the request arrived over UDP. > Likely this requires a new error code. > > Thanks, > Jonathan R. > > Adam Roach wrote: > > > Manjur wrote: > > > > > >>I would like to say that it should be fine to keep this flexibility of the > >>REQUESTED-TRANSPORT attribute. > >>STUN-relayed server comes to help the problem with NAT traversal and we > >>should not ignore the limited number of case as well. > >>Moreover, it gives more control to the client and the STUN-server to use not > >>only media but also file-transfer and other signaling communication. > >>It makes a bridge/tunnel to tcp and udp clinets/servers. > >>I found it very much useful when a tcp client(say udp is block) wants to > >>communicate to a udp server(server has only udp support) through the > >>STUN-relayed server. > >> > > > > > > Derek tried to clear this up, but apparently confusion continues to > > reign. No one is proposing that the use case you describe should be removed. > > > > Currently, the TURN draft allows four combinations: > > > > TO CLIENT TO NETWORK > > --------- ---------- > > 1. TCP TCP > > 2. UDP UDP > > 3. TCP UDP > > 4. UDP TCP > > > > What you want to do is handled by #3. As far as I can tell, everyone > > wants to keep #3. No one has proposed removing #3. > > > > What is being proposed is that #4 be removed. > > > > The problem is that #4 is currently underspecified, will be difficult to > > specify, will be very difficult to implement, and will not actually be > > useful. > > > > /a > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com From jdrosen@cisco.com Wed, 29 Mar 2006 12:24:32 -0800 (PST) From: Jonathan Rosenberg Date: Wed, 29 Mar 2006 12:24:32 -0800 (PST) Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay In-Reply-To: <2357.204.96.112.231.1143188984.webmail@204.96.112.231> Message-ID: <442AECFE.4070703@cisco.com> MIME-Version: 1.0 Content-Type: text/plain So, I'll repeat the question - what is the specific use case (what kind of tcp server and why wouldn't the client have tcp), and how do you propose solving the framing problem. -Jonathan R. Manjur wrote: I want to keep #4. I am thinking of the flexibility issue of client and STUN-relay server with #1 to #4. I believe STUN-relay will not have limited usage with media traversal only. It can use to make a tunneling/bridge with UDP and TCP protocol. Why I support #4 is that a UDP client can connect to a TCP server through the STUN-relay server. ----- Original Message ----- From: "Jonathan Rosenberg" To: "Adam Roach" Cc: "Manjur" ; Sent: Wednesday, March 29, 2006 11:27 AM Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay I'm not opposed to removing #4, but I can at least say what I had in mind. Whether it works or is useful, is a different question. The idea is that the TURN server would be receiving TCP segments from the public network. As it receives each segment, it places the content into a UDP packet and passes it on to the client. Thus, the TURN server is not assuming any framing at all; the UDP datagrams merely carry the TCP data without regard to any kind of framing. now, the problem here is that this is going to break horribly in cases where there is UDP packet loss or reordering. Thats because the tcp framing mechanism most likely assumes reliable in order delivery, and if this is violated, the framing mechanism probably won't be useful to the client. Now, there are potential TCP framing mechanisms which can work when translated to UDP; namely ones that rely on start codes for framing, along with embedded sequence numbers. How common is that? probably not too much. Certainly not useful for RTP over TCP. As such, I would agree with the current proposal to remove this capability from the draft, unless someone can provide a use case and solution that works (since mine doesnt). To specify this, I wouldn't change any syntax, but have the turn server reject a request for TCP transport if the request arrived over UDP. Likely this requires a new error code. Thanks, Jonathan R. Adam Roach wrote: Manjur wrote: I would like to say that it should be fine to keep this flexibility of the REQUESTED-TRANSPORT attribute. STUN-relayed server comes to help the problem with NAT traversal and we should not ignore the limited number of case as well. Moreover, it gives more control to the client and the STUN-server to use not only media but also file-transfer and other signaling communication. It makes a bridge/tunnel to tcp and udp clinets/servers. I found it very much useful when a tcp client(say udp is block) wants to communicate to a udp server(server has only udp support) through the STUN-relayed server. Derek tried to clear this up, but apparently confusion continues to reign. No one is proposing that the use case you describe should be removed. Currently, the TURN draft allows four combinations: TO CLIENT TO NETWORK --------- ---------- 1. TCP TCP 2. UDP UDP 3. TCP UDP 4. UDP TCP What you want to do is handled by #3. As far as I can tell, everyone wants to keep #3. No one has proposed removing #3. What is being proposed is that #4 be removed. The problem is that #4 is currently underspecified, will be difficult to specify, will be very difficult to implement, and will not actually be useful. /a _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From adam@estacado.net Wed, 29 Mar 2006 13:08:50 -0800 (PST) From: Adam Roach Date: Wed, 29 Mar 2006 13:08:50 -0800 (PST) Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay In-Reply-To: <2357.204.96.112.231.1143188984.webmail@204.96.112.231> Message-ID: <442AF750.5070602@estacado.net> MIME-Version: 1.0 Content-Type: text/plain Manjur wrote: >I want to keep #4. I am thinking of the flexibility issue of client and >STUN-relay server with #1 to #4. > > In that case, you need to propose how to do it. Sending text would be best, but a simple explanation of how such a usage can even work would be a start. /a >I believe STUN-relay will not have limited usage with media traversal only. >It can use to make a tunneling/bridge with UDP and TCP protocol. >Why I support #4 is that a UDP client can connect to a TCP server through >the STUN-relay server. > > > >----- Original Message ----- >From: "Jonathan Rosenberg" >To: "Adam Roach" >Cc: "Manjur" ; >Sent: Wednesday, March 29, 2006 11:27 AM >Subject: Re: [Ietf-behave] UDP/TCP in STUN-relay > > > > >>I'm not opposed to removing #4, but I can at least say what I had in >>mind. Whether it works or is useful, is a different question. >> >>The idea is that the TURN server would be receiving TCP segments from >>the public network. As it receives each segment, it places the content >>into a UDP packet and passes it on to the client. Thus, the TURN server >>is not assuming any framing at all; the UDP datagrams merely carry the >>TCP data without regard to any kind of framing. >> >>now, the problem here is that this is going to break horribly in cases >>where there is UDP packet loss or reordering. Thats because the tcp >>framing mechanism most likely assumes reliable in order delivery, and if >>this is violated, the framing mechanism probably won't be useful to the >>client. >> >>Now, there are potential TCP framing mechanisms which can work when >>translated to UDP; namely ones that rely on start codes for framing, >>along with embedded sequence numbers. How common is that? probably not >>too much. Certainly not useful for RTP over TCP. >> >>As such, I would agree with the current proposal to remove this >>capability from the draft, unless someone can provide a use case and >>solution that works (since mine doesnt). >> >>To specify this, I wouldn't change any syntax, but have the turn server >>reject a request for TCP transport if the request arrived over UDP. >>Likely this requires a new error code. >> >>Thanks, >>Jonathan R. >> >>Adam Roach wrote: >> >> >> >>>Manjur wrote: >>> >>> >>> >>> >>>>I would like to say that it should be fine to keep this flexibility of >>>> >>>> >the > > >>>>REQUESTED-TRANSPORT attribute. >>>>STUN-relayed server comes to help the problem with NAT traversal and we >>>>should not ignore the limited number of case as well. >>>>Moreover, it gives more control to the client and the STUN-server to use >>>> >>>> >not > > >>>>only media but also file-transfer and other signaling communication. >>>>It makes a bridge/tunnel to tcp and udp clinets/servers. >>>>I found it very much useful when a tcp client(say udp is block) wants to >>>>communicate to a udp server(server has only udp support) through the >>>>STUN-relayed server. >>>> >>>> >>>> >>>Derek tried to clear this up, but apparently confusion continues to >>>reign. No one is proposing that the use case you describe should be >>> >>> >removed. > > >>>Currently, the TURN draft allows four combinations: >>> >>> TO CLIENT TO NETWORK >>> --------- ---------- >>> 1. TCP TCP >>> 2. UDP UDP >>> 3. TCP UDP >>> 4. UDP TCP >>> >>>What you want to do is handled by #3. As far as I can tell, everyone >>>wants to keep #3. No one has proposed removing #3. >>> >>>What is being proposed is that #4 be removed. >>> >>>The problem is that #4 is currently underspecified, will be difficult to >>>specify, will be very difficult to implement, and will not actually be >>>useful. >>> >>>/a >>>_______________________________________________ >>>Ietf-behave mailing list >>>Ietf-behave@xxxxxxxxxxxxxxxxxxx >>>https://list.sipfoundry.org/mailman/listinfo/ietf-behave >>> >>> >>> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Cisco Fellow Parsippany, NJ 07054-2711 >>Cisco Systems >>jdrosen@xxxxxxxxx FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.com >> >> > > > From adam@estacado.net Wed, 29 Mar 2006 13:40:55 -0800 (PST) From: Adam Roach Date: Wed, 29 Mar 2006 13:40:55 -0800 (PST) Subject: [Ietf-behave] Re: TURN/STUN Interoperability Issues In-Reply-To: <44287B98.6020407@estacado.net> Message-ID: <442AFED8.6010109@estacado.net> MIME-Version: 1.0 Content-Type: text/plain Jonathan Rosenberg wrote: > To be clear, on the first issue, we discussed this at IETF and agreed > on approach 4, which says that the attribute length value encodes the > length of the actual data, but it is padded out when placed into the > packet in order to equal a multiple of 32 bits. In such a case, the > value of the pad is irrelevant. Unless someone says this gives them > real heartburn I plan on proceeding with that approach. Perhaps I'm just confused, but won't this cause Really Bad Things to happen if an old-style TURN server receives a new-style TURN message? At least with approach 1, it will be able to skip over the padding successfully. If the length no longer means "number of bytes to skip to get to the next attribute," then old-style STUN servers are likely to choke badly. /a > 1. 00 06 00 08 74 65 73 74 31 00 00 00 > 2. 00 06 00 08 74 65 73 74 31 20 20 20 > 3. 00 06 00 05 74 65 73 74 31 > 4. 00 06 00 05 74 65 73 74 31 00 00 00 From petithug@acm.org Wed, 29 Mar 2006 14:35:49 -0800 (PST) From: Marc Petit-Huguenin Date: Wed, 29 Mar 2006 14:35:49 -0800 (PST) Subject: [Ietf-behave] NONCE and REALM attribute type values in rfc3489bis Message-ID: <442B0BC1.2020107@acm.org> MIME-Version: 1.0 Content-Type: text/plain It will be great if in the next revision of rfc3489bis, the type value assigned to the NONCE and REALM attributes can be the same that was used in turn-08 for the same attributes. This is not really a problem in a client or server implementation, but it is difficult to implement in Ethereal. And this is also confusing. Thanks. -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx From petithug@acm.org Wed, 29 Mar 2006 17:34:34 -0800 (PST) From: Marc Petit-Huguenin Date: Wed, 29 Mar 2006 17:34:34 -0800 (PST) Subject: Re: [Ietf-behave] Re: TURN/STUN Interoperability Issues In-Reply-To: <44287B98.6020407@estacado.net> Message-ID: <442B35A8.5070606@acm.org> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Roach wrote: > Jonathan Rosenberg wrote: > > >>To be clear, on the first issue, we discussed this at IETF and agreed >>on approach 4, which says that the attribute length value encodes the >>length of the actual data, but it is padded out when placed into the >>packet in order to equal a multiple of 32 bits. In such a case, the >>value of the pad is irrelevant. Unless someone says this gives them >>real heartburn I plan on proceeding with that approach. > > > > Perhaps I'm just confused, but won't this cause Really Bad Things to > happen if an old-style TURN server receives a new-style TURN message? At > least with approach 1, it will be able to skip over the padding > successfully. If the length no longer means "number of bytes to skip to > get to the next attribute," then old-style STUN servers are likely to > choke badly. I perhaps missed something but I cannot find a case where it can happen: Here is the list of attributes that can have a variable length content: ERROR-CODE UNKNOWN-ATTRIBUTES SERVER PASSWORD NONCE REALM DATA USERNAME We can remove ERROR-CODE, UNKNOWN-ATTRIBUTES, SERVER and PASSWORD from the list, because there are sent only in response messages, so an old-style STUN/TURN server will send them padded. NONCE, REALM and DATA are used only with a TURN server. As the service part of the SRV RR is different (_turn and _stun-relay), the client knowns how to send this attributes. Same thing when the USERNAME is used with an old-style TURN server. USERNAME sent to an old-style STUN server is also not a problem as an old-style STUN server will return it already padded in the SHARED-SECRET-RESPONSE and it will be sent as it is to the BINDING-REQUEST, i.e. already padded. > > /a > > > >> 1. 00 06 00 08 74 65 73 74 31 00 00 00 >> 2. 00 06 00 08 74 65 73 74 31 20 20 20 >> 3. 00 06 00 05 74 65 73 74 31 >> 4. 00 06 00 05 74 65 73 74 31 00 00 00 - -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEKzVU9RoMZyVa61cRAj4dAJ9LKY3+12Xt2/mRIjVhA3mtB95SawCdFeR5 rUrPrFvtYE714IeU1KBBzhk= =oqXA -----END PGP SIGNATURE----- -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx From dwing@cisco.com Wed, 19 Apr 2006 16:14:33 -0700 (PDT) From: "Dan Wing" Date: Wed, 19 Apr 2006 16:14:33 -0700 (PDT) Subject: [Ietf-behave] Minutes from Dallas Message-ID: <01f801c66407$045e5ec0$8b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Minutes, BEHAVE WG at IETF 65 Minutes edited by Dan Wing based on notes by Spencer Dawkins Meeting chaired by Dan Wing Thursday, March 23, 2006, 13:00-15:00 ------------------------------------- Topic: Agenda and Chair Update (Chairs, 15 min) It was announced that Jiri Kuthan was stepping down as chair, and Dan Wing is the new co-chair (with Cullen Jennings). The new ADs, Magnus Westerlund and Lars Eggert, were introduced. The agenda was accepted as-is. ----- Topic: TCP Issues (Saikat Guha, 30 min) draft-ietf-behave-tcp-00 Saikat presented the draft. This is a revision of hoffman-03 draft, including comments from last meeting and the mailing list. This draft is now a WG item. The TCP draft describes NAT behavior to allow simultaneous open so that two hosts behind their own NATs can establish a TCP connection. Open issues: * Req-3, "MUST support inbounc SYN/3-way from specific endpoints (handle full cone or restrictive cone behavior)", generated some discussion. Jonathan asked if this requirement was just for SYN, and Saikat agreed it was and the next version of the draft would reflect this. Philip Matthews asked if we wanted same filtering behaviors for TCP and UDP. Discussion concluded that the TCP filtering behavior needed to be IP address dependant, but shouldn't be TCP port dependant, to allow for a BEHAVE- compliant NAT to talk with a non-BEHAVE-compliant NAT which changes the ephemeral TCP port. * REQ-5 - timeouts. Cullen asked if REQ-5 could specify an absolute minimum so applications could do keepalives just faster than this minimum. Cullen pointed out this was done in the UDP draft. Magnus asked if there was a DoS problem with keeping NAT bindings alive for hours if the host had crashed. Philip Matthews pointed out the UDP draft didn't discuss what should occur when the NAT "fills up" -- deleting the most recently used is exactly the wrong behavior from application view since the failures look random. Cullen said such decisions were up to vendors. Magnus said security implications of any such behavior should be considered. Philip suggested that applications want consistent behavior, and that is what we need to rely on. Francois - too late to recommend behavior for UDP, but TCP may be different - need to discuss this on list Lars suggested the principle of least astonishment would be good. Also - 2 hours is when TCP keepalive occur, and TCP keepalives are optional - if you don't use TCP keepalives, connection could be open and silent for years. No good answer that gives consistent behavior. Question was raised if TCP ALGs are in scope, such as FTP ALG. Consensus in the room is they are out of scope unless there is a compelling reason to make them in scope. Dan pointed out that Internet Explorer's FTP client doesn't use Passive mode (which is inaccurate as of 2004, , dwing). A hum was taken that the FTP ALG is turned off by default. Hums were 'yes' with some opposed. All other TCP ALGs were decided to be off by default. ----- STUN Issues (Jonathan Rosenberg, 25 min) draft-ietf-behave-rfc3489bis-03 Dan is now a co-author. This version is more than a minor revision. "STUN Usages" are now defined, and four usages are defined in RFC3489bis, discovery, connectivity check, NAT keepalives, short-term password. TURN is a separate draft that defines its own STUN Usage. A small number of people have implemented shared secret mechanism, short-term password would be simpler RFC3489bis removed all attributes to determine NAT types. Discussion briefly touched on disconnect between sip-outbound and rfc3489bis; these will be resolved by the respective authors. Open issue: fate of type-determination attributes? Proposal is to create separate "diagnostic usage" I-D, if we can find a stuckee, alternative is to back-reference RFC 3489. Derek McDonald agreed to author this draft. Philip Matthews suggested keeping diagnostics for P2P-SIP, even if it's not entirely accurate. Dan pointed out some NATs change behavior as they run out of resources, and Cullen pointed out that STUN server needs two IP addresses to do the diagnostics checks. Open issue: whether to send/receive TLS - use NAPTR? SIP used NAPTR, but client knows exactly what it needs in this case -- factor in usages (different ports for relays, etc.) Proposal - SRV record looks like _useage_.transport.domain There was some discussion; Jonathan will up the SRV proposal and post it. Jonathan requested help on failover behavior. This behavior is usage-specific (for example, NAT keepalive behavior is different from connectivity check). Cullen said server that is "half up" seems unlikely, don't use this as a requirement (although it will happen). Who has read? About half the room. Default STUN port, decision was Jonathan would request one from IANA. Aki asked by IPv6 was added; it's for v4/v6 transition (Gonzolo's draft) ----- Topic: TURN Issues (Jonathan Rosenberg, 20 min) draft-ietf-behave-turn-00 draft-camarillo-midcom-turn-ipv6-00 This draft replaces Jonathan's previous individual submission. It is now a WG item. Jonathan explained this draft has More changes than STUN, reflecting TURN's relative maturity Many things moved from TURN to rfc3489bis. Set Active Destination rewritten, unified TCP and UDP, Send is an indication, not a request, allow set active destination even if you've never been there. MAPPED-ADDRESS is server-reflexive, added RELAY-ADDRESS for relayed address, added requests for port attributes (specific port, port parity, contiguity port requests) Francois asked by TURN didn't support getting two ports at once? Jonathan explained it's because TURN exists to traverse NATs, and if you don't send a packet to the TURN server, the TURN server won't be able to get through your NAT. Francois asked how bad the 'port parity' request is this for TURN server? Jonathan explained it's merely a hint for the TURN server to keep an adjacent port available and is no worse than what a client does today for RTP port parity. Biggest change requested is that requests can now befor a specific IP addresses (useful for tcp stun, more than 64K clients), specific transports, permissions set on send and set active destination operations It was pointed out the RTCP SDP attribute (RFC3605) removes parity requirement, but Jonathan said there are RFC3605-unaware endpoints which need port parity. Jonathan will include text to this effect in the next version of the draft. Other changes - New Connect request for opening TCP connections, TCP connections NOT opened from ephemeral ports, closing TCP connections from external host do not release allocation (open multiple connections from an allocated address). Allocated lifetimes refreshed ONLY by Allocate request, not data flow. Hokey mechanism for dealing with connection setups that take longer than STUN transaction Lars - why don't I just wait until something succeeds or fails? If timeouts were set correctly, this wouldn't be an issue. Added example, overview of operations It was asked if one side of the connection could be closed. Jonathan agreed to think about this; it may make sense. Open issue - disambiguation (was skipped over during presentation for time concerns) Open issue - XOR of other addresses? Jonathan doesn't think this is needed, because NATs are looking for their own addresses. A discussion ensued around XOR-MAPPED-ADDRESS. Conclusion was to not XOR the TURN addresses. Open issue - allocate identification. Problem is when NATs reboot. If refresh comes over new flow, will update mapping to point to new flow. Open issue - demux over TCP. Server needs to look at bytes 5-8 (magic cookie), and server doesn't know framing protocol, doesn't actually know how to do demux when you don't know framing protocols (ex. Jabber requires full XML parsing to identify start/end). Could signal this, but it's a non-starter. "Do cookie hunt" in TCP until you find the cookie? Not at line rate, need timers (so introduce more jitter), danger of four-byte collisions (2**32 collisions in gigabyte files not too unlikely). Always use send and indication? Problem is overhead - no unencapsulated data. Lightweight demux (32-bits, 8 bit type, 24-bit length)? STUN and Data types. Propose that we use this for UDP, too, and evoid need for cookie check. The consensus in the room is this framing was good for TCP; not sure about UDP. Open issue - 32-bit alignment - TURN is 32-bit aligned, but data isn't - pad for 32-bit alignment? Jonathan agreed to put this in. ----- Topic: Multicast Draft (Dan Wing, 10 min) draft-ietf-behave-multicast-01 draft-ietf-magma-igmp-proxy-06 Magma draft has already passed IESG review. Will drop the behave draft and let it expire. Cullen - looks close, but if we give MAGMA draft to NAT vendors they will be confused. Make behave draft just point to MAGMA draft, point-by-point? Francois - how would anyone else figure this out in the first place. Is there an existing document where we can include the pointer? Philip pointed out that the MAGMA draft is in RFC Editor queue and we can't squeeze in a change of this size in AUTH-48. Dan said he would ask the list for suggestions. ----- Topic: ICMP Draft (Saikat Guha, 20 min) draft-srisuresh-behave-nat-icmp-01 The ICMP draft is an adjunct to the TCP and UDP drafts that we already have. Saikat: Draft describes five requirements: 1. same thing with timeouts as UDP/TCP, namely administrator- configured timeout. Want feedback from BEHAVE. Cullen asked what applications beyond ICMP PING and ICMP traceroute need this draft. Saikat agreed with Cullen, but said some ICMP errors are useful. Francois suggested we make sure something is broken before we take this as a WG item. Saikat skipped to end of presentation, asking room to adopt this as WG item. Philip Matthews (?) said the document is important if vendors screw up ICMP, or ICMP needs more predictable behavior. Saikat said the UDP and TCP documents identified what needs to change, at minimum, to make UDP and TCP work. For ICMP, we're less sure what those problems are. Continuing with the five requirements: 1. PING sends an echo request, next PING goes to a different mapping; what default timeout should exist for the mappings? Magnus - should give consideration to using Maximum Segment Lifetime. 2. NAT MUST NOT modify ICMP 'type' values. Saikat asked if anyone was familiar with a NAT that actually had this behavior, and if we should mention this in the draft. Magnus said perhaps it should stay in the draft. Cullen said he hadn't seen a NAT that does this. Francois asked if this requirement is trying to say "must not block ICMP?". Saikat said this wasn't related to filtering ICMP, but rather was related to changing the contents of the ICMP packet. Saikat suggested we remove this from the document. Dan asked that this be brought to the mailing list. 3. Outbound ICMP messages need to have their IP source rewritten to the NAT's public IP address. Dan - ingress filtering (RFC2827) will cause these packets to be dropped, if the NAT doesn't follow this behavior. So this is why such behavior is necessary. 4. ICMP messages shouldn't cause a binding to be refreshed or deleted. Saikat pointed out that the UDP draft already mentions this, for UDP. This requirement would generalize this behavior for NAT binding tables. Dan pointed out that some protocols may need different behavior. Saikat said the ICMP draft would allow protocol-specific drafts to override its behavior 5. Send ICMP error code 10 if NAT is exhausted of resources. This is a soft error; Saikat pointed out TCPM is modifying the interpretation of this ICMP error, and that this message is only sent at session initiation. Saikat suggested bringing discussion to the list. 6. DF behavior, follows normal router behavior. Question: keep this in the draft, or pull it out. Lars suggested that RFC1812 should be the baseline here - "NATs should look like routers". And that instead of duplicating what RFC1812 says, just point out the differences from RFC1812. 7. TTL behavior, should NAT return 'TTL exceeded' when TTL is exceeded at the NAT itself. end of minutes From dwing@cisco.com Wed, 19 Apr 2006 16:16:06 -0700 (PDT) From: "Dan Wing" Date: Wed, 19 Apr 2006 16:16:06 -0700 (PDT) Subject: [Ietf-behave] -behave-nat-udp-05: PROTO questionnaire and write-up Message-ID: <01f901c66407$3c1278b0$8b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain draft-ietf-behave-nat-udp has been submitted to the IESG for their review. Per the procedures described in draft-ietf-proto-wgchair-doc-shepherding-06, a copy of the PROTO questionnaire and write-up are below. You can track the progress of draft-ietf-behave-nat-udp at: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1268 2&rfc_flag=0 -Dan Wing ----- PROTO questionnaire for: draft-ietf-behave-nat-udp-05.txt prepared by: Dan Wing, dwing@xxxxxxxxx, 14-Apr-2005 WG chair shepherd: dwing@xxxxxxxxx 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Which chair is the WG Chair Shepherd for this document? Yes. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes. No concern about depth or breadth of reviews. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, internationalization, XML, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. Careful consideration should be made regarding the timers and the port ranges of the timers. This has been a difficult issue within the working group to resolve. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It represents strong consensus within the working group, with no known dissenters. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. (It should be separate email because this questionnaire will be entered into the tracker). No. 1.g) Have the chairs verified that the document checks out against all the ID nits? (see http://www.ietf.org/ID-Checklist.html). Boilerplate checks are not enough; this check needs to be thorough. Yes. (I did note that http://tools.ietf.org/tools/idnits says the document is fine, except for missing RFC2119 boilerplate. However, the document does have RFC2119 boilerplate at the beginning of its section 3.) 1.h) Has the document split its references into normative and informative? Yes. Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? There is only one normative reference, and it is to an RFC. The RFC Editor will not publish an RFC with normative references to IDs (will delay the publication until all such IDs are also ready for RFC publicatioin). If the normative references are behind, what is the strategy for their completion? On a related matter, are there normative references that are downward references, as described in BCP 97, RFC 3967 RFC 3967 [RFC3967]? Listing these supports the Area Director in the Last Call downref procedure specified in RFC 3967. ----- Protocol write-up for draft-ietf-behave-nat-udp-05.txt by Dan Wing, dwing@xxxxxxxxx, 14-Apr-2005 Technical Summary This document defines basic terminology for describing different types of NAT behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or on-line gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. Working Group Summary There has been some disagreement with default NAT binding timers in general, and specific concern around handling of specific applications such as DNS which don't need 5 minute timeouts Protocol Quality No new protocols are defined in this document, rather, this document describes how NATs should function when NATting UDP packets. The WG is confident that this document captures the behevior of NATs typically sold to consumers. ----- From dwing@cisco.com Wed, 19 Apr 2006 16:17:18 -0700 (PDT) From: "Dan Wing" Date: Wed, 19 Apr 2006 16:17:18 -0700 (PDT) Subject: [Ietf-behave] -behave-multicast and draft-ietf-magma-igmp-proxy Message-ID: <01fa01c66407$474fd240$8b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain During WGLC, it was brought to the chairs attention that draft-ietf-behave-multicast-01 and draft-ietf-magma-igmp-proxy-06 had significant overlap. In Dallas I presented a quick summary of the problem, which is captured in the BEHAVE minutes (below my signature). Consensus at the meeting was to reduce the scope of behave-multicast to only reference -magma-igmp-proxy and to point out the special issues around NATs. Please let me know if you disagree with this change of scope. We will also need a new author to volunteer to make these changes. -Dan Wing ----- Topic: Multicast Draft (Dan Wing, 10 min) draft-ietf-behave-multicast-01 draft-ietf-magma-igmp-proxy-06 Magma draft has already passed IESG review. Will drop the behave draft and let it expire. Cullen - looks close, but if we give MAGMA draft to NAT vendors they will be confused. Make behave draft just point to MAGMA draft, point-by-point? Francois - how would anyone else figure this out in the first place. Is there an existing document where we can include the pointer? Philip pointed out that the MAGMA draft is in RFC Editor queue and we can't squeeze in a change of this size in AUTH-48. Dan said he would ask the list for suggestions. From magnus.westerlund@ericsson.com Thu, 20 Apr 2006 02:01:03 -0700 (PDT) From: Magnus Westerlund Date: Thu, 20 Apr 2006 02:01:03 -0700 (PDT) Subject: [Ietf-behave] AD evalution comments on draft-ietf-behave-nat-udp-05 Message-ID: <44474DCA.6060907@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, My AD evaluation resulted in the below comments and questions. I do wish to have some discussion on some of these topics. 1. Section 4.1: "In particular, in the context of SIP, if my application supports the extensions defined in RFC 3605 [16] for indicating RTP and RTCP addresses and ports separately, but the other peer does not, there may still be breakage in the form of the stream losing RTP packets. This requirement will avoid the loss of RTP in this context, although the loss of RTCP may be inevitable in this particular example." Can you please clarify to me why the RTP packets would be lost in this case if the pooling is arbitrary? 2. Section 4.2.1, page 9, fourth paragraph: "For example it will fail if two internal endpoints try to reach the same external destination, e.g., a server used by both endpoints such as a SIP proxy, or a web server, etc." I think a web server is a confusing example. I agree that the general problem exist, but as a web server would be using TCP this confuses the matter in this UDP only document. 3. Section 4.2.1, page 9, fifth paragraph: "It should be noted that port 0 is reserved and must not be used." I think there are a number of ports that would be confusing to use as source ports. One especially would be port 9 (discard). Thus two questions to the WG. Should it be pointed out that there are several ports that are not suitable as source ports, and secondly should these be enumerated? 4. Section 4.2.1, REQ-3: Why isn't port preservation recommended? Is it due to that it can't be guaranteed and therefore there is meaningless to recommend it? 5. Section 4.3: REQ-5: "A NAT UDP mapping timer MUST NOT expire in less than 1 minute, unless REQ-5a applies. a) A NAT MAY have UDP mapping timers that have much shorter timers, but only for specific ports in the well-known port range (i.e., ports 0-1023) where the IANA- registered protocol is strictly a request/response protocol, such as for example DNS over UDP/53. b) The value of the NAT UDP mapping timer MAY be configurable. c) A default value of 5 minutes for the NAT UDP mapping timer is RECOMMENDED." I would like to re-open the discussion of the normative timeout period. I think 1 minute is to little. I would like at least 5 minutes to avoid unnecessary frequent keep-alive traffic. With a one minute timeout period the keep-alive will either be ACKed and then likely sent every 30-45 seconds or so. If not ACKed then people will go for statistical guarantees and that will mean 4 to 5 keep-alive packets during that minute. That amount of traffic is probably not a big problem for people with fixed network. If do create some serious concern for wireless devices, both from a cost perspective and also from a battery life-time perspective. In services that needs a UDP media channel but sometime are inactive these keep-alive will result in a battery consumption during idle time that is close to what is used when active. One such service that have this behavior is push to talk. Due to the above I ask the WG if they think 5 minutes would be a better compromise. I see at the main problem is the amount of state created in the NAT from short duration transactions. However I would like to point out requirement 5-a which allows known such protocols to be optimized to not keep those states open. I do also wonder if 5-c is worth the ink it is written with. As long as one don't have a reliable way of finding out that time-limit is prior to using it no one can really gain by the recommendation. It is only the normative timeout that means anything. 6. Section 8, REQ-11: " REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT change the NAT mapping or the External Filtering Behavior at any point in time or under any particular conditions." I think that one should include references to the behavior one is expecting to be deterministic. I would propose: REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT change the NAT mapping (Section 4.1) or the External Filtering Behavior (Section 5) at any point in time or under any particular conditions. 7. Section 9: REQ-12: "Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping." Is the use of "destroy" the right word. As the ICMP do not directly cause the destruction of the mapping, wouldn't using "terminate" be more correct? 8. Section 10.1: Nit: There is a missing empty line between the requirement and the justification. 9. Section 10.2, REQ-14: I don't see how this requirement is connected to the section text? Also it is not clear if there is anything more than what is described in section 9 and 10.1 that needs to be supported. I think some clarification and text changes in regards to this is needed. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From fluffy@cisco.com Thu, 20 Apr 2006 03:38:23 -0700 (PDT) From: Cullen Jennings Date: Thu, 20 Apr 2006 03:38:23 -0700 (PDT) Subject: [Ietf-behave] Re: AD evalution comments on draft-ietf-behave-nat-udp-05 In-Reply-To: <44474DCA.6060907@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Magnus - thanks for the careful review. Some comments inline... PS - Magnus knows this but just to be clear for others, I am only commenting on this as an individual contributor. I will Recuse myself from IESG voting on this and all chair actions to do with this are only dealt with by Dan (or Jiri in the past). On 4/19/06 11:00 PM, "Magnus Westerlund" wrote: > Hi, > > My AD evaluation resulted in the below comments and questions. I do wish > to have some discussion on some of these topics. > > 1. Section 4.1: "In particular, in > the context of SIP, if my application supports the extensions > defined in RFC 3605 [16] for indicating RTP and RTCP addresses and > ports separately, but the other peer does not, there may still be > breakage in the form of the stream losing RTP packets. This > requirement will avoid the loss of RTP in this context, although > the loss of RTCP may be inevitable in this particular example." > > Can you please clarify to me why the RTP packets would be lost in this > case if the pooling is arbitrary? I suspect we have a typo here and "losing RTP packets" should be " losing RTCP packets". The RTCP is lost when it the RTCP port can not be signaled and the n+1 rule is broken by the NAT using ports that are not n and n+1. > > 2. Section 4.2.1, page 9, fourth paragraph: > > "For example it will fail if two internal endpoints try to reach the > same external destination, e.g., a server used by both endpoints such > as a SIP proxy, or a web server, etc." > > I think a web server is a confusing example. I agree that the general > problem exist, but as a web server would be using TCP this confuses the > matter in this UDP only document. > Good point. We could use the example of a SIP proxy with SIP over UDP. Are there other UDP examples that come to mind? > 3. Section 4.2.1, page 9, fifth paragraph: > > "It should be noted that port 0 is reserved and must not be used." > > I think there are a number of ports that would be confusing to use as > source ports. One especially would be port 9 (discard). Thus two > questions to the WG. Should it be pointed out that there are several > ports that are not suitable as source ports, and secondly should these > be enumerated? > > 4. Section 4.2.1, REQ-3: Why isn't port preservation recommended? Is it > due to that it can't be guaranteed and therefore there is meaningless to > recommend it? It was even worse that than that. Statistically speaking from the test done on NATs, the nats that tried to do port preservation often had much more non deterministic behavior than the ones that did. For example, we found NATs that behaved on way on the 1 and 2 conflict but a different way on the 3rd. Applications that assumed port preservation were more brittle. The more we thought about it, the more it looked like a) it was impossible in all case b) it was hard to implement b) trying to do it in some case did more harm than good > > 5. Section 4.3: REQ-5: > "A NAT UDP mapping timer MUST NOT expire in less than 1 minute, > unless REQ-5a applies. > a) A NAT MAY have UDP mapping timers that have much shorter > timers, but only for specific ports in the well-known port > range (i.e., ports 0-1023) where the IANA- registered protocol > is strictly a request/response protocol, such as for example > DNS over UDP/53. > b) The value of the NAT UDP mapping timer MAY be configurable. > c) A default value of 5 minutes for the NAT UDP mapping timer is > RECOMMENDED." > > I would like to re-open the discussion of the normative timeout period. > I think 1 minute is to little. > I would like at least 5 minutes to avoid > unnecessary frequent keep-alive traffic. With a one minute timeout > period the keep-alive will either be ACKed and then likely sent every > 30-45 seconds or so. If not ACKed then people will go for statistical > guarantees and that will mean 4 to 5 keep-alive packets during that > minute. That amount of traffic is probably not a big problem for people > with fixed network. If do create some serious concern for wireless > devices, both from a cost perspective and also from a battery life-time > perspective. In services that needs a UDP media channel but sometime are > inactive these keep-alive will result in a battery consumption during > idle time that is close to what is used when active. One such service > that have this behavior is push to talk. > > Due to the above I ask the WG if they think 5 minutes would be a better > compromise. I see at the main problem is the amount of state created in > the NAT from short duration transactions. I suspect this will be the most contentious of all your comments. I also find 1 minute very short. One thing did become clear in the WG discussions on the topic - any value for the time will be picked somewhat arbitrarily. Everyone agrees the order of magnitude is minutes. Some issues with short times are they creates huge load on the application servers in the network. It consumes significant bandwidth. It has implications on battery life of mobile equipment. The arguments I have heard for short times fall in two categories: security, and limited number port resources. Let me comment on both of these security: The argument goes that 1 minute is more secure than 5 minutes. I've never really understood this - if the attacker has an attack that works when the port is open, well this might narrow the window they have to "find" a victim from 5 minutes to 1 minute but unless we are putting this down to the milliseconds zone, I don't see how it really makes the attack any harder to launch. limited port resources: the argument here is that the NATs run out of ports in their port pool and they can't reclaim the existing ports fast enough. In thinking about this there are a bunch of things to consider. If you have enough connections to use all the ports in a a few minutes, will that actually be the limiting resource on the NAT. A totally antidotal sample point I have on 1 nat in 1 network scenario showed the NAT ran out of CPU power to process the new flow transactions per second long before it ran out of ports. I make no claim that this might applied to other nats or other situations but it did make me wonder. The other things to consider is what are the clients behind the NAT doing that use up the ports. One things that has been brought up is they are doing DNS to tons of different DNS servers - presumably 1000s of DNS servers per second. This particular DNS example can be easily dealt with using the 5c rule or a recursive DNS server, or a DNS ALG in the NAT. Testing on a very limited set of NATs did not make it seem like DNS was a real issue but I could imagine that perhaps some application like a bulk SPAM sender behind a residential style NAT might have issues with some NATs around this. The other application that got brought up is that you have 20,000 phones doing UDP based signaling behind a NAT. The thing here is that the time is irrelevant - the phones want the number of flows they want and will do keep alives to keep them all. If the NAT can't support that many flows, no amount of moving the timer up or down will help the problem. So as you can see, the arguments so far have not help me figure out what time to use. The thing that I found most compelling was the following... A goal of BEHAVE is to make it possible to for applications to work but is also to minimize the changes needed to NATs so there was some hope they would happen. So the question comes up, what is the time used by NATs today? Could we find a time that allowed lots of NATs that already exist to be "behave compliant" as they are today? A large percentage of NATs use 180 seconds. When asked why I get ... because that is what their competitors use. Some NATs clear use 30 seconds or something a bit over that. At IETF meetings, operators reported seeing stuff where 30 seconds is too long and you need to go to 15 seconds but I have not managed to get one of these NATs in my hands yet to poke at it. Also there are NATs that allow arbitrary configuration and evidence that some people have configured arbitrary bizarre things into them. The WG discussed using 30 seconds since it seemed like a 99.9% were over that. (I just made up the 99.9% number but as a gut feeling 30 seconds covers "JUST ABOUT EVERYTHING"). People decided 30 seconds was too short for reasons you mentioned. The next logical break point seemed at about 180 seconds as that covered "LOTS" of existing NATs. (I don't know but this might be like 80% - again totally made up gut feel number). The 180 got moved to 2 minutes to be conservative or something. 2 minutes was used in WGLC of draft. This long ramble just provides a brain dump on some of my thoughts on choosing a time. I'm sure others remember stuff I have forgotten and perhaps can make a better explanation of the port resource depletion problem than I have. Over a long time, I became comfortable with 2 minutes - the number is so arbitrary, I could easily live with changing it. On my lowerbound, 30 seconds is too short. On the upper bound, my biggest worry is that we say 5 minutes, and NAT vendors decide it is "more secure" to implement 3 minutes because that is what their competitors do. That would be very bad. > However I would like to point > out requirement 5-a which allows known such protocols to be optimized to > not keep those states open. Just want to be clear this is only know protocols that have a port registered in the range of 0-1023. Perhaps the text needs to be clearer that by well-known we explicitly only mean stuff in the 0-1023 range. This seems like it has potential to cause confusion. > > I do also wonder if 5-c is worth the ink it is written with. As long as > one don't have a reliable way of finding out that time-limit is prior to > using it no one can really gain by the recommendation. It is only the > normative timeout that means anything. 100% agree - some people in the WG liked this - everyone agreed it caused no harm. I gave up discussing it. I forget what lead to it being here and I don't know how much push back there would be for removing it - there are certainly a bunch of people (myself included) that don't care one way or the other. I hesitate to change it at this point without a strong reason. > > 6. Section 8, REQ-11: > " REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT > change the NAT mapping or the External Filtering Behavior at any > point in time or under any particular conditions." > > I think that one should include references to the behavior one is > expecting to be deterministic. I would propose: > > REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT > change the NAT mapping (Section 4.1) or the External Filtering > Behavior (Section 5) at any point in time or under any particular > conditions. sure - easy to update. > > 7. Section 9: REQ-12: > > "Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping." > > Is the use of "destroy" the right word. As the ICMP do not directly > cause the destruction of the mapping, wouldn't using "terminate" be more > correct? > terminate sounds better to me - will see if anyone objects but sounds like a good change. > 8. Section 10.1: Nit: There is a missing empty line between the > requirement and the justification. yep - needs to be fixed. (looks fine in html :-) > > 9. Section 10.2, REQ-14: > > I don't see how this requirement is connected to the section text? Also > it is not clear if there is anything more than what is described in > section 9 and 10.1 that needs to be supported. I think some > clarification and text changes in regards to this is needed. I might be missing what you are saying here but .... are you thinking changing REQ-14: A NAT MUST support fragmentation of packets larger than link MTU. to something more like REQ-14: A NAT MUST support fragmentation of packets larger than link MTU by sending an ICMP for any packet larger than the MTU when DF=1 and in the case where DF=0, either break the packet into fragments smaller than the MTU or send an ICMP error. Clearly this text would need to be changed to make sense but just wanted to make sure I was understanding the scope of the change here. > > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From magnus.westerlund@ericsson.com Thu, 20 Apr 2006 07:24:12 -0700 (PDT) From: Magnus Westerlund Date: Thu, 20 Apr 2006 07:24:12 -0700 (PDT) Subject: [Ietf-behave] Re: AD evalution comments on draft-ietf-behave-nat-udp-05 In-Reply-To: Message-ID: <44479989.9050607@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, See inline comments. Cullen Jennings wrote: 1. Section 4.1: "In particular, in the context of SIP, if my application supports the extensions defined in RFC 3605 [16] for indicating RTP and RTCP addresses and ports separately, but the other peer does not, there may still be breakage in the form of the stream losing RTP packets. This requirement will avoid the loss of RTP in this context, although the loss of RTCP may be inevitable in this particular example." Can you please clarify to me why the RTP packets would be lost in this case if the pooling is arbitrary? I suspect we have a typo here and "losing RTP packets" should be " losing RTCP packets". The RTCP is lost when it the RTCP port can not be signaled and the n+1 rule is broken by the NAT using ports that are not n and n+1. Makes much more sense. [snipped 2] 3. Section 4.2.1, page 9, fifth paragraph: "It should be noted that port 0 is reserved and must not be used." I think there are a number of ports that would be confusing to use as source ports. One especially would be port 9 (discard). Thus two questions to the WG. Should it be pointed out that there are several ports that are not suitable as source ports, and secondly should these be enumerated? No comments on this issue? 4. Section 4.2.1, REQ-3: Why isn't port preservation recommended? Is it due to that it can't be guaranteed and therefore there is meaningless to recommend it? It was even worse that than that. Statistically speaking from the test done on NATs, the nats that tried to do port preservation often had much more non deterministic behavior than the ones that did. For example, we found NATs that behaved on way on the 1 and 2 conflict but a different way on the 3rd. Applications that assumed port preservation were more brittle. The more we thought about it, the more it looked like a) it was impossible in all case b) it was hard to implement b) trying to do it in some case did more harm than good Okay, this was just to ensure that I understand things correctly. 5. Section 4.3: REQ-5: "A NAT UDP mapping timer MUST NOT expire in less than 1 minute, unless REQ-5a applies. a) A NAT MAY have UDP mapping timers that have much shorter timers, but only for specific ports in the well-known port range (i.e., ports 0-1023) where the IANA- registered protocol is strictly a request/response protocol, such as for example DNS over UDP/53. b) The value of the NAT UDP mapping timer MAY be configurable. c) A default value of 5 minutes for the NAT UDP mapping timer is RECOMMENDED." I would like to re-open the discussion of the normative timeout period. I think 1 minute is to little. I would like at least 5 minutes to avoid unnecessary frequent keep-alive traffic. With a one minute timeout period the keep-alive will either be ACKed and then likely sent every 30-45 seconds or so. If not ACKed then people will go for statistical guarantees and that will mean 4 to 5 keep-alive packets during that minute. That amount of traffic is probably not a big problem for people with fixed network. If do create some serious concern for wireless devices, both from a cost perspective and also from a battery life-time perspective. In services that needs a UDP media channel but sometime are inactive these keep-alive will result in a battery consumption during idle time that is close to what is used when active. One such service that have this behavior is push to talk. Due to the above I ask the WG if they think 5 minutes would be a better compromise. I see at the main problem is the amount of state created in the NAT from short duration transactions. I suspect this will be the most contentious of all your comments. I also find 1 minute very short. One thing did become clear in the WG discussions on the topic - any value for the time will be picked somewhat arbitrarily. Everyone agrees the order of magnitude is minutes. Some issues with short times are they creates huge load on the application servers in the network. It consumes significant bandwidth. It has implications on battery life of mobile equipment. The arguments I have heard for short times fall in two categories: security, and limited number port resources. Let me comment on both of these security: The argument goes that 1 minute is more secure than 5 minutes. I've never really understood this - if the attacker has an attack that works when the port is open, well this might narrow the window they have to "find" a victim from 5 minutes to 1 minute but unless we are putting this down to the milliseconds zone, I don't see how it really makes the attack any harder to launch. limited port resources: the argument here is that the NATs run out of ports in their port pool and they can't reclaim the existing ports fast enough. In thinking about this there are a bunch of things to consider. If you have enough connections to use all the ports in a a few minutes, will that actually be the limiting resource on the NAT. A totally antidotal sample point I have on 1 nat in 1 network scenario showed the NAT ran out of CPU power to process the new flow transactions per second long before it ran out of ports. I make no claim that this might applied to other nats or other situations but it did make me wonder. The other things to consider is what are the clients behind the NAT doing that use up the ports. One things that has been brought up is they are doing DNS to tons of different DNS servers - presumably 1000s of DNS servers per second. This particular DNS example can be easily dealt with using the 5c rule or a recursive DNS server, or a DNS ALG in the NAT. Testing on a very limited set of NATs did not make it seem like DNS was a real issue but I could imagine that perhaps some application like a bulk SPAM sender behind a residential style NAT might have issues with some NATs around this. The other application that got brought up is that you have 20,000 phones doing UDP based signaling behind a NAT. The thing here is that the time is irrelevant - the phones want the number of flows they want and will do keep alives to keep them all. If the NAT can't support that many flows, no amount of moving the timer up or down will help the problem. So as you can see, the arguments so far have not help me figure out what time to use. The thing that I found most compelling was the following... A goal of BEHAVE is to make it possible to for applications to work but is also to minimize the changes needed to NATs so there was some hope they would happen. So the question comes up, what is the time used by NATs today? Could we find a time that allowed lots of NATs that already exist to be "behave compliant" as they are today? A large percentage of NATs use 180 seconds. When asked why I get ... because that is what their competitors use. Some NATs clear use 30 seconds or something a bit over that. At IETF meetings, operators reported seeing stuff where 30 seconds is too long and you need to go to 15 seconds but I have not managed to get one of these NATs in my hands yet to poke at it. Also there are NATs that allow arbitrary configuration and evidence that some people have configured arbitrary bizarre things into them. The WG discussed using 30 seconds since it seemed like a 99.9% were over that. (I just made up the 99.9% number but as a gut feeling 30 seconds covers "JUST ABOUT EVERYTHING"). People decided 30 seconds was too short for reasons you mentioned. The next logical break point seemed at about 180 seconds as that covered "LOTS" of existing NATs. (I don't know but this might be like 80% - again totally made up gut feel number). The 180 got moved to 2 minutes to be conservative or something. 2 minutes was used in WGLC of draft. This long ramble just provides a brain dump on some of my thoughts on choosing a time. I'm sure others remember stuff I have forgotten and perhaps can make a better explanation of the port resource depletion problem than I have. Over a long time, I became comfortable with 2 minutes - the number is so arbitrary, I could easily live with changing it. On my lowerbound, 30 seconds is too short. On the upper bound, my biggest worry is that we say 5 minutes, and NAT vendors decide it is "more secure" to implement 3 minutes because that is what their competitors do. That would be very bad. Thanks for the brain dump. I understand your concern with 5 minutes if people do not implement it. If 3 minutes is commonly implemented I would think that would be a good compromise of at least raising the bar a bit, rather than being ultra-conservative. However I would like to point out requirement 5-a which allows known such protocols to be optimized to not keep those states open. Just want to be clear this is only know protocols that have a port registered in the range of 0-1023. Perhaps the text needs to be clearer that by well-known we explicitly only mean stuff in the 0-1023 range. This seems like it has potential to cause confusion. Clarity is good. I do also wonder if 5-c is worth the ink it is written with. As long as one don't have a reliable way of finding out that time-limit is prior to using it no one can really gain by the recommendation. It is only the normative timeout that means anything. 100% agree - some people in the WG liked this - everyone agreed it caused no harm. I gave up discussing it. I forget what lead to it being here and I don't know how much push back there would be for removing it - there are certainly a bunch of people (myself included) that don't care one way or the other. I hesitate to change it at this point without a strong reason. Sure, it doesn't cause any problems. If people have the opinion that it should stay, then let it stay there. [snip 6] 7. Section 9: REQ-12: "Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping." Is the use of "destroy" the right word. As the ICMP do not directly cause the destruction of the mapping, wouldn't using "terminate" be more correct? terminate sounds better to me - will see if anyone objects but sounds like a good change. [snip 8] 9. Section 10.2, REQ-14: I don't see how this requirement is connected to the section text? Also it is not clear if there is anything more than what is described in section 9 and 10.1 that needs to be supported. I think some clarification and text changes in regards to this is needed. I might be missing what you are saying here but .... are you thinking changing REQ-14: A NAT MUST support fragmentation of packets larger than link MTU. to something more like REQ-14: A NAT MUST support fragmentation of packets larger than link MTU by sending an ICMP for any packet larger than the MTU when DF=1 and in the case where DF=0, either break the packet into fragments smaller than the MTU or send an ICMP error. Clearly this text would need to be changed to make sense but just wanted to make sure I was understanding the scope of the change here. What I don't understand is what is different in Req-13 and Req-14. To me REQ-13 applies independently if the packet is going from the internal to the external or vice versa. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From audet@nortel.com Thu, 20 Apr 2006 09:29:36 -0700 (PDT) From: "Francois Audet" Date: Thu, 20 Apr 2006 09:29:36 -0700 (PDT) Subject: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05 Message-ID: <1ECE0EB50388174790F9694F77522CCF08D93650@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Thanks Magnus and Cullen. I'll make all the changes where we have resolution. Here are the remaining issues from the list. > >> 3. Section 4.2.1, page 9, fifth paragraph: > >> > >> "It should be noted that port 0 is reserved and must not be used." > >> > >> I think there are a number of ports that would be > confusing to use as > >> source ports. One especially would be port 9 (discard). Thus two > >> questions to the WG. Should it be pointed out that there > are several > >> ports that are not suitable as source ports, and secondly should > >> these be enumerated? > > No comments on this issue? My recommendation would be to delete the sentence "It should be noted that port 0 is reserved and must not be used". I don't think it is useful to start ennumerating all the ports that shouldn't be used. > >> 5. Section 4.3: REQ-5: > >> "A NAT UDP mapping timer MUST NOT expire in less than 1 minute, > >> unless REQ-5a applies. > >> a) A NAT MAY have UDP mapping timers that have much shorter > >> timers, but only for specific ports in the > well-known port > >> range (i.e., ports 0-1023) where the IANA- > registered protocol > >> is strictly a request/response protocol, such as > for example > >> DNS over UDP/53. > >> b) The value of the NAT UDP mapping timer MAY be > configurable. > >> c) A default value of 5 minutes for the NAT UDP > mapping timer is > >> RECOMMENDED." We have been trying to balance our requirement for timer values between what makes sense for "residential-grade" NATs versus large Enterprise NATs (who happens to be Firewall at the same time). The larger timers make sense for the residential-grade NATs. Req 5-c is useful for residential-grade NATs, because often, the manufacturers are very amiable to a recommended default. What we have found however is that the Enterprise NAT vendors where quite uncomfortable with long timers. The change from "2 minutes" to "1 minute" for the minimum was a result of request from Enterprise NAT vendors. We are a bit worried that if the timer is too long, they will simply ignore the requirement. Req 5a was introduced to allow for optimizations that are very common for large Enterprise NATs. So, I think we have three options: a - Keep the original value (before -05), which was 2 minutes. b - Keep the lower limit from the -05 draft, which is 1 minute c - Use 3 minutes, as per Magnus and Cullen's dialog Personally, I think that we should revert to what we had before -05 which is the 2 minutes. It seems to me that we circled the argument many times now, and that it is the best compromise. But I'm happy with any of those values. > >> 9. Section 10.2, REQ-14: > >> > >> I don't see how this requirement is connected to the section text? > >> Also it is not clear if there is anything more than what > is described > >> in section 9 and 10.1 that needs to be supported. I think some > >> clarification and text changes in regards to this is needed. > > > > I might be missing what you are saying here but .... are > you thinking > > changing > > > > REQ-14: A NAT MUST support fragmentation of packets larger than link > > MTU. > > > > to something more like > > > > REQ-14: A NAT MUST support fragmentation of packets larger than link > > MTU by sending an ICMP for any packet larger than the > MTU when > > DF=1 and in the case where DF=0, either break the packet into > > fragments smaller than the MTU or send an ICMP error. > > > > Clearly this text would need to be changed to make sense but just > > wanted to make sure I was understanding the scope of the > change here. > > > > What I don't understand is what is different in Req-13 and > Req-14. To me > REQ-13 applies independently if the packet is going from the > internal to > the external or vice versa. Dan, can you expand on this? From dwing@cisco.com Thu, 20 Apr 2006 09:57:45 -0700 (PDT) From: "Dan Wing" Date: Thu, 20 Apr 2006 09:57:45 -0700 (PDT) Subject: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF08D93650@zrc2hxm0.corp.nortel.com> Message-ID: <06e601c6649b$8beb9b20$8b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > > >> 9. Section 10.2, REQ-14: > > >> > > >> I don't see how this requirement is connected to the section > > >> text? Also it is not clear if there is anything more than what > > >> is described in section 9 and 10.1 that needs to be supported. > > >> I think some clarification and text changes in regards to this > > >> is needed. > > > > > > I might be missing what you are saying here but .... are you > > > thinking changing > > > > > > REQ-14: A NAT MUST support fragmentation of packets larger than > > > link MTU. > > > > > > To something more like > > > > > > REQ-14: A NAT MUST support fragmentation of packets larger than > > > link MTU by sending an ICMP for any packet larger than the > > > MTU when DF=1 and in the case where DF=0, either break the > > > packet into fragments smaller than the MTU or send an ICMP > > > error. > > > > > > Clearly this text would need to be changed to make sense but > > > just wanted to make sure I was understanding the scope of the > > > change here. > > > > > > > What I don't understand is what is different in Req-13 and Req-14. > > To me REQ-13 applies independently if the packet is going from the > > internal to the external or vice versa. > > Dan, can you expand on this? (I contributed this text in the document.) Req-13 describes a UDP packet arriving at the NAT that is larger than the MTU for the next interface. Yes, it applies independently if the packet is going from internal to external or vice versa. It describes expected behavior depending on the DF bit. This is arguably not UDP specific, but we lack a "for all protocols" document; the intent is to echo the requirements for DF handling that are in RFC1812. Looking at this again, the current text in -05 reads: REQ-13: If the packet has DF=1, the NAT SHOULD send back an ICMP message "fragmentation needed and DF set" message to the host as described in RFC 792 [2]. a) If the packet has DF=0, the NAT SHOULD fragment the packet and send the fragments, in order. and could be improved by changing it to: REQ-13: If a UDP packet needs to be routed to a link with a smaller MTU, and a) the DF bit is set, the NAT MUST send back an ICMP 'fragmentation needed and DF set' message to the originating host as described in RFC792 [2]. b) the DF bit is clear, the NAT SHOULD fragment the packet and SHOULD send the fragments in order. The text around Req-14 (that is, the text of section 10.2) describes what the NAT should do when it, itself, receives an ICMP message. The text of section 10.2 and its Req-14 (which needs to be rewritten, as Req-14 is inaccurate) should be moved into an ICMP document, as this behavior is not specific to UDP. Thanks for catching this, Magnus. -d From srisuresh@yahoo.com Sun, 23 Apr 2006 20:13:46 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 23 Apr 2006 20:13:46 -0700 (PDT) Subject: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF08D93650@zrc2hxm0.corp.nortel.com> Message-ID: <20060424031345.9711.qmail@web33306.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Francois Audet wrote: ... > > >> 5. Section 4.3: REQ-5: > > >> "A NAT UDP mapping timer MUST NOT expire in less than 1 minute, > > >> unless REQ-5a applies. > > >> a) A NAT MAY have UDP mapping timers that have much shorter > > >> timers, but only for specific ports in the > > well-known port > > >> range (i.e., ports 0-1023) where the IANA- > > registered protocol > > >> is strictly a request/response protocol, such as > > for example > > >> DNS over UDP/53. > > >> b) The value of the NAT UDP mapping timer MAY be > > configurable. > > >> c) A default value of 5 minutes for the NAT UDP > > mapping timer is > > >> RECOMMENDED." > > We have been trying to balance our requirement for timer values between > what makes sense for "residential-grade" NATs versus large Enterprise > NATs (who happens to be Firewall at the same time). > > The larger timers make sense for the residential-grade NATs. Req 5-c is > useful for residential-grade NATs, because often, the manufacturers are > very amiable to a recommended default. > > What we have found however is that the Enterprise NAT vendors where > quite > uncomfortable with long timers. The change from "2 minutes" to "1 > minute" for > the minimum was a result of request from Enterprise NAT vendors. We are > a bit > worried that if the timer is too long, they will simply ignore the > requirement. > Req 5a was introduced to allow for optimizations that are very common > for > large Enterprise NATs. > > So, I think we have three options: > a - Keep the original value (before -05), which was 2 minutes. > b - Keep the lower limit from the -05 draft, which is 1 minute > c - Use 3 minutes, as per Magnus and Cullen's dialog > > Personally, I think that we should revert to what we had before -05 > which is > the 2 minutes. It seems to me that we circled the argument many times > now, > and that it is the best compromise. > > But I'm happy with any of those values. > [suresh] I agree, makinng the timers long can be problematic to a number of NAT vendors, especially those that make low-end NAT devices with limited resources. NAT vendors fine tune these timeouts to suit their customer environmets. If IETF mandates the timeouts to be long, the vendors could run into support problems they had not not anticipated as NATs run out of resources quickly. IETF will not be there to help them with the support issues. My vote is to keep the timer at 1 minute. I believe, setting this to more than 2 minutes could potentially invite unknown support issues. Many vendor might in turn choose not to adapt the madanted timeouts. My 2c. regards, suresh From srisuresh@yahoo.com Sun, 23 Apr 2006 20:20:30 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 23 Apr 2006 20:20:30 -0700 (PDT) Subject: Req-13 & Req-14 (WAS:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <06e601c6649b$8beb9b20$8b82200a@amer.cisco.com> Message-ID: <20060424032030.84005.qmail@web33313.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Basically, both requirements (Req-13 and Req-14) are RFC 1812 requirement for routers, not specific to NAT devices. The requirements are also not UDP specific and apply to all IP protocols. ICMP behave document also had requirements that directly overlapped with the above. In the last WG meeting, Lars commented that NATs should essentially confirm to RFC 1812. During a subsequent e-mail converation with Dan, Dan and the authors of the ICMP draft agreed that was the right thing to do. In the next rev of the ICMP draft, we are going to synthesize these and other such requirements into a single requirement stating that NATs should confirm to RFC-1812 router requirements in IP packet handling and list the specific ICMP requirements as examples under that requirement. Since both requirements (Req#13, Req#14) are not protocol specific and are to do with genrating/processing ICMP errors, may I suggest that these requirements be dropped from the UDP draft and just be included in the ICMP behave draft. regards, suresh --- Dan Wing wrote: > > > >> 9. Section 10.2, REQ-14: > > > >> > > > >> I don't see how this requirement is connected to the section > > > >> text? Also it is not clear if there is anything more than what > > > >> is described in section 9 and 10.1 that needs to be supported. > > > >> I think some clarification and text changes in regards to this > > > >> is needed. > > > > > > > > I might be missing what you are saying here but .... are you > > > > thinking changing > > > > > > > > REQ-14: A NAT MUST support fragmentation of packets larger than > > > > link MTU. > > > > > > > > To something more like > > > > > > > > REQ-14: A NAT MUST support fragmentation of packets larger than > > > > link MTU by sending an ICMP for any packet larger than the > > > > MTU when DF=1 and in the case where DF=0, either break the > > > > packet into fragments smaller than the MTU or send an ICMP > > > > error. > > > > > > > > Clearly this text would need to be changed to make sense but > > > > just wanted to make sure I was understanding the scope of the > > > > change here. > > > > > > > > > > What I don't understand is what is different in Req-13 and Req-14. > > > To me REQ-13 applies independently if the packet is going from the > > > internal to the external or vice versa. > > > > Dan, can you expand on this? > > (I contributed this text in the document.) > > Req-13 describes a UDP packet arriving at the NAT that is larger > than the MTU for the next interface. Yes, it applies independently if > the packet is going from internal to external or vice versa. > > It describes expected behavior depending on the DF bit. This is > arguably not UDP specific, but we lack a "for all protocols" > document; the intent is to echo the requirements for DF handling > that are in RFC1812. > > Looking at this again, the current text in -05 reads: > > REQ-13: If the packet has DF=1, the NAT SHOULD send back an ICMP > message "fragmentation needed and DF set" message to the host as > described in RFC 792 [2]. > a) If the packet has DF=0, the NAT SHOULD fragment the packet and > send the fragments, in order. > > and could be improved by changing it to: > > REQ-13: If a UDP packet needs to be routed to a link with a smaller > MTU, and > a) the DF bit is set, the NAT MUST send back an ICMP 'fragmentation > needed and DF set' message to the originating host as described > in RFC792 [2]. > b) the DF bit is clear, the NAT SHOULD fragment the packet and > SHOULD send the fragments in order. > > > The text around Req-14 (that is, the text of section 10.2) describes > what the NAT should do when it, itself, receives an ICMP message. > The text of section 10.2 and its Req-14 (which needs to be > rewritten, as Req-14 is inaccurate) should be moved into an ICMP > document, as this behavior is not specific to UDP. > > Thanks for catching this, Magnus. > > -d > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Sun, 23 Apr 2006 21:36:42 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 23 Apr 2006 21:36:42 -0700 (PDT) Subject: Req-12 (Was:: Re: [Ietf-behave] Re: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <44479989.9050607@ericsson.com> Message-ID: <20060424043641.71275.qmail@web33303.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Magnus Westerlund wrote: <... stuff deleted> > >> 7. Section 9: REQ-12: > >> > >> "Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping." > >> > >> Is the use of "destroy" the right word. As the ICMP do not directly > >> cause the destruction of the mapping, wouldn't using "terminate" be more > >> correct? > >> > > terminate sounds better to me - will see if anyone objects but sounds like > a > > good change. > > > > [snip 8] > [suresh] This is another requirement that is not UDP specific and is entirely to do with ICMP error handling. This requirement fully overlaps with the following requirement in the ICMP behave draft. REQ-3: While processing an ICMP error packet, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP error packet. I suggest, Req #12 be dropped from the UDP draft. ICMP error hadling should be deferred to the ICMP behave document, IMHO. regards, suresh From magnus.westerlund@ericsson.com Mon, 24 Apr 2006 00:53:23 -0700 (PDT) From: Magnus Westerlund Date: Mon, 24 Apr 2006 00:53:23 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060424031345.9711.qmail@web33306.mail.mud.yahoo.com> Message-ID: <444C83ED.9020004@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Pyda Srisuresh wrote: [suresh] I agree, makinng the timers long can be problematic to a number of NAT vendors, especially those that make low-end NAT devices with limited resources. NAT vendors fine tune these timeouts to suit their customer environmets. If IETF mandates the timeouts to be long, the vendors could run into support problems they had not not anticipated as NATs run out of resources quickly. IETF will not be there to help them with the support issues. My vote is to keep the timer at 1 minute. I believe, setting this to more than 2 minutes could potentially invite unknown support issues. Many vendor might in turn choose not to adapt the madanted timeouts. My 2c. Okay, but what is worst, unknown support issues or practical issues such that wireless devices will drain their batteries much faster? Unless you can point to actual practical problems I suggest we raise it at least to two minutes. I would have liked 5 min but do understand that goes beyond the commonly used 3 minutes which I agree have to large potential to create issues with deployed NATs. To me this is a discussion on finding the point where we break so few bad implementations, while still representing an actual functionality gain, thus creating a situation where deploying behave compliant NATs is an advantage and do happens. I do hope that we can raise the bar a bit and not simply take the smallest common denominator. We are after all doing this on a number of other points in these requirements. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From fluffy@cisco.com Mon, 24 Apr 2006 09:39:28 -0700 (PDT) From: Cullen Jennings Date: Mon, 24 Apr 2006 09:39:28 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060424031345.9711.qmail@web33306.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I would like to make a comment about low end NAT vendors. Most comments I make are just my opinion but this morning I contacted the relevant engineers and Linksys and am passing on the information from Linksys. I believe and support all this information. Linksys is by far and away the number one NAT vendors when measured by number of units shipped. None of the Linksys NATs have a time out value as low as one minute for this timer. There is no problem with running out of ports on any of the residnetintial NATs and that is not a concern. Even with heavy P2P applications, port depletion is not an issue. The memory to store state for a large number ports is a very small portion of the total memory budget for the devices and not an issue. In conversations with Netgear and DLink, I believe they have very similar beliefs on all this - basically all the low end NAT manufactures are using very similar code bases on nearly identical hardware so it is not surprising that if this is not a problem for any of them. I don't in anyway believe that a 1 minute time out will be useful for the residential style NATs. I don't know anyone involved with building these style NATs that believes that 1 minute is needed - there might be someone but I have not seen them post to the list or talk to me. I did not go and discuss this issue with the people that build high end enterprise style NATs at Cisco. This is a tradeoff between running out of ports on the NAT, and running out of bandwidth on the link and processing keep alive transactions on the servers and batter life on mobile clients. Many people have expressed many concerns about having this number too low. Cullen On 4/23/06 8:13 PM, "Pyda Srisuresh" wrote: > > > --- Francois Audet wrote: > ... >>>>> 5. Section 4.3: REQ-5: >>>>> "A NAT UDP mapping timer MUST NOT expire in less than 1 minute, >>>>> unless REQ-5a applies. >>>>> a) A NAT MAY have UDP mapping timers that have much shorter >>>>> timers, but only for specific ports in the >>> well-known port >>>>> range (i.e., ports 0-1023) where the IANA- >>> registered protocol >>>>> is strictly a request/response protocol, such as >>> for example >>>>> DNS over UDP/53. >>>>> b) The value of the NAT UDP mapping timer MAY be >>> configurable. >>>>> c) A default value of 5 minutes for the NAT UDP >>> mapping timer is >>>>> RECOMMENDED." >> >> We have been trying to balance our requirement for timer values between >> what makes sense for "residential-grade" NATs versus large Enterprise >> NATs (who happens to be Firewall at the same time). >> >> The larger timers make sense for the residential-grade NATs. Req 5-c is >> useful for residential-grade NATs, because often, the manufacturers are >> very amiable to a recommended default. >> >> What we have found however is that the Enterprise NAT vendors where >> quite >> uncomfortable with long timers. The change from "2 minutes" to "1 >> minute" for >> the minimum was a result of request from Enterprise NAT vendors. We are >> a bit >> worried that if the timer is too long, they will simply ignore the >> requirement. >> Req 5a was introduced to allow for optimizations that are very common >> for >> large Enterprise NATs. >> >> So, I think we have three options: >> a - Keep the original value (before -05), which was 2 minutes. >> b - Keep the lower limit from the -05 draft, which is 1 minute >> c - Use 3 minutes, as per Magnus and Cullen's dialog >> >> Personally, I think that we should revert to what we had before -05 >> which is >> the 2 minutes. It seems to me that we circled the argument many times >> now, >> and that it is the best compromise. >> >> But I'm happy with any of those values. >> > [suresh] I agree, makinng the timers long can be problematic to a number of > NAT > vendors, especially those that make low-end NAT devices with limited > resources. > NAT vendors fine tune these timeouts to suit their customer environmets. If > IETF mandates the timeouts to be long, the vendors could run into support > problems they had not not anticipated as NATs run out of resources quickly. > IETF will not be there to help them with the support issues. > > My vote is to keep the timer at 1 minute. I believe, setting this to more than > 2 minutes could potentially invite unknown support issues. Many vendor might > in turn choose not to adapt the madanted timeouts. My 2c. > > regards, > suresh From fluffy@cisco.com Mon, 24 Apr 2006 09:39:29 -0700 (PDT) From: Cullen Jennings Date: Mon, 24 Apr 2006 09:39:29 -0700 (PDT) Subject: Re: Req-13 & Req-14 (WAS:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060424032030.84005.qmail@web33313.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 4/23/06 8:20 PM, "Pyda Srisuresh" wrote: >> REQ-13: If a UDP packet needs to be routed to a link with a smaller >> MTU, and >> a) the DF bit is set, the NAT MUST send back an ICMP 'fragmentation >> needed and DF set' message to the originating host as described >> in RFC792 [2]. This was discussed in meetings long ago and found unacceptable. Many firewall and NATs are configure not to send ICMP responses to packets such as this. There is no application need to make all these devices non behave compliant so this was rejected. A NAT behaves like a a router some of the time but the goal of a firewall or NAT is not the same as a router. Cullen From spencer@mcsr-labs.org Mon, 24 Apr 2006 10:09:08 -0700 (PDT) From: "Spencer Dawkins" Date: Mon, 24 Apr 2006 10:09:08 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments ondraft-ietf-behave-nat-udp-05) In-Reply-To: <20060424031345.9711.qmail@web33306.mail.mud.yahoo.com> Message-ID: <01a501c667c1$711e7b90$0700a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain From: "Magnus Westerlund" To me this is a discussion on finding the point where we break so few bad implementations, while still representing an actual functionality gain, thus creating a situation where deploying behave compliant NATs is an advantage and do happens. I do hope that we can raise the bar a bit and not simply take the smallest common denominator. We are after all doing this on a number of other points in these requirements. Cheers Magnus Westerlund I agree with Magnus here. BEHAVE is chartered to develop Best Current Practice specifications, and there needs to be a balance between what's "Best", and what's "Current"... Thanks, Spencer From fluffy@cisco.com Mon, 24 Apr 2006 16:33:21 -0700 (PDT) From: Cullen Jennings Date: Mon, 24 Apr 2006 16:33:21 -0700 (PDT) Subject: Re: Req-13 & Req-14 (WAS:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain When I wrote my email, I did not understand that this requirement only applied to outgoing packets - if we could make it clear that this only applies to packets from the internal to external direction, I'm fine with it because at that point I think it is what the WG previously agreed to. On 4/24/06 9:38 AM, "Cullen Jennings" wrote: > On 4/23/06 8:20 PM, "Pyda Srisuresh" wrote: > >>> REQ-13: If a UDP packet needs to be routed to a link with a smaller >>> MTU, and >>> a) the DF bit is set, the NAT MUST send back an ICMP 'fragmentation >>> needed and DF set' message to the originating host as described >>> in RFC792 [2]. > > This was discussed in meetings long ago and found unacceptable. Many > firewall and NATs are configure not to send ICMP responses to packets such > as this. There is no application need to make all these devices non behave > compliant so this was rejected. A NAT behaves like a a router some of the > time but the goal of a firewall or NAT is not the same as a router. > > Cullen > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Mon, 24 Apr 2006 16:33:22 -0700 (PDT) From: Cullen Jennings Date: Mon, 24 Apr 2006 16:33:22 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments ondraft-ietf-behave-nat-udp-05) In-Reply-To: <01a501c667c1$711e7b90$0700a8c0@china.huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 4/24/06 10:06 AM, "Spencer Dawkins" wrote: > From: "Magnus Westerlund" > >> To me this is a discussion on finding the point where we break so few bad >> implementations, while still representing an actual functionality gain, >> thus creating a situation where deploying behave compliant NATs is an >> advantage and do happens. >> >> I do hope that we can raise the bar a bit and not simply take the smallest >> common denominator. We are after all doing this on a number of other >> points in these requirements. >> >> Cheers >> >> Magnus Westerlund > > I agree with Magnus here. > > BEHAVE is chartered to develop Best Current Practice specifications, and > there needs to be a balance between what's "Best", and what's "Current"... > > Thanks, > > Spencer Me too :-) From fluffy@cisco.com Mon, 24 Apr 2006 16:33:24 -0700 (PDT) From: Cullen Jennings Date: Mon, 24 Apr 2006 16:33:24 -0700 (PDT) Subject: Re: Req-12 (Was:: Re: [Ietf-behave] Re: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060424043641.71275.qmail@web33303.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 4/23/06 9:36 PM, "Pyda Srisuresh" wrote: > This requirement fully overlaps with the > following requirement in the ICMP behave draft. Glad you agree now - I seem to recall that you previously felt that the ICMP draft did not duplicated any of the requirements in the UDP document. From ascolnic@checkpoint.com Tue, 25 Apr 2006 01:25:21 -0700 (PDT) From: "Ariel Shaqed (Scolnicov)" Date: Tue, 25 Apr 2006 01:25:21 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060424031345.9711.qmail@web33306.mail.mud.yahoo.com> Message-ID: <200604251129.05560@kmail-ckp> MIME-Version: 1.0 Content-Type: text/plain On Monday 24 April 2006 10:53, Magnus Westerlund wrote: > Pyda Srisuresh wrote: > > [suresh] I agree, makinng the timers long can be problematic to a > > number of NAT vendors, especially those that make low-end NAT devices > > with limited resources. NAT vendors fine tune these timeouts to suit > > their customer environmets. If IETF mandates the timeouts to be long, > > the vendors could run into support problems they had not not > > anticipated as NATs run out of resources quickly. IETF will not be > > there to help them with the support issues. > > > > My vote is to keep the timer at 1 minute. I believe, setting this to > > more than 2 minutes could potentially invite unknown support issues. > > Many vendor might in turn choose not to adapt the madanted timeouts. > > My 2c. > > Okay, but what is worst, unknown support issues or practical issues such > that wireless devices will drain their batteries much faster? Unless you > can point to actual practical problems I suggest we raise it at least to > two minutes. I would have liked 5 min but do understand that goes beyond > the commonly used 3 minutes which I agree have to large potential to > create issues with deployed NATs. Some bad things: 1. Not only the 1st NAT on the path is affected. If an application sends keepalives every 2 minutes it will not work with firewalls anywhere along its path that keep a smaller timeout for UDP connections and also inspect the protocol. It is probably not very practical to hold a UDP connection (i.e. its current state) open on a firewall for 5 minutes of inactivity. Note that even 0 bits of stored state can make the difference: Consider a firewall dropping all UDP connections in one direction. It make sense to specify minimal timeouts, just not for all UDP ports. 2. The above, when the firewall is NATting its internal domain. 3. Some UDP connections are extremely short-lived. An example with port> 1024 is RADIUS, which (in some modes) performs many short exchanges. The requirement limits the number of concurrent sessions possible. There are <65000 ports available for NAT. If we reserve ports for 300 seconds this yields a sustained rate of <216 connections per second to a given server. It is acceptable for a residential NAT, probably not for #2 above. > To me this is a discussion on finding the point where we break so few > bad implementations, while still representing an actual functionality > gain, thus creating a situation where deploying behave compliant NATs is > an advantage and do happens. > > I do hope that we can raise the bar a bit and not simply take the > smallest common denominator. We are after all doing this on a number of > other points in these requirements. The issue here is not (just) of poor existing implementations. -- Ariel Scolnicov. From srisuresh@yahoo.com Tue, 25 Apr 2006 06:13:41 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 25 Apr 2006 06:13:41 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <200604251129.05560@kmail-ckp> Message-ID: <20060425131340.42144.qmail@web33313.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain I couldnt agree more. Ariel has nicely articulated the issues. It is a fine balance between short lived applications and applications that may need long pauses. Increasing the timeout will impact conenction rate for applications. This effects enterprise NATs more than the residential NATs. regards, suresh --- "Ariel Shaqed (Scolnicov)" wrote: > On Monday 24 April 2006 10:53, Magnus Westerlund wrote: > > Pyda Srisuresh wrote: > > > [suresh] I agree, makinng the timers long can be problematic to a > > > number of NAT vendors, especially those that make low-end NAT devices > > > with limited resources. NAT vendors fine tune these timeouts to suit > > > their customer environmets. If IETF mandates the timeouts to be long, > > > the vendors could run into support problems they had not not > > > anticipated as NATs run out of resources quickly. IETF will not be > > > there to help them with the support issues. > > > > > > My vote is to keep the timer at 1 minute. I believe, setting this to > > > more than 2 minutes could potentially invite unknown support issues. > > > Many vendor might in turn choose not to adapt the madanted timeouts. > > > My 2c. > > > > Okay, but what is worst, unknown support issues or practical issues such > > that wireless devices will drain their batteries much faster? Unless you > > can point to actual practical problems I suggest we raise it at least to > > two minutes. I would have liked 5 min but do understand that goes beyond > > the commonly used 3 minutes which I agree have to large potential to > > create issues with deployed NATs. > > Some bad things: > > 1. Not only the 1st NAT on the path is affected. If an application sends > keepalives every 2 minutes it will not work with firewalls anywhere along > its path that keep a smaller timeout for UDP connections and also inspect > the protocol. It is probably not very practical to hold a UDP connection > (i.e. its current state) open on a firewall for 5 minutes of inactivity. > > Note that even 0 bits of stored state can make the difference: Consider a > firewall dropping all UDP connections in one direction. > > It make sense to specify minimal timeouts, just not for all UDP ports. > > > 2. The above, when the firewall is NATting its internal domain. > > 3. Some UDP connections are extremely short-lived. An example with port> > 1024 is RADIUS, which (in some modes) performs many short exchanges. The > requirement limits the number of concurrent sessions possible. There are > <65000 ports available for NAT. If we reserve ports for 300 seconds this > yields a sustained rate of <216 connections per second to a given server. > > It is acceptable for a residential NAT, probably not for #2 above. > > > To me this is a discussion on finding the point where we break so few > > bad implementations, while still representing an actual functionality > > gain, thus creating a situation where deploying behave compliant NATs is > > an advantage and do happens. > > > > I do hope that we can raise the bar a bit and not simply take the > > smallest common denominator. We are after all doing this on a number of > > other points in these requirements. > > The issue here is not (just) of poor existing implementations. > > -- > Ariel Scolnicov. > From srisuresh@yahoo.com Tue, 25 Apr 2006 06:20:58 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 25 Apr 2006 06:20:58 -0700 (PDT) Subject: Re: Req-12 (Was:: Re: [Ietf-behave] Re: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: Message-ID: <20060425132058.45552.qmail@web33313.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > On 4/23/06 9:36 PM, "Pyda Srisuresh" wrote: > > > This requirement fully overlaps with the > > following requirement in the ICMP behave draft. > > Glad you agree now - I seem to recall that you previously felt that the ICMP > draft did not duplicated any of the requirements in the UDP document. > [suresh] I did not say there was no overlap. I said the overlaps did not conflict. I do believe, ICMP error handling requirement belongs in the ICMP behave draft. regards, suresh From srisuresh@yahoo.com Tue, 25 Apr 2006 06:33:29 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 25 Apr 2006 06:33:29 -0700 (PDT) Subject: Re: Req-13 & Req-14 (WAS:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: Message-ID: <20060425133328.69921.qmail@web33304.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > On 4/23/06 8:20 PM, "Pyda Srisuresh" wrote: > > >> REQ-13: If a UDP packet needs to be routed to a link with a smaller > >> MTU, and > >> a) the DF bit is set, the NAT MUST send back an ICMP 'fragmentation > >> needed and DF set' message to the originating host as described > >> in RFC792 [2]. > > This was discussed in meetings long ago and found unacceptable. Many > firewall and NATs are configure not to send ICMP responses to packets such > as this. There is no application need to make all these devices non behave > compliant so this was rejected. A NAT behaves like a a router some of the > time but the goal of a firewall or NAT is not the same as a router. > > Cullen > > [suresh] What are you talking about, Cullen? You sound confused. You are certainly not responding to the text I sent on this thread. The WG did not object to NATs sending an ICMP 'fragmentation needed and DF set' message, AFAIK, regards, suresh From srisuresh@yahoo.com Tue, 25 Apr 2006 06:40:44 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 25 Apr 2006 06:40:44 -0700 (PDT) Subject: Re: Req-13 & Req-14 (WAS:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: Message-ID: <20060425134043.651.qmail@web33315.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen - Sounds like, you are mixing up threads. You are not responding to the text I sent on this thread. Req-13 applies to both directions, AFAIK. That is not what we are talking about, though. regards, suresh --- Cullen Jennings wrote: > > When I wrote my email, I did not understand that this requirement only > applied to outgoing packets - if we could make it clear that this only > applies to packets from the internal to external direction, I'm fine with it > because at that point I think it is what the WG previously agreed to. > > > On 4/24/06 9:38 AM, "Cullen Jennings" wrote: > > > On 4/23/06 8:20 PM, "Pyda Srisuresh" wrote: > > > >>> REQ-13: If a UDP packet needs to be routed to a link with a smaller > >>> MTU, and > >>> a) the DF bit is set, the NAT MUST send back an ICMP 'fragmentation > >>> needed and DF set' message to the originating host as described > >>> in RFC792 [2]. > > > > This was discussed in meetings long ago and found unacceptable. Many > > firewall and NATs are configure not to send ICMP responses to packets such > > as this. There is no application need to make all these devices non behave > > compliant so this was rejected. A NAT behaves like a a router some of the > > time but the goal of a firewall or NAT is not the same as a router. > > > > Cullen > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Tue, 25 Apr 2006 07:06:47 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 25 Apr 2006 07:06:47 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: Message-ID: <20060425140647.57296.qmail@web33312.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Thank you for the feedback from Linksys. What is the UDP timeout used on the LinkSys, NetGear, D-Link and other residential NAT devices? What are the bounds to the limits they are willing to accept? There are a number of enterprise/data-center devices that embed NAT functioanlity within. They have resource constraints that would be put to test when the timeout is made very long. Not to mention the usage constraints that Ariel mentioned. It woudl be good to consider their feedback as well before mandating. Regards, suresh --- Cullen Jennings wrote: > > I would like to make a comment about low end NAT vendors. Most comments I > make are just my opinion but this morning I contacted the relevant engineers > and Linksys and am passing on the information from Linksys. I believe and > support all this information. > > Linksys is by far and away the number one NAT vendors when measured by > number of units shipped. None of the Linksys NATs have a time out value as > low as one minute for this timer. There is no problem with running out of > ports on any of the residnetintial NATs and that is not a concern. Even with > heavy P2P applications, port depletion is not an issue. The memory to store > state for a large number ports is a very small portion of the total memory > budget for the devices and not an issue. > > In conversations with Netgear and DLink, I believe they have very similar > beliefs on all this - basically all the low end NAT manufactures are using > very similar code bases on nearly identical hardware so it is not surprising > that if this is not a problem for any of them. > > I don't in anyway believe that a 1 minute time out will be useful for the > residential style NATs. I don't know anyone involved with building these > style NATs that believes that 1 minute is needed - there might be someone > but I have not seen them post to the list or talk to me. > > I did not go and discuss this issue with the people that build high end > enterprise style NATs at Cisco. > > This is a tradeoff between running out of ports on the NAT, and running out > of bandwidth on the link and processing keep alive transactions on the > servers and batter life on mobile clients. Many people have expressed many > concerns about having this number too low. > > Cullen Linksys> > > > On 4/23/06 8:13 PM, "Pyda Srisuresh" wrote: > > > > > > > --- Francois Audet wrote: > > ... > >>>>> 5. Section 4.3: REQ-5: > >>>>> "A NAT UDP mapping timer MUST NOT expire in less than 1 minute, > >>>>> unless REQ-5a applies. > >>>>> a) A NAT MAY have UDP mapping timers that have much shorter > >>>>> timers, but only for specific ports in the > >>> well-known port > >>>>> range (i.e., ports 0-1023) where the IANA- > >>> registered protocol > >>>>> is strictly a request/response protocol, such as > >>> for example > >>>>> DNS over UDP/53. > >>>>> b) The value of the NAT UDP mapping timer MAY be > >>> configurable. > >>>>> c) A default value of 5 minutes for the NAT UDP > >>> mapping timer is > >>>>> RECOMMENDED." > >> > >> We have been trying to balance our requirement for timer values between > >> what makes sense for "residential-grade" NATs versus large Enterprise > >> NATs (who happens to be Firewall at the same time). > >> > >> The larger timers make sense for the residential-grade NATs. Req 5-c is > >> useful for residential-grade NATs, because often, the manufacturers are > >> very amiable to a recommended default. > >> > >> What we have found however is that the Enterprise NAT vendors where > >> quite > >> uncomfortable with long timers. The change from "2 minutes" to "1 > >> minute" for > >> the minimum was a result of request from Enterprise NAT vendors. We are > >> a bit > >> worried that if the timer is too long, they will simply ignore the > >> requirement. > >> Req 5a was introduced to allow for optimizations that are very common > >> for > >> large Enterprise NATs. > >> > >> So, I think we have three options: > >> a - Keep the original value (before -05), which was 2 minutes. > >> b - Keep the lower limit from the -05 draft, which is 1 minute > >> c - Use 3 minutes, as per Magnus and Cullen's dialog > >> > >> Personally, I think that we should revert to what we had before -05 > >> which is > >> the 2 minutes. It seems to me that we circled the argument many times > >> now, > >> and that it is the best compromise. > >> > >> But I'm happy with any of those values. > >> > > [suresh] I agree, makinng the timers long can be problematic to a number of > > NAT > > vendors, especially those that make low-end NAT devices with limited > > resources. > > NAT vendors fine tune these timeouts to suit their customer environmets. If > > IETF mandates the timeouts to be long, the vendors could run into support > > problems they had not not anticipated as NATs run out of resources quickly. > > IETF will not be there to help them with the support issues. > > > > My vote is to keep the timer at 1 minute. I believe, setting this to more > than > > 2 minutes could potentially invite unknown support issues. Many vendor > might > > in turn choose not to adapt the madanted timeouts. My 2c. > > > > regards, > > suresh > From audet@nortel.com Tue, 25 Apr 2006 07:13:07 -0700 (PDT) From: "Francois Audet" Date: Tue, 25 Apr 2006 07:13:07 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments ondraft-ietf-behave-nat-udp-05) Message-ID: <1ECE0EB50388174790F9694F77522CCF09009871@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Guys, it is perfectly legal to have ports that are not behave-compliants. It just means you are reserving these ports for applications that have a short-lived timer. You can't use them for behave media. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Ariel Shaqed (Scolnicov) > Sent: Tuesday, April 25, 2006 01:29 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution > comments ondraft-ietf-behave-nat-udp-05) > > > On Monday 24 April 2006 10:53, Magnus Westerlund wrote: > > Pyda Srisuresh wrote: > > > [suresh] I agree, makinng the timers long can be problematic to a > > > number of NAT vendors, especially those that make low-end NAT > > > devices with limited resources. NAT vendors fine tune > these timeouts > > > to suit their customer environmets. If IETF mandates the > timeouts to > > > be long, the vendors could run into support problems they had not > > > not anticipated as NATs run out of resources quickly. > IETF will not > > > be there to help them with the support issues. > > > > > > My vote is to keep the timer at 1 minute. I believe, > setting this to > > > more than 2 minutes could potentially invite unknown support > > > issues. Many vendor might in turn choose not to adapt the > madanted > > > timeouts. My 2c. > > > > Okay, but what is worst, unknown support issues or practical issues > > such that wireless devices will drain their batteries much faster? > > Unless you can point to actual practical problems I suggest > we raise > > it at least to two minutes. I would have liked 5 min but do > understand > > that goes beyond the commonly used 3 minutes which I agree have to > > large potential to create issues with deployed NATs. > > Some bad things: > > 1. Not only the 1st NAT on the path is affected. If an > application sends > keepalives every 2 minutes it will not work with firewalls > anywhere along > its path that keep a smaller timeout for UDP connections and > also inspect > the protocol. It is probably not very practical to hold a > UDP connection > (i.e. its current state) open on a firewall for 5 minutes of > inactivity. > > Note that even 0 bits of stored state can make the > difference: Consider a > firewall dropping all UDP connections in one direction. > > It make sense to specify minimal timeouts, just not for all UDP ports. > > > 2. The above, when the firewall is NATting its internal domain. > > 3. Some UDP connections are extremely short-lived. An > example with port> > 1024 is RADIUS, which (in some modes) performs many short > exchanges. The > requirement limits the number of concurrent sessions > possible. There are > <65000 ports available for NAT. If we reserve ports for 300 > seconds this > yields a sustained rate of <216 connections per second to a > given server. > > It is acceptable for a residential NAT, probably not for #2 above. > > > To me this is a discussion on finding the point where we > break so few > > bad implementations, while still representing an actual > functionality > > gain, thus creating a situation where deploying behave > compliant NATs > > is an advantage and do happens. > > > > I do hope that we can raise the bar a bit and not simply take the > > smallest common denominator. We are after all doing this on > a number > > of other points in these requirements. > > The issue here is not (just) of poor existing implementations. > > -- > Ariel Scolnicov. _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From srisuresh@yahoo.com Tue, 25 Apr 2006 07:16:52 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 25 Apr 2006 07:16:52 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <444C83ED.9020004@ericsson.com> Message-ID: <20060425141652.89549.qmail@web33304.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Magnus, Ariel had identified some real issues with raising the timeouts. Resource constraints (Memory and CPU utilization) is another concern. When timeouts are increased, NAT devices need to a) set aside memory for the largely unused Zombie sessions, and, b) monitor the large number of zombie sessions periodically for timeouts. Having said that, I am OK with a timeout anywhere between a minute and two minutes. regards, suresh --- Magnus Westerlund wrote: > > > Pyda Srisuresh wrote: > >> > > [suresh] I agree, makinng the timers long can be problematic to a number of > NAT > > vendors, especially those that make low-end NAT devices with limited > resources. > > NAT vendors fine tune these timeouts to suit their customer environmets. If > > IETF mandates the timeouts to be long, the vendors could run into support > > problems they had not not anticipated as NATs run out of resources quickly. > > IETF will not be there to help them with the support issues. > > > > My vote is to keep the timer at 1 minute. I believe, setting this to more > than > > 2 minutes could potentially invite unknown support issues. Many vendor > might > > in turn choose not to adapt the madanted timeouts. My 2c. > > > > Okay, but what is worst, unknown support issues or practical issues such > that wireless devices will drain their batteries much faster? Unless you > can point to actual practical problems I suggest we raise it at least to > two minutes. I would have liked 5 min but do understand that goes beyond > the commonly used 3 minutes which I agree have to large potential to > create issues with deployed NATs. > > To me this is a discussion on finding the point where we break so few > bad implementations, while still representing an actual functionality > gain, thus creating a situation where deploying behave compliant NATs is > an advantage and do happens. > > I do hope that we can raise the bar a bit and not simply take the > smallest common denominator. We are after all doing this on a number of > other points in these requirements. > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx > From audet@nortel.com Tue, 25 Apr 2006 07:18:59 -0700 (PDT) From: "Francois Audet" Date: Tue, 25 Apr 2006 07:18:59 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) Message-ID: <1ECE0EB50388174790F9694F77522CCF09009889@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I will point out that ALL our drafts had a timeout of 2 minutes. It's only the -05 draft where we shortened it to 1 minute. The concensus of the group had always been 2 minutes. > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > Sent: Tuesday, April 25, 2006 07:17 > To: Magnus Westerlund > Cc: Audet, Francois [SC100:3055:EXCH]; Cullen Jennings; > dwing@xxxxxxxxx; Behave > Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution > comments on draft-ietf-behave-nat-udp-05) > > > Magnus, > > Ariel had identified some real issues with raising the > timeouts. Resource constraints (Memory and CPU utilization) > is another concern. When timeouts are increased, NAT devices > need to a) set aside memory for the largely unused Zombie > sessions, and, b) monitor the large number of zombie sessions > periodically for timeouts. > > Having said that, I am OK with a timeout anywhere between a > minute and two minutes. > > regards, > suresh > > --- Magnus Westerlund wrote: > > > > > > > Pyda Srisuresh wrote: > > >> > > > [suresh] I agree, makinng the timers long can be problematic to a > > > number of > > NAT > > > vendors, especially those that make low-end NAT devices > with limited > > resources. > > > NAT vendors fine tune these timeouts to suit their customer > > > environmets. If IETF mandates the timeouts to be long, > the vendors > > > could run into support problems they had not not > anticipated as NATs > > > run out of resources quickly. IETF will not be there to help them > > > with the support issues. > > > > > > My vote is to keep the timer at 1 minute. I believe, > setting this to > > > more > > than > > > 2 minutes could potentially invite unknown support issues. Many > > > vendor > > might > > > in turn choose not to adapt the madanted timeouts. My 2c. > > > > > > > Okay, but what is worst, unknown support issues or practical issues > > such > > that wireless devices will drain their batteries much > faster? Unless you > > can point to actual practical problems I suggest we raise > it at least to > > two minutes. I would have liked 5 min but do understand > that goes beyond > > the commonly used 3 minutes which I agree have to large > potential to > > create issues with deployed NATs. > > > > To me this is a discussion on finding the point where we > break so few > > bad implementations, while still representing an actual > functionality > > gain, thus creating a situation where deploying behave > compliant NATs is > > an advantage and do happens. > > > > I do hope that we can raise the bar a bit and not simply take the > > smallest common denominator. We are after all doing this on > a number of > > other points in these requirements. > > > > Cheers > > > > Magnus Westerlund > > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx > > > > > > > From srisuresh@yahoo.com Tue, 25 Apr 2006 07:19:02 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 25 Apr 2006 07:19:02 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments ondraft-ietf-behave-nat-udp-05) In-Reply-To: <01a501c667c1$711e7b90$0700a8c0@china.huawei.com> Message-ID: <20060425141900.75000.qmail@web33302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain I understand and agree. regards, suresh --- Spencer Dawkins wrote: > From: "Magnus Westerlund" > > > To me this is a discussion on finding the point where we break so few bad > > implementations, while still representing an actual functionality gain, > > thus creating a situation where deploying behave compliant NATs is an > > advantage and do happens. > > > > I do hope that we can raise the bar a bit and not simply take the smallest > > common denominator. We are after all doing this on a number of other > > points in these requirements. > > > > Cheers > > > > Magnus Westerlund > > I agree with Magnus here. > > BEHAVE is chartered to develop Best Current Practice specifications, and > there needs to be a balance between what's "Best", and what's "Current"... > > Thanks, > > Spencer > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From magnus.westerlund@ericsson.com Tue, 25 Apr 2006 07:20:22 -0700 (PDT) From: Magnus Westerlund Date: Tue, 25 Apr 2006 07:20:22 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060425140647.57296.qmail@web33312.mail.mud.yahoo.com> Message-ID: <444E3024.1050907@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Pyda Srisuresh wrote: Thank you for the feedback from Linksys. What is the UDP timeout used on the LinkSys, NetGear, D-Link and other residential NAT devices? What are the bounds to the limits they are willing to accept? There are a number of enterprise/data-center devices that embed NAT functioanlity within. They have resource constraints that would be put to test when the timeout is made very long. Not to mention the usage constraints that Ariel mentioned. It woudl be good to consider their feedback as well before mandating. This make me question the limitation of the caveat of removing mapping for request response protocols to below 1024. I think this caveat is reasonable to apply to any registered protocol with this behavior. I think the important fact here is that it requires a well known port that can be used to identify packets as belonging to that protocol. The potential backside of this is that applications that do use the registered port range for temporary and dynamic allocated ports can get into serious trouble. But these really should be using the dynamic range. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From dhudson@ubicom.com Tue, 25 Apr 2006 07:45:30 -0700 (PDT) From: "Dave Hudson" Date: Tue, 25 Apr 2006 07:45:30 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments ondraft-ietf-behave-nat-udp-05) Message-ID: MIME-Version: 1.0 Content-Type: text/plain On a number of residential devices for which we (Ubicom) deliver the core software we've just upped our timeouts to 5 minutes for UDP and 4 minutes for non-synchronized TCP states from the 2 minutes we used to use (we did this back in January). It does lead to more sessions being tracked but makes a number of P2P-based apps behave better (we see far fewer firewall messages about rejected packets and those that we do see now generally come from other NATs that incorrectly translated ICMP payloads or remapped ports mid-session). This affects routers from several vendors (one you queried and several smaller ones you didn't). Incidently I'd note that there are quite a few different codebases around in the residential router market and some have very different implementations of their NAT. It't not at all unusual to find that different products shipped by the same OEM have different codebases and quite different behaviour. Regards, Dave * -----Original Message----- * From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx * [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of * Pyda Srisuresh * Sent: 25 April 2006 15:07 * To: Cullen Jennings; Francois Audet; Magnus Westerlund; Dan Wing * Cc: Behave * Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution * comments ondraft-ietf-behave-nat-udp-05) * * * Thank you for the feedback from Linksys. What is the UDP * timeout used on the LinkSys, NetGear, D-Link and other * residential NAT devices? What are the bounds to the limits * they are willing to accept? * * There are a number of enterprise/data-center devices that * embed NAT functioanlity within. They have resource * constraints that would be put to test when the timeout is * made very long. Not to mention the usage constraints that * Ariel mentioned. It woudl be good to consider their feedback * as well before mandating. * * Regards, * suresh * * --- Cullen Jennings wrote: * * > * > I would like to make a comment about low end NAT vendors. Most * > comments I make are just my opinion but this morning I * contacted the * > relevant engineers and Linksys and am passing on the * information from * > Linksys. I believe and support all this information. * > * > Linksys is by far and away the number one NAT vendors when * measured by * > number of units shipped. None of the Linksys NATs have a time out * > value as low as one minute for this timer. There is no problem with * > running out of ports on any of the residnetintial NATs and * that is not * > a concern. Even with heavy P2P applications, port depletion * is not an * > issue. The memory to store state for a large number ports is a very * > small portion of the total memory budget for the devices * and not an issue. * > * > In conversations with Netgear and DLink, I believe they have very * > similar beliefs on all this - basically all the low end NAT * > manufactures are using very similar code bases on nearly identical * > hardware so it is not surprising that if this is not a * problem for any of them. * > * > I don't in anyway believe that a 1 minute time out will be * useful for * > the residential style NATs. I don't know anyone involved * with building * > these style NATs that believes that 1 minute is needed - * there might * > be someone but I have not seen them post to the list or talk to me. * > * > I did not go and discuss this issue with the people that build high * > end enterprise style NATs at Cisco. * > * > This is a tradeoff between running out of ports on the NAT, and * > running out of bandwidth on the link and processing keep alive * > transactions on the servers and batter life on mobile clients. Many * > people have expressed many concerns about having this * number too low. * > * > Cullen Linksys> * > * > * > On 4/23/06 8:13 PM, "Pyda Srisuresh" wrote: * > * > > * > > * > > --- Francois Audet wrote: * > > ... * > >>>>> 5. Section 4.3: REQ-5: * > >>>>> "A NAT UDP mapping timer MUST NOT expire in less * than 1 minute, * > >>>>> unless REQ-5a applies. * > >>>>> a) A NAT MAY have UDP mapping timers that have * much shorter * > >>>>> timers, but only for specific ports in the * > >>> well-known port * > >>>>> range (i.e., ports 0-1023) where the IANA- * > >>> registered protocol * > >>>>> is strictly a request/response protocol, such as * > >>> for example * > >>>>> DNS over UDP/53. * > >>>>> b) The value of the NAT UDP mapping timer MAY be * > >>> configurable. * > >>>>> c) A default value of 5 minutes for the NAT UDP * > >>> mapping timer is * > >>>>> RECOMMENDED." * > >> * > >> We have been trying to balance our requirement for timer values * > >> between what makes sense for "residential-grade" NATs * versus large * > >> Enterprise NATs (who happens to be Firewall at the same time). * > >> * > >> The larger timers make sense for the residential-grade NATs. Req * > >> 5-c is useful for residential-grade NATs, because often, the * > >> manufacturers are very amiable to a recommended default. * > >> * > >> What we have found however is that the Enterprise NAT * vendors where * > >> quite uncomfortable with long timers. The change from "2 * minutes" * > >> to "1 minute" for the minimum was a result of request from * > >> Enterprise NAT vendors. We are a bit worried that if the * timer is * > >> too long, they will simply ignore the requirement. * > >> Req 5a was introduced to allow for optimizations that are very * > >> common for large Enterprise NATs. * > >> * > >> So, I think we have three options: * > >> a - Keep the original value (before -05), which was 2 minutes. * > >> b - Keep the lower limit from the -05 draft, which is 1 * minute c - * > >> Use 3 minutes, as per Magnus and Cullen's dialog * > >> * > >> Personally, I think that we should revert to what we had * before -05 * > >> which is the 2 minutes. It seems to me that we circled * the argument * > >> many times now, and that it is the best compromise. * > >> * > >> But I'm happy with any of those values. * > >> * > > [suresh] I agree, makinng the timers long can be problematic to a * > > number of NAT vendors, especially those that make low-end NAT * > > devices with limited resources. * > > NAT vendors fine tune these timeouts to suit their customer * > > environmets. If IETF mandates the timeouts to be long, * the vendors * > > could run into support problems they had not not * anticipated as NATs run out of resources quickly. * > > IETF will not be there to help them with the support issues. * > > * > > My vote is to keep the timer at 1 minute. I believe, * setting this to * > > more * > than * > > 2 minutes could potentially invite unknown support issues. Many * > > vendor * > might * > > in turn choose not to adapt the madanted timeouts. My 2c. * > > * > > regards, * > > suresh * > * * * * _______________________________________________ * Ietf-behave mailing list * Ietf-behave@xxxxxxxxxxxxxxxxxxx * https://list.sipfoundry.org/mailman/listinfo/ietf-behave * * ***************************************************************************** **UPDATE 4/12/06*** Ubicom is Moving! Effective May 1st, 2006 our new address and phone number will be: Ubicom, Inc. 510 N. Pastoria Ave Sunnyvale, CA 94085 >>>>NEW NUMBER: (408) 789-2200 - Main (408) 739-2427 - Fax www.ubicom.com ****************************************************************************** From fluffy@cisco.com Tue, 25 Apr 2006 14:05:27 -0700 (PDT) From: Cullen Jennings Date: Tue, 25 Apr 2006 14:05:27 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060425141652.89549.qmail@web33304.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 4/25/06 7:16 AM, "Pyda Srisuresh" wrote: > Ariel had identified some real issues with raising the timeouts. We have been asking for this sort of feedback on this timer draft-audet-nat-behave-00 that went out in July 2004 - that version of the draft said 5 minutes. We are well past WGLC. I would be thrilled to learn more about the issue. Could you please be more specific about the the "real issues" are? However, it seems that 2 minutes would likely be acceptable to most people on this thread. 2 minutes was used in WGLC. 2 minutes was discussed and had support in WG meetings. I am not aware of new information that radically changes the thoughts on this. I suspect it may be getting very late in the process for more discussion of this. From srisuresh@yahoo.com Tue, 25 Apr 2006 17:51:02 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 25 Apr 2006 17:51:02 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09009889@zrc2hxm0.corp.nortel.com> Message-ID: <20060426005102.13084.qmail@web33306.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain 2 Minutes works for me. regards, suresh --- Francois Audet wrote: > I will point out that ALL our drafts had a timeout of 2 minutes. > > It's only the -05 draft where we shortened it to 1 minute. > > The concensus of the group had always been 2 minutes. > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > Sent: Tuesday, April 25, 2006 07:17 > > To: Magnus Westerlund > > Cc: Audet, Francois [SC100:3055:EXCH]; Cullen Jennings; > > dwing@xxxxxxxxx; Behave > > Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution > > comments on draft-ietf-behave-nat-udp-05) > > > > > > Magnus, > > > > Ariel had identified some real issues with raising the > > timeouts. Resource constraints (Memory and CPU utilization) > > is another concern. When timeouts are increased, NAT devices > > need to a) set aside memory for the largely unused Zombie > > sessions, and, b) monitor the large number of zombie sessions > > periodically for timeouts. > > > > Having said that, I am OK with a timeout anywhere between a > > minute and two minutes. > > > > regards, > > suresh > > > > --- Magnus Westerlund wrote: > > > > > > > > > > > Pyda Srisuresh wrote: > > > >> > > > > [suresh] I agree, makinng the timers long can be problematic to a > > > > number of > > > NAT > > > > vendors, especially those that make low-end NAT devices > > with limited > > > resources. > > > > NAT vendors fine tune these timeouts to suit their customer > > > > environmets. If IETF mandates the timeouts to be long, > > the vendors > > > > could run into support problems they had not not > > anticipated as NATs > > > > run out of resources quickly. IETF will not be there to help them > > > > with the support issues. > > > > > > > > My vote is to keep the timer at 1 minute. I believe, > > setting this to > > > > more > > > than > > > > 2 minutes could potentially invite unknown support issues. Many > > > > vendor > > > might > > > > in turn choose not to adapt the madanted timeouts. My 2c. > > > > > > > > > > Okay, but what is worst, unknown support issues or practical issues > > > such > > > that wireless devices will drain their batteries much > > faster? Unless you > > > can point to actual practical problems I suggest we raise > > it at least to > > > two minutes. I would have liked 5 min but do understand > > that goes beyond > > > the commonly used 3 minutes which I agree have to large > > potential to > > > create issues with deployed NATs. > > > > > > To me this is a discussion on finding the point where we > > break so few > > > bad implementations, while still representing an actual > > functionality > > > gain, thus creating a situation where deploying behave > > compliant NATs is > > > an advantage and do happens. > > > > > > I do hope that we can raise the bar a bit and not simply take the > > > smallest common denominator. We are after all doing this on > > a number of > > > other points in these requirements. > > > > > > Cheers > > > > > > Magnus Westerlund > > > > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > > > > ---------------------------------------------------------------------- > > > Ericsson AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx > > > > > > > > > > > > > > From srisuresh@yahoo.com Tue, 25 Apr 2006 17:58:04 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 25 Apr 2006 17:58:04 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <444E3024.1050907@ericsson.com> Message-ID: <20060426005804.95627.qmail@web33301.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain I agree, the caveat is reasonable to apply to any registered protocol with this behavior, not just the ports in the range of 1-1023. regards, suresh --- Magnus Westerlund wrote: > Pyda Srisuresh wrote: > > Thank you for the feedback from Linksys. What is the UDP timeout used on > the > > LinkSys, NetGear, D-Link and other residential NAT devices? What are the > bounds > > to the limits they are willing to accept? > > > > There are a number of enterprise/data-center devices that embed NAT > > functioanlity within. They have resource constraints that would be put to > test > > when the timeout is made very long. Not to mention the usage constraints > that > > Ariel mentioned. It woudl be good to consider their feedback as well before > > mandating. > > > > This make me question the limitation of the caveat of removing mapping > for request response protocols to below 1024. I think this caveat is > reasonable to apply to any registered protocol with this behavior. I > think the important fact here is that it requires a well known port that > can be used to identify packets as belonging to that protocol. > > The potential backside of this is that applications that do use the > registered port range for temporary and dynamic allocated ports can get > into serious trouble. But these really should be using the dynamic range. > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx > From srisuresh@yahoo.com Tue, 25 Apr 2006 18:02:50 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 25 Apr 2006 18:02:50 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments ondraft-ietf-behave-nat-udp-05) In-Reply-To: Message-ID: <20060426010250.56184.qmail@web33308.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dave Hudson wrote: > On a number of residential devices for which we (Ubicom) deliver the > core software we've just upped our timeouts to 5 minutes for UDP and 4 > minutes for non-synchronized TCP states from the 2 minutes we used to > use (we did this back in January). It does lead to more sessions being > tracked but makes a number of P2P-based apps behave better (we see far > fewer firewall messages about rejected packets and those that we do see > now generally come from other NATs that incorrectly translated ICMP > payloads or remapped ports mid-session). This affects routers from > several vendors (one you queried and several smaller ones you didn't). [suresh] Thank you for the feedback. This is good to hear, especially the positive effect the change had on P2P connenctions. regards, suresh > > Incidently I'd note that there are quite a few different codebases > around in the residential router market and some have very different > implementations of their NAT. It't not at all unusual to find that > different products shipped by the same OEM have different codebases and > quite different behaviour. > > > Regards, > Dave > > > * -----Original Message----- > * From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > * [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > * Pyda Srisuresh > * Sent: 25 April 2006 15:07 > * To: Cullen Jennings; Francois Audet; Magnus Westerlund; Dan Wing > * Cc: Behave > * Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution > * comments ondraft-ietf-behave-nat-udp-05) > * > * > * Thank you for the feedback from Linksys. What is the UDP > * timeout used on the LinkSys, NetGear, D-Link and other > * residential NAT devices? What are the bounds to the limits > * they are willing to accept? > * > * There are a number of enterprise/data-center devices that > * embed NAT functioanlity within. They have resource > * constraints that would be put to test when the timeout is > * made very long. Not to mention the usage constraints that > * Ariel mentioned. It woudl be good to consider their feedback > * as well before mandating. > * > * Regards, > * suresh > * > * --- Cullen Jennings wrote: > * > * > > * > I would like to make a comment about low end NAT vendors. Most > * > comments I make are just my opinion but this morning I > * contacted the > * > relevant engineers and Linksys and am passing on the > * information from > * > Linksys. I believe and support all this information. > * > > * > Linksys is by far and away the number one NAT vendors when > * measured by > * > number of units shipped. None of the Linksys NATs have a time out > * > value as low as one minute for this timer. There is no problem with > * > running out of ports on any of the residnetintial NATs and > * that is not > * > a concern. Even with heavy P2P applications, port depletion > * is not an > * > issue. The memory to store state for a large number ports is a very > * > small portion of the total memory budget for the devices > * and not an issue. > * > > * > In conversations with Netgear and DLink, I believe they have very > * > similar beliefs on all this - basically all the low end NAT > * > manufactures are using very similar code bases on nearly identical > * > hardware so it is not surprising that if this is not a > * problem for any of them. > * > > * > I don't in anyway believe that a 1 minute time out will be > * useful for > * > the residential style NATs. I don't know anyone involved > * with building > * > these style NATs that believes that 1 minute is needed - > * there might > * > be someone but I have not seen them post to the list or talk to me. > * > > * > I did not go and discuss this issue with the people that build high > * > end enterprise style NATs at Cisco. > * > > * > This is a tradeoff between running out of ports on the NAT, and > * > running out of bandwidth on the link and processing keep alive > * > transactions on the servers and batter life on mobile clients. Many > * > people have expressed many concerns about having this > * number too low. > * > > * > Cullen * on data from > * > Linksys> > * > > * > > * > On 4/23/06 8:13 PM, "Pyda Srisuresh" wrote: > * > > * > > > * > > > * > > --- Francois Audet wrote: > * > > ... > * > >>>>> 5. Section 4.3: REQ-5: > * > >>>>> "A NAT UDP mapping timer MUST NOT expire in less > * than 1 minute, > * > >>>>> unless REQ-5a applies. > * > >>>>> a) A NAT MAY have UDP mapping timers that have > * much shorter > * > >>>>> timers, but only for specific ports in the > * > >>> well-known port > * > >>>>> range (i.e., ports 0-1023) where the IANA- > * > >>> registered protocol > * > >>>>> is strictly a request/response protocol, such as > * > >>> for example > * > >>>>> DNS over UDP/53. > * > >>>>> b) The value of the NAT UDP mapping timer MAY be > * > >>> configurable. > * > >>>>> c) A default value of 5 minutes for the NAT UDP > * > >>> mapping timer is > * > >>>>> RECOMMENDED." > * > >> > * > >> We have been trying to balance our requirement for timer values > * > >> between what makes sense for "residential-grade" NATs > * versus large > * > >> Enterprise NATs (who happens to be Firewall at the same time). > * > >> > * > >> The larger timers make sense for the residential-grade NATs. Req > * > >> 5-c is useful for residential-grade NATs, because often, the > * > >> manufacturers are very amiable to a recommended default. > * > >> > * > >> What we have found however is that the Enterprise NAT > * vendors where > * > >> quite uncomfortable with long timers. The change from "2 > * minutes" > * > >> to "1 minute" for the minimum was a result of request from > * > >> Enterprise NAT vendors. We are a bit worried that if the > * timer is > * > >> too long, they will simply ignore the requirement. > * > >> Req 5a was introduced to allow for optimizations that are very > * > >> common for large Enterprise NATs. > * > >> > * > >> So, I think we have three options: > * > >> a - Keep the original value (before -05), which was 2 minutes. > * > >> b - Keep the lower limit from the -05 draft, which is 1 > * minute c - > * > >> Use 3 minutes, as per Magnus and Cullen's dialog > * > >> > * > >> Personally, I think that we should revert to what we had > * before -05 > * > >> which is the 2 minutes. It seems to me that we circled > * the argument > * > >> many times now, and that it is the best compromise. > * > >> > * > >> But I'm happy with any of those values. > * > >> > * > > [suresh] I agree, makinng the timers long can be problematic to a > * > > number of NAT vendors, especially those that make low-end NAT > * > > devices with limited resources. > * > > NAT vendors fine tune these timeouts to suit their customer > * > > environmets. If IETF mandates the timeouts to be long, > * the vendors > * > > could run into support problems they had not not > * anticipated as NATs run out of resources quickly. > * > > IETF will not be there to help them with the support issues. > * > > > * > > My vote is to keep the timer at 1 minute. I believe, > * setting this to > * > > more > * > than > * > > 2 minutes could potentially invite unknown support issues. Many > * > > vendor > * > might > * > > in turn choose not to adapt the madanted timeouts. My 2c. > * > > > * > > regards, > * > > suresh > * > > * > * > * > * _______________________________________________ > * Ietf-behave mailing list > * Ietf-behave@xxxxxxxxxxxxxxxxxxx > * https://list.sipfoundry.org/mailman/listinfo/ietf-behave > * > * > ***************************************************************************** > **UPDATE 4/12/06*** > Ubicom is Moving! > Effective May 1st, 2006 our new address and phone number will be: > > Ubicom, Inc. > 510 N. Pastoria Ave > Sunnyvale, CA 94085 > >>>>NEW NUMBER: (408) 789-2200 - Main > (408) 739-2427 - Fax > www.ubicom.com > > ****************************************************************************** > > > From dwing@cisco.com Tue, 25 Apr 2006 23:46:52 -0700 (PDT) From: "Dan Wing" Date: Tue, 25 Apr 2006 23:46:52 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060426005804.95627.qmail@web33301.mail.mud.yahoo.com> Message-ID: <01de01c668fd$33362980$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > I agree, the caveat is reasonable to apply to any registered > protocol with this behavior, not just the ports in the range > of 1-1023. Let me walk through a problem with this line of thinking. You build a product which uses port UDP/1025, let's say. In the year 2009, IANA assigns a new protocol, called JILL, to port UDP/1025. JILL is a strict request/response protocol. It is very popular. JILL causes a lot of load on residential NATs. JILL is an IETF standard. A NAT vendor -- perhaps even a big one -- decides that traffic running on UDP/1025 must be JILL traffic. Because, after all, it's running on the port that IANA assigned to JILL. Thus, that NAT vendor will ship NATs with a default configuration which closes down the NAT binding immediately after receipt of a UDP response packet. Your product, that you wrote in 2006, now ceases to work once that new, BEHAVE-compliant NAT, is installed. How would we prevent this from occurring? -d From magnus.westerlund@ericsson.com Wed, 26 Apr 2006 00:35:05 -0700 (PDT) From: Magnus Westerlund Date: Wed, 26 Apr 2006 00:35:05 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <01de01c668fd$33362980$c2f0200a@amer.cisco.com> Message-ID: <444F22A2.1040009@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Thanks Dan, I understand the dangers with such a behavior. I wished we would have been clearer on RTP port usage and really pointed to the 49152-65535 range. So unless other have strong opinions about this lets drop this idea. Cheers Magnus Dan Wing wrote: I agree, the caveat is reasonable to apply to any registered protocol with this behavior, not just the ports in the range of 1-1023. Let me walk through a problem with this line of thinking. You build a product which uses port UDP/1025, let's say. In the year 2009, IANA assigns a new protocol, called JILL, to port UDP/1025. JILL is a strict request/response protocol. It is very popular. JILL causes a lot of load on residential NATs. JILL is an IETF standard. A NAT vendor -- perhaps even a big one -- decides that traffic running on UDP/1025 must be JILL traffic. Because, after all, it's running on the port that IANA assigned to JILL. Thus, that NAT vendor will ship NATs with a default configuration which closes down the NAT binding immediately after receipt of a UDP response packet. Your product, that you wrote in 2006, now ceases to work once that new, BEHAVE-compliant NAT, is installed. How would we prevent this from occurring? -d -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From srisuresh@yahoo.com Wed, 26 Apr 2006 06:13:09 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 26 Apr 2006 06:13:09 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <444F22A2.1040009@ericsson.com> Message-ID: <20060426131308.86896.qmail@web33309.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain There are two ways, I can think of, to future proofing Req-5A, a) NAT closing down the Binding or state immediately after receipt of a UDP response packet is a bad idea. When Req-5A is interpreted this way, there is a danger that many of the existing request/response protocols would fail to work. There ought to be a minimum timeout even for this subset to make NATs deterministic. I.e., Req-5A should specify minimum timeout for the request/response type registered ports as well - say 1 min. b) Drop Req-5A entirely. By removing this caveat, all UDP applications will be required to have a min. timeout of 2 mins without exception. I prefer option b. regards, suresh --- Magnus Westerlund wrote: > Thanks Dan, > > I understand the dangers with such a behavior. I wished we would have > been clearer on RTP port usage and really pointed to the 49152-65535 > range. So unless other have strong opinions about this lets drop this idea. > > Cheers > > Magnus > > Dan Wing wrote: > >> I agree, the caveat is reasonable to apply to any registered > >> protocol with this behavior, not just the ports in the range > >> of 1-1023. > > > > Let me walk through a problem with this line of thinking. > > > > You build a product which uses port UDP/1025, let's say. > > > > In the year 2009, IANA assigns a new protocol, called JILL, to > > port UDP/1025. JILL is a strict request/response protocol. It > > is very popular. JILL causes a lot of load on residential NATs. > > JILL is an IETF standard. > > > > A NAT vendor -- perhaps even a big one -- decides that traffic > > running on UDP/1025 must be JILL traffic. Because, after all, > > it's running on the port that IANA assigned to JILL. Thus, > > that NAT vendor will ship NATs with a default configuration > > which closes down the NAT binding immediately after receipt > > of a UDP response packet. > > > > Your product, that you wrote in 2006, now ceases to work once > > that new, BEHAVE-compliant NAT, is installed. > > > > > > How would we prevent this from occurring? > > > > -d > > > > > > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx > From ascolnic@checkpoint.com Wed, 26 Apr 2006 23:16:08 -0700 (PDT) From: "Ariel Shaqed (Scolnicov)" Date: Wed, 26 Apr 2006 23:16:08 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060426005102.13084.qmail@web33306.mail.mud.yahoo.com> Message-ID: <200604270919.54442@kmail-ckp> MIME-Version: 1.0 Content-Type: text/plain On Wednesday 26 April 2006 03:51, Pyda Srisuresh wrote: > 2 Minutes works for me. 2 minutes is probably too much, as I explained in my <200604251129.05560@kmail-ckp>. The requirement to keep state for all ports is quite heavy on a large NAT. Additionally, whether we like it or not, firewall traversal requires keepalives. It is often unacceptable for firewalls to keep state for all UDP connections -- to registered ports -- for 2 minutes. > regards, > suresh > > --- Francois Audet wrote: > > I will point out that ALL our drafts had a timeout of 2 minutes. > > > > It's only the -05 draft where we shortened it to 1 minute. > > > > The concensus of the group had always been 2 minutes. And 60 seconds is better than requiring that all UDP connections last for at least 2 minutes. > > > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > Sent: Tuesday, April 25, 2006 07:17 > > > To: Magnus Westerlund > > > Cc: Audet, Francois [SC100:3055:EXCH]; Cullen Jennings; > > > dwing@xxxxxxxxx; Behave > > > Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution > > > comments on draft-ietf-behave-nat-udp-05) [...snipped...] -- Ariel Scolnicov. From philip_matthews@magma.ca Thu, 27 Apr 2006 08:58:45 -0700 (PDT) From: Philip Matthews Date: Thu, 27 Apr 2006 08:58:45 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060426005102.13084.qmail@web33306.mail.mud.yahoo.com> Message-ID: <4D951116-192F-4340-A667-A9FFC0DD51DB@magma.ca> MIME-Version: 1.0 Content-Type: text/plain As a person who is designing a P2P application which I hope will support a large number of simultaneous connections to other peers (about 100 connections), I am very concerned about the keep-alive traffic necessary to maintain these connection, especially if these are sent from a hand-held wireless device. So of course I am very interested in Magnus's proposal to raise the timeout value. I think it would be very helpful from folks who are worried about this change exactly what their concern is. Specifically, in his message, Ariel stated that: 2 minutes is probably too much, as I explained in my <200604251129.05560@kmail-ckp>. The requirement to keep state for all ports is quite heavy on a large NAT. Additionally, whether we like it or not, firewall traversal requires keepalives. It is often unacceptable for firewalls to keep state for all UDP connections -- to registered ports -- for 2 minutes. What exactly is the problem? Is it the memory required to store all the UDP connections? This seems NOT to be a problem for low-end NAT devices (as witnessed by the info from Linksys and Ubicom), so I would be surprised if it was a problem for high-end NAT/Firewall devices. Is it the total number of public UDP ports available? A single IP address can have about 65,000 ports. I would doubt this is a problem for a low-end NAT device which is typically used at home or by a small enterprise (and it doesn't seem to be, according to Ubicom), but perhaps it is for a high-end NAT/Firewall which presumably has more computers and applications behind it? Or is it something else? If, as I suspect, the problem is that a large enterprise with lots of computers would need more than 65,000 ports in certain situations, then perhaps the right solution is to say "get a second public IP address for your NAT", which gives another 65,000 ports? Enterprises that need this many ports active at once, and which can afford a high-end NAT/Firewall, can most likely afford the cost of getting an extra IP address from their provider. - Philip From audet@nortel.com Thu, 27 Apr 2006 09:16:43 -0700 (PDT) From: "Francois Audet" Date: Thu, 27 Apr 2006 09:16:43 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) Message-ID: <1ECE0EB50388174790F9694F77522CCF09142435@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain You should be aware that this means that products that have long timers will not work with SIP or most other VoiP/Multimedia protocols. I'm worried that if we can't find a middleground, what will happen is that there will be two types of firewalls: - The ones that work with SIP and VoIP (BEHAVE-compliant) - The ones that don't (not BEHAVE-compliant) It seems from the list that the rough concensus is a 2 minute timer. > -----Original Message----- > From: Ariel Shaqed (Scolnicov) [mailto:ascolnic@xxxxxxxxxxxxxx] > Sent: Wednesday, April 26, 2006 23:20 > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Cc: Pyda Srisuresh; Audet, Francois [SC100:3055:EXCH]; Magnus > Westerlund > Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution > comments on draft-ietf-behave-nat-udp-05) > > > On Wednesday 26 April 2006 03:51, Pyda Srisuresh wrote: > > 2 Minutes works for me. > > 2 minutes is probably too much, as I explained in my > <200604251129.05560@kmail-ckp>. The requirement to keep > state for all > ports is quite heavy on a large NAT. Additionally, whether > we like it or > not, firewall traversal requires keepalives. It is often > unacceptable for > firewalls to keep state for all UDP connections -- to > registered ports -- > for 2 minutes. > > > regards, > > suresh > > > > --- Francois Audet wrote: > > > I will point out that ALL our drafts had a timeout of 2 minutes. > > > > > > It's only the -05 draft where we shortened it to 1 minute. > > > > > > The concensus of the group had always been 2 minutes. > > And 60 seconds is better than requiring that all UDP > connections last for > at least 2 minutes. > > > > > > > > -----Original Message----- > > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > > Sent: Tuesday, April 25, 2006 07:17 > > > > To: Magnus Westerlund > > > > Cc: Audet, Francois [SC100:3055:EXCH]; Cullen Jennings; > > > > dwing@xxxxxxxxx; Behave > > > > Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution > > > > comments on draft-ietf-behave-nat-udp-05) > > [...snipped...] > > -- > Ariel Scolnicov. > > From philip_matthews@magma.ca Thu, 27 Apr 2006 09:32:32 -0700 (PDT) From: Philip Matthews Date: Thu, 27 Apr 2006 09:32:32 -0700 (PDT) Subject: [Ietf-behave] What to do if a NAT runs out of binding entries? Message-ID: <31566B61-C8A9-495A-B899-C2053C85992C@magma.ca> MIME-Version: 1.0 Content-Type: text/plain The current discussion on the timeout value for a UDP binding connection is closely related to a question I brought up during the last WG meeting in Dallas: What should a NAT do if it receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use? As a P2P application designer, I would like NATs to behave in some deterministic and helpful manner when faced with this situation. My guess is that most NATs today, when faced with this situation, pick some existing binding, discard it, and then used the freed entry for the new packet. Think for a minute how this behavior appears to the P2P application which is sending keep-alives on all its connections at the appropriate interval (every 1 minutes, 2 minutes, or whatever we decide). Its connections seem VERY UNRELIABLE. The application can always send UDP packets, but incoming UDP packets on that connection will get mysteriously dropped if the binding entry for that connection was one that got re-used by the NAT for some other purpose. However, the connection will be re-established (at least temporarily) whenever the applications sends the next keep-alive. My suggestion is that NATs should implement the following behavior: If a NAT receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use, then the UDP packet is dropped and an ICMP reply sent back. This would give deterministic behavior to applications. A P2P application would know that, if it succeeds in establishing the connection, then the connection will stay up if the necessary keep-alives are sent. Any comments? Especially from folks implementing NATs? - Philip - Philip From audet@nortel.com Thu, 27 Apr 2006 10:53:27 -0700 (PDT) From: "Francois Audet" Date: Thu, 27 Apr 2006 10:53:27 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments ondraft-ietf-behave-nat-udp-05) Message-ID: <1ECE0EB50388174790F9694F77522CCF09142670@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I meant "short timers".... Sorry for the confusion. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Audet, Francois [SC100:3055:EXCH] > Sent: Thursday, April 27, 2006 09:17 > To: Ariel Shaqed (Scolnicov); ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution > comments ondraft-ietf-behave-nat-udp-05) > > > You should be aware that this means that products that have > long timers will not work with SIP or most other > VoiP/Multimedia protocols. > > I'm worried that if we can't find a middleground, what will > happen is that there will be two types of firewalls: > - The ones that work with SIP and VoIP (BEHAVE-compliant) > - The ones that don't (not BEHAVE-compliant) > > It seems from the list that the rough concensus is a 2 minute timer. > > > -----Original Message----- > > From: Ariel Shaqed (Scolnicov) [mailto:ascolnic@xxxxxxxxxxxxxx] > > Sent: Wednesday, April 26, 2006 23:20 > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Cc: Pyda Srisuresh; Audet, Francois [SC100:3055:EXCH]; Magnus > > Westerlund > > Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution > > comments on draft-ietf-behave-nat-udp-05) > > > > > > On Wednesday 26 April 2006 03:51, Pyda Srisuresh wrote: > > > 2 Minutes works for me. > > > > 2 minutes is probably too much, as I explained in my > > <200604251129.05560@kmail-ckp>. The requirement to keep > > state for all > > ports is quite heavy on a large NAT. Additionally, whether > > we like it or > > not, firewall traversal requires keepalives. It is often > > unacceptable for > > firewalls to keep state for all UDP connections -- to > > registered ports -- > > for 2 minutes. > > > > > regards, > > > suresh > > > > > > --- Francois Audet wrote: > > > > I will point out that ALL our drafts had a timeout of 2 minutes. > > > > > > > > It's only the -05 draft where we shortened it to 1 minute. > > > > > > > > The concensus of the group had always been 2 minutes. > > > > And 60 seconds is better than requiring that all UDP > > connections last for > > at least 2 minutes. > > > > > > > > > > > -----Original Message----- > > > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > > > Sent: Tuesday, April 25, 2006 07:17 > > > > > To: Magnus Westerlund > > > > > Cc: Audet, Francois [SC100:3055:EXCH]; Cullen Jennings; > > > > > dwing@xxxxxxxxx; Behave > > > > > Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution > > > > > comments on draft-ietf-behave-nat-udp-05) > > > > [...snipped...] > > > > -- > > Ariel Scolnicov. > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From dwing@cisco.com Thu, 27 Apr 2006 15:24:36 -0700 (PDT) From: "Dan Wing" Date: Thu, 27 Apr 2006 15:24:36 -0700 (PDT) Subject: RE: [Ietf-behave] What to do if a NAT runs out of binding entries? In-Reply-To: <31566B61-C8A9-495A-B899-C2053C85992C@magma.ca> Message-ID: <03e101c66a49$5c57e9a0$8b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Philip, Would section 2.3 of draft-srisuresh-behave-nat-icmp-01.txt, or text very similar to it, satisfy your need? The authors, chairs, and a few others have had a long offline discussion about that ICMP message. -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Philip Matthews > Sent: Thursday, April 27, 2006 9:33 AM > To: Behave > Subject: [Ietf-behave] What to do if a NAT runs out of > binding entries? > > The current discussion on the timeout value for a UDP binding > connection > is closely related to a question I brought up during the last > WG meeting > in Dallas: > > What should a NAT do if it receives a UDP packet (on the > private side > of the NAT) with a new source (address,port) combination and > all its > binding entries are in use? > > As a P2P application designer, I would like NATs to behave in some > deterministic and helpful manner when faced with this situation. > > My guess is that most NATs today, when faced with this situation, > pick some existing binding, discard it, and then used the freed entry > for the new packet. > > Think for a minute how this behavior appears to the P2P application > which > is sending keep-alives on all its connections at the appropriate > interval > (every 1 minutes, 2 minutes, or whatever we decide). > Its connections seem VERY UNRELIABLE. > The application can always send UDP packets, but incoming UDP packets > on that connection will get mysteriously dropped if the > binding entry > for > that connection was one that got re-used by the NAT for some other > purpose. > However, the connection will be re-established (at least temporarily) > whenever the applications sends the next keep-alive. > > My suggestion is that NATs should implement the following behavior: > > If a NAT receives a UDP packet (on the private side of the NAT) > with a new source (address,port) combination and all its binding > entries are in use, then the UDP packet is dropped and an ICMP > reply sent back. > > This would give deterministic behavior to applications. A P2P > application > would know that, if it succeeds in establishing the > connection, then the > connection will stay up if the necessary keep-alives are sent. > > Any comments? > Especially from folks implementing NATs? > > - Philip > > > > > - Philip > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From philip_matthews@magma.ca Fri, 28 Apr 2006 05:23:18 -0700 (PDT) From: Philip Matthews Date: Fri, 28 Apr 2006 05:23:18 -0700 (PDT) Subject: Re: [Ietf-behave] What to do if a NAT runs out of binding entries? In-Reply-To: <03e101c66a49$5c57e9a0$8b82200a@amer.cisco.com> Message-ID: <020D070B-DD34-42FB-A611-D0E95C969F3B@magma.ca> MIME-Version: 1.0 Content-Type: text/plain Dan: I think that the section you refer to is part of the answer, but not the entire answer. That section says that _IF_ the NAT decides to reject an outbound session, then it should send an ICMP packet back to the host. But consider a NAT that never rejects a new outbound session but simply discards some older session and re-uses its binding entry. Does section 2.3 of draft-srisuresh-behave-nat-icmp-01 apply, since outbound packets are never rejected? By my reading, the answer is NO. I feel we need an additional requirement that talks explicitly about the situation when all binding entries are in use and a packet arrives that would create a new outbound session. My suggestion for the behavior in this situation is to say: The new session is rejected. An ICMP reply is generated back to the host (as described in draft-srisuresh-behave-nat-icmp-01). Under this suggestion, the only way a NAT terminates an outbound UDP session is when it times out. Note that I am open to other proposals for how to handle this situation, as long as the proposal gives a NAT behavior that an application can work with. - Philip On 27-Apr-06, at 18:24 , Dan Wing wrote: Philip, Would section 2.3 of draft-srisuresh-behave-nat-icmp-01.txt, or text very similar to it, satisfy your need? The authors, chairs, and a few others have had a long offline discussion about that ICMP message. -d -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Philip Matthews Sent: Thursday, April 27, 2006 9:33 AM To: Behave Subject: [Ietf-behave] What to do if a NAT runs out of binding entries? The current discussion on the timeout value for a UDP binding connection is closely related to a question I brought up during the last WG meeting in Dallas: What should a NAT do if it receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use? As a P2P application designer, I would like NATs to behave in some deterministic and helpful manner when faced with this situation. My guess is that most NATs today, when faced with this situation, pick some existing binding, discard it, and then used the freed entry for the new packet. Think for a minute how this behavior appears to the P2P application which is sending keep-alives on all its connections at the appropriate interval (every 1 minutes, 2 minutes, or whatever we decide). Its connections seem VERY UNRELIABLE. The application can always send UDP packets, but incoming UDP packets on that connection will get mysteriously dropped if the binding entry for that connection was one that got re-used by the NAT for some other purpose. However, the connection will be re-established (at least temporarily) whenever the applications sends the next keep-alive. My suggestion is that NATs should implement the following behavior: If a NAT receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use, then the UDP packet is dropped and an ICMP reply sent back. This would give deterministic behavior to applications. A P2P application would know that, if it succeeds in establishing the connection, then the connection will stay up if the necessary keep-alives are sent. Any comments? Especially from folks implementing NATs? - Philip - Philip _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Fri, 28 Apr 2006 09:30:14 -0700 (PDT) From: "Francois Audet" Date: Fri, 28 Apr 2006 09:30:14 -0700 (PDT) Subject: RE: [Ietf-behave] What to do if a NAT runs out of binding entries? Message-ID: <1ECE0EB50388174790F9694F77522CCF09204354@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain This should be in the ICMP draft, right? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Philip Matthews > Sent: Friday, April 28, 2006 05:23 > To: Dan Wing > Cc: 'Behave' > Subject: Re: [Ietf-behave] What to do if a NAT runs out of > binding entries? > > > Dan: > > I think that the section you refer to is part of the answer, > but not the entire answer. > > That section says that _IF_ the NAT decides to reject an outbound > session, > then it should send an ICMP packet back to the host. > > But consider a NAT that never rejects a new outbound session > but simply discards some older session and re-uses its > binding entry. Does section 2.3 of > draft-srisuresh-behave-nat-icmp-01 apply, since outbound > packets are never rejected? By my reading, the answer is NO. > > > I feel we need an additional requirement that talks > explicitly about the situation when all binding entries are > in use and a packet arrives that would create a new outbound session. > > My suggestion for the behavior in this situation is to say: > The new session is rejected. An ICMP reply is generated back > to the host (as described in draft-srisuresh-behave-nat-icmp-01). > Under this suggestion, the only way a NAT terminates an > outbound UDP session is when it times out. > > Note that I am open to other proposals for how to handle this > situation, as long as the proposal gives a NAT behavior that > an application can work with. > > - Philip > > > > On 27-Apr-06, at 18:24 , Dan Wing wrote: > > > Philip, > > > > Would section 2.3 of > draft-srisuresh-behave-nat-icmp-01.txt, or text > > very similar to it, satisfy your need? The authors, > chairs, and a few > > others have had a long offline discussion about that ICMP message. > > > > -d > > > > > >> -----Original Message----- > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf > Of Philip > >> Matthews > >> Sent: Thursday, April 27, 2006 9:33 AM > >> To: Behave > >> Subject: [Ietf-behave] What to do if a NAT runs out of binding > >> entries? > >> > >> The current discussion on the timeout value for a UDP binding > >> connection is closely related to a question I brought up > during the > >> last WG meeting > >> in Dallas: > >> > >> What should a NAT do if it receives a UDP packet (on the > >> private side > >> of the NAT) with a new source (address,port) combination and > >> all its > >> binding entries are in use? > >> > >> As a P2P application designer, I would like NATs to behave in some > >> deterministic and helpful manner when faced with this situation. > >> > >> My guess is that most NATs today, when faced with this situation, > >> pick some existing binding, discard it, and then used the > freed entry > >> for the new packet. > >> > >> Think for a minute how this behavior appears to the P2P > application > >> which is sending keep-alives on all its connections at the > >> appropriate interval > >> (every 1 minutes, 2 minutes, or whatever we decide). > >> Its connections seem VERY UNRELIABLE. > >> The application can always send UDP packets, but incoming > UDP packets > >> on that connection will get mysteriously dropped if the > >> binding entry > >> for > >> that connection was one that got re-used by the NAT for some other > >> purpose. > >> However, the connection will be re-established (at least > temporarily) > >> whenever the applications sends the next keep-alive. > >> > >> My suggestion is that NATs should implement the following behavior: > >> > >> If a NAT receives a UDP packet (on the private side > of the NAT) > >> with a new source (address,port) combination and all > its binding > >> entries are in use, then the UDP packet is dropped and an ICMP > >> reply sent back. > >> > >> This would give deterministic behavior to applications. A P2P > >> application would know that, if it succeeds in establishing the > >> connection, then the > >> connection will stay up if the necessary keep-alives are sent. > >> > >> Any comments? > >> Especially from folks implementing NATs? > >> > >> - Philip > >> > >> > >> > >> > >> - Philip > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From yutaka_takeda@playstation.sony.com Fri, 28 Apr 2006 10:16:14 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Fri, 28 Apr 2006 10:16:14 -0700 (PDT) Subject: Re: [Ietf-behave] What to do if a NAT runs out of binding entries? In-Reply-To: <03e101c66a49$5c57e9a0$8b82200a@amer.cisco.com> Message-ID: <44524DD8.9070908@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain I have the same concern as Philip does. I remember that I mentioned this issue more than a year ago in this WG, but at that time, my concern did not get a consensus. I, as an application developer, still cannot answer to this question: "How many nodes can a local UDP socket receive packets from simultaneously via a NAT?" The ICMP error does not help because an application developer needs to know "how many" ahead of time. Let's say, you are designing an application that runs behind a NAT and monitors status of many remote nodes concurrently. How many nodes can you expect to be able to monitor? 32? 256? 1024? - We really don't know. Even with '32', nothing guarantees you that minimum 32 is supported by all NATs. - Yutaka Philip Matthews wrote: Dan: I think that the section you refer to is part of the answer, but not the entire answer. That section says that _IF_ the NAT decides to reject an outbound session, then it should send an ICMP packet back to the host. But consider a NAT that never rejects a new outbound session but simply discards some older session and re-uses its binding entry. Does section 2.3 of draft-srisuresh-behave-nat-icmp-01 apply, since outbound packets are never rejected? By my reading, the answer is NO. I feel we need an additional requirement that talks explicitly about the situation when all binding entries are in use and a packet arrives that would create a new outbound session. My suggestion for the behavior in this situation is to say: The new session is rejected. An ICMP reply is generated back to the host (as described in draft-srisuresh-behave-nat-icmp-01). Under this suggestion, the only way a NAT terminates an outbound UDP session is when it times out. Note that I am open to other proposals for how to handle this situation, as long as the proposal gives a NAT behavior that an application can work with. - Philip On 27-Apr-06, at 18:24 , Dan Wing wrote: Philip, Would section 2.3 of draft-srisuresh-behave-nat-icmp-01.txt, or text very similar to it, satisfy your need? The authors, chairs, and a few others have had a long offline discussion about that ICMP message. -d -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Philip Matthews Sent: Thursday, April 27, 2006 9:33 AM To: Behave Subject: [Ietf-behave] What to do if a NAT runs out of binding entries? The current discussion on the timeout value for a UDP binding connection is closely related to a question I brought up during the last WG meeting in Dallas: What should a NAT do if it receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use? As a P2P application designer, I would like NATs to behave in some deterministic and helpful manner when faced with this situation. My guess is that most NATs today, when faced with this situation, pick some existing binding, discard it, and then used the freed entry for the new packet. Think for a minute how this behavior appears to the P2P application which is sending keep-alives on all its connections at the appropriate interval (every 1 minutes, 2 minutes, or whatever we decide). Its connections seem VERY UNRELIABLE. The application can always send UDP packets, but incoming UDP packets on that connection will get mysteriously dropped if the binding entry for that connection was one that got re-used by the NAT for some other purpose. However, the connection will be re-established (at least temporarily) whenever the applications sends the next keep-alive. My suggestion is that NATs should implement the following behavior: If a NAT receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use, then the UDP packet is dropped and an ICMP reply sent back. This would give deterministic behavior to applications. A P2P application would know that, if it succeeds in establishing the connection, then the connection will stay up if the necessary keep-alives are sent. Any comments? Especially from folks implementing NATs? - Philip - Philip _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From ssenthil@cisco.com Fri, 28 Apr 2006 10:45:55 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Fri, 28 Apr 2006 10:45:55 -0700 (PDT) Subject: RE: [Ietf-behave] What to do if a NAT runs out of binding entries? Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB01A17CC3@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Is this situation specific to UDP? I think this is common to both UDP and TCP. However, I agree with you that NAT should behave in a deterministic fashion in this scenario and it should not randomly pick a mapping to remove. But I think the requirement should reside in the ICMP draft or in a generic draft that is common to both TCP and UDP. Senthil > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Philip Matthews > Sent: Friday, April 28, 2006 8:23 AM > To: Dan Wing (dwing) > Cc: 'Behave' > Subject: Re: [Ietf-behave] What to do if a NAT runs out of > binding entries? > > Dan: > > I think that the section you refer to is part of the answer, > but not the entire answer. > > That section says that _IF_ the NAT decides to reject an > outbound session, then it should send an ICMP packet back to the host. > > But consider a NAT that never rejects a new outbound session > but simply discards some older session and re-uses its binding entry. > Does section 2.3 of draft-srisuresh-behave-nat-icmp-01 apply, > since outbound packets are never rejected? By my reading, the > answer is NO. > > > I feel we need an additional requirement that talks > explicitly about the situation when all binding entries are > in use and a packet arrives that would create a new outbound session. > > My suggestion for the behavior in this situation is to say: > The new session is rejected. An ICMP reply is generated back > to the host (as described in draft-srisuresh-behave-nat-icmp-01). > Under this suggestion, the only way a NAT terminates an > outbound UDP session is when it times out. > > Note that I am open to other proposals for how to handle this > situation, as long as the proposal gives a NAT behavior that > an application can work with. > > - Philip > > > > On 27-Apr-06, at 18:24 , Dan Wing wrote: > > > Philip, > > > > Would section 2.3 of > draft-srisuresh-behave-nat-icmp-01.txt, or text > > very similar to it, satisfy your need? The authors, > chairs, and a few > > others have had a long offline discussion about that ICMP message. > > > > -d > > > > > >> -----Original Message----- > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf > Of Philip > >> Matthews > >> Sent: Thursday, April 27, 2006 9:33 AM > >> To: Behave > >> Subject: [Ietf-behave] What to do if a NAT runs out of binding > >> entries? > >> > >> The current discussion on the timeout value for a UDP binding > >> connection is closely related to a question I brought up > during the > >> last WG meeting in Dallas: > >> > >> What should a NAT do if it receives a UDP packet (on the > >> private side > >> of the NAT) with a new source (address,port) combination and > >> all its > >> binding entries are in use? > >> > >> As a P2P application designer, I would like NATs to behave in some > >> deterministic and helpful manner when faced with this situation. > >> > >> My guess is that most NATs today, when faced with this situation, > >> pick some existing binding, discard it, and then used the > freed entry > >> for the new packet. > >> > >> Think for a minute how this behavior appears to the P2P > application > >> which is sending keep-alives on all its connections at the > >> appropriate interval (every 1 minutes, 2 minutes, or whatever we > >> decide). > >> Its connections seem VERY UNRELIABLE. > >> The application can always send UDP packets, but incoming > UDP packets > >> on that connection will get mysteriously dropped if the > binding entry > >> for that connection was one that got re-used by the NAT for some > >> other purpose. > >> However, the connection will be re-established (at least > temporarily) > >> whenever the applications sends the next keep-alive. > >> > >> My suggestion is that NATs should implement the following behavior: > >> > >> If a NAT receives a UDP packet (on the private side > of the NAT) > >> with a new source (address,port) combination and all > its binding > >> entries are in use, then the UDP packet is dropped and an ICMP > >> reply sent back. > >> > >> This would give deterministic behavior to applications. A P2P > >> application would know that, if it succeeds in establishing the > >> connection, then the connection will stay up if the necessary > >> keep-alives are sent. > >> > >> Any comments? > >> Especially from folks implementing NATs? > >> > >> - Philip > >> > >> > >> > >> > >> - Philip > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From ssenthil@cisco.com Fri, 28 Apr 2006 10:55:00 -0700 (PDT) From: "Senthil Sivakumar (ssenthil)" Date: Fri, 28 Apr 2006 10:55:00 -0700 (PDT) Subject: RE: [Ietf-behave] What to do if a NAT runs out of binding entries? Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB01A17CD3@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > yutaka_takeda@xxxxxxxxxxxxxxxxxxxx > Sent: Friday, April 28, 2006 1:16 PM > To: Philip Matthews > Cc: 'Behave' > Subject: Re: [Ietf-behave] What to do if a NAT runs out of > binding entries? > > I have the same concern as Philip does. I remember that I > mentioned this issue more than a year ago in this WG, but at > that time, my concern did not get a consensus. > > I, as an application developer, still cannot answer to this question: > > "How many nodes can a local UDP socket receive packets from > simultaneously via a NAT?" > > The ICMP error does not help because an application developer > needs to know "how many" ahead of time. Let's say, you are > designing an application that runs behind a NAT and monitors > status of many remote nodes concurrently. How many nodes can > you expect to be able to monitor? I am not sure how could a NAT tell you this information ahead of time. I could tell you how many maximum sessions (TCP or UDP) that it could support or allowed to support, but like you said it is not guaranteed because there could be other applications that would be sharing the resource space. Secondly, there could be some security concerns with this type of support. Let's say there is no NAT in the path, how many nodes would you be willing to accept connections from? There is no one to tell you this information ahead of time. Shouldn't that be the same number of nodes that you are willing to support even when there is NAT? Senthil > 32? 256? 1024? - We really don't know. Even with '32', > nothing guarantees you that minimum 32 is supported by all NATs. > > > - Yutaka > > > > Philip Matthews wrote: > > Dan: > > > > I think that the section you refer to is part of the > answer, but not > > the entire answer. > > > > That section says that _IF_ the NAT decides to reject an outbound > > session, then it should send an ICMP packet back to the host. > > > > But consider a NAT that never rejects a new outbound session but > > simply discards some older session and re-uses its binding entry. > > Does section 2.3 of draft-srisuresh-behave-nat-icmp-01 apply, since > > outbound packets are never rejected? By my reading, the > answer is NO. > > > > > > I feel we need an additional requirement that talks > explicitly about > > the situation when all binding entries are in use and a > packet arrives > > that would create a new outbound session. > > > > My suggestion for the behavior in this situation is to say: > > The new session is rejected. An ICMP reply is generated back > > to the host (as described in > draft-srisuresh-behave-nat-icmp-01). > > Under this suggestion, the only way a NAT terminates an > outbound UDP > > session is when it times out. > > > > Note that I am open to other proposals for how to handle this > > situation, as long as the proposal gives a NAT behavior that an > > application can work with. > > > > - Philip > > > > > > > > On 27-Apr-06, at 18:24 , Dan Wing wrote: > > > >> Philip, > >> > >> Would section 2.3 of > draft-srisuresh-behave-nat-icmp-01.txt, or text > >> very similar to it, satisfy your need? The authors, chairs, and a > >> few others have had a long offline discussion about that ICMP > >> message. > >> > >> -d > >> > >> > >>> -----Original Message----- > >>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > Behalf Of Philip > >>> Matthews > >>> Sent: Thursday, April 27, 2006 9:33 AM > >>> To: Behave > >>> Subject: [Ietf-behave] What to do if a NAT runs out of binding > >>> entries? > >>> > >>> The current discussion on the timeout value for a UDP binding > >>> connection is closely related to a question I brought up > during the > >>> last WG meeting in Dallas: > >>> > >>> What should a NAT do if it receives a UDP packet (on the > >>> private side > >>> of the NAT) with a new source (address,port) > combination and > >>> all its > >>> binding entries are in use? > >>> > >>> As a P2P application designer, I would like NATs to > behave in some > >>> deterministic and helpful manner when faced with this situation. > >>> > >>> My guess is that most NATs today, when faced with this situation, > >>> pick some existing binding, discard it, and then used the freed > >>> entry for the new packet. > >>> > >>> Think for a minute how this behavior appears to the P2P > application > >>> which is sending keep-alives on all its connections at the > >>> appropriate interval (every 1 minutes, 2 minutes, or whatever we > >>> decide). > >>> Its connections seem VERY UNRELIABLE. > >>> The application can always send UDP packets, but incoming UDP > >>> packets on that connection will get mysteriously dropped if the > >>> binding entry for that connection was one that got re-used by the > >>> NAT for some other purpose. > >>> However, the connection will be re-established (at least > >>> temporarily) whenever the applications sends the next keep-alive. > >>> > >>> My suggestion is that NATs should implement the following > behavior: > >>> > >>> If a NAT receives a UDP packet (on the private side > of the NAT) > >>> with a new source (address,port) combination and all > its binding > >>> entries are in use, then the UDP packet is dropped > and an ICMP > >>> reply sent back. > >>> > >>> This would give deterministic behavior to applications. A P2P > >>> application would know that, if it succeeds in establishing the > >>> connection, then the connection will stay up if the necessary > >>> keep-alives are sent. > >>> > >>> Any comments? > >>> Especially from folks implementing NATs? > >>> > >>> - Philip > >>> > >>> > >>> > >>> > >>> - Philip > >>> _______________________________________________ > >>> Ietf-behave mailing list > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From philip_matthews@magma.ca Fri, 28 Apr 2006 11:35:02 -0700 (PDT) From: Philip Matthews Date: Fri, 28 Apr 2006 11:35:02 -0700 (PDT) Subject: Re: [Ietf-behave] What to do if a NAT runs out of binding entries? In-Reply-To: <03e101c66a49$5c57e9a0$8b82200a@amer.cisco.com> Message-ID: <9BDCE43A-15BA-48EF-AE80-EC05A611871A@magma.ca> MIME-Version: 1.0 Content-Type: text/plain Yutaka: My original thought was the same as yours -- specify some minimum number of bindings that a NAT needs to support. But after thinking about this for a while, I realized the following: a) A number that makes sense for a small home NAT would likely not make sense for a large enterprise NAT b) Whatever the number, the local application has no idea how many other applications are creating bindings in the NAT. c) There are cases where an application can be behind a succession of NATs (e.g., behind both a home NAT and a ISP's NAT). In this case, which NAT does one ask? So I believe the best things that an application can do is to try to obtain as many NAT bindings as it needs. It may get 50 bindings one time, and 30 bindings the next, and 100 bindings the third time. All I am trying to do by my proposal below is to give the application a consistent and deterministic experience once it has obtained whatever bindings it can get. - Philip On 28-Apr-06, at 13:16 , yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: I have the same concern as Philip does. I remember that I mentioned this issue more than a year ago in this WG, but at that time, my concern did not get a consensus. I, as an application developer, still cannot answer to this question: "How many nodes can a local UDP socket receive packets from simultaneously via a NAT?" The ICMP error does not help because an application developer needs to know "how many" ahead of time. Let's say, you are designing an application that runs behind a NAT and monitors status of many remote nodes concurrently. How many nodes can you expect to be able to monitor? 32? 256? 1024? - We really don't know. Even with '32', nothing guarantees you that minimum 32 is supported by all NATs. - Yutaka Philip Matthews wrote: Dan: I think that the section you refer to is part of the answer, but not the entire answer. That section says that _IF_ the NAT decides to reject an outbound session, then it should send an ICMP packet back to the host. But consider a NAT that never rejects a new outbound session but simply discards some older session and re-uses its binding entry. Does section 2.3 of draft-srisuresh-behave-nat-icmp-01 apply, since outbound packets are never rejected? By my reading, the answer is NO. I feel we need an additional requirement that talks explicitly about the situation when all binding entries are in use and a packet arrives that would create a new outbound session. My suggestion for the behavior in this situation is to say: The new session is rejected. An ICMP reply is generated back to the host (as described in draft-srisuresh-behave-nat-icmp-01). Under this suggestion, the only way a NAT terminates an outbound UDP session is when it times out. Note that I am open to other proposals for how to handle this situation, as long as the proposal gives a NAT behavior that an application can work with. - Philip On 27-Apr-06, at 18:24 , Dan Wing wrote: Philip, Would section 2.3 of draft-srisuresh-behave-nat-icmp-01.txt, or text very similar to it, satisfy your need? The authors, chairs, and a few others have had a long offline discussion about that ICMP message. -d -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Philip Matthews Sent: Thursday, April 27, 2006 9:33 AM To: Behave Subject: [Ietf-behave] What to do if a NAT runs out of binding entries? The current discussion on the timeout value for a UDP binding connection is closely related to a question I brought up during the last WG meeting in Dallas: What should a NAT do if it receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use? As a P2P application designer, I would like NATs to behave in some deterministic and helpful manner when faced with this situation. My guess is that most NATs today, when faced with this situation, pick some existing binding, discard it, and then used the freed entry for the new packet. Think for a minute how this behavior appears to the P2P application which is sending keep-alives on all its connections at the appropriate interval (every 1 minutes, 2 minutes, or whatever we decide). Its connections seem VERY UNRELIABLE. The application can always send UDP packets, but incoming UDP packets on that connection will get mysteriously dropped if the binding entry for that connection was one that got re-used by the NAT for some other purpose. However, the connection will be re-established (at least temporarily) whenever the applications sends the next keep-alive. My suggestion is that NATs should implement the following behavior: If a NAT receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use, then the UDP packet is dropped and an ICMP reply sent back. This would give deterministic behavior to applications. A P2P application would know that, if it succeeds in establishing the connection, then the connection will stay up if the necessary keep-alives are sent. Any comments? Especially from folks implementing NATs? - Philip - Philip _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Fri, 28 Apr 2006 12:08:12 -0700 (PDT) From: "Dan Wing" Date: Fri, 28 Apr 2006 12:08:12 -0700 (PDT) Subject: RE: [Ietf-behave] What to do if a NAT runs out of binding entries? In-Reply-To: <44524DD8.9070908@playstation.sony.com> Message-ID: <0e9101c66af7$1b729bc0$8b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > I, as an application developer, still cannot answer to this question: > > "How many nodes can a local UDP socket receive packets from > simultaneously via a NAT?" Let me understand this question a bit better. Are you wanting to know how many UDP bindings the NAT could support, or do you want to know if, on a _single_ UDP binding, the NAT will accept incoming UDP packets from NNNN different source IP addresses on the Internet? From your wording, I think you're asking about the latter? -d From yutaka_takeda@playstation.sony.com Fri, 28 Apr 2006 14:26:03 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Fri, 28 Apr 2006 14:26:03 -0700 (PDT) Subject: Re: [Ietf-behave] What to do if a NAT runs out of binding entries? In-Reply-To: <03e101c66a49$5c57e9a0$8b82200a@amer.cisco.com> Message-ID: <44528865.1090701@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain Thanks Philip and Senthil for your comments. I understand your points and that all make sense to me. To answer to Dan's question first, I am more concerned about the latter: "I want to know if, on a _single_ UDP binding, the NAT will accept incoming UDP packets from NNNN different source transport addresses on the Internet." In this case, if a NAT is NB=I and EF=I, this is not an issue. If a NAT is NB=I and EF=AD or EF=APD, this becomes a concern because a UDP binding in the NAT needs to remember the remote host addresses for external filtering. My concerns is, there may be a dumb NAT that statically limits the number of remote hosts from which a single UDP binding (external port) can receive packets, at a very small number like 8 for example. I agree that an application can not know ahead of time and tell exactly how much resources on a NAT is available for it, especially when the resources are shared by others. But without a minimum requirement, it is also hard for developers to say go ahead and do it. a) A number that makes sense for a small home NAT would likely not make sense for a large enterprise NAT Mostly, yes. What about the minimum number of remote hosts per external port a NAT needs to support? b) Whatever the number, the local application has no idea how many other applications are creating bindings in the NAT. I agree. I am not so concerned about the total number of bindings a NAT can create, assuming that it is likely plenty.. The number of remote nodes from a local UDP socket is my concern. c) There are cases where an application can be behind a succession of NATs (e.g., behind both a home NAT and a ISP's NAT). In this case, which NAT does one ask? I see your point. Regarding the maximum number of remote hosts from a local transport address, whichever has a smaller number is the critical point. So I believe the best things that an application can do is to try to obtain as many NAT bindings as it needs. It may get 50 bindings one time, and 30 bindings the next, and 100 bindings the third time. How can we reserve bindings for remote nodes of which address is unknown? All I am trying to do by my proposal below is to give the application a consistent and deterministic experience once it has obtained whatever bindings it can get. I completely agree. Thanks, - Yutaka - Philip On 28-Apr-06, at 13:16 , yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: I have the same concern as Philip does. I remember that I mentioned this issue more than a year ago in this WG, but at that time, my concern did not get a consensus. I, as an application developer, still cannot answer to this question: "How many nodes can a local UDP socket receive packets from simultaneously via a NAT?" The ICMP error does not help because an application developer needs to know "how many" ahead of time. Let's say, you are designing an application that runs behind a NAT and monitors status of many remote nodes concurrently. How many nodes can you expect to be able to monitor? 32? 256? 1024? - We really don't know. Even with '32', nothing guarantees you that minimum 32 is supported by all NATs. - Yutaka Philip Matthews wrote: Dan: I think that the section you refer to is part of the answer, but not the entire answer. That section says that _IF_ the NAT decides to reject an outbound session, then it should send an ICMP packet back to the host. But consider a NAT that never rejects a new outbound session but simply discards some older session and re-uses its binding entry. Does section 2.3 of draft-srisuresh-behave-nat-icmp-01 apply, since outbound packets are never rejected? By my reading, the answer is NO. I feel we need an additional requirement that talks explicitly about the situation when all binding entries are in use and a packet arrives that would create a new outbound session. My suggestion for the behavior in this situation is to say: The new session is rejected. An ICMP reply is generated back to the host (as described in draft-srisuresh-behave-nat-icmp-01). Under this suggestion, the only way a NAT terminates an outbound UDP session is when it times out. Note that I am open to other proposals for how to handle this situation, as long as the proposal gives a NAT behavior that an application can work with. - Philip On 27-Apr-06, at 18:24 , Dan Wing wrote: Philip, Would section 2.3 of draft-srisuresh-behave-nat-icmp-01.txt, or text very similar to it, satisfy your need? The authors, chairs, and a few others have had a long offline discussion about that ICMP message. -d -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Philip Matthews Sent: Thursday, April 27, 2006 9:33 AM To: Behave Subject: [Ietf-behave] What to do if a NAT runs out of binding entries? The current discussion on the timeout value for a UDP binding connection is closely related to a question I brought up during the last WG meeting in Dallas: What should a NAT do if it receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use? As a P2P application designer, I would like NATs to behave in some deterministic and helpful manner when faced with this situation. My guess is that most NATs today, when faced with this situation, pick some existing binding, discard it, and then used the freed entry for the new packet. Think for a minute how this behavior appears to the P2P application which is sending keep-alives on all its connections at the appropriate interval (every 1 minutes, 2 minutes, or whatever we decide). Its connections seem VERY UNRELIABLE. The application can always send UDP packets, but incoming UDP packets on that connection will get mysteriously dropped if the binding entry for that connection was one that got re-used by the NAT for some other purpose. However, the connection will be re-established (at least temporarily) whenever the applications sends the next keep-alive. My suggestion is that NATs should implement the following behavior: If a NAT receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use, then the UDP packet is dropped and an ICMP reply sent back. This would give deterministic behavior to applications. A P2P application would know that, if it succeeds in establishing the connection, then the connection will stay up if the necessary keep-alives are sent. Any comments? Especially from folks implementing NATs? - Philip - Philip _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From saikat@cs.cornell.edu Sun, 30 Apr 2006 16:29:53 -0700 (PDT) From: Saikat Guha Date: Sun, 30 Apr 2006 16:29:53 -0700 (PDT) Subject: Re: Fwd: [Ietf-behave] What to do if a NAT runs out of binding entries? In-Reply-To: <31566B61-C8A9-495A-B899-C2053C85992C@magma.ca> Message-ID: <1146439790.12070.8.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2006-04-28 at 16:00 -0400, Philip Matthews wrote: > Since you have done some NAT limit testing, > I am wondering if you can tell me how some of > the NATs you have tested behave in the situation > described below? > > Begin forwarded message: > > From: Philip Matthews > > Date: April 27, 2006 12:33:12 EDT (CA) > > > > > > What should a NAT do if it receives a UDP packet (on the > > private side of the NAT) with a new source (address,port) > > combination and all its binding entries are in use? My experience relates to TCP (as you noted Philip), so it may not apply here, but for TCP atleast, the NATs that I could hit the connection cap on, would silently drop the new TCP SYN packet sent after its connection table was full. To clarify, it would not randomly pick an established connection and shoot it, nor send back some TCP RST or ICMP packet to coarse the sender to fail quickly. That said, only 2 (rather old) NATs out of 13 had a connection cap low enough for me to observe this; for the others, I ran out of file descriptors on the sender before I hit the cap. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00095.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00095.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChHTlUv TGludXgpCgppRDhEQlFCRVZVaHRuRmx0cWk2OTEvb1JBa2M0QUp3SW14a0RGNzRiQ1ZxSlA0VmVk dlNPSnZMNERRQ2ZhbEZ4CkFqbjZWc0M2bDRhekhmb3g3Zk9pZDNvPQo9T3c1dQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630136.multipart/signed-- From philip_matthews@magma.ca Mon, 1 May 2006 05:38:58 -0700 (PDT) From: Philip Matthews Date: Mon, 1 May 2006 05:38:58 -0700 (PDT) Subject: Re: [Ietf-behave] What to do if a NAT runs out of binding entries? In-Reply-To: <03e101c66a49$5c57e9a0$8b82200a@amer.cisco.com> Message-ID: <57A3DE7E-B436-463F-9C53-1BDEA756F063@magma.ca> MIME-Version: 1.0 Content-Type: text/plain Yutaka: Please ignore my previous reply. I misunderstood your question. I now believe that you are talking about the number of filtering entries _per_ binding entry, while before I thought you were talking about the total number of either filtering entries or binding entries. I had just assumed that there would be no explicit limit in this area; the limits would simply be on the total number of filtering entries and the total number of binding entries. Can you (or anyone else on the mailing list) think of a good reason to want a limit in this area? Off hand, I cannot. One think that I _could_ see a NAT vendor doing is limiting the number of binding and filtering entries consumed by a single IP address on the private side of the NAT. This I could see being done in a large NAT box (one uses for a large enterprise, or used to NAT an entire ISP's network). This would prevent a single computer from using up a large fraction of the entries. However, I cannot see a good reason to limit the number of filtering entries used by a single binding entry. - Philip On 28-Apr-06, at 17:25 , yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: Thanks Philip and Senthil for your comments. I understand your points and that all make sense to me. To answer to Dan's question first, I am more concerned about the latter: "I want to know if, on a _single_ UDP binding, the NAT will accept incoming UDP packets from NNNN different source transport addresses on the Internet." In this case, if a NAT is NB=I and EF=I, this is not an issue. If a NAT is NB=I and EF=AD or EF=APD, this becomes a concern because a UDP binding in the NAT needs to remember the remote host addresses for external filtering. My concerns is, there may be a dumb NAT that statically limits the number of remote hosts from which a single UDP binding (external port) can receive packets, at a very small number like 8 for example. I agree that an application can not know ahead of time and tell exactly how much resources on a NAT is available for it, especially when the resources are shared by others. But without a minimum requirement, it is also hard for developers to say go ahead and do it. a) A number that makes sense for a small home NAT would likely not make sense for a large enterprise NAT Mostly, yes. What about the minimum number of remote hosts per external port a NAT needs to support? b) Whatever the number, the local application has no idea how many other applications are creating bindings in the NAT. I agree. I am not so concerned about the total number of bindings a NAT can create, assuming that it is likely plenty.. The number of remote nodes from a local UDP socket is my concern. c) There are cases where an application can be behind a succession of NATs (e.g., behind both a home NAT and a ISP's NAT). In this case, which NAT does one ask? I see your point. Regarding the maximum number of remote hosts from a local transport address, whichever has a smaller number is the critical point. So I believe the best things that an application can do is to try to obtain as many NAT bindings as it needs. It may get 50 bindings one time, and 30 bindings the next, and 100 bindings the third time. How can we reserve bindings for remote nodes of which address is unknown? All I am trying to do by my proposal below is to give the application a consistent and deterministic experience once it has obtained whatever bindings it can get. I completely agree. Thanks, - Yutaka - Philip On 28-Apr-06, at 13:16 , yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: I have the same concern as Philip does. I remember that I mentioned this issue more than a year ago in this WG, but at that time, my concern did not get a consensus. I, as an application developer, still cannot answer to this question: "How many nodes can a local UDP socket receive packets from simultaneously via a NAT?" The ICMP error does not help because an application developer needs to know "how many" ahead of time. Let's say, you are designing an application that runs behind a NAT and monitors status of many remote nodes concurrently. How many nodes can you expect to be able to monitor? 32? 256? 1024? - We really don't know. Even with '32', nothing guarantees you that minimum 32 is supported by all NATs. - Yutaka Philip Matthews wrote: Dan: I think that the section you refer to is part of the answer, but not the entire answer. That section says that _IF_ the NAT decides to reject an outbound session, then it should send an ICMP packet back to the host. But consider a NAT that never rejects a new outbound session but simply discards some older session and re-uses its binding entry. Does section 2.3 of draft-srisuresh-behave-nat-icmp-01 apply, since outbound packets are never rejected? By my reading, the answer is NO. I feel we need an additional requirement that talks explicitly about the situation when all binding entries are in use and a packet arrives that would create a new outbound session. My suggestion for the behavior in this situation is to say: The new session is rejected. An ICMP reply is generated back to the host (as described in draft-srisuresh-behave-nat- icmp-01). Under this suggestion, the only way a NAT terminates an outbound UDP session is when it times out. Note that I am open to other proposals for how to handle this situation, as long as the proposal gives a NAT behavior that an application can work with. - Philip On 27-Apr-06, at 18:24 , Dan Wing wrote: Philip, Would section 2.3 of draft-srisuresh-behave-nat-icmp-01.txt, or text very similar to it, satisfy your need? The authors, chairs, and a few others have had a long offline discussion about that ICMP message. -d -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Philip Matthews Sent: Thursday, April 27, 2006 9:33 AM To: Behave Subject: [Ietf-behave] What to do if a NAT runs out of binding entries? The current discussion on the timeout value for a UDP binding connection is closely related to a question I brought up during the last WG meeting in Dallas: What should a NAT do if it receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use? As a P2P application designer, I would like NATs to behave in some deterministic and helpful manner when faced with this situation. My guess is that most NATs today, when faced with this situation, pick some existing binding, discard it, and then used the freed entry for the new packet. Think for a minute how this behavior appears to the P2P application which is sending keep-alives on all its connections at the appropriate interval (every 1 minutes, 2 minutes, or whatever we decide). Its connections seem VERY UNRELIABLE. The application can always send UDP packets, but incoming UDP packets on that connection will get mysteriously dropped if the binding entry for that connection was one that got re-used by the NAT for some other purpose. However, the connection will be re-established (at least temporarily) whenever the applications sends the next keep-alive. My suggestion is that NATs should implement the following behavior: If a NAT receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use, then the UDP packet is dropped and an ICMP reply sent back. This would give deterministic behavior to applications. A P2P application would know that, if it succeeds in establishing the connection, then the connection will stay up if the necessary keep-alives are sent. Any comments? Especially from folks implementing NATs? - Philip - Philip _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From philip_matthews@magma.ca Mon, 1 May 2006 05:58:38 -0700 (PDT) From: Philip Matthews Date: Mon, 1 May 2006 05:58:38 -0700 (PDT) Subject: Re: [Ietf-behave] What to do if a NAT runs out of binding entries? In-Reply-To: <31566B61-C8A9-495A-B899-C2053C85992C@magma.ca> Message-ID: <4DEDB98F-D795-4C18-85F9-2342DFF620C7@magma.ca> MIME-Version: 1.0 Content-Type: text/plain On 30-Apr-06, at 19:29 , Saikat Guha wrote: On Fri, 2006-04-28 at 16:00 -0400, Philip Matthews wrote: Since you have done some NAT limit testing, I am wondering if you can tell me how some of the NATs you have tested behave in the situation described below? Begin forwarded message: From: Philip Matthews Date: April 27, 2006 12:33:12 EDT (CA) What should a NAT do if it receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use? My experience relates to TCP (as you noted Philip), so it may not apply here, but for TCP atleast, the NATs that I could hit the connection cap on, would silently drop the new TCP SYN packet sent after its connection table was full. To clarify, it would not randomly pick an established connection and shoot it, nor send back some TCP RST or ICMP packet to coarse the sender to fail quickly. That said, only 2 (rather old) NATs out of 13 had a connection cap low enough for me to observe this; for the others, I ran out of file descriptors on the sender before I hit the cap. Saikat: Thanks for the info! Even though you have data for only 2 NATs, this is certainly encouraging news for TCP. - Philip From yutaka_takeda@playstation.sony.com Mon, 1 May 2006 12:06:57 -0700 (PDT) From: yutaka_takeda@playstation.sony.com Date: Mon, 1 May 2006 12:06:57 -0700 (PDT) Subject: Re: [Ietf-behave] What to do if a NAT runs out of binding entries? In-Reply-To: <03e101c66a49$5c57e9a0$8b82200a@amer.cisco.com> Message-ID: <44565C4A.7080808@playstation.sony.com> MIME-Version: 1.0 Content-Type: text/plain My comments in-line. Philip Matthews wrote: I now believe that you are talking about the number of filtering entries _per_ binding entry, while before I thought you were talking about the total number of either filtering entries or binding entries. My wording was not clear. Sorry for the confusion. I had just assumed that there would be no explicit limit in this area; the limits would simply be on the total number of filtering entries and the total number of binding entries. I agree. I like the terms 'filtering entries' and 'binding entries'. Can you (or anyone else on the mailing list) think of a good reason to want a limit in this area? Off hand, I cannot. Me either. One think that I _could_ see a NAT vendor doing is limiting the number of binding and filtering entries consumed by a single IP address on the private side of the NAT. This I could see being done in a large NAT box (one uses for a large enterprise, or used to NAT an entire ISP's network). This would prevent a single computer from using up a large fraction of the entries. However, I cannot see a good reason to limit the number of filtering entries used by a single binding entry. Problem here is that what a NAT implementor implements may not be all intensional. The assumption "there is no rational reason to do this, so they would not do this." has been wrong in my experience in NAT space. I have seen many NATs that do weird things. Having said that, I have not actually tested with NATs to know how many 'filtering entries' a restrictive NAT can hold on to. I understand that people in this WG may be wondering if it is worth well addressing this issue because of a lack of evidence. But again, this is definitely a application developer's concern. - Yutaka - Philip On 28-Apr-06, at 17:25 , yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: Thanks Philip and Senthil for your comments. I understand your points and that all make sense to me. To answer to Dan's question first, I am more concerned about the latter: "I want to know if, on a _single_ UDP binding, the NAT will accept incoming UDP packets from NNNN different source transport addresses on the Internet." In this case, if a NAT is NB=I and EF=I, this is not an issue. If a NAT is NB=I and EF=AD or EF=APD, this becomes a concern because a UDP binding in the NAT needs to remember the remote host addresses for external filtering. My concerns is, there may be a dumb NAT that statically limits the number of remote hosts from which a single UDP binding (external port) can receive packets, at a very small number like 8 for example. I agree that an application can not know ahead of time and tell exactly how much resources on a NAT is available for it, especially when the resources are shared by others. But without a minimum requirement, it is also hard for developers to say go ahead and do it. a) A number that makes sense for a small home NAT would likely not make sense for a large enterprise NAT Mostly, yes. What about the minimum number of remote hosts per external port a NAT needs to support? b) Whatever the number, the local application has no idea how many other applications are creating bindings in the NAT. I agree. I am not so concerned about the total number of bindings a NAT can create, assuming that it is likely plenty.. The number of remote nodes from a local UDP socket is my concern. c) There are cases where an application can be behind a succession of NATs (e.g., behind both a home NAT and a ISP's NAT). In this case, which NAT does one ask? I see your point. Regarding the maximum number of remote hosts from a local transport address, whichever has a smaller number is the critical point. So I believe the best things that an application can do is to try to obtain as many NAT bindings as it needs. It may get 50 bindings one time, and 30 bindings the next, and 100 bindings the third time. How can we reserve bindings for remote nodes of which address is unknown? All I am trying to do by my proposal below is to give the application a consistent and deterministic experience once it has obtained whatever bindings it can get. I completely agree. Thanks, - Yutaka - Philip On 28-Apr-06, at 13:16 , yutaka_takeda@xxxxxxxxxxxxxxxxxxxx wrote: I have the same concern as Philip does. I remember that I mentioned this issue more than a year ago in this WG, but at that time, my concern did not get a consensus. I, as an application developer, still cannot answer to this question: "How many nodes can a local UDP socket receive packets from simultaneously via a NAT?" The ICMP error does not help because an application developer needs to know "how many" ahead of time. Let's say, you are designing an application that runs behind a NAT and monitors status of many remote nodes concurrently. How many nodes can you expect to be able to monitor? 32? 256? 1024? - We really don't know. Even with '32', nothing guarantees you that minimum 32 is supported by all NATs. - Yutaka Philip Matthews wrote: Dan: I think that the section you refer to is part of the answer, but not the entire answer. That section says that _IF_ the NAT decides to reject an outbound session, then it should send an ICMP packet back to the host. But consider a NAT that never rejects a new outbound session but simply discards some older session and re-uses its binding entry. Does section 2.3 of draft-srisuresh-behave-nat-icmp-01 apply, since outbound packets are never rejected? By my reading, the answer is NO. I feel we need an additional requirement that talks explicitly about the situation when all binding entries are in use and a packet arrives that would create a new outbound session. My suggestion for the behavior in this situation is to say: The new session is rejected. An ICMP reply is generated back to the host (as described in draft-srisuresh-behave-nat-icmp-01). Under this suggestion, the only way a NAT terminates an outbound UDP session is when it times out. Note that I am open to other proposals for how to handle this situation, as long as the proposal gives a NAT behavior that an application can work with. - Philip On 27-Apr-06, at 18:24 , Dan Wing wrote: Philip, Would section 2.3 of draft-srisuresh-behave-nat-icmp-01.txt, or text very similar to it, satisfy your need? The authors, chairs, and a few others have had a long offline discussion about that ICMP message. -d -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Philip Matthews Sent: Thursday, April 27, 2006 9:33 AM To: Behave Subject: [Ietf-behave] What to do if a NAT runs out of binding entries? The current discussion on the timeout value for a UDP binding connection is closely related to a question I brought up during the last WG meeting in Dallas: What should a NAT do if it receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use? As a P2P application designer, I would like NATs to behave in some deterministic and helpful manner when faced with this situation. My guess is that most NATs today, when faced with this situation, pick some existing binding, discard it, and then used the freed entry for the new packet. Think for a minute how this behavior appears to the P2P application which is sending keep-alives on all its connections at the appropriate interval (every 1 minutes, 2 minutes, or whatever we decide). Its connections seem VERY UNRELIABLE. The application can always send UDP packets, but incoming UDP packets on that connection will get mysteriously dropped if the binding entry for that connection was one that got re-used by the NAT for some other purpose. However, the connection will be re-established (at least temporarily) whenever the applications sends the next keep-alive. My suggestion is that NATs should implement the following behavior: If a NAT receives a UDP packet (on the private side of the NAT) with a new source (address,port) combination and all its binding entries are in use, then the UDP packet is dropped and an ICMP reply sent back. This would give deterministic behavior to applications. A P2P application would know that, if it succeeds in establishing the connection, then the connection will stay up if the necessary keep-alives are sent. Any comments? Especially from folks implementing NATs? - Philip - Philip _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From magnus.westerlund@ericsson.com Mon, 1 May 2006 13:56:06 -0700 (PDT) From: Magnus Westerlund Date: Mon, 1 May 2006 13:56:06 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09009889@zrc2hxm0.corp.nortel.com> Message-ID: <445675E3.5090503@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Francois Audet wrote: I will point out that ALL our drafts had a timeout of 2 minutes. It's only the -05 draft where we shortened it to 1 minute. The concensus of the group had always been 2 minutes. Reviewing the discussion that resulted from me raising this issue results in me seeing rough consensus for having the value at 2 minutes. I think that resolves all the topics I raised in relation to my AD comments on the UDP draft. I am not yet certain if the new topic raised about consistent handling when the NAT has run out of resources is intended to affect the NAT UDP draft or not. Please clarify that! I do like to be have an updated draft as soon as possible and going forward in the process towards publication. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From dwing@cisco.com Mon, 1 May 2006 14:37:43 -0700 (PDT) From: "Dan Wing" Date: Mon, 1 May 2006 14:37:43 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <445675E3.5090503@ericsson.com> Message-ID: <037301c66d67$74309d80$d960150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Magnus Westerlund wrote: > Francois Audet wrote: > > I will point out that ALL our drafts had a timeout of 2 minutes. > > > > It's only the -05 draft where we shortened it to 1 minute. > > > > The concensus of the group had always been 2 minutes. > > > > Reviewing the discussion that resulted from me raising this issue > results in me seeing rough consensus for having the value at > 2 minutes. > > I think that resolves all the topics I raised in relation to my AD > comments on the UDP draft. > > I am not yet certain if the new topic raised about consistent > handling when the NAT has run out of resources is intended to > affect the NAT UDP draft or not. Please clarify that! Consensus seems to be that it would belong in the ICMP draft. > I do like to be have an updated draft as soon as possible and going > forward in the process towards publication. -d From srisuresh@yahoo.com Mon, 1 May 2006 15:05:24 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 1 May 2006 15:05:24 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <037301c66d67$74309d80$d960150a@amer.cisco.com> Message-ID: <20060501220524.15368.qmail@web33311.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Magnus and Dan, I had suggested that Reqs 12, 13 and 14 be dropped from the UDP draft as they are ICMP related and not unique to UDP. Any reason why these should remain in the UDP draft? Thanks. regards, suresh --- Dan Wing wrote: > Magnus Westerlund wrote: > > > Francois Audet wrote: > > > I will point out that ALL our drafts had a timeout of 2 minutes. > > > > > > It's only the -05 draft where we shortened it to 1 minute. > > > > > > The concensus of the group had always been 2 minutes. > > > > > > > Reviewing the discussion that resulted from me raising this issue > > results in me seeing rough consensus for having the value at > > 2 minutes. > > > > I think that resolves all the topics I raised in relation to my AD > > comments on the UDP draft. > > > > I am not yet certain if the new topic raised about consistent > > handling when the NAT has run out of resources is intended to > > affect the NAT UDP draft or not. Please clarify that! > > Consensus seems to be that it would belong in the ICMP draft. > > > I do like to be have an updated draft as soon as possible and going > > forward in the process towards publication. > > -d > From dwing@cisco.com Mon, 1 May 2006 15:18:11 -0700 (PDT) From: "Dan Wing" Date: Mon, 1 May 2006 15:18:11 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060501220524.15368.qmail@web33311.mail.mud.yahoo.com> Message-ID: <043101c66d6d$21858860$d960150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Magnus and Dan, > > I had suggested that Reqs 12, 13 and 14 be dropped from the > UDP draft as they are ICMP related and not unique to UDP. > Any reason why these should remain in the UDP draft? Thanks. I agree REQ-12 (receiving ICMP should not terminate an existing NAT binding) should be removed from the UDP draft and put into the ICMP draft. REQ-13 (fragment outgoing packets) is restating a router requirement. I agree it isn't unique to UDP. However, it seems useful to have in the UDP document because it's necessary for Path MTU Discovery, and many implementors only consider Path MTU Discovery with TCP (and not UDP). With things like video, UDP packets will need to be as large as possible and it's important that NATs understand the need to implement this function. If this requirement is generalized to cover all IP protocols (not just UDP) and appears in the ICMP draft, though, that is a reasonable separation of scope for me. I agree REQ-14 (support receiving out of order IP fragments) isn't unique to UDP, but we don't have an "all protocols" document in our charter. This requirement goes hand-in-hand with REQ-13 and with endpoints that don't perform Path MTU Discovery for UDP flows. -d > > regards, > suresh > > --- Dan Wing wrote: > > > Magnus Westerlund wrote: > > > > > Francois Audet wrote: > > > > I will point out that ALL our drafts had a timeout of 2 minutes. > > > > > > > > It's only the -05 draft where we shortened it to 1 minute. > > > > > > > > The concensus of the group had always been 2 minutes. > > > > > > > > > > Reviewing the discussion that resulted from me raising this issue > > > results in me seeing rough consensus for having the value at > > > 2 minutes. > > > > > > I think that resolves all the topics I raised in relation > to my AD > > > comments on the UDP draft. > > > > > > I am not yet certain if the new topic raised about consistent > > > handling when the NAT has run out of resources is intended to > > > affect the NAT UDP draft or not. Please clarify that! > > > > Consensus seems to be that it would belong in the ICMP draft. > > > > > I do like to be have an updated draft as soon as possible > and going > > > forward in the process towards publication. > > > > -d > > From saikat@cs.cornell.edu Mon, 1 May 2006 15:23:52 -0700 (PDT) From: Saikat Guha Date: Mon, 1 May 2006 15:23:52 -0700 (PDT) Subject: [Ietf-behave] TCP equivalent of UDP Req-5 (Was: RE: Req-5) In-Reply-To: <037301c66d67$74309d80$d960150a@amer.cisco.com> Message-ID: <1146522231.14214.36.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2006-05-01 at 14:37 -0700, Dan Wing wrote: > Magnus Westerlund wrote: > > > Reviewing the discussion that resulted from me raising this issue > > results in me seeing rough consensus for having the value at > > 2 minutes. Now that that's settles, I'd like some feedback regarding the two main issues identified with the TCP draft in the last meeting. The one this thread is about is REQ-5 -- the idle-timer for TCP sessions (much like UDP Req-5). Currently in draft-ietf-behave-tcp-00: REQ-5: If a NAT cannot determine whether the endpoints of a TCP session are active, it MAY abandon the session if it has been idle for some time. A default value of 2 hours for the established session timer is RECOMMENDED. A default value of 4 minutes for the transitory session timer is RECOMMENDED. a) The value of the NAT TCP session timers MAY be configurable. It was decided in the last meeting that a minimum must be set for application developers to rely on. Proposal: - Strengthen the RECOMMENDED to MUST. - Exclude the TIME_WAIT state from the definition of 'transitory session timer' Things to note: - This does NOT affect "normal" TCP connections that close the connection with a normal FIN exchange. Normal TCP's do go through TIME_WAIT state, which needs to be excluded so that closed connections are not held open for 4 minutes. - This mainly pertains to endpoints that have crashed, or are intentionally holding the connection idle in the established state. Crashes are rare. So the timer values here shouldn't cause undue stress on the connection-table. - The numbers (4min, and 2hours) are from RFC 1122. I believe, there is consensus to use the RFC numbers (from IETF'64). - There is a loop-hole that allows for NATs that can "determine whether the endpoints of a TCP session [is] active" e.g. by themselves sourcing a TCP keep-alive packet to use more conservative timers. However, there is NO need to require NATs to do this ... they are free to if they choose, especially if under attack, and the loop-hole protects them from falling out of behave compliance if they need to take such drastic actions. - Finally, dropping the TIME_WAIT from the 4-minute mandatory stall is not as dubious as it sounds. While its presence in TCP is a feature, and not a bug, it intent it to protect against stray packets that should be discarded by the endhost stack, as opposed to serve as a window for a packet to be accepted within. Closing the hole in TIME-WAIT doesn't go against this. Question to the WG: - Is the following requirement (and suitably edited preceding paragraph) acceptable: The transitory session timer is [...for states SYN_SENT, SYN_RCVD, CLOSING, and LAST_ACK...] but not the TIME_WAIT state. REQ-5: If a NAT cannot determine whether the endpoints of a TCP session are active, it MAY abandon the session if it has been idle for some time. The value for the established session timer MUST NOT be less than 2 hours. The value for the transitory session timer MUST NOT be less than 4 minutes. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00096.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00096.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFVm9wM25GbHRxaTY5MS9vUkFzcndBSnNGKzhFZVVLT1kycGtISWtZ RngrRXltWkVJWWdDZlpZS3UKbU1pZmFrbUF1bG5WdTlOc0dTL1VNRGs9Cj0yNmRqCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From dwing@cisco.com Mon, 1 May 2006 15:51:38 -0700 (PDT) From: "Dan Wing" Date: Mon, 1 May 2006 15:51:38 -0700 (PDT) Subject: [Ietf-behave] BEHAVE minutes corrections Message-ID: <048501c66d71$cdbe2340$d960150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain On April 27, Philip Matthews emailed some corrections to the BEHAVE minutes. The updated minutes are now posted at http://www3.ietf.org/proceedings/06mar/minutes/behave.txt. The changes were: * minutes clarify that Dan is chairing BEHAVE, and Cullen is listed as co-chair to help with transitioning chairs. * 'hum' vote for FTP ALG was to have them *on* by default. * In the earlier minutes, a comment abou the MAGMA draft was incorrectly attributed to Philip. This attribution has been corrected. -d From dwing@cisco.com Mon, 1 May 2006 16:20:29 -0700 (PDT) From: "Dan Wing" Date: Mon, 1 May 2006 16:20:29 -0700 (PDT) Subject: [Ietf-behave] FW: IETF Meeting Survey Message-ID: <04bc01c66d75$d1fd08a0$d960150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Ray Pelletier, IETF Admininstrative Director, asked that WG chairs send a note about the IETF meeting survey. This survey has been announced on the main IETF list (ietf@xxxxxxxx). If you're interested in taking the survey you can find it at: http://www.surveymonkey.com/s.asp?u=649182049947 -d From audet@nortel.com Mon, 1 May 2006 18:18:09 -0700 (PDT) From: "Francois Audet" Date: Mon, 1 May 2006 18:18:09 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) Message-ID: <1ECE0EB50388174790F9694F77522CCF09332991@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I'll make the changes. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Monday, May 01, 2006 15:18 > To: 'Pyda Srisuresh'; 'Magnus Westerlund' > Cc: 'Cullen Jennings'; 'Behave'; Audet, Francois [SC100:3055:EXCH] > Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution > comments on draft-ietf-behave-nat-udp-05) > > > > Magnus and Dan, > > > > I had suggested that Reqs 12, 13 and 14 be dropped from the > > UDP draft as they are ICMP related and not unique to UDP. > > Any reason why these should remain in the UDP draft? Thanks. > > I agree REQ-12 (receiving ICMP should not terminate an > existing NAT binding) should be removed from the UDP draft > and put into the ICMP draft. > > REQ-13 (fragment outgoing packets) is restating a router > requirement. I agree it isn't unique to UDP. However, it > seems useful to have in the UDP document because it's > necessary for Path MTU Discovery, and many implementors only > consider Path MTU Discovery with TCP (and not UDP). With > things like video, UDP packets will need to be as large as > possible and it's important that NATs understand the need to > implement this function. If this requirement is generalized > to cover all IP protocols (not just UDP) and appears in the > ICMP draft, though, that is a reasonable separation of scope for me. > > I agree REQ-14 (support receiving out of order IP fragments) > isn't unique to UDP, but we don't have an "all protocols" > document in our charter. This requirement goes hand-in-hand > with REQ-13 and with endpoints that don't perform Path MTU > Discovery for UDP flows. > > -d > > > > > regards, > > suresh > > > > --- Dan Wing wrote: > > > > > Magnus Westerlund wrote: > > > > > > > Francois Audet wrote: > > > > > I will point out that ALL our drafts had a timeout of > 2 minutes. > > > > > > > > > > It's only the -05 draft where we shortened it to 1 minute. > > > > > > > > > > The concensus of the group had always been 2 minutes. > > > > > > > > > > > > > Reviewing the discussion that resulted from me raising > this issue > > > > results in me seeing rough consensus for having the value at > > > > 2 minutes. > > > > > > > > I think that resolves all the topics I raised in relation > > to my AD > > > > comments on the UDP draft. > > > > > > > > I am not yet certain if the new topic raised about consistent > > > > handling when the NAT has run out of resources is intended to > > > > affect the NAT UDP draft or not. Please clarify that! > > > > > > Consensus seems to be that it would belong in the ICMP draft. > > > > > > > I do like to be have an updated draft as soon as possible > > and going > > > > forward in the process towards publication. > > > > > > -d > > > > > From srisuresh@yahoo.com Mon, 1 May 2006 18:31:10 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 1 May 2006 18:31:10 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <043101c66d6d$21858860$d960150a@amer.cisco.com> Message-ID: <20060502013049.96705.qmail@web33305.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Dan, We still have a couple of unanswered questions on Req-5A. Req-5A leaves no minimal timeout for request-response protocols. One of the comments from the list was that there are several protocols that do not need large state time in NAT (ex: Radius), not just ports < 1024. There was a suggestion to change the wording to include larger port set in that follow the request-response protocol pattern in Req-5A. Also, I made a comment that Req-5A ought to have a deterministic minimal timeout (say, 1 min.) (or) Req-5a should be removed. I am OK with either of the options, But, we need to make a choice instead of leaving the text as is. The text as is leaves it to the NAT vendors to make guesses on the timeout for Req-5a. I believe, we need to come to a closure on this Please find my responses to your comments on Req 12, 13, and 14 below inline. regards, suresh --- Dan Wing wrote: > > Magnus and Dan, > > > > I had suggested that Reqs 12, 13 and 14 be dropped from the > > UDP draft as they are ICMP related and not unique to UDP. > > Any reason why these should remain in the UDP draft? Thanks. > > I agree REQ-12 (receiving ICMP should not terminate an existing > NAT binding) should be removed from the UDP draft and put into the > ICMP draft. > [suresh] OK. > REQ-13 (fragment outgoing packets) is restating a router requirement. > I agree it isn't unique to UDP. However, it seems useful to have in > the UDP document because it's necessary for Path MTU Discovery, and > many implementors only consider Path MTU Discovery with TCP (and not > UDP). With things like video, UDP packets will need to be as large as > possible and it's important that NATs understand the need to implement > this function. If this requirement is generalized to cover all IP > protocols (not just UDP) and appears in the ICMP draft, though, that > is a reasonable separation of scope for me. > [suresh] Dan - I disagree. This is an ICMP error generation requirement when DF bit is set in the IP packets, not one of UDP applications being allowed to set DF bit. Further, this is also not the draft discussing UDP application choices. I do not see the necessity of include this in the UDP behave draft, considering that the requirement in ICMP fully covers this. > I agree REQ-14 (support receiving out of order IP fragments) isn't > unique to UDP, but we don't have an "all protocols" document in our > charter. This requirement goes hand-in-hand with REQ-13 and with > endpoints that don't perform Path MTU Discovery for UDP flows. > [suresh] I agree with your above explanation and dont have a problem with including this requirement. However, the explanation above refers to Req-15, Not Req-14. Req-14 states that NAT MUST support fragmentation of packets larger than link MTU. regards, suresh > -d > > > > > regards, > > suresh > > > > --- Dan Wing wrote: > > > > > Magnus Westerlund wrote: > > > > > > > Francois Audet wrote: > > > > > I will point out that ALL our drafts had a timeout of 2 minutes. > > > > > > > > > > It's only the -05 draft where we shortened it to 1 minute. > > > > > > > > > > The concensus of the group had always been 2 minutes. > > > > > > > > > > > > > Reviewing the discussion that resulted from me raising this issue > > > > results in me seeing rough consensus for having the value at > > > > 2 minutes. > > > > > > > > I think that resolves all the topics I raised in relation > > to my AD > > > > comments on the UDP draft. > > > > > > > > I am not yet certain if the new topic raised about consistent > > > > handling when the NAT has run out of resources is intended to > > > > affect the NAT UDP draft or not. Please clarify that! > > > > > > Consensus seems to be that it would belong in the ICMP draft. > > > > > > > I do like to be have an updated draft as soon as possible > > and going > > > > forward in the process towards publication. > > > > > > -d > > > > From fluffy@cisco.com Mon, 1 May 2006 20:07:45 -0700 (PDT) From: Cullen Jennings Date: Mon, 1 May 2006 20:07:45 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060502013049.96705.qmail@web33305.mail.mud.yahoo.com> Message-ID: <17E35B83-A33C-4825-8CE1-E309EE6B3F01@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On May 1, 2006, at 6:30 PM, Pyda Srisuresh wrote: --- Dan Wing wrote: Magnus and Dan, I had suggested that Reqs 12, 13 and 14 be dropped from the UDP draft as they are ICMP related and not unique to UDP. Any reason why these should remain in the UDP draft? Thanks. I agree REQ-12 (receiving ICMP should not terminate an existing NAT binding) should be removed from the UDP draft and put into the ICMP draft. [suresh] OK. I don't agree. This is about what happens to a UDP binding under various conditions network conditions. The WG had been in agreement on this for a very long time - probably years if we go back and look. It's not like their is new information here that would suddenly cause the WG to go "wow, i did not realize what was going on here" Cullen (as always, only as an individual contributor) From dwing@cisco.com Mon, 1 May 2006 20:24:28 -0700 (PDT) From: "Dan Wing" Date: Mon, 1 May 2006 20:24:28 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060502013049.96705.qmail@web33305.mail.mud.yahoo.com> Message-ID: <059401c66d97$eb6c7240$d960150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > We still have a couple of unanswered questions on Req-5A. > Req-5A leaves no minimal timeout for request-response protocols. > One of the comments from the list was that there are several > protocols that do not need large state time in NAT (ex: Radius), > not just ports < 1024. > > There was a suggestion to change the wording to include > larger port set in that follow the request-response protocol > pattern in Req-5A. In http://list.sipfoundry.org/archive/ietf-behave/msg01250.html, you said there is a danger of breaking protocols if a NAT binding is destroyed immediately after a request/response. Let's take the case of DNS over UDP/53. Why require a NAT to keep that binding open for 60 seconds? Specifically, what breaks if the binding is closed immediately after the response. Same question for DAYTIME and ECHO, which are the only two UDP request/response protocols that come to my mind at the moment. > Also, I made a comment that Req-5A ought to have a > deterministic minimal timeout (say, 1 min.) (or) > Req-5a should be removed. > > I am OK with either of the options, But, we need to > make a choice instead of leaving the text as is. The text as > is leaves it to the NAT vendors to make guesses on the timeout > for Req-5a. I believe, we need to come to a closure on this > > Please find my responses to your comments on Req 12, 13, and > 14 below inline. ... > > REQ-13 (fragment outgoing packets) is restating a router > > requirement. > > I agree it isn't unique to UDP. However, it seems useful to have in > > the UDP document because it's necessary for Path MTU Discovery, and > > many implementors only consider Path MTU Discovery with TCP (and not > > UDP). With things like video, UDP packets will need to be > > as large as > > possible and it's important that NATs understand the need > > to implement > > this function. If this requirement is generalized to cover all IP > > protocols (not just UDP) and appears in the ICMP draft, though, that > > is a reasonable separation of scope for me. > > [suresh] Dan - I disagree. This is an ICMP error generation > requirement when DF > bit is set in the IP packets, not one of UDP applications > being allowed to set > DF bit. Further, this is also not the draft discussing UDP > application choices. > I do not see the necessity of include this in the UDP behave draft, > considering that the requirement in ICMP fully covers this. As I said, if the ICMP draft generalizes this to all IP protocols, I'm fine moving it to the ICMP draft. I believe the ICMP draft does generalize this to all IP protocols. > > I agree REQ-14 (support receiving out of order IP fragments) isn't > > unique to UDP, but we don't have an "all protocols" document in our > > charter. This requirement goes hand-in-hand with REQ-13 and with > > endpoints that don't perform Path MTU Discovery for UDP flows. > > > > [suresh] I agree with your above explanation and dont have a > problem with including this requirement. However, the explanation > above refers to Req-15, Not Req-14. Req-14 states that NAT MUST > support fragmentation of packets larger than link MTU. Sorry, I was reading http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-nat-udp-0 6.txt which renumbered some of the latter requirements. I'm fine moving the requirement regarding fragmentation of packets larger than link MTU (with requirements for handling of packets with DF=0 and DF=1) to the ICMP document. -d > regards, > suresh > > > > -d > > > > > > > > regards, > > > suresh > > > > > > --- Dan Wing wrote: > > > > > > > Magnus Westerlund wrote: > > > > > > > > > Francois Audet wrote: > > > > > > I will point out that ALL our drafts had a timeout > of 2 minutes. > > > > > > > > > > > > It's only the -05 draft where we shortened it to 1 minute. > > > > > > > > > > > > The concensus of the group had always been 2 minutes. > > > > > > > > > > > > > > > > Reviewing the discussion that resulted from me > raising this issue > > > > > results in me seeing rough consensus for having the value at > > > > > 2 minutes. > > > > > > > > > > I think that resolves all the topics I raised in relation > > > to my AD > > > > > comments on the UDP draft. > > > > > > > > > > I am not yet certain if the new topic raised about consistent > > > > > handling when the NAT has run out of resources is intended to > > > > > affect the NAT UDP draft or not. Please clarify that! > > > > > > > > Consensus seems to be that it would belong in the ICMP draft. > > > > > > > > > I do like to be have an updated draft as soon as possible > > > and going > > > > > forward in the process towards publication. > > > > > > > > -d > > > > > > From dwing@cisco.com Mon, 1 May 2006 20:25:36 -0700 (PDT) From: "Dan Wing" Date: Mon, 1 May 2006 20:25:36 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <17E35B83-A33C-4825-8CE1-E309EE6B3F01@cisco.com> Message-ID: <059501c66d98$13849370$d960150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > >>> Magnus and Dan, > >>> > >>> I had suggested that Reqs 12, 13 and 14 be dropped from the > >>> UDP draft as they are ICMP related and not unique to UDP. > >>> Any reason why these should remain in the UDP draft? Thanks. > >> > >> I agree REQ-12 (receiving ICMP should not terminate an existing > >> NAT binding) should be removed from the UDP draft and put into the > >> ICMP draft. > >> > > [suresh] OK. > > I don't agree. This is about what happens to a UDP binding under > various conditions network conditions. The WG had been in agreement > on this for a very long time - probably years if we go back > and look. > It's not like their is new information here that would > suddenly cause > the WG to go "wow, i did not realize what was going on here" > > Cullen (as always, only as an individual contributor) So is there a case where we _want_ an ICMP error, of any sort, to destroy a UDP, TCP, IPSec SPI, or any other thing we might consider a 'NAT Binding'? -d From john.loughney@nokia.com Tue, 2 May 2006 04:28:05 -0700 (PDT) From: Date: Tue, 2 May 2006 04:28:05 -0700 (PDT) Subject: [Ietf-behave] Request for a review of the "NAT/Firewall NSIS Signaling Layer Protocol (NSLP) " In-Reply-To: <44567016.9040408@gmx.net> Message-ID: <615BD9B54CB01B41838C323DB9E91AAB40768F@esebe100.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain Hi all, Currently, the NSIS working group is finalizing the "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)" for signaling middleboxes. The current document can be found here: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt NSIS is working on a path-coupled signaling protocol, to signal nodes along the data patch. As both NAT and Firewalls are along the data path, NSIS signaling is developing a protocol for allow end nodes to signal these boxes. As both BEHAVE and MIDCOM have been working on related issues, I'd like to encourage people to read the document and send comments and questions to the mailing list - nsis@xxxxxxxxx As long as your subject lines are clearly marked, I'll enable posting rights so that you don't have to join the NSIS mailing list. Additionally, please try not to cross-post discussion on the other mailing lists; unless the BEHAVE & MIDCOM chairs feel that cross-posting would be beneficial. thanks, John From philip_matthews@magma.ca Tue, 2 May 2006 06:31:19 -0700 (PDT) From: Philip Matthews Date: Tue, 2 May 2006 06:31:19 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <037301c66d67$74309d80$d960150a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 1-May-06, at 17:37 , Dan Wing wrote: Magnus Westerlund wrote: I am not yet certain if the new topic raised about consistent handling when the NAT has run out of resources is intended to affect the NAT UDP draft or not. Please clarify that! Consensus seems to be that it would belong in the ICMP draft. I raised the issue of: How a NAT should behave if it runs out of binding entries or filtering entries for either UDP or TCP and a packet arrives that requires a new entry. Yukata Takeda raised a related issue of whether there should be a limit on the number of filtering entries per binding entry, and how a NAT should behave in this case. I think these are what Magnus was referring to -- hence this reply. I initially suggested that the NAT should drop the packet and send an ICMP reply. However, it was suggested to me privately that perhaps the NAT should NOT send an ICMP, but just silently discard the packet. This behavior would be similar to the behavior of routers when packets are dropped due to link or other congestion -- most routers do not send an ICMP reply in this case. I personally find this argument persuasive, but others may disagree. Given this twist, it is not clear to me that a discussion of this situation belongs in the ICMP draft. I personally feel that the best thing to do would be to add a requirement dealing with this situation to both the UDP and TCP documents. However, if there is an unwillingness to add this to the UDP document (which, after all, passed WGLC some time ago), then I feel the next best think would be to have a separate draft discussing this issue. I would be willing to write such a draft. If we decided that an ICMP reply should be sent in this situation, then a reference could be made to the ICMP document. - Philip From srisuresh@yahoo.com Tue, 2 May 2006 06:41:21 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 2 May 2006 06:41:21 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <059401c66d97$eb6c7240$d960150a@amer.cisco.com> Message-ID: <20060502134121.19527.qmail@web33312.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dan Wing wrote: > > We still have a couple of unanswered questions on Req-5A. > > Req-5A leaves no minimal timeout for request-response protocols. > > One of the comments from the list was that there are several > > protocols that do not need large state time in NAT (ex: Radius), > > not just ports < 1024. > > > > There was a suggestion to change the wording to include > > larger port set in that follow the request-response protocol > > pattern in Req-5A. > > In http://list.sipfoundry.org/archive/ietf-behave/msg01250.html, > you said there is a danger of breaking protocols if a NAT > binding is destroyed immediately after a request/response. > > Let's take the case of DNS over UDP/53. Why require a > NAT to keep that binding open for 60 seconds? Specifically, > what breaks if the binding is closed immediately after the > response. Same question for DAYTIME and ECHO, which are the > only two UDP request/response protocols that come to my mind > at the moment. [suresh] Consider the DNS/UDP scenario. Say, a DNS request was forwarded by NAT but the response was delayed because of load on the system or delays in the network on the way on or on the way out. It is not uncommon to have network delays effect the application response times. In any case, It took a while (say, a few seconds) for the response to reach the NAT device. What is the idle timeout the NAT should allow for the DNS session? If it is extremely short (say a second), NAT woudl simply drop the response on the floor. Clearly, NAT couldnt keep the session timeout to be forever. I am not religious about 60 seconds. If you prefer this to be 30 secs., that would be fine as well. But, there needs to be a predictable timeout one could set, to account for network delays/failures and end node delays. > > > Also, I made a comment that Req-5A ought to have a > > deterministic minimal timeout (say, 1 min.) (or) > > Req-5a should be removed. > > > > I am OK with either of the options, But, we need to > > make a choice instead of leaving the text as is. The text as > > is leaves it to the NAT vendors to make guesses on the timeout > > for Req-5a. I believe, we need to come to a closure on this > > > > Please find my responses to your comments on Req 12, 13, and > > 14 below inline. > > ... > > > REQ-13 (fragment outgoing packets) is restating a router > > > requirement. > > > I agree it isn't unique to UDP. However, it seems useful to have in > > > the UDP document because it's necessary for Path MTU Discovery, and > > > many implementors only consider Path MTU Discovery with TCP (and not > > > UDP). With things like video, UDP packets will need to be > > > as large as > > > possible and it's important that NATs understand the need > > > to implement > > > this function. If this requirement is generalized to cover all IP > > > protocols (not just UDP) and appears in the ICMP draft, though, that > > > is a reasonable separation of scope for me. > > > > [suresh] Dan - I disagree. This is an ICMP error generation > > requirement when DF > > bit is set in the IP packets, not one of UDP applications > > being allowed to set > > DF bit. Further, this is also not the draft discussing UDP > > application choices. > > I do not see the necessity of include this in the UDP behave draft, > > considering that the requirement in ICMP fully covers this. > > As I said, if the ICMP draft generalizes this to all IP protocols, > I'm fine moving it to the ICMP draft. I believe the ICMP draft > does generalize this to all IP protocols. > [suresh] OK. Sounds like, we are in agreement. Thanks. > > > I agree REQ-14 (support receiving out of order IP fragments) isn't > > > unique to UDP, but we don't have an "all protocols" document in our > > > charter. This requirement goes hand-in-hand with REQ-13 and with > > > endpoints that don't perform Path MTU Discovery for UDP flows. > > > > > > > [suresh] I agree with your above explanation and dont have a > > problem with including this requirement. However, the explanation > > above refers to Req-15, Not Req-14. Req-14 states that NAT MUST > > support fragmentation of packets larger than link MTU. > > Sorry, I was reading > http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-nat-udp-0 > 6.txt > which renumbered some of the latter requirements. > > I'm fine moving the requirement regarding fragmentation of packets larger > than link MTU (with requirements for handling of packets with DF=0 and DF=1) > to the ICMP document. > [suresh]OK. Sounds good. In summary, I understand, REQs 12, 13 and 14 will be removed from the UDP draft. regards, suresh > -d > > > regards, > > suresh > > > > > > > -d > > > > > > > > > > > regards, > > > > suresh > > > > > > > > --- Dan Wing wrote: > > > > > > > > > Magnus Westerlund wrote: > > > > > > > > > > > Francois Audet wrote: > > > > > > > I will point out that ALL our drafts had a timeout > > of 2 minutes. > > > > > > > > > > > > > > It's only the -05 draft where we shortened it to 1 minute. > > > > > > > > > > > > > > The concensus of the group had always been 2 minutes. > > > > > > > > > > > > > > > > > > > Reviewing the discussion that resulted from me > > raising this issue > > > > > > results in me seeing rough consensus for having the value at > > > > > > 2 minutes. > > > > > > > > > > > > I think that resolves all the topics I raised in relation > > > > to my AD > > > > > > comments on the UDP draft. > > > > > > > > > > > > I am not yet certain if the new topic raised about consistent > > > > > > handling when the NAT has run out of resources is intended to > > > > > > affect the NAT UDP draft or not. Please clarify that! > > > > > > > > > > Consensus seems to be that it would belong in the ICMP draft. > > > > > > > > > > > I do like to be have an updated draft as soon as possible > > > > and going > > > > > > forward in the process towards publication. > > > > > > > > > > -d > > > > > > > > > From srisuresh@yahoo.com Tue, 2 May 2006 07:02:42 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 2 May 2006 07:02:42 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: Message-ID: <20060502140241.81009.qmail@web33303.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Philip Matthews wrote: > On 1-May-06, at 17:37 , Dan Wing wrote: > > > Magnus Westerlund wrote: > > > >> > >> I am not yet certain if the new topic raised about consistent > >> handling when the NAT has run out of resources is intended to > >> affect the NAT UDP draft or not. Please clarify that! > > > > Consensus seems to be that it would belong in the ICMP draft. > > > > I raised the issue of: How a NAT should behave if it runs out of binding > entries or filtering entries for either UDP or TCP and a packet arrives > that requires a new entry. > > Yukata Takeda raised a related issue of whether there should be a limit > on the number of filtering entries per binding entry, and how a NAT > should > behave in this case. > [suresh] No. of filters/binding and things like this are encroaching on how NATs are implemented. That wouldnt be appropriate or within the scope of this WG, IMHO. > I think these are what Magnus was referring to -- hence this reply. > > I initially suggested that the NAT should drop the packet and send an > ICMP reply. However, it was suggested to me privately that perhaps > the NAT should NOT send an ICMP, but just silently discard the packet. [suresh] Why is it desirable to not send an ICMP error for the first packet of a flow? > This behavior would be similar to the behavior of routers when > packets are dropped due to link or other congestion -- most routers > do not > send an ICMP reply in this case. > I personally find this argument persuasive, but others may disagree. > [suresh] This is diferent and more serious than the router scenario. We are not talking about dropping any arbitrary packet. We are talking about the first packet of a new flow. When NAT drops the first packet, not only that packet, but all subsequent packets belonging to that flow are dropped by the NAT. Hence, it is only reasonable that the application learn about the NAT dropping the flow through an ICMP error message. regards, suresh > Given this twist, it is not clear to me that a discussion of this > situation belongs > in the ICMP draft. > > I personally feel that the best thing to do would be to add a > requirement > dealing with this situation to both the UDP and TCP documents. > > However, if there is an unwillingness to add this to the UDP document > (which, after all, passed WGLC some time ago), then I feel the next best > think would be to have a separate draft discussing this issue. I > would be > willing to write such a draft. If we decided that an ICMP reply > should be > sent in this situation, then a reference could be made to the ICMP > document. > > - Philip > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From philip_matthews@magma.ca Tue, 2 May 2006 07:05:59 -0700 (PDT) From: Philip Matthews Date: Tue, 2 May 2006 07:05:59 -0700 (PDT) Subject: Re: [Ietf-behave] TCP equivalent of UDP Req-5 (Was: RE: Req-5) In-Reply-To: <037301c66d67$74309d80$d960150a@amer.cisco.com> Message-ID: <79AD8430-47A8-4EF4-BFF5-9E710A2DD716@magma.ca> MIME-Version: 1.0 Content-Type: text/plain Saikat: Would you explain in a bit more detail your reasoning for the TIME_WAIT state? Otherwise, I think these values are fine. The states, of course, refer to what the NAT box believes is the state of the _local_ endpoint's state machine. - Philip On 1-May-06, at 18:23 , Saikat Guha wrote: On Mon, 2006-05-01 at 14:37 -0700, Dan Wing wrote: Magnus Westerlund wrote: Reviewing the discussion that resulted from me raising this issue results in me seeing rough consensus for having the value at 2 minutes. Now that that's settles, I'd like some feedback regarding the two main issues identified with the TCP draft in the last meeting. The one this thread is about is REQ-5 -- the idle-timer for TCP sessions (much like UDP Req-5). Currently in draft-ietf-behave-tcp-00: REQ-5: If a NAT cannot determine whether the endpoints of a TCP session are active, it MAY abandon the session if it has been idle for some time. A default value of 2 hours for the established session timer is RECOMMENDED. A default value of 4 minutes for the transitory session timer is RECOMMENDED. a) The value of the NAT TCP session timers MAY be configurable. It was decided in the last meeting that a minimum must be set for application developers to rely on. Proposal: - Strengthen the RECOMMENDED to MUST. - Exclude the TIME_WAIT state from the definition of 'transitory session timer' Things to note: - This does NOT affect "normal" TCP connections that close the connection with a normal FIN exchange. Normal TCP's do go through TIME_WAIT state, which needs to be excluded so that closed connections are not held open for 4 minutes. - This mainly pertains to endpoints that have crashed, or are intentionally holding the connection idle in the established state. Crashes are rare. So the timer values here shouldn't cause undue stress on the connection-table. - The numbers (4min, and 2hours) are from RFC 1122. I believe, there is consensus to use the RFC numbers (from IETF'64). - There is a loop-hole that allows for NATs that can "determine whether the endpoints of a TCP session [is] active" e.g. by themselves sourcing a TCP keep-alive packet to use more conservative timers. However, there is NO need to require NATs to do this ... they are free to if they choose, especially if under attack, and the loop-hole protects them from falling out of behave compliance if they need to take such drastic actions. - Finally, dropping the TIME_WAIT from the 4-minute mandatory stall is not as dubious as it sounds. While its presence in TCP is a feature, and not a bug, it intent it to protect against stray packets that should be discarded by the endhost stack, as opposed to serve as a window for a packet to be accepted within. Closing the hole in TIME-WAIT doesn't go against this. Question to the WG: - Is the following requirement (and suitably edited preceding paragraph) acceptable: The transitory session timer is [...for states SYN_SENT, SYN_RCVD, CLOSING, and LAST_ACK...] but not the TIME_WAIT state. REQ-5: If a NAT cannot determine whether the endpoints of a TCP session are active, it MAY abandon the session if it has been idle for some time. The value for the established session timer MUST NOT be less than 2 hours. The value for the transitory session timer MUST NOT be less than 4 minutes. cheers, -- Saikat _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Tue, 2 May 2006 11:01:14 -0700 (PDT) From: "Dan Wing" Date: Tue, 2 May 2006 11:01:14 -0700 (PDT) Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060502134121.19527.qmail@web33312.mail.mud.yahoo.com> Message-ID: <07ab01c66e12$670cb2f0$d960150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > > > We still have a couple of unanswered questions on Req-5A. > > > Req-5A leaves no minimal timeout for request-response protocols. > > > One of the comments from the list was that there are several > > > protocols that do not need large state time in NAT (ex: Radius), > > > not just ports < 1024. > > > > > > There was a suggestion to change the wording to include > > > larger port set in that follow the request-response protocol > > > pattern in Req-5A. > > > > In http://list.sipfoundry.org/archive/ietf-behave/msg01250.html, > > you said there is a danger of breaking protocols if a NAT > > binding is destroyed immediately after a request/response. > > > > Let's take the case of DNS over UDP/53. Why require a > > NAT to keep that binding open for 60 seconds? Specifically, > > what breaks if the binding is closed immediately after the > > response. Same question for DAYTIME and ECHO, which are the > > only two UDP request/response protocols that come to my mind > > at the moment. > > [Suresh] Consider the DNS/UDP scenario. Say, a DNS request was > forwarded by NAT but the response was delayed because of load on the > system or delays in the network on the way on or on the way out. It > is not uncommon to have network delays effect the application > response times. In any case, It took a while (say, a few seconds) > for the response to reach the NAT device. What is the idle timeout > the NAT should allow for the DNS session? If it is extremely short > (say a second), NAT woudl simply drop the response on the floor. > Clearly, NAT couldnt keep the session timeout to be forever. I am > not religious about 60 seconds. If you prefer this to be 30 secs., > That would be fine as well. But, there needs to be a predictable > timeout one could set, to account for network delays/failures and > end node delays. Yes, the NAT needs to wait for the response -- the response won't arrive in 0 milliseconds. The response will take some number of milliseconds to arrive. Perhaps as long as 10 seconds. But what I'm trying to allow is for the NAT to close the binding immediately after the response comes back. You're trying to set a minimum timeout for the NAT to wait. I think we can accomdate both. Here is suggested replacement text for 5a: For request/response protocols assigned to the well-known port range (ports 0-1023), such as for example DNS over UDP/53, a NAT MAY close its binding immediately after receiving the response. In such a case, the NAT MUST wait at least 60 seconds for such a response. > > > Also, I made a comment that Req-5A ought to have a > > > deterministic minimal timeout (say, 1 min.) (or) > > > Req-5a should be removed. > > > > > > I am OK with either of the options, But, we need to > > > make a choice instead of leaving the text as is. The text as > > > is leaves it to the NAT vendors to make guesses on the timeout > > > for Req-5a. I believe, we need to come to a closure on this > > > > > > Please find my responses to your comments on Req 12, 13, and > > > 14 below inline. > > > > ... > > > > REQ-13 (fragment outgoing packets) is restating a router > > > > requirement. > > > > I agree it isn't unique to UDP. However, it seems > useful to have in > > > > the UDP document because it's necessary for Path MTU > Discovery, and > > > > many implementors only consider Path MTU Discovery with > TCP (and not > > > > UDP). With things like video, UDP packets will need to be > > > > as large as > > > > possible and it's important that NATs understand the need > > > > to implement > > > > this function. If this requirement is generalized to > cover all IP > > > > protocols (not just UDP) and appears in the ICMP draft, > though, that > > > > is a reasonable separation of scope for me. > > > > > > [suresh] Dan - I disagree. This is an ICMP error generation > > > requirement when DF > > > bit is set in the IP packets, not one of UDP applications > > > being allowed to set > > > DF bit. Further, this is also not the draft discussing UDP > > > application choices. > > > I do not see the necessity of include this in the UDP > behave draft, > > > considering that the requirement in ICMP fully covers this. > > > > As I said, if the ICMP draft generalizes this to all IP protocols, > > I'm fine moving it to the ICMP draft. I believe the ICMP draft > > does generalize this to all IP protocols. > > [suresh] OK. Sounds like, we are in agreement. Thanks. > > > > > I agree REQ-14 (support receiving out of order IP > fragments) isn't > > > > unique to UDP, but we don't have an "all protocols" > document in our > > > > charter. This requirement goes hand-in-hand with > REQ-13 and with > > > > endpoints that don't perform Path MTU Discovery for UDP flows. > > > > > > > > > > [suresh] I agree with your above explanation and dont have a > > > problem with including this requirement. However, the explanation > > > above refers to Req-15, Not Req-14. Req-14 states that NAT MUST > > > support fragmentation of packets larger than link MTU. > > > > Sorry, I was reading > > > http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-be > have-nat-udp-0 > > 6.txt > > which renumbered some of the latter requirements. > > > > I'm fine moving the requirement regarding fragmentation of > packets larger > > than link MTU (with requirements for handling of packets > with DF=0 and DF=1) > > to the ICMP document. > > > > [suresh]OK. Sounds good. In summary, I understand, REQs 12, > 13 and 14 will be > removed from the UDP draft. Yes, I believe that makes sense. I'll start a new thread on this to gather consensus; this thread has been long and I feel many aren't following it. -d From dwing@cisco.com Tue, 2 May 2006 11:48:27 -0700 (PDT) From: "Dan Wing" Date: Tue, 2 May 2006 11:48:27 -0700 (PDT) Subject: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements Message-ID: <07fa01c66e18$ff5d4190$d960150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain This email is to poll for consensus on moving the following requirements from the UDP document (draft-ietf-behave-nat-udp-05.txt) to the forthcoming BEHAVE working group ICMP document (currently draft-srisuresh-behave-nat-icmp-01.txt): REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping. a) The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address. b) It is RECOMMENDED that a NAT support ICMP Destination Unreachable messages. REQ-13: If the packet has DF=1, the NAT SHOULD send back an ICMP message "fragmentation needed and DF set" message to the host as described in RFC 792 [2]. a) If the packet has DF=0, the NAT SHOULD fragment the packet and send the fragments, in order. REQ-14: A NAT MUST support fragmentation of packets larger than link MTU. If you have an objection to moving these requirements from the UDP document to the ICMP document, please reply to this email. -d From huitema@windows.microsoft.com Tue, 2 May 2006 20:36:05 -0700 (PDT) From: "Christian Huitema" Date: Tue, 2 May 2006 20:36:05 -0700 (PDT) Subject: RE: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <07fa01c66e18$ff5d4190$d960150a@amer.cisco.com> Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064805511@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain > This email is to poll for consensus on moving the following requirements > from the UDP document (draft-ietf-behave-nat-udp-05.txt) to the > forthcoming > BEHAVE working group ICMP document (currently > draft-srisuresh-behave-nat-icmp-01.txt): > > REQ-12: Receipt of any sort of ICMP message MUST NOT destroy > the NAT mapping. > a) The NAT's default configuration SHOULD NOT filter > ICMP messages based on their source IP address. > b) It is RECOMMENDED that a NAT support ICMP > Destination Unreachable messages. This requirement must remain in the UDP draft. When developing Teredo, we have observed many problems with NAT implementations that removed a UDP mapping after receiving an ICMP unreachable message. This is a common bug, which in some cases prevent establishment of UDP associations. I understand that this is a requirement on the handling of ICMP packets, but the result of that handling directly affects UDP mappings. You may want to clarify the requirement and mentions that it only applies to ICMP messages related to UDP associations. -- Christian Huitema From saikat@cs.cornell.edu Wed, 3 May 2006 01:14:58 -0700 (PDT) From: Saikat Guha Date: Wed, 3 May 2006 01:14:58 -0700 (PDT) Subject: Re: [Ietf-behave] TCP equivalent of UDP Req-5 (Was: RE: Req-5) In-Reply-To: <037301c66d67$74309d80$d960150a@amer.cisco.com> Message-ID: <1146644097.28266.51.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2006-05-02 at 10:05 -0400, Philip Matthews wrote: > Would you explain in a bit more detail your reasoning for the > TIME_WAIT state? One side of a regular TCP will always enter TIME_WAIT state (the side that sends the first FIN). Figure 4, RFC 793. At TIME_WAIT state, the endpoint has received a FIN from the other endpoint and acknowledged it, and sent its own FIN and received an ACK for it. The applications at both endpoints have closed the socket (since FIN's have been sent). The next transition is to CLOSED after a _timeout_ to prevent potential overlap with new connections. A compliant OS is going to wait for TIME_WAIT before accepting new connections on the same 5-tuple. The NAT has two choices -- either to keep the connection open (for 4 minutes) even after FINs have been exchanged and ACKs sent, or close it. Keeping it open means that for each an every properly-closed TCP connection, the NAT can't evict the connection-table entry for 4 minutes. The demerits are obvious: this cuts the connection-per-second throughput of the NAT in non-exceptional settings. The merit of this is that packets for the old connection can still be routed to the endpoint (only to be dropped by the kernel). Either way, it doesn't affect the application at all since the app has already close()'ed the socket. Allowing the NAT to (possibly) delete state increases the connections-per-second throughput of the NAT -- the point of compromise recently discussed for UDP. It doesn't affect the application still. Consequently, the proposal is to leave NAT behavior in this regard (TIME_WAIT state) undefined. Vendors may keep state for 4 minutes, or 0 minutes as they choose. Applications are not affected. > The states, of course, refer to what the NAT box believes is the > state of the > _local_ endpoint's state machine. The way REQ-5 is set up, it admits very simple implementations. Here is one (possible) implementation strategy for a NAT. 1. Set connection expiry to 4 minutes at start. 2. Wait for ACK flag on one incoming packet and one outgoing packet (2-bit state required) 3. Set connection expiry to 2 hours. 4. Wait for FIN flag on one incoming packet and one outgoing packet (can re-use those 2 bits here) 5. Set connection expiry to 4 minutes. This implementation track state on _both_ local and remote endpoint, and ensures that established connections stay up for 2h, and transient ones for 4 minutes. That said, if your emphasis is on "believes", then yes, if a packet is lost between the NAT and endpoint (local or remote), then the NAT's estimate of the state lags that of the endpoint's until one retransmission finally makes it to the NAT. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00097.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00097.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFV0dhQm5GbHRxaTY5MS9vUkFqMEJBSjltUXlmRmdVYVVoSTdqV0d1 dUE5ZnpDaldwdkFDY0RzK0YKVWdhRCtLWjB4SitOSDNpcEE0ZkNRVGM9Cj1LZEUrCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From dhudson@ubicom.com Wed, 3 May 2006 02:03:08 -0700 (PDT) From: "Dave Hudson" Date: Wed, 3 May 2006 02:03:08 -0700 (PDT) Subject: RE: [Ietf-behave] TCP equivalent of UDP Req-5 (Was: RE: Req-5) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Saikat, * -----Original Message----- * From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx * [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of * Saikat Guha * Sent: 03 May 2006 09:15 * To: Philip Matthews * Cc: Behave * Subject: Re: [Ietf-behave] TCP equivalent of UDP Req-5 (Was: * RE: Req-5) * * Keeping it open means that for each an every properly-closed * TCP connection, the NAT can't evict the connection-table * entry for 4 minutes. The demerits are obvious: this cuts the * connection-per-second throughput of the NAT in * non-exceptional settings. The merit of this is that packets * for the old connection can still be routed to the endpoint * (only to be dropped by the kernel). Either way, it doesn't * affect the application at all since the app has already * close()'ed the socket. * * Allowing the NAT to (possibly) delete state increases the * connections-per-second throughput of the NAT -- the point of * compromise recently discussed for UDP. It doesn't affect the * application still. * * Consequently, the proposal is to leave NAT behavior in this * regard (TIME_WAIT state) undefined. Vendors may keep state * for 4 minutes, or 0 minutes as they choose. Applications are * not affected. One real problem I've seen with NATs that discard state after 0 minutes is when the NATs themselves don't then send well-formed RST:ACK packets in response to TCP traffic that doesn't match a known flow in the connection table. With P2P file sharing apps it's very easy to see congestion problems causing packets to get dropped after one NAT's sent them but before a remote NAT receives them (especially true with many residential broadband connections since they're relatively low bandwidth - 40 or 50 peers sending traffic at once can and will cause congestion problems). Increasingly though packets are also getting lost on the local side too - it's very common to see wirelessly-connected systems lose packets between a NAT and the local system (this happens all the time - switch on your microwave oven when you're using 802.11b/g/n and watch the TCP retransmission rates :-)). The problem is that just because a NAT has seen all of the FINs (and most seem to completely ignore ACKs) or even the ACKs of FINs in a congested or lossy network, it doesn't follow that the endpoints themselves saw those things. If a NAT evactuates a connection from the connection table without allowing any time for retransmissions and doesn't then send RSTs in response to traffic for unknown connections (ignoring initial SYNs of course) then instead it ends up with one endpoint or the other sending FINs at it until the endpoint eventually gets bored and times-out. Having the TIME-WAIT timer isn't guaranteed to stop problems either (since retransmissions can also get lost) but the incidence of failure is significantly lower. Incidently one interesting failure mode I see in a lot of traffic I've seen from systems behind NATs is where the NAT will create a new connection in the connection table without ensuring that it was in response to a SYN, thus you can see retransmitted FINs creating new connection entries with different port bindings to the original traffic (and thus you see response packets coming back from the wrong port number). Regards, Dave ***************************************************************************** We've Moved! Please note our new address and phone numbers: Ubicom, Inc. 510 N. Pastoria Ave Sunnyvale, CA 94085 (408) 789-2200 - Main (408) 739-2427 - Fax www.ubicom.com ****************************************************************************** From saikat@cs.cornell.edu Wed, 3 May 2006 02:55:41 -0700 (PDT) From: Saikat Guha Date: Wed, 3 May 2006 02:55:41 -0700 (PDT) Subject: RE: [Ietf-behave] TCP equivalent of UDP Req-5 (Was: RE: Req-5) In-Reply-To: Message-ID: <1146650140.28266.115.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-05-03 at 02:02 -0700, Dave Hudson wrote: > One real problem I've seen with NATs that discard state after 0 minutes > is when the NATs themselves don't then send well-formed RST:ACK packets > in response to TCP traffic that doesn't match a known flow in the > connection table[...] > (ignoring initial SYNs of course) Just to clarify, the relaxation for TIME_WAIT does _not_ affect the cases where the FIN is lost after it crosses the NAT but before it reaches the destination. Those states are LAST_ACK, FIN_WAIT_1, FIN_WAIT_2, and CLOSING. As per the requirement, NATs must wait 4 minutes for retransmissions etc. As you noted, the timer itself doesn't solve this problem, but decreases the chances of failure by allowing the endpoints to make a few retransmissions. The relaxation for TIME_WAIT affects connections where both the FINs have been received but the very last ACK may have been lost. In these situations, the OS has already notified the application that the connection has terminated. The OS internally lets the TCP state linger for some time. As a result, allowing vendors to pick a timeout for TIME_WAIT (and only TIME_WAIT) doesn't affect the application per se. Now considering TIME_WAIT, if the last ACK is lost and endpoint OS re-sends the FIN (in the background while the application has moved on). If the NAT has dropped the associated state, then I agree that it should respond with an ACK to the sender. The question then becomes -- does the draft need to state this? i.e. something along the lines of if the timer for TIME_WAIT is short, then the NAT should ACK unexpected FIN packets. Or, should the draft stay silent about it since it doesn't affect the application. My vote would be to not leave this unspecified. What do others think? > Incidently one interesting failure mode I see in a lot of traffic I've > seen from systems behind NATs is where the NAT will create a new > connection in the connection table without ensuring that it was in > response to a SYN Aye. There are some really broken ones out there. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00098.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00098.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFV0g0Y25GbHRxaTY5MS9vUkFoZWdBSjRueTJ1eHYxUWlhaDI0KzJv cGtqUDN4WWlRb1FDZU1xdEoKanFOUGt0NVkxU1RGaER0VkJUQUdKZ0k9Cj1HTDlxCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From philip_matthews@magma.ca Wed, 3 May 2006 06:04:25 -0700 (PDT) From: Philip Matthews Date: Wed, 3 May 2006 06:04:25 -0700 (PDT) Subject: Re: [Ietf-behave] TCP equivalent of UDP Req-5 (Was: RE: Req-5) In-Reply-To: Message-ID: <6FC39243-7511-443F-830D-BD0D62932489@magma.ca> MIME-Version: 1.0 Content-Type: text/plain Saikat: Thanks for your reply. I think that Dave has more direct experience in this area, so I will simply give some general comments. Speaking personally, I am concerned with both the application and the TCP state machine in the underlying OS. I would like to ensure that both of them have a "good" experience when they are behind a NAT. So when things are left unspecified (like how long the NAT's state machine should remain in the TIME_WAIT state), then I personally would like to see the document give some suggestions or guidelines to NAT implementors on what are acceptable implementation choices, and what to watch out for. Specifically, the document might say something like "The time to remain in the TIME_WAIT state is left unspecified to allow for some variations in implementation. A NAT should remain in this state for at most 4 minutes. Some NAT implementations will choose stay in this state for exactly 4 minutes. Other NAT implementations may choose to reduce this time. However, NATs that reduce this time must still behave as follows: .... " How this should be split between requirement text and informative text is something I am not yet sure of. To me, the thing about NATs is that, unlike many other products, a bad choice by a NAT implementor affects not only the NAT itself, but all products behind the NAT, so reasonable behavior is very important. Of course, all this is just my own opinion, and others may disagree. Anyway, hope this helps. Thanks very much for working on this document. - Philip On 3-May-06, at 05:55 , Saikat Guha wrote: On Wed, 2006-05-03 at 02:02 -0700, Dave Hudson wrote: One real problem I've seen with NATs that discard state after 0 minutes is when the NATs themselves don't then send well-formed RST:ACK packets in response to TCP traffic that doesn't match a known flow in the connection table[...] (ignoring initial SYNs of course) Just to clarify, the relaxation for TIME_WAIT does _not_ affect the cases where the FIN is lost after it crosses the NAT but before it reaches the destination. Those states are LAST_ACK, FIN_WAIT_1, FIN_WAIT_2, and CLOSING. As per the requirement, NATs must wait 4 minutes for retransmissions etc. As you noted, the timer itself doesn't solve this problem, but decreases the chances of failure by allowing the endpoints to make a few retransmissions. The relaxation for TIME_WAIT affects connections where both the FINs have been received but the very last ACK may have been lost. In these situations, the OS has already notified the application that the connection has terminated. The OS internally lets the TCP state linger for some time. As a result, allowing vendors to pick a timeout for TIME_WAIT (and only TIME_WAIT) doesn't affect the application per se. Now considering TIME_WAIT, if the last ACK is lost and endpoint OS re-sends the FIN (in the background while the application has moved on). If the NAT has dropped the associated state, then I agree that it should respond with an ACK to the sender. The question then becomes -- does the draft need to state this? i.e. something along the lines of if the timer for TIME_WAIT is short, then the NAT should ACK unexpected FIN packets. Or, should the draft stay silent about it since it doesn't affect the application. My vote would be to not leave this unspecified. What do others think? Incidently one interesting failure mode I see in a lot of traffic I've seen from systems behind NATs is where the NAT will create a new connection in the connection table without ensuring that it was in response to a SYN Aye. There are some really broken ones out there. cheers, -- Saikat From philip_matthews@magma.ca Wed, 3 May 2006 06:39:10 -0700 (PDT) From: Philip Matthews Date: Wed, 3 May 2006 06:39:10 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060502140241.81009.qmail@web33303.mail.mud.yahoo.com> Message-ID: <3C2EAFF5-340F-4086-857A-8A71FC0DD685@magma.ca> MIME-Version: 1.0 Content-Type: text/plain On 2-May-06, at 10:02 , Pyda Srisuresh wrote: --- Philip Matthews wrote: On 1-May-06, at 17:37 , Dan Wing wrote: Magnus Westerlund wrote: I am not yet certain if the new topic raised about consistent handling when the NAT has run out of resources is intended to affect the NAT UDP draft or not. Please clarify that! Consensus seems to be that it would belong in the ICMP draft. I raised the issue of: How a NAT should behave if it runs out of binding entries or filtering entries for either UDP or TCP and a packet arrives that requires a new entry. Yukata Takeda raised a related issue of whether there should be a limit on the number of filtering entries per binding entry, and how a NAT should behave in this case. [suresh] No. of filters/binding and things like this are encroaching on how NATs are implemented. That wouldnt be appropriate or within the scope of this WG, IMHO. I think Yukata's point is that there should NOT be a limit on the number of filtering entries per binding entry. Rather, these should just be covered by the limits on the total number of filtering entries and binding entries. In particular, he doesn't want to see a very small limit, like: max 8 filtering entries per binding entry I agree with him, because it would seriously limit the number of connections that a P2P application could have. Imagine a NAT with the endpoint-independent mapping property, the address-dependent filtering property, and a limit of 8 filtering entries per binding entry. A P2P application behind this NAT that wanted to connect to 32 peers would have to allocate at least 4 different ports, one for each group of 8 connections. I think these are what Magnus was referring to -- hence this reply. I initially suggested that the NAT should drop the packet and send an ICMP reply. However, it was suggested to me privately that perhaps the NAT should NOT send an ICMP, but just silently discard the packet. [suresh] Why is it desirable to not send an ICMP error for the first packet of a flow? This behavior would be similar to the behavior of routers when packets are dropped due to link or other congestion -- most routers do not send an ICMP reply in this case. I personally find this argument persuasive, but others may disagree. [suresh] This is diferent and more serious than the router scenario. We are not talking about dropping any arbitrary packet. We are talking about the first packet of a new flow. When NAT drops the first packet, not only that packet, but all subsequent packets belonging to that flow are dropped by the NAT. Hence, it is only reasonable that the application learn about the NAT dropping the flow through an ICMP error message. Here are a few thoughts (mine plus those sent to me privately by other people). For TCP, an ICMP reply will be received by the TCP state machine and may cause a state transition. So sending an ICMP reply might make sense. For UDP, ICMP messages are usually not delivered to the application and there is no OS-level state machine to affect, so sending a reply might not be so useful. So it MAY be that handling UDP and TCP differently might be appropriate. - Philip From srisuresh@yahoo.com Wed, 3 May 2006 07:23:05 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 3 May 2006 07:23:05 -0700 (PDT) Subject: Req-5/5a (Was:: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05)) In-Reply-To: <07ab01c66e12$670cb2f0$d960150a@amer.cisco.com> Message-ID: <20060503142305.38803.qmail@web33308.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dan Wing wrote: > > > > We still have a couple of unanswered questions on Req-5A. > > > > Req-5A leaves no minimal timeout for request-response protocols. > > > > One of the comments from the list was that there are several > > > > protocols that do not need large state time in NAT (ex: Radius), > > > > not just ports < 1024. > > > > > > > > There was a suggestion to change the wording to include > > > > larger port set in that follow the request-response protocol > > > > pattern in Req-5A. > > > > > > In http://list.sipfoundry.org/archive/ietf-behave/msg01250.html, > > > you said there is a danger of breaking protocols if a NAT > > > binding is destroyed immediately after a request/response. > > > > > > Let's take the case of DNS over UDP/53. Why require a > > > NAT to keep that binding open for 60 seconds? Specifically, > > > what breaks if the binding is closed immediately after the > > > response. Same question for DAYTIME and ECHO, which are the > > > only two UDP request/response protocols that come to my mind > > > at the moment. > > > > [Suresh] Consider the DNS/UDP scenario. Say, a DNS request was > > forwarded by NAT but the response was delayed because of load on the > > system or delays in the network on the way on or on the way out. It > > is not uncommon to have network delays effect the application > > response times. In any case, It took a while (say, a few seconds) > > for the response to reach the NAT device. What is the idle timeout > > the NAT should allow for the DNS session? If it is extremely short > > (say a second), NAT woudl simply drop the response on the floor. > > Clearly, NAT couldnt keep the session timeout to be forever. I am > > not religious about 60 seconds. If you prefer this to be 30 secs., > > That would be fine as well. But, there needs to be a predictable > > timeout one could set, to account for network delays/failures and > > end node delays. > > Yes, the NAT needs to wait for the response -- the response won't > arrive in 0 milliseconds. The response will take some number > of milliseconds to arrive. Perhaps as long as 10 seconds. > > But what I'm trying to allow is for the NAT to close the binding > immediately after the response comes back. > > You're trying to set a minimum timeout for the NAT to wait. > > I think we can accomdate both. Here is suggested replacement > text for 5a: > > For request/response protocols assigned to the well-known > port range (ports 0-1023), such as for example DNS over > UDP/53, a NAT MAY close its binding immediately after > receiving the response. In such a case, the NAT MUST > wait at least 60 seconds for such a response. > [suresh] Thus far, the NAT documnts only talked about Idle timeout. I.e., an idle timeout for TCP, an idle timeout for UDP, an idletimeout for ICMP query sessions etc. These idle timeouts are application agnostic. However, the replacement text for 5A implies that NATs should have a new kind of timeout to monitor response time for requests. This request-response timeout is new and different from the idle timeout. I would not suggest adding text implying newer type of timeouts. I am also not comfortable with a requirement that makes distinction between behavior for well-known ports in how the timeouts are used. To me, this goes against the sipirit of REQ-10 (Do not enable ALGs), which says that NATs shoudl be application agnostic. Would the following text work for you? REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 minutes, unless REQ-5B applies. a) The value of the NAT UDP mapping timer MAY be configurable, either for all ports or on a per-port basis. b) For request/response protocols such as, for example, DNS over UDP/53, a default UDP mapping timer of 1 minute is RECOMMENDED. For the remaining, a default UDP mapping timer of 5 minutes is RECOMMENDED. regards, suresh > > > > Also, I made a comment that Req-5A ought to have a > > > > deterministic minimal timeout (say, 1 min.) (or) > > > > Req-5a should be removed. > > > > > > > > I am OK with either of the options, But, we need to > > > > make a choice instead of leaving the text as is. The text as > > > > is leaves it to the NAT vendors to make guesses on the timeout > > > > for Req-5a. I believe, we need to come to a closure on this > > > > <.. Rest of the message trimmed ..> From srisuresh@yahoo.com Wed, 3 May 2006 12:21:56 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 3 May 2006 12:21:56 -0700 (PDT) Subject: RE: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064805511@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <20060503192155.1719.qmail@web33311.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Christian Huitema wrote: > > This email is to poll for consensus on moving the following > requirements > > from the UDP document (draft-ietf-behave-nat-udp-05.txt) to the > > forthcoming > > BEHAVE working group ICMP document (currently > > draft-srisuresh-behave-nat-icmp-01.txt): > > > > REQ-12: Receipt of any sort of ICMP message MUST NOT destroy > > the NAT mapping. > > a) The NAT's default configuration SHOULD NOT filter > > ICMP messages based on their source IP address. > > b) It is RECOMMENDED that a NAT support ICMP > > Destination Unreachable messages. > > This requirement must remain in the UDP draft. When developing Teredo, > we have observed many problems with NAT implementations that removed a > UDP mapping after receiving an ICMP unreachable message. This is a > common bug, which in some cases prevent establishment of UDP > associations. I understand that this is a requirement on the handling of > ICMP packets, but the result of that handling directly affects UDP > mappings. > [suresh] My understanding of Teredo is limited. I havent read your RFC. Do correct, if I misundertood. I believe, Teredo is a tunnel based solution, primarily for V4/V6. Did the testing include V4 NATs? Also, was the testing targeted primarily at RTP/UDP applications or did that include a wide range of applications? Can you tell us the range of NATs and the range of applications tested? Also, what are the ICMP error messages you had seen? Were the NATs removing the state irrespective of the type of ICMP error message (soft or hard)? > You may want to clarify the requirement and mentions that it only > applies to ICMP messages related to UDP associations. > [suresh] I disagree. Just because some NATs have been known to delete state for UDP sessions, that does not mean that REQ-12 is specific to UDP flows only. Likewise, REQ-13 cannot be deemed TCP specific, just because a large number of TCP apps set the DF bit. Both these requirements are applicable to ICMP error generation/processing and applicale to all IP flows and the behave requirements shoudl reflect that as generic ICMP requirements, IMHO. It is certainly beneficial to state that Req-12 vioaltions have been noticied w.r.t. UDP flows and that TCP apps are particularly sensitive to REq-13. regards, suresh > -- Christian Huitema > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From huitema@windows.microsoft.com Wed, 3 May 2006 13:54:41 -0700 (PDT) From: "Christian Huitema" Date: Wed, 3 May 2006 13:54:41 -0700 (PDT) Subject: RE: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <20060503192155.1719.qmail@web33311.mail.mud.yahoo.com> Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0648A5CBD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain > [suresh] My understanding of Teredo is limited. I havent read your RFC. Do > correct, if I misundertood. I believe, Teredo is a tunnel based solution, > primarily for V4/V6. Did the testing include V4 NATs? Teredo provides for Tunneling of IPv6 packets over IPv4/UDP, across IPv4 NAT. > Also, was the testing > targeted primarily at RTP/UDP applications or did that include a wide > range of > applications? Can you tell us the range of NATs and the range of > applications > tested? Once you have Teredo installed, you can run pretty much any application you want over IPv6. We have tested it across a very large range of NATs. > Also, what are the ICMP error messages you had seen? Were the NATs > removing the state irrespective of the type of ICMP error message (soft or > hard)? Teredo essentially establishes an UDP/IPv4 association between two hosts. The interesting case happens when both hosts are behind a NAT. The basic exchange is as follow: 1) Host A maintains UDP/IPv4 connection with a non NAT server. The mapping is pinned in the NAT by regular refresh. The server tells A its "mapped address", i.e. UDP port and IPv4 address as seen outside the NAT. 2) Host B learns the "mapped address" of host A (i.e. IPv4 address and UDP port). It sends a UDP packet directly to that address, effectively creating a mapping in the local NAT. The packet is typically refused by A's NAT, because no mapping exists yet for the communication between A and B. 3) Host B also sends a packet to Host A through host A's server. Through this packet, A learns the mapped address of B. 4) Host A sends a UDP/IPv4 packet to B. This packet is received, because a mapping was installed at step 2. The bug we have observed is as follow: 1) ... 2) ... 2a) Upon receiving the packet from B, the NAT at Host A generates an ICMP error message and sends it to B. 2b) Upon receiving the ICMP error, the NAT at host B destroys the mapping established at step 2. 3) .. 4) Host A sends a UDP/IPv4 packet to B. The packet is NOT received, because a mapping was installed at step 2. -- Christian Huitema From fluffy@cisco.com Wed, 3 May 2006 19:24:43 -0700 (PDT) From: Cullen Jennings Date: Wed, 3 May 2006 19:24:43 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <07fa01c66e18$ff5d4190$d960150a@amer.cisco.com> Message-ID: <9BB3068C-67F3-40F9-87A1-C0E7FC1150C2@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Yes, I have a serious objection. A long time ago we had these ICMP items in a separate draft from the UDP. For several reason the WG decided to put the things that effected UDP application into the UDP document. The document is now past WGLC. We have people waiting to implement it. We need it. I see no reason to play musical chairs with paragraphs of text at this point in time. I see no new information that causes me to want to reverse the decision the WG made when it decided to move these together. I don't believe that separating them will improve the odds of NAT vendors doing the things for UDP that they need to do for UDP based application to be able to reliably work. If a ICMP draft gets done, it could update this UPD draft. I will point out the ICMP draft is not yet a WG item. Applications need the destination unreachable so that we know a host is down and can use DNS to go to the next host. Applications need the "Do Not Fragment" support so they can do MTU discover. Applications need to know that fragmentation will work because MTU discovery does not always work. This are things we all agree the WG agreed we need - I object to removing them. I view the whole topic of even considering removing them at this late stage of the game to be the worst of distasteful standards gamesmanship when there is no reason this could not have been brought up sooner. Cullen (with my individual contributor hat on) On May 2, 2006, at 2:48 PM, Dan Wing wrote: This email is to poll for consensus on moving the following requirements from the UDP document (draft-ietf-behave-nat-udp-05.txt) to the forthcoming BEHAVE working group ICMP document (currently draft-srisuresh-behave-nat-icmp-01.txt): REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping. a) The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address. b) It is RECOMMENDED that a NAT support ICMP Destination Unreachable messages. REQ-13: If the packet has DF=1, the NAT SHOULD send back an ICMP message "fragmentation needed and DF set" message to the host as described in RFC 792 [2]. a) If the packet has DF=0, the NAT SHOULD fragment the packet and send the fragments, in order. REQ-14: A NAT MUST support fragmentation of packets larger than link MTU. If you have an objection to moving these requirements from the UDP document to the ICMP document, please reply to this email. -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Wed, 3 May 2006 19:24:51 -0700 (PDT) From: Cullen Jennings Date: Wed, 3 May 2006 19:24:51 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060425131340.42144.qmail@web33313.mail.mud.yahoo.com> Message-ID: <97BFB79D-6892-44B4-8668-E370777B6142@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Apr 25, 2006, at 9:13 AM, Pyda Srisuresh wrote: 3. Some UDP connections are extremely short-lived. An example with port> 1024 is RADIUS, which (in some modes) performs many short exchanges. As I have pointed out before - it is simply not true that all RADIUD connection are short lived - some are but not all. Furthermore, you are unlikely to have some very large number of radius transaction per second on different UDP flows through one NAT. I'm would not be surprised, if there are protocol that are short lived greater than 1024 but so far we seem to be lacking examples of them. Particularly ones that will generate enough connections to make a substantial impact on an enterprise NAT. I am beginning to think there is no real problem here. If there is a real problem, let's get specific about it. From rohan.mahy@gmail.com Wed, 3 May 2006 19:48:49 -0700 (PDT) From: "Rohan Mahy" Date: Wed, 3 May 2006 19:48:49 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <07fa01c66e18$ff5d4190$d960150a@amer.cisco.com> Message-ID: <953beacc0605031948xb0a6548xfae6778eb149c966@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Hi Dan,If the ICMP draft was a stable WG item and the UDP draft normatively referenced the ICMP draft, then this would be reorganization and I would not care. It isn't. These requirements are needed to make UDP applications work, and I believe that is non-controversial. The proposed "move" would change what a NAT vendor has to do to claim compliance with the document. Please just leave the requirements in place. thanks,-rohanOn 5/2/06, Dan Wing wrote: This email is to poll for consensus on moving the following requirementsfrom the UDP document (draft-ietf-behave-nat-udp-05.txt) to the forthcomingBEHAVE working group ICMP document (currentlydraft-srisuresh-behave-nat-icmp-01.txt ):REQ-12:Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping. a) The NAT's default configuration SHOULD NOT filterICMP messages based on their source IP address. b) It is RECOMMENDED that a NAT support ICMPDestination Unreachable messages.REQ-13:If the packet has DF=1, the NAT SHOULD send back an ICMP message "fragmentation needed and DF set" message to the host as described in RFC 792 [2]. a) If the packet has DF=0, the NAT SHOULD fragmentthe packet and send the fragments, in order.REQ-14:A NAT MUST support fragmentation of packets larger than link MTU.If you have an objection to moving these requirements from the UDP documentto the ICMP document, please reply to this email.-d_______________________________________________ Ietf-behave mailing listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Wed, 3 May 2006 20:24:08 -0700 (PDT) From: "Francois Audet" Date: Wed, 3 May 2006 20:24:08 -0700 (PDT) Subject: [Ietf-behave] RE: consensus query: -behave-nat-udp: moving requirements Message-ID: <1ECE0EB50388174790F9694F77522CCF0947C7AA@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I agree with both Rohan and Cullen. It is way past bedtime. WGLC was completed a long time ago. All technical issues have been resolved. It is very clear that we had a concensus. This draft needs to be submitted with the requirements in. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Tuesday, May 02, 2006 11:48 > To: BEHAVE WG > Cc: Audet, Francois [SC100:3055:EXCH]; 'Pyda Srisuresh'; > baford@xxxxxxx; ssenthil@xxxxxxxxx; 'Saikat Guha' > Subject: consensus query: -behave-nat-udp: moving requirements > > > This email is to poll for consensus on moving the following > requirements from the UDP document > (draft-ietf-behave-nat-udp-05.txt) to the forthcoming BEHAVE > working group ICMP document (currently > draft-srisuresh-behave-nat-icmp-01.txt): > > REQ-12: Receipt of any sort of ICMP message MUST NOT destroy > the NAT mapping. > a) The NAT's default configuration SHOULD NOT filter > ICMP messages based on their source IP address. > b) It is RECOMMENDED that a NAT support ICMP > Destination Unreachable messages. > > REQ-13: If the packet has DF=1, the NAT SHOULD send back an > ICMP message "fragmentation needed and DF set" message > to the host as described in RFC 792 [2]. > a) If the packet has DF=0, the NAT SHOULD fragment > the packet and send the fragments, in order. > > REQ-14: A NAT MUST support fragmentation of packets larger > than link MTU. > > > If you have an objection to moving these requirements from > the UDP document to the ICMP document, please reply to this email. > > -d > > From ascolnic@checkpoint.com Wed, 3 May 2006 23:33:32 -0700 (PDT) From: "Ariel Shaqed (Scolnicov)" Date: Wed, 3 May 2006 23:33:32 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060425131340.42144.qmail@web33313.mail.mud.yahoo.com> Message-ID: <200605040937.28427@kmail-ckp> MIME-Version: 1.0 Content-Type: text/plain On Thursday 04 May 2006 03:32, Cullen Jennings wrote: > On Apr 25, 2006, at 9:13 AM, Pyda Srisuresh wrote: > >> 3. Some UDP connections are extremely short-lived. An example > >> with port> > >> 1024 is RADIUS, which (in some modes) performs many short exchanges. > > As I have pointed out before - it is simply not true that all RADIUD > connection are short lived - some are but not all. As this is probably my text, I should respond. Yes, it is true that not all RADIUS connections are short-lived -- those used for accounting are long-lived. But it's also true that some RADIUS connections can be very short-lived. And it is true that administrators generally know if they intend to use RADIUS authentication or accounting and accordingly the desired lifetime for RADIUS connections. RADIUS is an example of a short-lived UDP connection. Authentication is perfectly suited to RADIUS. > Furthermore, you > are unlikely to have some very large number of radius transaction per > second on different UDP flows through one NAT. I'm would not be > surprised, if there are protocol that are short lived greater than > 1024 but so far we seem to be lacking examples of them. Particularly > ones that will generate enough connections to make a substantial > impact on an enterprise NAT. I am beginning to think there is no real > problem here. If there is a real problem, let's get specific about it. I attempted to provide this in my point #1, which got lost above. [*Not* quoting Cullen, obviously:] ] 1. Not only the 1st NAT on the path is affected. If an application sends ] keepalives every 2 minutes it will not work with firewalls anywhere along ] its path that keep a smaller timeout for UDP connections and also inspect ] the protocol. It is probably not very practical to hold a UDP connection ] (i.e. its current state) open on a firewall for 5 minutes of inactivity. ] ] Note that even 0 bits of stored state can make the difference: Consider a ] firewall dropping all UDP connections in one direction. ] ] It make sense to specify minimal timeouts, just not for all UDP ports. The draft is mandating particular behaviour all along the path, not just along the first and last hops. For BEHAVE to be useful it must traverse firewalls. Or rather, for BEHAVE-compliant apps to be useful, they must traverse firewalls. And in my point #2: ] 2. The above, when the firewall is NATting its internal domain. For example. You have a firewall internally in your domain. Every host authenticates with RADIUS. The RADIUS server is on one side. The hosts are on the other. At 08:00 every host starts several UDP flows for each of several applications. As an administrator, draft-ietf-behave-nat-udp has just decided for you you cannot NAT the protected hosts' domain. -- Ariel. From fluffy@cisco.com Thu, 4 May 2006 05:28:42 -0700 (PDT) From: Cullen Jennings Date: Thu, 4 May 2006 05:28:42 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060425131340.42144.qmail@web33313.mail.mud.yahoo.com> Message-ID: <2DD42932-A658-46FC-9D4A-507DD4CCAF4F@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On May 4, 2006, at 2:37 AM, Ariel Shaqed (Scolnicov) wrote: Yes, it is true that not all RADIUS connections are short-lived -- those used for accounting are long-lived. But it's also true that some RADIUS connections can be very short-lived. And it is true that administrators generally know if they intend to use RADIUS authentication or accounting and accordingly the desired lifetime for RADIUS connections. OK - we are in agreement on this then. The key point here is it is something the administrator would know and the vendor of the NAT can't know. I never have any objections to the administrator being able to configure the policy of firewall in any way they want. From ascolnic@checkpoint.com Thu, 4 May 2006 05:42:46 -0700 (PDT) From: "Ariel Shaqed (Scolnicov)" Date: Thu, 4 May 2006 05:42:46 -0700 (PDT) Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05) In-Reply-To: <20060425131340.42144.qmail@web33313.mail.mud.yahoo.com> Message-ID: <200605041546.36245@kmail-ckp> MIME-Version: 1.0 Content-Type: text/plain On Thursday 04 May 2006 15:28, Cullen Jennings wrote: > On May 4, 2006, at 2:37 AM, Ariel Shaqed (Scolnicov) wrote: > > Yes, it is true that not all RADIUS connections are short-lived -- > > those > > used for accounting are long-lived. But it's also true that some > > RADIUS > > connections can be very short-lived. And it is true that > > administrators > > generally know if they intend to use RADIUS authentication or > > accounting > > and accordingly the desired lifetime for RADIUS connections. > > OK - we are in agreement on this then. The key point here is it is > something the administrator would know and the vendor of the NAT > can't know. I never have any objections to the administrator being > able to configure the policy of firewall in any way they want. Obviously the administrator can make this decision. Equally obviously, having made this decision (very possibly in the past), BEHAVE-compliant apps cannot work. This is not a decision on the level of disconnecting the machine, it is a valid configuration decision. BEHAVE is specifying behaviour for apps, therefore it is specifying the same thing for devices along the way. It is doing this for all ports. -- Ariel Scolnicov. From srisuresh@yahoo.com Fri, 5 May 2006 03:50:49 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 5 May 2006 03:50:49 -0700 (PDT) Subject: RE: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0648A5CBD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <20060505105049.80760.qmail@web33303.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Christian Huitema wrote: > > [suresh] My understanding of Teredo is limited. I havent read your > RFC. Do > > correct, if I misundertood. I believe, Teredo is a tunnel based > solution, > > primarily for V4/V6. Did the testing include V4 NATs? > > Teredo provides for Tunneling of IPv6 packets over IPv4/UDP, across IPv4 > NAT. > > > Also, was the testing > > targeted primarily at RTP/UDP applications or did that include a wide > > range of > > applications? Can you tell us the range of NATs and the range of > > applications > > tested? > > Once you have Teredo installed, you can run pretty much any application > you want over IPv6. We have tested it across a very large range of NATs. > > > Also, what are the ICMP error messages you had seen? Were the NATs > > removing the state irrespective of the type of ICMP error message > (soft or > > hard)? > > Teredo essentially establishes an UDP/IPv4 association between two > hosts. The interesting case happens when both hosts are behind a NAT. > The basic exchange is as follow: > > 1) Host A maintains UDP/IPv4 connection with a non NAT server. The > mapping is pinned in the NAT by regular refresh. The server tells A its > "mapped address", i.e. UDP port and IPv4 address as seen outside the > NAT. > > 2) Host B learns the "mapped address" of host A (i.e. IPv4 address and > UDP port). It sends a UDP packet directly to that address, effectively > creating a mapping in the local NAT. The packet is typically refused by > A's NAT, because no mapping exists yet for the communication between A > and B. > > 3) Host B also sends a packet to Host A through host A's server. Through > this packet, A learns the mapped address of B. > > 4) Host A sends a UDP/IPv4 packet to B. This packet is received, because > a mapping was installed at step 2. > [suresh] Thanks, Christian, for the details. For purposes of this discussion, I will assume, there is no IPv6 traffic involved and all hosts, servers and NATs mentioned are V4 based. > The bug we have observed is as follow: > > 1) ... > > 2) ... > > 2a) Upon receiving the packet from B, the NAT at Host A generates an > ICMP error message and sends it to B. [suresh] This is not good for P2P. For precisely this reason, the TCP behave draft recommends NATs to silently drop the inbound Syns, and not send an ICMP error message back. The UDP draft is silent about this. I believe, the UDP behave should also make the same recommendation. Any thoughts? > > 2b) Upon receiving the ICMP error, the NAT at host B destroys the > mapping established at step 2. > [suresh] This is not good. The above test steps are UDP centric. It is quite likely the behavior exists for TCP as well, especially as the TCP Session is in connecting state. Same might be true with ICMP and other NAT sessions as well. The specific requirement that an ICMP error should not destroy or age NAT session (no matter what protocol the session belongs to and what state the session is in) applies to all NAT Sessions and belongs in the ICMP draft, IMHO. regards, suresh > 3) .. > > 4) Host A sends a UDP/IPv4 packet to B. The packet is NOT received, > because a mapping was installed at step 2. > > -- Christian Huitema > > From srisuresh@yahoo.com Fri, 5 May 2006 04:05:24 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 5 May 2006 04:05:24 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <953beacc0605031948xb0a6548xfae6778eb149c966@mail.gmail.com> Message-ID: <20060505110524.73177.qmail@web33315.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Here is the status of the ICMP draft. As Dan mentioned in one of his e-mails, the authors of the ICMP draft have had a long private discussion on the ICMP requirements with Dan, Cullen and Fernando past couple of months. We had closure on all outstanding items durig the discussion. I had put out a revised ICMP draft on 05/01/06 for one more review by the same audience (authors, Dan, Cullen and Fernando) before submitting to the IETF. I will be submitting the updated draft this weekend. I fully expect this updated draft to be a WG item. Perhaps Dan can comment otherwise. regards, suresh --- Rohan Mahy wrote: > Hi Dan, > > If the ICMP draft was a stable WG item and the UDP draft normatively > referenced the ICMP draft, then this would be reorganization and I would not > care. It isn't. These requirements are needed to make UDP applications > work, and I believe that is non-controversial. The proposed "move" would > change what a NAT vendor has to do to claim compliance with the document. > Please just leave the requirements in place. > > thanks, > -rohan > > > > On 5/2/06, Dan Wing wrote: > > > > This email is to poll for consensus on moving the following requirements > > from the UDP document (draft-ietf-behave-nat-udp-05.txt) to the > > forthcoming > > BEHAVE working group ICMP document (currently > > draft-srisuresh-behave-nat-icmp-01.txt): > > > > REQ-12: Receipt of any sort of ICMP message MUST NOT destroy > > the NAT mapping. > > a) The NAT's default configuration SHOULD NOT filter > > ICMP messages based on their source IP address. > > b) It is RECOMMENDED that a NAT support ICMP > > Destination Unreachable messages. > > > > REQ-13: If the packet has DF=1, the NAT SHOULD send back an > > ICMP message "fragmentation needed and DF set" message > > to the host as described in RFC 792 [2]. > > a) If the packet has DF=0, the NAT SHOULD fragment > > the packet and send the fragments, in order. > > > > REQ-14: A NAT MUST support fragmentation of packets larger > > than link MTU. > > > > > > If you have an objection to moving these requirements from the UDP > > document > > to the ICMP document, please reply to this email. > > > > -d > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Fri, 5 May 2006 05:19:01 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 5 May 2006 05:19:01 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <9BB3068C-67F3-40F9-87A1-C0E7FC1150C2@cisco.com> Message-ID: <20060505121901.32032.qmail@web33301.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > > Yes, I have a serious objection. > > A long time ago we had these ICMP items in a separate draft from the > UDP. For several reason the WG decided to put the things that > effected UDP application into the UDP document. [suresh] Let me corect. Not long ago (05/2005), we had an independent behave-gen document that covered all Protocol independent stuff. The WG decided to keep all generic IP reqmts and common terminology in the UDP draft. At that time, there was no ICMP draft. So, the UDP draft kept the ICMP requirements it had (under the banner of generic IP requirements). > The document is now > past WGLC. We have people waiting to implement it. We need it. I see > no reason to play musical chairs with paragraphs of text at this > point in time. I see no new information that causes me to want to > reverse the decision the WG made when it decided to move these > together. I don't believe that separating them will improve the odds > of NAT vendors doing the things for UDP that they need to do for UDP > based application to be able to reliably work. If a ICMP draft gets > done, it could update this UPD draft. I will point out the ICMP draft > is not yet a WG item. [suresh] It is better to have a clear, non-ambiguous RFC out than one that would confuse people. You keep saying this is past WGLC, as though it is a sacrlege to comment past that. When a document goes through prolonged comments during a WGLC, it is normally customary to subject it to another WGLC after the updates are done. I have seen this done in many WGs. But, that was not the case with the UDP draft. UDP draft went through a prolonged discussion during WGLC. But, that was that. Tnere was no follow up. AT some point, the draft was considered a done deal. So, people did not have a chance to comment on the list after an updated draft was put out. Anyways, after the WGLC of the UDP draft was done, some of us had come out with an ICMP requirements draft, as per the milestone listed in the WG at the time. The ICMP draft had no choice but to overlap with some of the requirements already included in the UDP draft. But, there were no conflicts. Since the UDP draft was considered a "ready to publish" item, the subject of pullinthe ICMP requirements out of the UDP draft did not come up. > > Applications need the destination unreachable so that we know a host > is down and can use DNS to go to the next host. Applications need the > "Do Not Fragment" support so they can do MTU discover. Applications > need to know that fragmentation will work because MTU discovery does > not always work. This are things we all agree the WG agreed we need - > I object to removing them. I view the whole topic of even > considering removing them at this late stage of the game to be the > worst of distasteful standards gamesmanship when there is no reason > this could not have been brought up sooner. > [suresh] Cullen - You should look in the mirror before you call people names. I am not asking for the UDP draft to be blocked. I am merely commenting what I believe to be true - that requirements that ICMP centric and not UDP specific should be removed from the UDP draft. I do not play games. May be you do. >From my view point, this is exactly the right time to bring up the concerns. Here is three reasons why. a. When people including myself made comments on the UDP draft in the past, Francois commented this is a done deal and ready to be published and that it is not going to be changed. When I asked the WG chairs to respond if this was indeed the case, you (the WG chair at the time) did not respond. I assumed, Francois's comment must be true and made no further comments. Below is the reference e-mail, FYI. http://list.sipfoundry.org/archive/ietf-behave/msg01104.html b. As I mentioned in another thread, the authors of the ICMP draft had extensive review and discussion on the ICMP requirements with Dan. And, we closed on all the issues and put out an updated rev of the draft. You were also on the thread. Given all the consensus reached, I am of the opinion that it is very likely, the ICMP draft will be a WG item. c. Lastly, when I saw Magnus send his AD comments to the list, I figured this would be the right time to respond. I made comments in response to Magnus's comments and in light of the new development in item b) above. There is no games here, as you insinuate. cheers, suresh > Cullen (with my individual contributor hat on) > > > On May 2, 2006, at 2:48 PM, Dan Wing wrote: > > > This email is to poll for consensus on moving the following > > requirements > > from the UDP document (draft-ietf-behave-nat-udp-05.txt) to the > > forthcoming > > BEHAVE working group ICMP document (currently > > draft-srisuresh-behave-nat-icmp-01.txt): > > > > REQ-12: Receipt of any sort of ICMP message MUST NOT destroy > > the NAT mapping. > > a) The NAT's default configuration SHOULD NOT filter > > ICMP messages based on their source IP address. > > b) It is RECOMMENDED that a NAT support ICMP > > Destination Unreachable messages. > > > > REQ-13: If the packet has DF=1, the NAT SHOULD send back an > > ICMP message "fragmentation needed and DF set" message > > to the host as described in RFC 792 [2]. > > a) If the packet has DF=0, the NAT SHOULD fragment > > the packet and send the fragments, in order. > > > > REQ-14: A NAT MUST support fragmentation of packets larger > > than link MTU. > > > > > > If you have an objection to moving these requirements from the UDP > > document > > to the ICMP document, please reply to this email. > > > > -d > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From alan@polyphase.ca Fri, 5 May 2006 08:27:30 -0700 (PDT) From: Alan Hawrylyshen Date: Fri, 5 May 2006 08:27:30 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <07fa01c66e18$ff5d4190$d960150a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On May 2, 2006, at 12.48, Dan Wing wrote: If you have an objection to moving these requirements from the UDP document to the ICMP document, please reply to this email. The objection that I would raise is one of timing. I would like to see the UDP document published quickly and removing these items will delay the availability of a complete set of recommendations for implementors. Even if we 'hurry along' with the ICMP document, there will be significant lag in presenting the larger community with a document set that has concrete recommendations. I have seen time and time again at interop events where vendors have implemented _their_ interpretation of the standards; frequently a very misguided subset. It is my experience that providing clear, single source guidance to an implementation community leads to better interoperability. With those comments in mind, I would prefer to have a best effort at ensuring no conflict with the in-progress ICMP document and publishing the UDP draft quickly. Then, as required, we can have the ICMP draft update the UDP document. Thanks, Alan Hawrylyshen -- a l a n a t p o l y p h a s e d o t c a From mallman@icir.org Fri, 5 May 2006 09:20:33 -0700 (PDT) From: Mark Allman Date: Fri, 5 May 2006 09:20:33 -0700 (PDT) Subject: [Ietf-behave] comments on behave-tcp Message-ID: <20060505161936.119E6408222@lawyers.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Folks- I am one of the TCPM co-chairs and Lars asked us to get a couple reviews for the behave-tcp i-d. A couple folks volunteered and I expect their reviews will arrive soon. Below are my quick comments on the document. Basically, it looks fine to me. I found some of this a little hard to grok because of the dependence on [1]. A few more words around a bunch of the references might be useful to help give someone the context. (I am not advocating repeating all of [1], but a little more help would be helpful.) Swapping sections 4.2 and 4.3 would make things more natural to me. I didn't follow the bit about "masquerad[ing] as the NAT'ed endpoint" in section 8. What is this? I don't see how this is really practical unless the attacker is in the path. And, if that is the case then it seems like the NAT isn't going to be able to foil the attack anyway. Or, am I missing something here? For the last paragraph in section 8 I think it'd be useful to cite Joe Touch's antispoof document: draft-ietf-tcpm-tcp-antispoof-03.txt FWIW. allman Attachment: pgp00099.pgp --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00099.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00099.pgp" Content-Description: "Description: PGP signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjIgKERh cndpbikKCmlEOERCUUZFVzNzWVd5cnJXczR5SXM0UkFnUGhBS0NYRHN0bWVEWmYvVlFkT0R2UHRl c1NlTGlUTGdDY0NZY3EKaWRndE0vNFVLR0lNbk1kMmNXRDl1a1U9Cj0wWTB2Ci0tLS0tRU5EIFBH UCBTSUdOQVRVUkUtLS0tLQ== --Boundary..27398.1163630136.multipart/signed-- From huitema@windows.microsoft.com Fri, 5 May 2006 12:04:54 -0700 (PDT) From: "Christian Huitema" Date: Fri, 5 May 2006 12:04:54 -0700 (PDT) Subject: RE: [Ietf-behave] consensus query: -behave-nat-udp: movingrequirements In-Reply-To: Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0648A67F7@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain > With those comments in mind, I would prefer to have a best effort at > ensuring no conflict with the in-progress ICMP document and > publishing the UDP draft quickly. Then, as required, we can have the > ICMP draft update the UDP document. Yes. Please publish the UDP spec as is, including the requirements about how to handle ICMP packets that are triggered by UDP traffic. -- Christian Huitema From fluffy@cisco.com Fri, 5 May 2006 21:27:45 -0700 (PDT) From: Cullen Jennings Date: Fri, 5 May 2006 21:27:45 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <20060505110524.73177.qmail@web33315.mail.mud.yahoo.com> Message-ID: <4BE99C5E-5A8F-408E-AC73-422F2BE4D743@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On May 5, 2006, at 7:05 AM, Pyda Srisuresh wrote: I fully expect this updated draft to be a WG item. Perhaps Dan can comment otherwise. We have not even asked for WG consensus to adopt this draft, it's not clear we have a milestone fro the material in it. That would have to be dealt with first. From fluffy@cisco.com Fri, 5 May 2006 21:45:24 -0700 (PDT) From: Cullen Jennings Date: Fri, 5 May 2006 21:45:24 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <20060505121901.32032.qmail@web33301.mail.mud.yahoo.com> Message-ID: <009D14E8-EAEC-47C2-BF8A-59CC83E5C0BD@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On May 5, 2006, at 8:19 AM, Pyda Srisuresh wrote: When I asked the WG chairs to respond if this was indeed the case, you (the WG chair at the time) did not respond. I assumed, Francois's comment must be true and made no further comments. Below is the reference e-mail, FYI. http://list.sipfoundry.org/archive/ietf-behave/msg01104.html To quote your question from the email you reference below, you say On Jan 4, 2006, at 5:21 PM, Pyda Srisuresh wrote: Question to the WG chairs and AD: Is the UDP rev 4 draft assumed to have been reviewed and approved by the WG and the IESG? This email was not sent to the chairs or the AD and I suspect that many people probably interepreted this as a retorical question. You have publihsed RFCs and ceritaily must be aware of the process and that this draft had not been aproved by IESG. As you well know, it is easy to go check on what has been aproved by the IESG not to mention you would have seen things such as the IETF Last Call for the call before it was aproved by IESG.. From magnus.westerlund@ericsson.com Sat, 6 May 2006 04:52:22 -0700 (PDT) From: Magnus Westerlund Date: Sat, 6 May 2006 04:52:22 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: movingrequirements In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0648A67F7@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <445C8DF0.8090802@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, To me it seems too disrupting to the timeliness of the UDP draft to remove the ICMP requirements from it. There seems to be rough consensus also on this. So lets go forward with the update of the draft so that we can get this document published. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From srisuresh@yahoo.com Sat, 6 May 2006 13:28:03 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 6 May 2006 13:28:03 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <4BE99C5E-5A8F-408E-AC73-422F2BE4D743@cisco.com> Message-ID: <20060506202803.9853.qmail@web33313.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, I am not against WG consensus. However, I dont recall, you had WG consensus, when you removed the ICMP milestone from the WG charter in the first place. regards, suresh --- Cullen Jennings wrote: > > On May 5, 2006, at 7:05 AM, Pyda Srisuresh wrote: > > > I fully expect this updated draft to be a WG item. Perhaps Dan can > > comment > > otherwise. > > We have not even asked for WG consensus to adopt this draft, it's not > clear we have a milestone fro the material in it. That would have to > be dealt with first. > > > From fluffy@cisco.com Sat, 6 May 2006 20:16:02 -0700 (PDT) From: Cullen Jennings Date: Sat, 6 May 2006 20:16:02 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <20060506202803.9853.qmail@web33313.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain We've talked about the process around charters, milestones, and WG drafts before. I don't know what I can say that I have not said before so I think I probably won't try to do it in email. I don't think there has been any process violation here or things that needed WG consensus done without WG consensus. If you think there has been or just want to understand why, I'm glad to have a phone call about this some time. Cullen On May 6, 2006, at 4:28 PM, Pyda Srisuresh wrote: Cullen, I am not against WG consensus. However, I dont recall, you had WG consensus, when you removed the ICMP milestone from the WG charter in the first place. regards, suresh --- Cullen Jennings wrote: On May 5, 2006, at 7:05 AM, Pyda Srisuresh wrote: I fully expect this updated draft to be a WG item. Perhaps Dan can comment otherwise. We have not even asked for WG consensus to adopt this draft, it's not clear we have a milestone fro the material in it. That would have to be dealt with first. From saikat@cs.cornell.edu Sun, 7 May 2006 18:19:07 -0700 (PDT) From: Saikat Guha Date: Sun, 7 May 2006 18:19:07 -0700 (PDT) Subject: Re: [Ietf-behave] comments on behave-tcp In-Reply-To: <20060505161936.119E6408222@lawyers.icir.org> Message-ID: <1147051145.25590.20.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Mark, Thanks for taking the time to review the document. Comments inline. On Fri, 2006-05-05 at 12:19 -0400, Mark Allman wrote: > I found some of this a little hard to grok because of the dependence on > [1]. A few more words around a bunch of the references might be useful Ok. > Swapping sections 4.2 and 4.3 would make things more natural to me. My intention was to talk about internally initiated connections first since it is the common mode of operation of a NAT, and an internal connection needs to be established first before external connections can be initiated. Can you help me understand a bit more why 4.3 before 4.2 would make things more natural for a reader. > I didn't follow the bit about "masquerad[ing] as the NAT'ed endpoint" in > section 8. What is this? I don't see how this is really practical > unless the attacker is in the path. I suppose it is less important now since most stacks pick random initial sequence numbers. If the sequence number were easily guessable by an off-path attacker, then the attacker could spoof the entire TCP stream. > For the last paragraph in section 8 I think it'd be useful to cite Joe > Touch's antispoof document: draft-ietf-tcpm-tcp-antispoof-03.txt Ok. Thanks! -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00100.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00100.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFWHB5Sm5GbHRxaTY5MS9vUkFvMU9BSjk3VG1Ma1lUelJxcDNKT2d2 NWFYNEtVdWtVbVFDY0RQcXYKcG05ZlFkNjNCRklsaGhHVTdnMFdMN009Cj1lR2c1Ci0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Sun, 7 May 2006 18:21:45 -0700 (PDT) From: Saikat Guha Date: Sun, 7 May 2006 18:21:45 -0700 (PDT) Subject: Re: [Ietf-behave] TCP equivalent of UDP Req-5 (Was: RE: Req-5) In-Reply-To: Message-ID: <1147051304.25590.24.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-05-03 at 09:05 -0400, Philip Matthews wrote: > Speaking personally, I am concerned with both the application and the > TCP state machine in the > underlying OS. Fair enough. > So when things are left unspecified (like how long the NAT's state > machine > should remain in the TIME_WAIT state), then I personally would like > to see the document > give some suggestions or guidelines to NAT implementors on what are > acceptable implementation choices, and what to watch out for. Ok. I'll incorporate the text you suggested into the draft. Essentially to the effect that it is up to the vendor and it would be nice if they were to stick to 4 minutes, but there may be reasons to reduce it, which may in turn cause certain side-effects and one way to handle such effects. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00101.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00101.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFWHAwb25GbHRxaTY5MS9vUkFoSmFBSjQ2NkZUUDdJTjB6blRJSnZO a0tpWUxUVFhwSWdDZU4rMHIKdExNQlhlQ1FEaC9lcVgrakdCN1VaYm89Cj1Xd0RmCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From srisuresh@yahoo.com Sun, 7 May 2006 18:23:13 -0700 (PDT) From: Pyda Srisuresh Date: Sun, 7 May 2006 18:23:13 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <009D14E8-EAEC-47C2-BF8A-59CC83E5C0BD@cisco.com> Message-ID: <20060508012312.85793.qmail@web33301.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > > > On May 5, 2006, at 8:19 AM, Pyda Srisuresh wrote: > > > When I asked the WG chairs to respond if this was > > indeed the case, you (the WG chair at the time) did not respond. I > > assumed, > > Francois's comment must be true and made no further comments. Below > > is the > > reference e-mail, FYI. > > > > http://list.sipfoundry.org/archive/ietf-behave/msg01104.html > > > To quote your question from the email you reference below, you say > > On Jan 4, 2006, at 5:21 PM, Pyda Srisuresh wrote: > > Question to the WG chairs and AD: Is the UDP rev 4 draft assumed to > > have been > > reviewed and approved by the WG and the IESG? > > > > This email was not sent to the chairs or the AD and I suspect that > many people probably interepreted this as a retorical question. [suresh] Cullen - The WG chairs are supposed to be on the list by default, AFAIK. I should not have to Cc the WG chairs explicitly. I did not Cc Jon explicitly because he had commented on the list in the past, even as he was not explicitly Cced. So, I figured, he must also be on the list. The question was clearly directed at the WG chairs and the AD. I dont understand how that coudl have been interpreted as rhetorical by anyone. Certainly you, as WG chair, coudl have responded. > You > have publihsed RFCs and ceritaily must be aware of the process and > that this draft had not been aproved by IESG. As you well know, it is > easy to go check on what has been aproved by the IESG not to mention > you would have seen things such as the IETF Last Call for the call > before it was aproved by IESG.. > [suresh] Processes change. When in doubt, one seeks clarification from WG chair. Francois made the satetment several times about the draft bein in done state. You never bothered to correct that. The first time I understood that UDP draft was up for comments was when Dan pointed out to me in a private e-mail that he had not sent PROTOS comments on it yet and hence is still open to comments. PROTOS comments is a new process. Within a few days after that, Dan sent his PROTOS comments to the list. Magnus followed with his comments. I responded with my concerns. cheers, suresh From mallman@icir.org Sun, 7 May 2006 19:40:17 -0700 (PDT) From: Mark Allman Date: Sun, 7 May 2006 19:40:17 -0700 (PDT) Subject: Re: [Ietf-behave] comments on behave-tcp In-Reply-To: <1147051145.25590.20.camel@localhost.localdomain> Message-ID: <20060508023917.31D2B409930@lawyers.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit > > Swapping sections 4.2 and 4.3 would make things more natural to me. > > My intention was to talk about internally initiated connections first > since it is the common mode of operation of a NAT, and an internal > connection needs to be established first before external connections can > be initiated. > > Can you help me understand a bit more why 4.3 before 4.2 would make > things more natural for a reader. Ignore my comment. It was the drugs. You're clearly right. > > I didn't follow the bit about "masquerad[ing] as the NAT'ed > > endpoint" in section 8. What is this? I don't see how this is > > really practical unless the attacker is in the path. > > I suppose it is less important now since most stacks pick random > initial sequence numbers. If the sequence number were easily guessable > by an off-path attacker, then the attacker could spoof the entire TCP > stream. I still don't really understand what you're talking about. How about a quick example of this masquerading that you're worried about? allman Attachment: pgp00102.pgp --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00102.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00102.pgp" Content-Description: "Description: PGP signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjIgKERh cndpbikKCmlEOERCUUZFWHE5VVd5cnJXczR5SXM0UkFuRUFBSjlrM1VBK1F4SHJnWE91SDgveDRj K1NpRWxIdmdDZld6eHcKSnF5VEkxOHB3Z1JmSVI0U1ZZM0t3akE9Cj11STMwCi0tLS0tRU5EIFBH UCBTSUdOQVRVUkUtLS0tLQ== --Boundary..27398.1163630136.multipart/signed-- From gregd@research.panasonic.com Mon, 8 May 2006 09:14:20 -0700 (PDT) From: Greg Daley Date: Mon, 8 May 2006 09:14:20 -0700 (PDT) Subject: [Ietf-behave] REALM in draft-ietf-behave-rfc3489bis-03 Message-ID: <445F6E5B.7050703@research.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain Hi, I've got a question about use of REALM in RFC3489bis-03, which was raised by one of our developers. Is it necessary to test for the REALM attribute in received Request messages, even if Short Term credentials are being used? When using method two from Section 8.1.2: 2. use a short term credential, as determined by the STUN usage. In this case, the STUN Request or STUN Indication would contain the USERNAME and MESSAGE-INTEGRITY attributes. The message would not contain the NONCE attribute. The key for MESSAGE-INTEGRITY is the password. There's no REALM, but in section 9.1.1 (paragraph 2 of page 18): If the MESSAGE-INTEGRITY attribute was present, the server checks for the existence of the REALM attribute. If the attribute is not present, the server MUST generate an error response. That error response MUST include an ERROR-CODE attribute with response code of 434. That error response MUST also include a NONCE and a REALM attribute. This seems to conflict, in that it implies that the REALM is always present if MESSAGE-INTEGRITY is present. Also, it's not exactly obvious in the document, what constitutes Short Term and Long Term authentication. It is possible to infer that Short Term authentication is using Shared Secret Request, ICE or equivalent, but there's little description of Long Term authentication (reference to 3261 section 22 is probably appropriate). The most appropriate description of the terms I found was in: http://permalink.gmane.org/gmane.ietf.nat.behave/776 Clarification within the document would be appreciated. Greg Daley From dwing@cisco.com Mon, 8 May 2006 11:05:13 -0700 (PDT) From: "Dan Wing" Date: Mon, 8 May 2006 11:05:13 -0700 (PDT) Subject: [Ietf-behave] PROTOS In-Reply-To: <20060508012312.85793.qmail@web33301.mail.mud.yahoo.com> Message-ID: <0b5101c672c9$f4580540$179a150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Pyda Srisuresh wrote: ... > The first time I understood that UDP draft was up for > comments was when Dan pointed out to me in a private e-mail > that he had not sent PROTOS comments on it yet and hence is > still open to comments. PROTOS comments is a new process. > Within a few days after that, Dan sent his PROTOS comments to > the list. Magnus followed with his comments. I responded with > my concerns. (It's my mistake for adding an "S" to PROTO, because there is a test suite called PROTOS. Sorry. Anyway, it's "PROTO".) Magnus had asked me to do the two write-ups described in draft-ietf-proto-wgchair-doc-shepherding-06.txt, to give this new procedure a try. In this procedure, the shepherding working group chair (me, in this case) does a write-up which is used during IESG review of the document. Prior to having the entire IESG review the document, Magnus gave it a careful read and had suggested changes. However, as you know, the document itself had its initial WGLC in April 2005 -- a year ago. http://list.sipfoundry.org/archive/ietf-behave/msg00606.html Even then there was an active discussion of how to split protocol-specific and non-protocol-specific text amongst several drafts. Over the weekend Magnus, our current AD, has said we should progress with the UDP document as-is, which matches with the consensus of the WG. In the archives and in the current discussion I could only find objections to this from you (srisuresh@xxxxxxxxx) and Byran Ford regarding this split, and Bryan seemed Last week in private email to me, Magnus proposed an idea -- publish UDP as-is, publish TCP and ICMP (in whatever order they're done) and ensure there are no conflicts. Then, if there is energy, publish an RFC1812-like document that combines UDP, TCP, IP, ICMP, and perhaps SCTP, DCCP, and whatever else needs a protocol-specific document, which would supercede the older, independant documents. Thank you for submitting your revised ICMP document; this will allow the WG to determine if it is scoped according to people's expectations and if it should be added as a milestone. -d From dwing@cisco.com Mon, 8 May 2006 11:42:07 -0700 (PDT) From: "Dan Wing" Date: Mon, 8 May 2006 11:42:07 -0700 (PDT) Subject: [Ietf-behave] PROTOS In-Reply-To: <20060508012312.85793.qmail@web33301.mail.mud.yahoo.com> Message-ID: <0c6b01c672cf$1b5bde00$179a150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain [resending because I had an incomplete paragraph. Thanks for pointing that out, Jiri.] Pyda Srisuresh wrote: ... > The first time I understood that UDP draft was up for > comments was when Dan pointed out to me in a private e-mail > that he had not sent PROTOS comments on it yet and hence is > still open to comments. PROTOS comments is a new process. > Within a few days after that, Dan sent his PROTOS comments to > the list. Magnus followed with his comments. I responded with > my concerns. (It's my mistake for adding an "S" to PROTO, because there is a test suite called PROTOS. Sorry. Anyway, it's "PROTO".) Magnus had asked me to do the two write-ups described in draft-ietf-proto-wgchair-doc-shepherding-06.txt, to give this new procedure a try. In this procedure, the shepherding working group chair (me, in this case) does a write-up which is used during IESG review of the document. Prior to having the entire IESG review the document, Magnus gave it a careful read and had suggested changes. However, as you know, the document itself had its initial WGLC in April 2005 -- a year ago. http://list.sipfoundry.org/archive/ietf-behave/msg00606.html Even then there was an active discussion of how to split protocol-specific and non-protocol-specific text amongst several drafts. Over the weekend Magnus, our current AD, has said we should progress with the UDP document as-is, which matches with the consensus of the WG. In the archives and in the current discussion I could only find objections to this from you (srisuresh@xxxxxxxxx) and Byran Ford regarding this split. But Bryan seemed to agree keeping some non-UDP stuff in there would be alright when he wrote: http://list.sipfoundry.org/archive/ietf-behave/msg00681.html Last week in private email to me, Magnus proposed an idea -- publish UDP as-is, publish TCP and ICMP (in whatever order they're done) and ensure there are no conflicts. Then, if there is energy, publish an RFC1812-like document that combines UDP, TCP, IP, ICMP, and perhaps SCTP, DCCP, and whatever else needs a protocol-specific document, which would supercede the older, independant documents. Thank you for submitting your revised ICMP document; this will allow the WG to determine if it is scoped according to people's expectations and if it should be added as a milestone. -d From srisuresh@yahoo.com Mon, 8 May 2006 15:59:02 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 8 May 2006 15:59:02 -0700 (PDT) Subject: [Ietf-behave] Re: PROTOS In-Reply-To: <0c6b01c672cf$1b5bde00$179a150a@amer.cisco.com> Message-ID: <20060508225156.93901.qmail@web33301.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dan Wing wrote: > [resending because I had an incomplete paragraph. Thanks for pointing that > out, Jiri.] > > Pyda Srisuresh wrote: > ... > > The first time I understood that UDP draft was up for > > comments was when Dan pointed out to me in a private e-mail > > that he had not sent PROTOS comments on it yet and hence is > > still open to comments. PROTOS comments is a new process. > > Within a few days after that, Dan sent his PROTOS comments to > > the list. Magnus followed with his comments. I responded with > > my concerns. > > (It's my mistake for adding an "S" to PROTO, because there is a > test suite called PROTOS. Sorry. Anyway, it's "PROTO".) > > Magnus had asked me to do the two write-ups described in > draft-ietf-proto-wgchair-doc-shepherding-06.txt, to give > this new procedure a try. In this procedure, the shepherding > working group chair (me, in this case) does a write-up which > is used during IESG review of the document. > [suresh] OK. > Prior to having the entire IESG review the document, Magnus > gave it a careful read and had suggested changes. However, > as you know, the document itself had its initial WGLC in > April 2005 -- a year ago. > > http://list.sipfoundry.org/archive/ietf-behave/msg00606.html > > Even then there was an active discussion of how to split > protocol-specific and non-protocol-specific text amongst > several drafts. > > Over the weekend Magnus, our current AD, has said we should > progress with the UDP document as-is, which matches with the > consensus of the WG. > > In the archives and in the current discussion I could only > find objections to this from you (srisuresh@xxxxxxxxx) > and Byran Ford regarding this split. But Bryan seemed to > agree keeping some non-UDP stuff in there would be alright > when he wrote: > http://list.sipfoundry.org/archive/ietf-behave/msg00681.html > [suresh] Dan - During WGLC, we had identified 2 choices. Have a seperate document for Generic requirements (or) keep them in the UDP draft. On the name of expeditious completion, the WG opted to go with the latter. I went along with that. At the time, the WG charter also had a milestone for ICMP requirements. The above WG choice did not imply eliminating the ICMP requirements milestone. I checked with Jon, the AD at the time, on whether the ICMP milestone still existed. And, he mentioned to me that the ICMP milestone remained and still existed. That confirmation from the AD was the genesis of the ICMP draft. Attempts by me and the co-authors in requesting the draft for adaption as WG document fell in the deaf ears. The WG chairs simply did not respond. On top of that, when the Behave charter was redone to add media realy milstones to the charter, the WG chairs simply eliminated the ICMP milestone without seeking any input from the list. That was callous. We discussed ICMP overlaps on the list before. This is not new. During that time, when UDP draft was considered sancrosact, I did say the overlap was OK, so long as there is no conflict between the drafts. When Magnus sent his AD comments to the list, it seemed appropriate to bring up the ICMP overlap. My intent was to use the opportunity to keep the UDP draft clean and remove the ICMP overlap. Once again, On the name of expeditious completion, the WG seems to have opted to go with keeping the overlap requirements in the UDP draft. > > Last week in private email to me, Magnus proposed an idea > -- publish UDP as-is, publish TCP and ICMP (in whatever order > they're done) and ensure there are no conflicts. [suresh] Glad to see that the ICMP requirements is on the agenda. > Then, if > there is energy, publish an RFC1812-like document that > combines UDP, TCP, IP, ICMP, and perhaps SCTP, DCCP, and > whatever else needs a protocol-specific document, which > would supercede the older, independant documents. > > > Thank you for submitting your revised ICMP document; this > will allow the WG to determine if it is scoped according > to people's expectations and if it should be added as a > milestone. [suresh] You are welcome. Thank you for your detailed feedback. I am looking forward to hearing feedback from the list. regards, suresh > > -d > From dwing@cisco.com Mon, 8 May 2006 17:04:58 -0700 (PDT) From: "Dan Wing" Date: Mon, 8 May 2006 17:04:58 -0700 (PDT) Subject: [Ietf-behave] Milestones, ICMP Message-ID: <13da01c672fc$35eae770$179a150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I would like the list to consider having draft-srisuresh-behave-nat-icmp-02.txt become a WG item. I expect its milestone would align with the TCP document, which will have its milestone date pushed out to sometime this fall, as the working group needs to concentrate its efforts on the revision to STUN (rfc3489bis) and on TURN, which are needed for VoIP. Please provide comments to the list. -d From iesg-secretary@ietf.org Tue, 9 May 2006 07:42:35 -0700 (PDT) From: The IESG Date: Tue, 9 May 2006 07:42:35 -0700 (PDT) Subject: [Ietf-behave] Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) Message-ID: MIME-Version: 1.0 Content-Type: text/plain The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG to consider the following document: - 'NAT Behavioral Requirements for Unicast UDP ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2006-05-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-06.txt From Internet-Drafts@ietf.org Mon, 8 May 2006 15:50:02 -0700 (PDT) From: Internet-Drafts@ietf.org Date: Mon, 8 May 2006 15:50:02 -0700 (PDT) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-nat-udp-06.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for Unicast UDP Author(s) : F. Audet, C. Jennings Filename : draft-ietf-behave-nat-udp-06.txt Pages : 28 Date : 2006-5-8 This document defines basic terminology for describing different types of NAT behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or on-line gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-nat-udp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-nat-udp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From fluffy@cisco.com Tue, 9 May 2006 16:50:31 -0700 (PDT) From: Cullen Jennings Date: Tue, 9 May 2006 16:50:31 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <20060508012312.85793.qmail@web33301.mail.mud.yahoo.com> Message-ID: <023A61EB-C35C-4D90-AFDC-094ECDF6F9A1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On May 7, 2006, at 6:23 PM, Pyda Srisuresh wrote: --- Cullen Jennings wrote: On May 5, 2006, at 8:19 AM, Pyda Srisuresh wrote: When I asked the WG chairs to respond if this was indeed the case, you (the WG chair at the time) did not respond. I assumed, Francois's comment must be true and made no further comments. Below is the reference e-mail, FYI. http://list.sipfoundry.org/archive/ietf-behave/msg01104.html To quote your question from the email you reference below, you say On Jan 4, 2006, at 5:21 PM, Pyda Srisuresh wrote: Question to the WG chairs and AD: Is the UDP rev 4 draft assumed to have been reviewed and approved by the WG and the IESG? This email was not sent to the chairs or the AD and I suspect that many people probably interepreted this as a retorical question. [suresh] Cullen - The WG chairs are supposed to be on the list by default, AFAIK. I should not have to Cc the WG chairs explicitly. I did not Cc Jon explicitly because he had commented on the list in the past, even as he was not explicitly Cced. So, I figured, he must also be on the list. The question was clearly directed at the WG chairs and the AD. I dont understand how that coudl have been interpreted as rhetorical by anyone. Certainly you, as WG chair, coudl have responded. You have publihsed RFCs and ceritaily must be aware of the process and that this draft had not been aproved by IESG. As you well know, it is easy to go check on what has been aproved by the IESG not to mention you would have seen things such as the IETF Last Call for the call before it was aproved by IESG.. [suresh] Processes change. When in doubt, one seeks clarification from WG chair. Francois made the satetment several times about the draft bein in done state. You never bothered to correct that. The first time I understood that UDP draft was up for comments was when Dan pointed out to me in a private e-mail that he had not sent PROTOS comments on it yet and hence is still open to comments. PROTOS comments is a new process. Within a few days after that, Dan sent his PROTOS comments to the list. Magnus followed with his comments. I responded with my concerns. cheers, suresh There is probably not much more to say about this but in defense of the ADs, do consider that reading all the email on all the lists they are subscribed to is probably not feasible. From saikat@cs.cornell.edu Tue, 9 May 2006 18:40:03 -0700 (PDT) From: Saikat Guha Date: Tue, 9 May 2006 18:40:03 -0700 (PDT) Subject: Re: [Ietf-behave] comments on behave-tcp In-Reply-To: <20060508023917.31D2B409930@lawyers.icir.org> Message-ID: <1147225198.15969.17.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2006-05-07 at 22:39 -0400, Mark Allman wrote: > > > I didn't follow the bit about "masquerad[ing] as the NAT'ed > > > endpoint" in section 8. What is this? I don't see how this is > > > really practical unless the attacker is in the path. The concern was that an off-path attacker can spoof an entire TCP session (if the initial sequence number can be guessed). X | A ----- N -----------+------- B 1. X sends SYN to B. Spoof's source address as N. 2. X predicts B's initial sequence number. Say 0. 3. B sends SYNACK to N. N drops it silently. 4. X sends ACK packet with A's spoofed source ack'ing B's guessed sequence #. Packet may contain data. 5. B acks data to N. N drops packets. 6. X sends more data and so on X can blindly spoof A. If N were to send some response to packets 3 or 5, like a RST for example ... then A/N's identity could not have been impersonated. To that effect, the idea is to allow the NAT to respond to any packet other than the initial incoming SYN with a RST if the vendor so decides. The RST on SYN doesn't buy any extra security since this issue arises only when the SYN was sent by the attacker (and therefor didn't cross the NAT). In any event, there are subsequent packets to refute if such an attack is underway -- like the ACK or SYNACK. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00103.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00103.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChHTlUv TGludXgpCgppRDhEQlFCRVlVUnRuRmx0cWk2OTEvb1JBcTFxQUowYnJ2TERwaEZQS2F0NnRLZEln TVZNWFFZS29BQ2ZmdUFuCk1YemJTRTh2bWJBcHNNN2lHcEtWRFU4PQo9Qy9PZgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630136.multipart/signed-- From mallman@icir.org Tue, 9 May 2006 19:18:38 -0700 (PDT) From: Mark Allman Date: Tue, 9 May 2006 19:18:38 -0700 (PDT) Subject: Re: [Ietf-behave] comments on behave-tcp In-Reply-To: <1147225198.15969.17.camel@localhost.localdomain> Message-ID: <20060510021732.B02B540AE6F@lawyers.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit > The concern was that an off-path attacker can spoof an entire TCP > session (if the initial sequence number can be guessed). > > X > | > A ----- N -----------+------- B > > > > 1. X sends SYN to B. Spoof's source address as N. > 2. X predicts B's initial sequence number. Say 0. > 3. B sends SYNACK to N. N drops it silently. > 4. X sends ACK packet with A's spoofed source ack'ing B's guessed > sequence #. Packet may contain data. > 5. B acks data to N. N drops packets. > 6. X sends more data and so on I see where you're going now. This seems like a really theoretical attack to me. First we know that ISNs ought to be random - which essentially defeats this attack. But, even if you hit the ISN lottery X has to guess what was sent and if B needs more than simple ACKs (e.g., an application reply) to continue then you're hosed. Basically, for this document I don't even see a point in raising this issue. Because it's not an issue. But, if you are going to raise it, I'd recommend more than one passing remark about it. You should fully explain this "threat". allman Attachment: pgp00104.pgp --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00104.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00104.pgp" Content-Description: "Description: PGP signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjIgKERh cndpbikKCmlEOERCUUZFWVUwOFd5cnJXczR5SXM0UkF1OVVBSjQzaUdUOU9mOFpFMHVaUHhINi9J blBlUVhmcmdDZ2g5aFoKd2JLaFcveXNzYmpZaEE0UTByNUN5WUE9Cj1qaVBDCi0tLS0tRU5EIFBH UCBTSUdOQVRVUkUtLS0tLQ== --Boundary..27398.1163630136.multipart/signed-- From philip_matthews@magma.ca Wed, 10 May 2006 05:44:13 -0700 (PDT) From: Philip Matthews Date: Wed, 10 May 2006 05:44:13 -0700 (PDT) Subject: Re: [Ietf-behave] Milestones, ICMP In-Reply-To: <13da01c672fc$35eae770$179a150a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I support having the ICMP draft becoming a WG work item. I agree that the WG needs to concentrate on STUN and TURN, which are needed for ICE. - Philip On 8-May-06, at 20:04 , Dan Wing wrote: I would like the list to consider having draft-srisuresh-behave-nat-icmp-02.txt become a WG item. I expect its milestone would align with the TCP document, which will have its milestone date pushed out to sometime this fall, as the working group needs to concentrate its efforts on the revision to STUN (rfc3489bis) and on TURN, which are needed for VoIP. Please provide comments to the list. -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From saikat@cs.cornell.edu Wed, 10 May 2006 09:05:37 -0700 (PDT) From: Saikat Guha Date: Wed, 10 May 2006 09:05:37 -0700 (PDT) Subject: Re: [Ietf-behave] comments on behave-tcp In-Reply-To: <20060510021732.B02B540AE6F@lawyers.icir.org> Message-ID: <1147277134.15969.45.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2006-05-09 at 22:17 -0400, Mark Allman wrote: > Basically, for this document I don't even see a point in raising this > issue. Because it's not an issue. But, if you are going to raise it, > I'd recommend more than one passing remark about it. Fair enough. Actually, come to think on the flip side sending the RST can actually (slightly) worsen a DoS attack. If no RST is sent, the attacker spoofs many SYN packets, the target responds with SYNACKs (potentially using TCP SYN-cookies) and network bandwidth is used. If an RST is sent by N, then that amplifies the DoS by 50% (3 packets instead of 2). As for the TCP blindly spoofing a connection, I suspect you are right that it is theoretical today. I do recall hearing about someone actually pulling it off a long long time ago (the Mitnik case was it perhaps?) but there the victim stack was hardcoded to use ISN=0 I think. In any event, I agree that the issues on both sides should be made more clear. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00105.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00105.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChHTlUv TGludXgpCgppRDhEQlFCRVlnOU9uRmx0cWk2OTEvb1JBdXF4QUo5aUtGV3hmSkE4dkVIUk9SQmdS aVI5YllqU2hBQ2FBdzJyCk1ObitML2lWd0hSUlBlS0J4TXd0cW9jPQo9cm1vQQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630136.multipart/signed-- From fernando@gont.com.ar Thu, 11 May 2006 04:00:31 -0700 (PDT) From: Fernando Gont Date: Thu, 11 May 2006 04:00:31 -0700 (PDT) Subject: Re: [Ietf-behave] Milestones, ICMP In-Reply-To: <13da01c672fc$35eae770$179a150a@amer.cisco.com> Message-ID: <7.0.1.0.0.20060511054657.04709670@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain At 09:45 10/05/2006, Philip Matthews wrote: It seems I didn't receive the original post from Dan, so I am answering to this e-mail instead. I support the ICMP draft in becoming a WG item. Kindest regards, Fernando Gont I support having the ICMP draft becoming a WG work item. I agree that the WG needs to concentrate on STUN and TURN, which are needed for ICE. - Philip On 8-May-06, at 20:04 , Dan Wing wrote: I would like the list to consider having draft-srisuresh-behave-nat-icmp-02.txt become a WG item. I expect its milestone would align with the TCP document, which will have its milestone date pushed out to sometime this fall, as the working group needs to concentrate its efforts on the revision to STUN (rfc3489bis) and on TURN, which are needed for VoIP. Please provide comments to the list. -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From srisuresh@yahoo.com Thu, 11 May 2006 07:04:56 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 11 May 2006 07:04:56 -0700 (PDT) Subject: Re: [Ietf-behave] consensus query: -behave-nat-udp: moving requirements In-Reply-To: <023A61EB-C35C-4D90-AFDC-094ECDF6F9A1@cisco.com> Message-ID: <20060511140456.72581.qmail@web33301.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, Yes, I do give benefit of doubt to the AD at the time. But, let us step back a bit. This is not so much about the AD. This is about what you, as WG chair, did not do to encoourage comments on the draft, ever since we had WGLC. WG chairs are supposed to be on the list and monitoring e-mails on the list. As WG chair, you could have corrected and solicited comments. But, you did not. Francois made similar comments afterwards as well on the list when people commented on the draft. But, you, as WG chair, remained quiet and did not encourage any additional comments. As WG chair, you also did not call a WGLC after the rather prolonged initial WGLC. In summary, not only did you not solicit additional comments from the list, you did not bother to correct misconceptions that the draft is a done deal. Yet, when the judgement time came, and I send what I believe to be very legitimate concerns, you, as individual contributor, call it "distasteful standards gamesmanship". This, I find, hypocritical. regards, suresh --- Cullen Jennings wrote: > > On May 7, 2006, at 6:23 PM, Pyda Srisuresh wrote: > > > > > > > --- Cullen Jennings wrote: > > > >> > >> > >> On May 5, 2006, at 8:19 AM, Pyda Srisuresh wrote: > >> > >>> When I asked the WG chairs to respond if this was > >>> indeed the case, you (the WG chair at the time) did not respond. I > >>> assumed, > >>> Francois's comment must be true and made no further comments. Below > >>> is the > >>> reference e-mail, FYI. > >>> > >>> http://list.sipfoundry.org/archive/ietf-behave/msg01104.html > >> > >> > >> To quote your question from the email you reference below, you say > >> > >> On Jan 4, 2006, at 5:21 PM, Pyda Srisuresh wrote: > >>> Question to the WG chairs and AD: Is the UDP rev 4 draft assumed to > >>> have been > >>> reviewed and approved by the WG and the IESG? > >>> > >> > >> This email was not sent to the chairs or the AD and I suspect that > >> many people probably interepreted this as a retorical question. > > > > [suresh] Cullen - The WG chairs are supposed to be on the list by > > default, > > AFAIK. I should not have to Cc the WG chairs explicitly. I did not > > Cc Jon > > explicitly because he had commented on the list in the past, even > > as he was not > > explicitly Cced. So, I figured, he must also be on the list. The > > question was > > clearly directed at the WG chairs and the AD. I dont understand how > > that coudl > > have been interpreted as rhetorical by anyone. Certainly you, as WG > > chair, > > coudl have responded. > > > >> You > >> have publihsed RFCs and ceritaily must be aware of the process and > >> that this draft had not been aproved by IESG. As you well know, it is > >> easy to go check on what has been aproved by the IESG not to mention > >> you would have seen things such as the IETF Last Call for the call > >> before it was aproved by IESG.. > >> > > [suresh] Processes change. When in doubt, one seeks clarification > > from WG > > chair. Francois made the satetment several times about the draft > > bein in done > > state. You never bothered to correct that. > > > > The first time I understood that UDP draft was up for comments was > > when Dan > > pointed out to me in a private e-mail that he had not sent PROTOS > > comments on > > it yet and hence is still open to comments. PROTOS comments is a > > new process. > > Within a few days after that, Dan sent his PROTOS comments to the > > list. Magnus > > followed with his comments. I responded with my concerns. > > > > cheers, > > suresh > > There is probably not much more to say about this but in defense of > the ADs, do consider that reading all the email on all the lists they > are subscribed to is probably not feasible. > > > From philip_matthews@magma.ca Fri, 12 May 2006 07:31:16 -0700 (PDT) From: Philip Matthews Date: Fri, 12 May 2006 07:31:16 -0700 (PDT) Subject: Re: [Ietf-behave] TCP equivalent of UDP Req-5 (Was: RE: Req-5) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Saikat: Sorry to be slow in responding, but I was away. What you said below sounds fine to me. - Philip On 7-May-06, at 21:21 , Saikat Guha wrote: On Wed, 2006-05-03 at 09:05 -0400, Philip Matthews wrote: Speaking personally, I am concerned with both the application and the TCP state machine in the underlying OS. Fair enough. So when things are left unspecified (like how long the NAT's state machine should remain in the TIME_WAIT state), then I personally would like to see the document give some suggestions or guidelines to NAT implementors on what are acceptable implementation choices, and what to watch out for. Ok. I'll incorporate the text you suggested into the draft. Essentially to the effect that it is up to the vendor and it would be nice if they were to stick to 4 minutes, but there may be reasons to reduce it, which may in turn cause certain side-effects and one way to handle such effects. cheers, -- Saikat From gregd@research.panasonic.com Tue, 16 May 2006 06:56:07 -0700 (PDT) From: Greg Daley Date: Tue, 16 May 2006 06:56:07 -0700 (PDT) Subject: [Ietf-behave] STUN message length in rfc3489bis Message-ID: <4469D9EC.1000203@research.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain Hi, (Cc: authors) Is it really the intention to limit the sum of the lengths of STUN attributes to 255 characters in RFC3489bis? The length is currently encoded as an 8 bit field in octets. This is very limiting when used in conjunction with data/send indications in draft-ietf-behave-turn-00, especially where there are REMOTE/DESTINATION ADDRESS and DATA fields (plus possibly MESSAGE INTEGRITY) If you could comment that would be really useful. Greg Daley From juberti@aol.com Tue, 16 May 2006 10:56:13 -0700 (PDT) From: "Justin Uberti" Date: Tue, 16 May 2006 10:56:13 -0700 (PDT) Subject: Re: [Ietf-behave] STUN message length in rfc3489bis In-Reply-To: <4469D9EC.1000203@research.panasonic.com> Message-ID: <446A1234.30303@aol.com> MIME-Version: 1.0 Content-Type: text/plain Hi Greg, According to rfc3489bis-03.txt, section 6, at the top of page 11: "After the STUN header are zero or more attributes. Each attribute is TLV encoded, with a 16 bit type, 16 bit length, and variable value:" IOW, the length is 16 bits, not 8. --justin Greg Daley wrote on 5/16/2006, 9:55 AM: > Hi, > (Cc: authors) > > Is it really the intention to limit the sum of > the lengths of STUN attributes to 255 characters > in RFC3489bis? > > The length is currently encoded as an 8 bit field > in octets. > > This is very limiting when used in conjunction > with data/send indications in draft-ietf-behave-turn-00, > especially where there are REMOTE/DESTINATION ADDRESS > and DATA fields (plus possibly MESSAGE INTEGRITY) > > If you could comment that would be really useful. > > Greg Daley > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From gregd@research.panasonic.com Tue, 16 May 2006 18:12:13 -0700 (PDT) From: Greg Daley Date: Tue, 16 May 2006 18:12:13 -0700 (PDT) Subject: Re: [Ietf-behave] STUN message length in rfc3489bis In-Reply-To: <4469D9EC.1000203@research.panasonic.com> Message-ID: <446A785B.9090308@research.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Thanks gain, Justin for pointing this out. I'd misread the figure. Greg Justin Uberti wrote: Hi Greg, According to rfc3489bis-03.txt, section 6, at the top of page 11: "After the STUN header are zero or more attributes. Each attribute is TLV encoded, with a 16 bit type, 16 bit length, and variable value:" IOW, the length is 16 bits, not 8. --justin From pekkas@netcore.fi Mon, 15 May 2006 03:44:09 -0700 (PDT) From: Pekka Savola Date: Mon, 15 May 2006 03:44:09 -0700 (PDT) Subject: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi, I had a flight so I read this. I think the document gives two very bad pieces of advice: turn off all NAT ALGs and remove all NAT state mapping filtering unless you require otherwise for security reasons. Hence, I think wider IETF review seems warranted, and I'd encourage more folks to read the documents and raise their concerns or lack thereof. More below. On Tue, 9 May 2006, The IESG wrote: The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG to consider the following document: - 'NAT Behavioral Requirements for Unicast UDP ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2006-05-23. The document was very well written so it was easy to read. As a generic comment, I'd like to know whether the different NAT mapping methods have different scaling characteristics in terms of amount of state created and in terms of external NAT ports/addresses reserved (compare to the IETF list discussion a while back). As another generic comment, I'd have liked this document to refer to RFC 4380 (Teredo), because IMHO that's probably the most useful generic NAT traversal mechanism out there. A few specific comments below, substantial ----------- REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address dependent filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. ==> I think this is WAY too dangerous approach. I'd say that the filtering behaviour MUST be at least address dependent, unless explicitly configured otherwise. NAT ALGs may interfere with UNSAF methods or protocols that try to be NAT-aware and must therefore be used with extreme caution. REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED that all of those ALGs be disabled by default. a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the NAT administrator to enable or disable each ALG separately. ==> this seems like a VERY bad advice. You're assuming that all the protocols used within a site (which DO work with NAT ALGs) would use UNSAF mechanisms, i.e., it's OK for them to fail with native NAT ALGs because they can just fall back to using UNSAF methods. I think that UNSAF mechanisms must be able to work with ALGs enabled by default. If they don't, they're too brittle and should be written in a more generic manner, with non-ALG mechanisms. semi-editorial -------------- Address Dependent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address, regardless of the external port. Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals Y1. ==> this would have been easier to understand if you had added 'only' before 'reuses'. The same for Addr/Port Dep Mapping and respective filtering sections. REQ-13: If the packet received on an internal IP address has DF=1, the NAT SHOULD send back an ICMP message "fragmentation needed and DF set" message to the host as described in RFC 792 [2]. a) If the packet has DF=0, the NAT SHOULD fragment the packet and send the fragments, in order. Justification: This is as per RFC 792. a) This is the same function a router performs in a similar situation RFC 1812 [5]. ==> RFC 1812 requires that a router MUST support fragmentation, though proper ordering of fragments is a SHOULD. So, I'm a bit puzzled by both of these SHOULDs. What is the alternative? Silently discard packets with DF set? Silently discard packets with DF=0 which require fragmentation? Maybe these should be stronger.. Arch-3: This does not reduce the overall brittleness of NATs but will hopefully reduce some of the more outrageous NAT behaviors and make it easer to discuss and predict NAT behavior in given situations. ==> not sure if I agree with this statement, because you're recommending turning off ALGs which means that some applications are going to stop functioning. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From moore@cs.utk.edu Mon, 15 May 2006 07:12:07 -0700 (PDT) From: Keith Moore Date: Mon, 15 May 2006 07:12:07 -0700 (PDT) Subject: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: Message-ID: <44688C30.6070207@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address dependent filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. ==> I think this is WAY too dangerous approach. I'd say that the filtering behaviour MUST be at least address dependent, unless explicitly configured otherwise. I'd strongly disagree with that. I'd say that NATs MUST NOT have address dependent filtering unless configured otherwise; and even then, filtering SHOULD be configurable on a (destination) port-by-port basis. In other words, transparency MUST be the default setting. NAT ALGs may interfere with UNSAF methods or protocols that try to be NAT-aware and must therefore be used with extreme caution. REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED that all of those ALGs be disabled by default. a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the NAT administrator to enable or disable each ALG separately. ==> this seems like a VERY bad advice. I agree with this. The problem, I suspect, is that this invites questions about which ALGs to enable and how those ALGs should behave, which is a big can of worms. Some kinds of ALGs are very bad, others are essential and semi-harmless. But it certainly should not be expected that apps will use UNSAF methods, as UNSAF methods are woefully inadequate. While I appreciate the desire to limit the problem, I think this document is too narrowly scoped - there's no way to define a desirable NAT behavior that doesn't, at a minimum, allow explicit host/application control over bindings in the NAT. Keith From hartmans-ietf@mit.edu Mon, 15 May 2006 09:23:53 -0700 (PDT) From: Sam Hartman Date: Mon, 15 May 2006 09:23:53 -0700 (PDT) Subject: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain >>>>> "Keith" == Keith Moore writes: >> REQ-8: If application transparency is most important, it is >> RECOMMENDED that a NAT have an "Endpoint independent filtering" >> behavior. If a more stringent filtering behavior is most >> important, it is RECOMMENDED that a NAT have an "Address >> dependent filtering" behavior. a) The filtering behavior MAY >> be an option configurable by the administrator of the NAT. ==> >> I think this is WAY too dangerous approach. I'd say that the >> filtering behaviour MUST be at least address dependent, unless >> explicitly configured otherwise. Keith> I'd strongly disagree with that. I'd say that NATs MUST Keith> NOT have address dependent filtering unless configured Keith> otherwise; and even then, filtering SHOULD be configurable Keith> on a (destination) port-by-port basis. In other words, Keith> transparency MUST be the default setting. I have not yet read the document, but believe I understand the context for this discussion point well enough to contribute. I think that it is important to separate NAT from firewall functionality. One device may provide both functions. But if the intent is to provide only a NAT function,, then Keith is right and transparency needs to be the default. If the intent is to provide a firewall function then all the manageability and configuration concerns of a firewall apply. From moore@cs.utk.edu Mon, 15 May 2006 10:31:49 -0700 (PDT) From: Keith Moore Date: Mon, 15 May 2006 10:31:49 -0700 (PDT) Subject: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: Message-ID: <4468BB00.5070908@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain I think that it is important to separate NAT from firewall functionality. One device may provide both functions. But if the intent is to provide only a NAT function,, then Keith is right and transparency needs to be the default. If the intent is to provide a firewall function then all the manageability and configuration concerns of a firewall apply. this ends up trying to specify how a zero-configuration firewall should work, or how a firewall for a dumb customer should work out-of-the-box. it's an unreasonable problem because the network is explicitly designed to be general purpose and to support an infinite variety of applications, but the fundamental assumption behind such a firewall is that the firewall can be aware of what is going on in the network and know whether or not the network behavior it is seeing is reasonable. the answer to the question of whether the behavior is reasonable is going to vary widely from one application to another and from one installation to another. there's no way that the firewall can tell by looking. even expecting all conversations to be initiated from inside the firewall is dodgy - partially because there are legitimate apps that need to not work that way, partially because there are conversations that involve more than two hosts at a time, partially because there are occasions when remote hosts are forced to change IP addresses. Keith From pbaker@verisign.com Mon, 15 May 2006 12:07:28 -0700 (PDT) From: "Hallam-Baker, Phillip" Date: Mon, 15 May 2006 12:07:28 -0700 (PDT) Subject: [Ietf-behave] RE: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) Message-ID: <198A730C2044DE4A96749D13E167AD37ABA64E@MOU1WNEXMB04.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain I agree that separating out the NAT and firewall functions is useful and necessary. Even if the two functions are performed by the same box they should be considered separately. I don't think that the idea of zero configuration firewalls should be dismissed. A firewall is simply a policy enforcement point, usually located at the border where the network meets the Internetwork. First people have the model wrong, ask not how you can protect yourself from the Internet, ask how to protect the Internet from you. There are huge numbers of insecure machines connected to the Internet. And yes, even Linux machines are vulnerable. Your desktop may be patched against the latest attacks but you probably have a machine used as a printer/file/DNS server sitting in the corner that has not had any maintenance for three years. A reverse firewall with simple protection rules to protect the Internet from a rogue server should be part of the default configuration of every gateway device. Let people turn it off if their use model requires it. But very very few people need to have a machine that has a use signature that remotely resembles a DDoS bot or a spambot. Eventually I am going to persuade one of the major ISPs to make such a feature a requirement in the cable modems / wifi routers / dsl modems they buy. I am pretty sure that failing to do so would constitute negligence - certainly the Hands formula indicates a duty of care here. In the future every NIC, router, hub and wifi access point will be a policy enforcement point. Policy configuration on the enforcement device is going to be impractical. The obvious solution is to use a standards based protocol such as SAML/XACML to encode the rules, sign them and distribute them to the enforcement points. There is no reason why this should not be possible in the home environment. If we start by assuming that there is some form of trustworthy hardware, that cannot be stomped on by malicious code it becomes obvious that the network config can be made plug and play. The only thing the user has to do is to decide what applications can and cannot connect up to the network and/or Internetwork and the uses to be made. From jhutz@cmu.edu Mon, 15 May 2006 14:10:20 -0700 (PDT) From: Jeffrey Hutzelman Date: Mon, 15 May 2006 14:10:20 -0700 (PDT) Subject: [Ietf-behave] RE: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: <198A730C2044DE4A96749D13E167AD37ABA64E@MOU1WNEXMB04.vcorp.ad.vr sn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Monday, May 15, 2006 12:07:09 PM -0700 "Hallam-Baker, Phillip" wrote: I agree that separating out the NAT and firewall functions is useful and necessary. Even if the two functions are performed by the same box they should be considered separately. I don't think that the idea of zero configuration firewalls should be dismissed. A firewall is simply a policy enforcement point, usually located at the border where the network meets the Internetwork. Sure. But a policy enforcement point must necessarily be configured; otherwise, how is it going to know what policy to enforce? First people have the model wrong, ask not how you can protect yourself from the Internet, ask how to protect the Internet from you. No. Being a good neighbor is desirable, but does not replace protecting yourself from bad neighbors and evildoers. A reverse firewall with simple protection rules to protect the Internet from a rogue server should be part of the default configuration of every gateway device. Let people turn it off if their use model requires it. But very very few people need to have a machine that has a use signature that remotely resembles a DDoS bot or a spambot. What a "rogue server"? What distinguishes a ddos bot from a P2P file sharing application? What distinguishes a Windows virus from a krb524 client (hint: nothing; several network providers and common firewall configuration block outgoing UDP traffic to port 4444, with the result that getting krb4 tickets and AFS tokens doesn't work from inside such a network). Who updates the configuration on these filters as new applications and new malware appear? Eventually I am going to persuade one of the major ISPs to make such a feature a requirement in the cable modems / wifi routers / dsl modems they buy. I am pretty sure that failing to do so would constitute negligence - certainly the Hands formula indicates a duty of care here. I should be required to have a device which limits my ability to use the network connection I've paid for to a limited set of applications chosen by my network provider? That's not only insane; it would probably be legally very stupid for my network provider; by restricting what I'm allowed to do, they take some responsibility for what I do. In the future every NIC, router, hub and wifi access point will be a policy enforcement point. Policy configuration on the enforcement device is going to be impractical. I see you're among those who think users and customers should be required to enforce policy counter to their interests, and that the network should trust that they do so. One of the basic rules of distributed systems design is that service providers MUST NOT depend on clients to enforce policy for them, because anyone can make a rogue client. There is no reason why this should not be possible in the home environment. If we start by assuming that there is some form of trustworthy hardware, that cannot be stomped on by malicious code it becomes obvious that the network config can be made plug and play. The only thing the user has to do is to decide what applications can and cannot connect up to the network and/or Internetwork and the uses to be made. Except that the user won't get to do that; the user's network provider will, and users who want to do anything even a little strange will just completely lose, because they're not powerful enough to force their provider to accept different terms. But for the moment, let's assume that doesn't happen. There's still a serious usability problem. The ideal situation is for the network to become like a true utility - always there, completely invisible to the user except when it breaks, and they almost forget they have it because it _never_ breaks. Power's not invisible if I have to go make changes at the service entrance before I can plug in a new appliance. Water's not invisible if I have to ask the water company before I can install a new faucet. And it's been decades since you could only attach a telephone approved (and owned!) by the telephone company. Why should the network require that I reconfigure some device I don't even know exists before I can run a new application? -- Jeff From pbaker@verisign.com Mon, 15 May 2006 14:52:11 -0700 (PDT) From: "Hallam-Baker, Phillip" Date: Mon, 15 May 2006 14:52:11 -0700 (PDT) Subject: [Ietf-behave] RE: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) Message-ID: <198A730C2044DE4A96749D13E167AD37ABA694@MOU1WNEXMB04.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain > From: Jeffrey Hutzelman [mailto:jhutz@xxxxxxx] > Sure. But a policy enforcement point must necessarily be > configured; otherwise, how is it going to know what policy to enforce? The policy can be generated automatically from the network configuration and the authorized hosts and applications authorized to run on those hosts. Forget the administration model where you administer the machines. Administer the network instead. Machine config should be generated from network config. The model can be applied in either the home or the enterprise setting. The home setting is the most challenging because it has to be transparent. But users already have machines that have internal firewalls. There is no reason why that config should not be exportable to the edge policy enforcement point as well. > > First people have the model wrong, ask not how you can > protect yourself > > from the Internet, ask how to protect the Internet from you. > > No. Being a good neighbor is desirable, but does not replace > protecting > yourself from bad neighbors and evildoers. I cannot provide you with a foolproof way to protect your machine from any attack that an Internet criminal might throw at it. Nor can anyone else without reducing it to a functionaless heap of junk. What I can do is make your machine as uninteresting a target to an attacker as possible. Make it so that its value on the botnet wholesale market is as close to zero as possible. > What a "rogue server"? What distinguishes a ddos bot from a P2P file > sharing application? No P2P file sharing application I am aware of uses spoofed source addresses in IP packets. The data bandwidth is high but the control bandwidth is not excessive. DDoS bots are mostly attacking the control channel rather than data. > What distinguishes a Windows virus from > a krb524 > client (hint: nothing; several network providers and common firewall > configuration block outgoing UDP traffic to port 4444, with > the result that > getting krb4 tickets and AFS tokens doesn't work from inside such a > network). Who updates the configuration on these filters as new > applications and new malware appear? To do damage to the rest of the net the virus has to be hammering port 4444. The type of controls people are suggesting is limiting the number of outbound control connections (SYN packets, DNS packets) to a rate that is large compared to typical consumer uses but small compared to bot uses. This is a 98%/2% solution. The vast majority of users do not need or want to make 1000 outbound TCP session initiation attempts per second. Any site that is doing that on a sustained basis for several hours is highly unlikely to be doing something legitimate. > I should be required to have a device which limits my ability > to use the > network connection I've paid for to a limited set of > applications chosen by > my network provider? You should not be allowed to connect to the net at all, yes this is all about you personally. Actually my proposal is to ship the devices with the default setting to 'on' but allow idiots to turn it off if they must. Otherwise we end up with a black market in unrestricted machines > That's not only insane; it would probably be legally > very stupid for my network provider; by restricting what I'm > allowed to do, they take some responsibility for what I do. You are not a lawyer, but you are playing one on the net. While that particular view of negligence has some currency in the US the law of negligence does not contain an ostritch exception. I am not a lawyer either. I suggest that anyone running an ISP ask their actual lawyers what the situation is here: If you are selling a service to consumers, if the harm is forseeable, if the probability of harm and the cost of the harm are great, if the cost of limiting that harm is small, are you better off helping the consumer limit that harm or ignoring it. > I see you're among those who think users and customers should > be required > to enforce policy counter to their interests, and that the > network should > trust that they do so. No, the rules are generated from configuration commands made by the user. It is simply enforcing the old security principle of least privillege. > One of the basic rules of distributed systems > design is that service providers MUST NOT depend on clients > to enforce > policy for them, because anyone can make a rogue client. That's not a rule it's a dogmatic interpretation of security principles that were probably wrong when they were proposed. Until the Internet is secure please save us the dogma. > Except that the user won't get to do that; the user's network > provider Yeah yeah yeah, stop worrying about the bogeyman and worry about the real attackers. The balance of power in this case is mostly with the consumer. Most houses have at least two wires going into them. Do not try to build your political systems into protocol design unless you understand people and understand economics. From pekkas@netcore.fi Mon, 15 May 2006 22:04:42 -0700 (PDT) From: Pekka Savola Date: Mon, 15 May 2006 22:04:42 -0700 (PDT) Subject: [Ietf-behave] policy enforcement points and management [RE: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp)] In-Reply-To: <198A730C2044DE4A96749D13E167AD37ABA694@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Mon, 15 May 2006, Hallam-Baker, Phillip wrote: From: Jeffrey Hutzelman [mailto:jhutz@xxxxxxx] Sure. But a policy enforcement point must necessarily be configured; otherwise, how is it going to know what policy to enforce? The policy can be generated automatically from the network configuration and the authorized hosts and applications authorized to run on those hosts. ... I think the discussion about policy enforcement points and their management is out of scope for this work. On the other hand, there is a proposed WG (they had a BoF at the last IETF) -- NEA (Network End-point Assessment) which aims to do something about this space. I'd recommend folks interested in it go take a look: http://www1.ietf.org/mailman/listinfo/nea -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dromasca@avaya.com Tue, 16 May 2006 00:15:07 -0700 (PDT) From: "Romascanu, Dan (Dan)" Date: Tue, 16 May 2006 00:15:07 -0700 (PDT) Subject: [Ietf-behave] RE: policy enforcement points and management [RE: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp)] Message-ID: MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Pekka Savola [mailto:pekkas@xxxxxxxxxx] > Sent: Tuesday, May 16, 2006 8:04 AM > To: Hallam-Baker, Phillip > Cc: ietf@xxxxxxxx; Keith Moore; iesg@xxxxxxxx; > ietf-behave@xxxxxxxxxxxxxxxxxxx; Jeffrey Hutzelman > Subject: policy enforcement points and management [RE: Last > Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP > (draft-ietf-behave-nat-udp)] > > On Mon, 15 May 2006, Hallam-Baker, Phillip wrote: > >> From: Jeffrey Hutzelman [mailto:jhutz@xxxxxxx] > > > >> Sure. But a policy enforcement point must necessarily be > configured; > >> otherwise, how is it going to know what policy to enforce? > > > > The policy can be generated automatically from the network > > configuration and the authorized hosts and applications > authorized to > > run on those hosts. > ... > > I think the discussion about policy enforcement points and > their management is out of scope for this work. > > On the other hand, there is a proposed WG (they had a BoF at the last > IETF) -- NEA (Network End-point Assessment) which aims to do > something about this space. > > I'd recommend folks interested in it go take a look: > > http://www1.ietf.org/mailman/listinfo/nea > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > Is not NEA dealing with a different set of problems mainly related assessing the hardware or software configuration of an endpoint as it pertains to an organization's security policy for access control purposes - called 'posture' in the NEA language? I am not sure how this would apply. Dan From lars.eggert@netlab.nec.de Tue, 16 May 2006 09:10:30 -0700 (PDT) From: Lars Eggert Date: Tue, 16 May 2006 09:10:30 -0700 (PDT) Subject: [Ietf-behave] Re: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <20060418135453.DAC3C77AF38@guns.icir.org> Message-ID: <6C07B553-A48F-45D4-AECB-79ED2361230C@netlab.nec.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Forwarding to the behave list, where this discussion should take place. Tom - thanks for the review! On May 16, 2006, at 15:32, Tom Petch wrote: I looked, took a few Paracetamol, looked some more and still think this is not fit to advance; it is or is likely to be incomprehensible to many intended readers. Not surprisingly, then, I find it hard to give specific, tcp- technical reasons why - eg REQ-3 is wrong because it does not take cognizance of para x in RFCyyyy; rather, it is the 'first impressions count', the look and feel that convinces me that this I-D is not fit. First page and there are too many editors for the RFC Editor's liking. Move on to 'Applicability' and it is very clear: 'Application and OS aspects of TCP NAT traversal are out-of-scope'; but wait for section 6, "6. Application Level Gateways FIXME OPEN ISSUE: Is this out-of-scope? Do we need to specify all TCP ALGs should be off by default? What about FTP?" (good questions). The document is written in an unfamiliar (to me) language of NAT- specific technical terms, for which the reader is referred to FIXME-BEHAVE- UDP (sic) which is in fact draft-ietf-behave-nat-udp-06 (the subject of recent criticism on the main IETF list). This has a poorly laid out section on Terminology which urges the reader "to refer to RFC 2263 [8] for information on NAT taxonomy and terminology" (in passing, RFC2263 is SNMP Applications from one of the abortive starts on SNMPv3) and ends with comments that the terminology from RFC3489 {STUN} "has been the source of much confusion as it has proven inadequate..." (yes, feels about right). In between, this section makes no mention of several of the terms in use (eg Address and Port Dependent Mapping) so the reader of behave-tcp must read and digest behave-udp (and RFC2263) before starting. A simple example on terminology; these I-D take terms like internal and external for granted; well yes, I can deduce what they mean but what is internal to an ISP is not internal to an ISP's customer and vice versa; it would be so easy to make the meaning clear (like, a diagram). This I-D has normative references to NUTSS and NATBLASTER in the shape of SIGCOMM Proceedings which suggests to me that the intended audience is rather esoteric. As I said, none of this is hard, tcp-related reasons why I regard this I-D as unfit to advance but I think it does give the flavour. I note that the only reference to TCP is to RFC793, which, great as it is, is not the TCP used in most sessions today (are the editors aware of this?). The I-D should at least reference the recent Roadmap and say whether or not the many later additions to TCP are relevant to NATs or not. Overall, I think that behave is on the wrong track; this I-D reads like an afterthought tacked onto UDP-related work by someone keen on gaming. Rather, they should first produce an update to RFC2263 on NAT in general, with clear concepts and related terminology, and then produce separate I-D for UDP and TCP (and DCCP and STCP and etc etc) which refer back to this common work. The idea that someone concerned with TCP should first become a master of UDP and NUTSS is, well nuts:-) Tom Petch ----- Original Message ----- From: "Mark Allman" To: Sent: Tuesday, April 18, 2006 3:54 PM Subject: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 Folks- Lars sent the attached request a few weeks back and we haven't heard anything. Could a couple of folks volunteer to take a look at this document in the next week or two (it's pretty short)? (And, send along a note to me indicating that you intend to do so, else I'll have to try to poll people specifically.) Thanks! allman ---------------------------------------------------------------------- ---------- _______________________________________________ tcpm mailing list tcpm@xxxxxxxx https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@xxxxxxxx https://www1.ietf.org/mailman/listinfo/tcpm Lars -- Lars Eggert NEC Network Laboratories Attachment: smime.p7s --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="p7s00005.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7s00005.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNTE2MTYxMDI2WjAjBgkqhkiG9w0BCQQxFgQUjh0Fb2AaHhXMZyXwgIlS ypd6C0UwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAHBMbfior85ipfHZFRt6/+9zvErUUAuTSXgko2/WEG+pysTjcpQ5ECL7VJmgB59E946KmeBn w4dG8yKMdD80JXAdgswqRu+89oShUq+Acsg4GnyCrdUQCcpB8/zIVEW8WhoQYw9CmUZWI7IQNSo1 mEhdbTGHqSHuH2TBZiJC4FLfzUdPTke7kqOeu8FRPAv8DC9cdSexKUIJWAFYn8dKYpJgHWItCkZl Wn1k5n9nyyIZkUTGST055rx67LEM+M/Br4HgoJYXonj0duhXQZiUIO7zWf3oXIYf/tJon2m6vxc0 kMExXRbQsZACx+1rdRhcyGqkFXggbbQyKDQ3C7tz7j8AAAAAAAA= --Boundary..27398.1163630136.multipart/signed-- From lars.eggert@netlab.nec.de Thu, 18 May 2006 00:50:53 -0700 (PDT) From: Lars Eggert Date: Thu, 18 May 2006 00:50:53 -0700 (PDT) Subject: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <8E2C2DD1-E0EA-4D05-8358-02033837C3B3@netlab.nec.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, thanks for the review, Joe. I forwarded it to the behave list, where the discussion should take place. Lars Begin forwarded message: From: Joe Touch Date: May 17, 2006 11:26:16 PM GMT+02:00 To: tcpm@xxxxxxxx Subject: Re: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 I took a look as well. I agree with Tom's assessment: it doesn't stand as a readable document. I also agree with Tom that: 1. this doc should start with the TCP roadmap as a reference, and should address items in there specifically (at least the basic ones, if not the recommended ones). 2. this doc should be more stand-alone regarding terminology --- I'll be more specific than Tom as to TCP-technical errors: - some of the scope declarations in section 1 are inappropriate. this document must declare the limit to which TCP headers can be interpreted in their entirety. declaring that anything not related to translation of TCP is out of scope begs the question of what's related to that translation - options? modification of the number of segments (e.g., splitting)? these are all definitely in-scope. I agree with the doc that above-TCP, below-TCP, and signalling beyond IP and TCP can be declared out of scope. - REQ-2 is overstated; a NAT MUST support translation of any packet valid in a pending TCP session, where "pending TCP session" is initiated by an outbound TCP SYN that means a NAT MUST accept incoming TCP SYNs which match current pending sessions. this supports simultaneous open *if* after the session is initiated by an internal host - REQ-3 is incorrect TCP defines sessions, sessions are defined by socket pairs, and sockets are defined by IP address/port pairs. Period. TCP port numbers do NOT identify hosts; they identify session demultiplexing points on hosts. To that end, the NAT is an early, remapping point for that demuxing, where everything behind a NAT (assuming it has only one external IP address) functions _exactly_ as if it were on a single host with that address. That also means that transmissions that differ in any of source IP, destination IP, source port, and destination port are unrelated from TCP's point of view. It is inappropriate for this document to suggest otherwise, or to suggest use of a NAT for that purpose. While other documents can refer to such 'NAT tricks', this document, from TCP's perspective, should recommend against such tricks, IMO. - REQ-4 is incorrect First, the ways in which a NAT would respond to a TCP SYN not matching a pending session should be listed, e.g., ICMP dest unreachable (3 port unreach, 10 host admin unreach) or TCP RST. The document is written assuming the desire to support simultaneous opens, but ignores the desire to know more rapidly when a port is not available. In particular, when an ICMP dest unreach/3 port unreach is issued, that would be a hard error that would cause the external TCP to quickly abort. Not sending the error would impact those hosts and cause them to respond less quickly to connection failure. While I agree that simultaneous open MUST be supported for pending sessions, I disagree that external SYNs should always be silently discarded just to support simultaneous open. While simultaneous open is OK when it works, the whole notion of a NAT is counter to incoming, unsolicited connections. I would recommend that incoming SYNs that do not match pending sessions MAY be signalled by an ICMP or RST error. I would NOT recommend that silence be required. - regarding ALGs FTP is not a relevant issue; FTP is already supported through NATs by passive mode; there is no requirement to translate the body of an FTP session to support NATs. There are other ALG issues, but they are - as noted in Sec 1 - above TCP, and not relevant to TCP. - session refresh This section is too messy. TCP can be open and silent if neither side has pending data; this must be addressed. Discarding state might allow subsequent sessions from other hosts to inadvertently receive data from other hosts' connections; this is a hazard that MUST be discussed. NATs may typically send keepalive TCPs, but *this* document should recommend that such behavior be restricted to endpoints. This document should be VERY clear on when such state should be kept, for how long, and when it can be cleared. The NAT must keep state in TIME_WAIT just like any end host to avoid reuse of connections and crossed-data. This section is the most critical of this document, and currently is both too disorganized and incorrect to proceed. - IPsec is missing since IPsec examines TCP headers, it would be useful to address IPsec/TCP combined issues here (e.g., transport mode issues) I didn't bother with addressing the security considerations, given the errors above. I'm presuming that a thorough revision of that section would be needed, since the doc missed some very obvious issues IMO (above). Minor nit: 6 authors? from a WG? pick a subset who are editors, please Joe _______________________________________________ tcpm mailing list tcpm@xxxxxxxx https://www1.ietf.org/mailman/listinfo/tcpm -- Lars Eggert NEC Network Laboratories Attachment: smime.p7s --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="p7s00006.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7s00006.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNTE4MDc1MDUwWjAjBgkqhkiG9w0BCQQxFgQU6LRyw4HVOaXowzCxzWnn HeVG9/IwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAImXdie/4BDOK4OrDXCe6h86sm8ChzcJoIGiiayuwazkDB1k0hJ9OOZdeR7OA17npapgyX6E tHgfHtIPDfLGmVoednn2pvUg65UfqSs/6JuSgnYd3s7BNErkDOXYz+RuH7IGD5FFDjVuXASfJSFa qb8WZcjq+JDphTPthOgIYojjOT4nzDbfQCnCrcECqTVzDzd+NDrBAq/nGnQvDXD8WteMZUAlXbsJ +yWGAI9tm9gxIhoouFzxtEJ/mSf2kNtkayJbuE/5b7c1sJdYm/2XbB7AjB9hb+8LSH40QN3qAgXI 5j9hHd4dLUgITeS9VkcNNeCIlw1iOzc45xSwBy8U868AAAAAAAA= --Boundary..27398.1163630136.multipart/signed-- From lars.eggert@netlab.nec.de Thu, 18 May 2006 00:51:31 -0700 (PDT) From: Lars Eggert Date: Thu, 18 May 2006 00:51:31 -0700 (PDT) Subject: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B970B.109@isi.edu> Message-ID: <8BB59439-3B73-4EBB-A336-881E2B068641@netlab.nec.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Forwarding a correction. Begin forwarded message: From: Joe Touch Date: May 17, 2006 11:35:07 PM GMT+02:00 To: Joe Touch Cc: tcpm@xxxxxxxx Subject: Re: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 Joe Touch wrote: - REQ-2 is overstated; a NAT MUST support translation of any packet valid in a pending TCP session, where "pending TCP session" is initiated by an outbound TCP SYN that means a NAT MUST accept incoming TCP SYNs which match current pending sessions. this supports simultaneous open *if* after the session is initiated by an internal host Sorry - minor typo. This should read "*if* (and only after) the session... Joe _______________________________________________ tcpm mailing list tcpm@xxxxxxxx https://www1.ietf.org/mailman/listinfo/tcpm Lars -- Lars Eggert NEC Network Laboratories Attachment: smime.p7s --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="p7s00007.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7s00007.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNTE4MDc1MTMwWjAjBgkqhkiG9w0BCQQxFgQUnvUhY34zkBYUPV14UgKb B37s+JQwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAGhXAlhgLeu4KEe/FCdgEJcLdxfy1uC8Z/wdYs81C8nzRGrK9qYG106lM7X3HNZuDRDNfKr6 DSu2C9TeYWokNouUZaoPImQqTWMIOprrEhhCE0/Rw7d1SmKZZMQyLfEvqO/q2r/h6s1wy4xDbQoZ K6EKw1YWaXeBkc4/dFxref7ceXOgGVXO4rewpNbRUIdIAGQ3E++NK1pI+GhjotcEnL8/bWCqyNRz ONPwmyK8RhhoOmAfMo372o3x6hXpaOuXr6JdfDtWYrbSYFCHZYHPPIsmO63qNRgyMDeqlIqFkPOO R7+kC5ExeJTERThAdNo5S/woVqko4YfCkhIqTl8D4dMAAAAAAAA= --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Thu, 18 May 2006 09:28:26 -0700 (PDT) From: Saikat Guha Date: Thu, 18 May 2006 09:28:26 -0700 (PDT) Subject: Re: [Ietf-behave] Re: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <20060418135453.DAC3C77AF38@guns.icir.org> Message-ID: <1147969704.16055.131.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks for the review Tom. On Tue, 2006-05-16 at 18:10 +0200, Lars Eggert wrote: > On May 16, 2006, at 15:32, Tom Petch wrote: > > 'Applicability' and it is very clear: 'Application and OS > > aspects of TCP > > NAT traversal are out-of-scope'; but wait for section 6, > > "6. Application Level Gateways Agreed. ALGs were deemed in scope at the last meeting. The applicability statement will reflect this. > > The document is written in an unfamiliar (to me) language of NAT- > > specific > > technical terms, for which the reader is referred to FIXME-BEHAVE- > > UDP (sic) Agreed. The draft now summarizes the important terminology from UDP where appropriate. > > This I-D has normative references to NUTSS and NATBLASTER in the > > shape of > > SIGCOMM Proceedings References to the above and like have been moved to the informational references section. > > The > > I-D should at least reference the recent Roadmap and say whether or > > not the many > > later additions to TCP are relevant to NATs or not. OK. > The idea > > that someone concerned with TCP should first become a master of UDP > > [...] is, well nuts:-) While I agree to some extent, I believe the main audience of the documents (both UDP and TCP) are NAT vendors (and to some extent application developers). The argument for moving some protocol-independent stuff into UDP was that a vendors will need to read and understand the full set of 3-4 RFC/BCPs (UDP, TCP, ICMP, ...) for their product anyway and each therefore need not be stand-alone. That said, I agree that TCP draft should reduce its dependence on the UDP terminology by summarizing the important bits when necessary. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00106.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00106.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFYktDb25GbHRxaTY5MS9vUkF1K21BSjRzSjlvRyszWTRhakRKUklZ RDlzWklSdE9BZ0FDZUl0czMKQU9MTFllcWk2S3U2Zjd5TmZpYko3a2M9Cj02ejZvCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Thu, 18 May 2006 10:37:27 -0700 (PDT) From: Saikat Guha Date: Thu, 18 May 2006 10:37:27 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <1147973845.16055.193.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks Joe. Responses (separate from those to Tom's mail) inline. On Thu, 2006-05-18 at 09:50 +0200, Lars Eggert wrote: > Begin forwarded message: > > From: Joe Touch > > > > > > - some of the scope declarations in section 1 are inappropriate. > > this document must declare the limit to which TCP headers can be > > interpreted in their entirety. Ok. > > - REQ-2 is overstated; a NAT MUST support translation of any > > packet valid in a pending TCP session, where "pending TCP > > session" is initiated by an outbound TCP SYN > > > > that means a NAT MUST accept incoming TCP SYNs which match > > current pending sessions. this supports simultaneous open > > *if* after the session is initiated by an internal host Depending on the filtering behavior of the NAT, a NAT can accept incoming TCP SYNs for a 3-way handshake initiated from the outside. (-00.txt didn't have that clarification). The constraint is that the very first session for a local address/port must be initiated by the local endpoint. After that, (policy permitting) sessions can be initiated (both 3-way and sim-open) by either internal or external endpoints. Can you suggest some text that would address your concerns? > > - REQ-3 is incorrect > > > > TCP defines sessions, sessions are defined by socket pairs, > > and sockets are defined by IP address/port pairs. Period. Ok. The intention was to use the definition of session in RFC 2663 which states: "a session is defined as the set of traffic that is managed as a unit of translation." Unfortunately, 2663 contradicts itself for TCP by later stating "sessions are uniquely identified by the [5-tuple]". This latter claim doesn't distinguish between two TCP "connections" between the same 5-tuple but not overlapping in time. Such two connections need not be "managed as [one] unit of translation" (some NATs create a new mapping for each one) and would therefore be considered two sessions. RFC 2663 equates "connection" and session; is there another term that distinguishes between two (temporally) separate TCP connections (between the same 5-tuple), or should the document (re)define session? > > - REQ-4 is incorrect > > > > First, the ways in which a NAT would respond to a > > TCP SYN not matching a pending session should be listed, > > e.g., ICMP dest unreachable (3 port unreach, 10 host admin > > unreach) or TCP RST. OK. > > The document is written assuming the desire to support > > simultaneous opens, but ignores the desire to know more > > rapidly when a port is not available. While I don't disagree, it is not always possible to rapidly know whem a port is not available -- routers that drop packets need not generate an ICMP, the ICMP may be lost in the network and so on. Nor is it desirable to force a TCP to shutdown if a port is (potentially temporarily) unreachable -- it only forces the end to flood the network with SYNs so it can win the Sim-Open race against a jabbering NAT. Ideally, if there were an ICMP code that were to be considered a soft-error during TCP initiation then the NAT could be required to send that. Fernando's draft in TCP-M proposes to make all ICMPs into hard-errors during initiation. Under the assumption that any unsolicited connection inbound into a NAT is the result of a configuration error or attack, it may be desirable for the NAT to stay silent while at the same time helping along Sim-Open. Compounded is the ability of the NAT, as a router, of being able to drop packets without being required to send an error. Lacking a soft-error, this was roughly the discussion on the list that lead to this requirement. Basically it helps more than it hurts. > > - regarding ALGs > > FTP is not a relevant issue; FTP is already supported through > > NATs by passive mode; there is no requirement to translate the > > body of an FTP session to support NATs. Unfortunately, I believe that the most popular FTP client -- Microsoft Internet Explorer -- doesn't support passive mode. For vendors to take this document seriously, the FTP ALG should be allowed to be turned on by default. While the FTP ALG helps more than it hurts (atleast until the world upgrades to a better FTP client), the case for other ALGs is not as clear. > > - session refresh > > This section is too messy. TCP can be open and silent if > > neither side has pending data; this must be addressed. The session timers affect idle sessions, and the established session timer pertains to the state that you mention. I'll make it more clear. > > Discarding state might allow subsequent sessions from other > > hosts to inadvertently receive data from other hosts' > > connections; this is a hazard that MUST be discussed. I am not convinced of this. Once a session has been abandoned, another session cannot be created through the same hole without a SYN going one way or another. The new SYN sets up a different mapping (different 5-tuple) so delayed packets from the first sessions wouldn't match (depending on endpoint filtering). Even if it does match and is routed to the endpoint, is this case any different from a non-NAT'ed TCP stack (say one that crashed, came back up and established a new session) from receiving a stay packet from an old session? > > The NAT must keep state in TIME_WAIT just like any end host to avoid > > reuse of connections and crossed-data. Agreed that to be consistent with other RFCs that a NAT should keep connections in TIME_WAIT state for 4 minutes (although most all OS's use 30s). At the same time, TIME_WAIT is always encountered for TCP during the normal operation (more typically at the client; where the NAT is) and significantly cuts the connection throughput through a NAT with bounded state. One compromise would be to leave the handling of TIME_WAIT unspecified but point out the issues associated. I believe that is the current consensus. > > - IPsec is missing > > since IPsec examines TCP headers, it would be useful to address > > IPsec/TCP combined issues here (e.g., transport mode issues) Perhaps an IPSec draft may be a better place for that. As is there are major hurdles getting IPsec flows (more than one, or even just one) to work consistently through NATs. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00107.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00107.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFYkxEVm5GbHRxaTY5MS9vUkFvS0hBSjRzdU9jQVZNbWFPdmlUSE42 MkdPSEFNRm83VHdDZlVOSFoKTWU4cm9RR2puYkxzUU5QZHRCQ0lTUGc9Cj1rQlRjCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From fluffy@cisco.com Thu, 18 May 2006 19:29:23 -0700 (PDT) From: Cullen Jennings Date: Thu, 18 May 2006 19:29:23 -0700 (PDT) Subject: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On May 15, 2006, at 6:23 PM, Sam Hartman wrote: "Keith" == Keith Moore writes: REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint independent filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address dependent filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. ==> I think this is WAY too dangerous approach. I'd say that the filtering behaviour MUST be at least address dependent, unless explicitly configured otherwise. Keith> I'd strongly disagree with that. I'd say that NATs MUST Keith> NOT have address dependent filtering unless configured Keith> otherwise; and even then, filtering SHOULD be configurable Keith> on a (destination) port-by-port basis. In other words, Keith> transparency MUST be the default setting. I have not yet read the document, but believe I understand the context for this discussion point well enough to contribute. I think that it is important to separate NAT from firewall functionality. One device may provide both functions. But if the intent is to provide only a NAT function,, then Keith is right and transparency needs to be the default. If the intent is to provide a firewall function then all the manageability and configuration concerns of a firewall apply. The intent was never to describe how to build a firewall or a NAT. It was to provide a "safe harbor" of assumptions that an application behind a NAT or firewall could assume "behave compliant" NATs or FWs would provide. The BEHAVE WG has tried to find a balance between what had a chance of deploying and what would be enough transparency to allow some applications to work. Clearly more transparency would allow more applications to work but not if it will never be deployed. This particular item was discussed for a long time in the WG. The bulk of the running code we have today does not provide "address independent" mappings because of the associated security properties. Manufactures are building boxes that are designed for to sit in houses in front of windows machines run by technically unsophisticated users. I don't know if these boxes are NATs, Firewalls, or something else but no manufacture in their right mind is going to ship these boxes with the default as address independent mappings. If we change this to "address independent", close to 100% of NATs produced will be non behave compliant. At this point applications will have nothing they can rely on and we will be at the same point we are now and the BEHAVE WG will have been reduce to an irrelevant waste of time. I 100% agree that if we were advising people how to build NATs, we would recommend "address independent", however this is not the situation. Cullen (with my individual contributor hat on) From moore@cs.utk.edu Thu, 18 May 2006 19:44:21 -0700 (PDT) From: Keith Moore Date: Thu, 18 May 2006 19:44:21 -0700 (PDT) Subject: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: Message-ID: <446D30FB.3080007@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain If we change this to "address independent", close to 100% of NATs produced will be non behave compliant. At this point applications will have nothing they can rely on and we will be at the same point we are now and the BEHAVE WG will have been reduce to an irrelevant waste of time. what's the point of this exercise? to encourage predictable behavior that applications cannot use? to give NAT vendors a seal of approval? maybe it's just not possible to specify a NAT such that it's useful to application writers and vendors will build it...at least, not without significant functionality beyond just address translation and packet filtering. Keith From touch@ISI.EDU Thu, 18 May 2006 11:09:41 -0700 (PDT) From: Joe Touch Date: Thu, 18 May 2006 11:09:41 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <446CB81E.9020501@isi.edu> MIME-Version: 1.0 Content-Type: text/plain Comments below... Saikat Guha wrote: Thanks Joe. Responses (separate from those to Tom's mail) inline. On Thu, 2006-05-18 at 09:50 +0200, Lars Eggert wrote: Begin forwarded message: From: Joe Touch - some of the scope declarations in section 1 are inappropriate. this document must declare the limit to which TCP headers can be interpreted in their entirety. Ok. - REQ-2 is overstated; a NAT MUST support translation of any packet valid in a pending TCP session, where "pending TCP session" is initiated by an outbound TCP SYN that means a NAT MUST accept incoming TCP SYNs which match current pending sessions. this supports simultaneous open *if* after the session is initiated by an internal host Depending on the filtering behavior of the NAT, a NAT can accept incoming TCP SYNs for a 3-way handshake initiated from the outside. (-00.txt didn't have that clarification). NATs can do anything they want, including not NAT. What we're talking about is that to be compliant with TCP: All NATs MUST accept incoming SYNs to connections that are pending. The constraint is that the very first session for a local address/port must be initiated by the local endpoint. After that, (policy permitting) sessions can be initiated (both 3-way and sim-open) by either internal or external endpoints. Can you suggest some text that would address your concerns? See above. - REQ-3 is incorrect TCP defines sessions, sessions are defined by socket pairs, and sockets are defined by IP address/port pairs. Period. Ok. The intention was to use the definition of session in RFC 2663 which states: "a session is defined as the set of traffic that is managed as a unit of translation." You can define NAT sessions that way; this doc should be careful to distinguish between the term "NAT session" and "TCP session". Unfortunately, 2663 contradicts itself for TCP by later stating "sessions are uniquely identified by the [5-tuple]". I presume you're referring to Sec 2.3; that's a 4-tuple. ;-) This latter claim doesn't distinguish between two TCP "connections" between the same 5-tuple but not overlapping in time. Such two connections need not be "managed as [one] unit of translation" (some NATs create a new mapping for each one) and would therefore be considered two sessions. RFC 2663 equates "connection" and session; is there another term that distinguishes between two (temporally) separate TCP connections (between the same 5-tuple), or should the document (re)define session? A connection is a session in the connected state, IMO. There is no term to differentiate between non-overlapping TCP sessions; is there some reason to need this as a separate term? - REQ-4 is incorrect First, the ways in which a NAT would respond to a TCP SYN not matching a pending session should be listed, e.g., ICMP dest unreachable (3 port unreach, 10 host admin unreach) or TCP RST. OK. The document is written assuming the desire to support simultaneous opens, but ignores the desire to know more rapidly when a port is not available. While I don't disagree, it is not always possible to rapidly know whem a port is not available At a NAT it's trivial - the lack of a corresponding translation entry. -- routers that drop packets need not generate an ICMP, the ICMP may be lost in the network and so on. Routers drop packets due to load; a general rule is to never send a packet in response to congestion (to avoid collapse). NATs drop packets due to policy; the latter is the kind of error that the source should potentially be informed of. Nor is it desirable to force a TCP to shutdown if a port is (potentially temporarily) unreachable -- it only forces the end to flood the network with SYNs so it can win the Sim-Open race against a jabbering NAT. It doesn't _force_ anything. It informs. The other end should never flood SYNs in response to an ICMP error; that's an attack. Ideally, if there were an ICMP code that were to be considered a soft-error during TCP initiation then the NAT could be required to send that. Well, the error that's appropriate is a hard error as currently defined. It's a hard error because it tells the other end not to bother on this port again - the same error is expected. The alternative would be to NOT send the ICMP error. I don't agree that redefining ICMP response is the right solution. Fernando's draft in TCP-M proposes to make all ICMPs into hard-errors during initiation. That's a different issue, which is (IMO) motivated by trying to make ICMP compensate for the lack of a simple transition to IPv6 (which I don't support either). That's not really relevant to this discussion IMO. Under the assumption that any unsolicited connection inbound into a NAT is the result of a configuration error or attack, it may be desirable for the NAT to stay silent while at the same time helping along Sim-Open. Compounded is the ability of the NAT, as a router, of being able to drop packets without being required to send an error. We don't change protocols to compensate for configuration errors. Or do you accept all incoming packets with incorrect checksums too? ICMP error messages already are supposed to be throttled, so an attack is not an issue. Lacking a soft-error, this was roughly the discussion on the list that lead to this requirement. Basically it helps more than it hurts. I still see no reason to veer outside RFC1122 or RFC1812 on this - MAY send the error, MUST rate limit, etc. - regarding ALGs FTP is not a relevant issue; FTP is already supported through NATs by passive mode; there is no requirement to translate the body of an FTP session to support NATs. Unfortunately, I believe that the most popular FTP client -- Microsoft Internet Explorer -- doesn't support passive mode. For vendors to take this document seriously, the FTP ALG should be allowed to be turned on by default. IE supports passive mode; it isn't on by default, but it's trivial to configure that way. A quick search of "internet explorer passive mode" will find it. While the FTP ALG helps more than it hurts (atleast until the world upgrades to a better FTP client), the case for other ALGs is not as clear. The world caught up in 2004 (according to what Microsoft's website says on the matter) ;-) http://support.microsoft.com/?kbid=309816 - session refresh This section is too messy. TCP can be open and silent if neither side has pending data; this must be addressed. The session timers affect idle sessions, and the established session timer pertains to the state that you mention. I'll make it more clear. Discarding state might allow subsequent sessions from other hosts to inadvertently receive data from other hosts' connections; this is a hazard that MUST be discussed. I am not convinced of this. Once a session has been abandoned, another session cannot be created through the same hole without a SYN going one way or another. The new SYN sets up a different mapping (different 5-tuple) so delayed packets from the first sessions wouldn't match (depending on endpoint filtering). Good point, but that means the doc needs another rule: NATs MUST change the translation entry when a new SYN arrives if an existing translation entry matches it. Even if it does match and is routed to the endpoint, is this case any different from a non-NAT'ed TCP stack (say one that crashed, came back up and established a new session) from receiving a stay packet from an old session? Not if the SYN is what fixes it. Got it. The NAT must keep state in TIME_WAIT just like any end host to avoid reuse of connections and crossed-data. Agreed that to be consistent with other RFCs that a NAT should keep connections in TIME_WAIT state for 4 minutes (although most all OS's use 30s). At the same time, TIME_WAIT is always encountered for TCP during the normal operation (more typically at the client; where the NAT is) and significantly cuts the connection throughput through a NAT with bounded state. One compromise would be to leave the handling of TIME_WAIT unspecified but point out the issues associated. I believe that is the current consensus. Agreed. - IPsec is missing since IPsec examines TCP headers, it would be useful to address IPsec/TCP combined issues here (e.g., transport mode issues) Perhaps an IPSec draft may be a better place for that. As is there are major hurdles getting IPsec flows (more than one, or even just one) to work consistently through NATs. This doc really needs to mention this IMO. It need not solve all issues, but it should be sufficient that if no IPsec draft were written, the doc would be sufficient in pointing out the issue. Joe From saikat@cs.cornell.edu Sat, 20 May 2006 13:04:04 -0700 (PDT) From: Saikat Guha Date: Sat, 20 May 2006 13:04:04 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <1148155440.3065.36.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2006-05-18 at 11:08 -0700, Joe Touch wrote: > Saikat Guha wrote: > >>> From: Joe Touch > > Depending on the filtering behavior of the NAT, a NAT can accept > > incoming TCP SYNs for a 3-way handshake initiated from the outside. > > (-00.txt didn't have that clarification). > > NATs can do anything they want, including not NAT. What we're talking > about is that to be compliant with TCP: > > All NATs MUST accept incoming SYNs to connections that are pending. Ok. > IMO. There is no term > to differentiate between non-overlapping TCP sessions; is there some > reason to need this as a separate term? As with the UDP document, this document gives a name to (bad) behavior that has been observed -- partly to classify NATs, partly to tell vendors what not to do. When a mapping is active, some NATs have been known to allocate a different mapping for a new TCP that matches the old mapping ... resulting in non only non endpoint-independent behavior, but an as-yet undefined type of destination dependent behavior. I am guessing a better definition of session will make it more clear. > > Ideally, if there were an ICMP code that were to be considered a > > soft-error during TCP initiation then the NAT could be required to send > > that. > > Well, the error that's appropriate is a hard error as currently defined. > It's a hard error because it tells the other end not to bother on this > port again - the same error is expected. The alternative would be to NOT > send the ICMP error. > > I don't agree that redefining ICMP response is the right solution. I agree that redefining ICMP is not the right solution, but mainly because old stacks will not be aware of the new definition. If one of the existing soft-error ICMPs could be used -- like one of the Host Unreachables -- that could work with existing stacks. > > Fernando's draft in TCP-M proposes to make all ICMPs into hard-errors > > during initiation. > > That's a different issue, which is (IMO) motivated by trying to make > ICMP compensate for the lack of a simple transition to IPv6 (which I > don't support either). That's not really relevant to this discussion IMO. If that draft does proceed, then it restricts the use of existing soft-errors as well. > I still see no reason to veer outside RFC1122 or RFC1812 on this - MAY > send the error, MUST rate limit, etc. A NAT that MAY or MAY NOT cause the OS to abort a Sim-Open attempt doesn't help an application developer traverse NATs. The goal of behave is to define behavior that allows the app developer to reliably establish connections through the NAT -- and Sim-Open is the single biggest requirement for TCP apps traversing NATs. An application developer should be able to depend on the guarantee that Sim-Open will work with his OS stack (potentially old) and NAT (new/behave compliant). Silently dropping the SYN provides this guarantee, as does requiring the NAT to return a soft-error. A NAT that can possibly return a hard-error does not provide this guarantee. Since silently dropping the SYN at the NAT-router does not violate any RFCs (AFAIK), but helps application developers traverse NATs more easily as compared to allowing NATs to OPTIONALly return hard-errors, the long-standing WG consensus has been to silently drop SYNs. Are there any other options? > IE supports passive mode; it isn't on by default, but it's trivial to > configure that way. If it is not enabled by default, then it means a support call (from grandma's) to the vendor's helpdesk. =/ Just one more reason for the vendor to balk at the draft IMHO. But FTP aside, I think your question was whether ALGs are now in scope since the draft was written. I believe so, as decided at IETF'65. >>> - IPsec is missing > > This doc really needs to mention this IMO. It need not solve all issues, > but it should be sufficient that if no IPsec draft were written, the doc > would be sufficient in pointing out the issue. Can you (or someone) suggest text for this. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00108.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00108.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFYjNZd25GbHRxaTY5MS9vUkFnZnZBSm9EUkZTa21rU3FDMEJWSUE0 WVhEcE9CQjN2bFFDZlc4UDMKNjdTblN2eXJoUm9nSDJvNGxhVHA5OGs9Cj1tbi9ICi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From touch@ISI.EDU Mon, 22 May 2006 08:04:14 -0700 (PDT) From: Joe Touch Date: Mon, 22 May 2006 08:04:14 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <4471D0DC.8090504@isi.edu> MIME-Version: 1.0 Content-Type: text/plain Saikat Guha wrote: ... IMO. There is no term to differentiate between non-overlapping TCP sessions; is there some reason to need this as a separate term? As with the UDP document, this document gives a name to (bad) behavior that has been observed -- partly to classify NATs, partly to tell vendors what not to do. When a mapping is active, some NATs have been known to allocate a different mapping for a new TCP that matches the old mapping ... resulting in non only non endpoint-independent behavior, but an as-yet undefined type of destination dependent behavior. You need to be more specific about why this behavior is bad. What is the appropriate period that makes it acceptable to reuse mapping information? Why is it not the TIME_WAIT, and why aren't all mapping entries put into that state when closed? That seems the only reasonable constraint to be TCP-safe. I am guessing a better definition of session will make it more clear. See above. It's not the name that's the issue; it's sufficient to use names of existing TCP entities to describe the problem. Ideally, if there were an ICMP code that were to be considered a soft-error during TCP initiation then the NAT could be required to send that. Well, the error that's appropriate is a hard error as currently defined. It's a hard error because it tells the other end not to bother on this port again - the same error is expected. The alternative would be to NOT send the ICMP error. I don't agree that redefining ICMP response is the right solution. I agree that redefining ICMP is not the right solution, but mainly because old stacks will not be aware of the new definition. This document is supposed to describe how TCP reacts to NATs and how to make NATs more TCP-compatible. IMO, that takes all mods to _TCP_ off the table. This would be a mod to TCP; if that's what you're proposing, you need to write the document from the other perspective... and, more importantly, propose it as work in TCPM (where changes to TCP are vetted). ;-) If one of the existing soft-error ICMPs could be used -- like one of the Host Unreachables -- that could work with existing stacks. That's an acceptable alternative, but note that there are some in TCPM who think that TCP's current reaction to soft and hard errors should be changed, so you may be referring to a specification issue that is in flux. Fernando's draft in TCP-M proposes to make all ICMPs into hard-errors during initiation. That's a different issue, which is (IMO) motivated by trying to make ICMP compensate for the lack of a simple transition to IPv6 (which I don't support either). That's not really relevant to this discussion IMO. If that draft does proceed, then it restricts the use of existing soft-errors as well. Yes, (unfortunately). That's what I'm referring to above. I still see no reason to veer outside RFC1122 or RFC1812 on this - MAY send the error, MUST rate limit, etc. A NAT that MAY or MAY NOT cause the OS to abort a Sim-Open attempt doesn't help an application developer traverse NATs. The goal of behave is to define behavior that allows the app developer to reliably establish connections through the NAT -- and Sim-Open is the single biggest requirement for TCP apps traversing NATs. An application developer should be able to depend on the guarantee that Sim-Open will work with his OS stack (potentially old) and NAT (new/behave compliant). NATs prevent incoming connections; Sim-Open happens in one of two ways; one starts on the inside, in which case it's easy to specify what NATs need to do (accept incoming SYNs that match pending translations). When S-O starts on the outside, it's equivalent to a regular SYN arriving from the outside. That's a capability NATs do not support. Silently dropping the SYN provides this guarantee, as does requiring the NAT to return a soft-error. A NAT that can possibly return a hard-error does not provide this guarantee. It's not appropriate to pick the error just on the response it generates; it must be reasonable to use. For a NAT, the following could be considered: 0 net unreachable 1 host unreachable 2 protocol unreachable 3 port unreachable Of these, 0, 1, and 2 might cause a host to kill all other connections sharing the net, host, or protocol - that would be bad. So only #3 (type 3, code 3) is appropriate. Unfortunately that's a hard error. Since silently dropping the SYN at the NAT-router does not violate any RFCs (AFAIK), but helps application developers traverse NATs more easily as compared to allowing NATs to OPTIONALly return hard-errors, the long-standing WG consensus has been to silently drop SYNs. The NAT behaves like a combination of a router and a host; it needs to follow RFCs 1122/1123, 793, and 1812 on this. If we're talking about port unreachable, only 1122 says anything on this (that I could find). 1122 indicates that sending an ICMP port unreachable is a SHOULD. You're suggesting MUST NOT. That's a substantial change. Routers aren't supposed to drop TCP packets based on ICMP rules; when they do, they have SHOULDs as well. Are there any other options? Give up on allowing simultaneous open where the outside message arrives first. That would be more consistent with what NATs do anyway, IMO. Yes, it forces the connection to open from the inside first, but that's consistent. IE supports passive mode; it isn't on by default, but it's trivial to configure that way. If it is not enabled by default, then it means a support call (from grandma's) to the vendor's helpdesk. =/ Just one more reason for the vendor to balk at the draft IMHO. Er, to balk at NATs, frankly. This is a problem that NATs create, and one that the public deployments haven't yet caught up to. But FTP aside, I think your question was whether ALGs are now in scope since the draft was written. I believe so, as decided at IETF'65. My question was whether making requirements of FTP was in-scope for BEHAVE. This goes back to BEHAVE making requirements of TCP; in either case, it's out of scope for the WG (regardless of what the WG decides ;-). IMO, the best *this doc* should do is indicate where things might break when NATs are used (e.g., that FTP has this capability but it isn't on). - IPsec is missing This doc really needs to mention this IMO. It need not solve all issues, but it should be sufficient that if no IPsec draft were written, the doc would be sufficient in pointing out the issue. Can you (or someone) suggest text for this. See the RFCs on NAT traversal by IPsec; it might be useful to contact their authors for suggestions. Joe From saikat@cs.cornell.edu Mon, 22 May 2006 09:07:28 -0700 (PDT) From: Saikat Guha Date: Mon, 22 May 2006 09:07:28 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <1148314046.4095.49.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2006-05-22 at 07:55 -0700, Joe Touch wrote: > NATs prevent incoming connections; Sim-Open happens in one of two ways; > one starts on the inside, in which case it's easy to specify what NATs > need to do (accept incoming SYNs that match pending translations). When > S-O starts on the outside, it's equivalent to a regular SYN arriving > from the outside. That's a capability NATs do not support. When S-O starts from the outside, and the NAT is silent on the SYN (or equivalently something that doesn't abort the attempt) then the NAT supports S-O from the outside. > Give up on allowing simultaneous open where the outside message arrives > first. The whole purpose of this draft is to ensure TCP can be established between two NAT'ed hosts -- each behind its own NAT. In such scenarios, S-O will *always* be initiated from the outside (for one of them). A NAT MUST support S-O from the outside for TCP traversal to work. > The NAT behaves like a combination of a router and a host; it needs > to follow RFCs 1122/1123, 793, and 1812 on this. What happens when the requirements for the two (router and host) aren't the same? The role of the NAT is open to interpretation, which in turn determines which requirement should apply. For this specific instance, it is beneficial to interpret the NAT as a router as opposed to as a host. The justification is as follows: #1: NAT as a host (for this specific case): SHOULD send ICMP for non-routable SYN Result: a) CANNOT establish TCP between two NAT'ed hosts. b) Can quickly detect if port is closed #2: NAT as router (for this specific case): Unspecified how to handle non-routable SYN (Proposed: silently drop) Result: a) Supports TCP establishment between two NAT'ed hosts b) Can detect (with high probability) if port is closed after 2-3 retransmissions When it comes to best current practice, b) is actually perceived an attack! IMHO b) is an exceptional case of which there are few legitimate uses at the moment. a) is by-far what must be supported today. Case #1 precludes a) to optimize for b). Case #2 supports a) while de-optimizing for b). Both #1 and #2 are equally consistent with the RFCs for the corresponding interpretations of the NAT's role. Can you explain why #2 is not acceptable? IMHO, the intent of this document is to enable connectivity in a NAT'ed world as opposed to maintaining the status-quo; #2 is consistent with that goal while #1 is not. Can the chairs take a stand? cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00109.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00109.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFY2VHK25GbHRxaTY5MS9vUkFrMjBBSndQVE1oZU50NVk5UzFYOGNj ekxTRFJIQWJNSHdDZEV1WFIKMElGT0NIMTVYNXBmK0lVL0ZIODZiYzA9Cj01bm5KCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From touch@ISI.EDU Mon, 22 May 2006 09:26:26 -0700 (PDT) From: Joe Touch Date: Mon, 22 May 2006 09:26:26 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <4471E5F1.7080809@isi.edu> MIME-Version: 1.0 Content-Type: text/plain Saikat Guha wrote: On Mon, 2006-05-22 at 07:55 -0700, Joe Touch wrote: NATs prevent incoming connections; Sim-Open happens in one of two ways; one starts on the inside, in which case it's easy to specify what NATs need to do (accept incoming SYNs that match pending translations). When S-O starts on the outside, it's equivalent to a regular SYN arriving from the outside. That's a capability NATs do not support. When S-O starts from the outside, and the NAT is silent on the SYN (or equivalently something that doesn't abort the attempt) then the NAT supports S-O from the outside. NATs do not support incoming connections in this way. They support having the source retry until it gets through. Unfortunately, that would happen for ALL incoming SYNs, which is not necessarily the right answer. Since a NAT can't know whether an incoming SYN is for a S-O that hasn't started or is just an unsolicited request, it must treat the two the same. Give up on allowing simultaneous open where the outside message arrives first. The whole purpose of this draft is to ensure TCP can be established between two NAT'ed hosts -- each behind its own NAT. The purpose of the draft is to describe all interactions between NAT and TCP; if the purpose is to focus on ways to support S-O for two NAT'd hosts, the doc needs to be rewritten. In such scenarios, S-O will *always* be initiated from the outside (for one of them). A NAT MUST support S-O from the outside for TCP traversal to work. NATs don't know what S-O is _unless_ it's after a translation is already established. Otherwise, they're just incoming SYNs. A NAT SHOULD send an ICMP for an incoming SYN that doesn't match its tables; it MAY (as a result) ignore that SYN. You might suggest that it SHOULD ignore the first incoming SYN for a non-existent entry, but respond to other SYNs - however, that provides an opportunity for an external DOS attack (to flood the 'incoming SYN' table). You might suggest that you just rate limit the ICMPs you SHOULD be sending as a result of the SYNs, but that means that some connections will work while others will just fail. The NAT behaves like a combination of a router and a host; it needs to follow RFCs 1122/1123, 793, and 1812 on this. What happens when the requirements for the two (router and host) aren't the same? The role of the NAT is open to interpretation, which in turn determines which requirement should apply. Agreed. However, there are only two options: - it's a host: where it SHOULD send an ICMP dest unreachable / port unreachable - it's a router: where it MUST generate a dest unreachable / net unreachable or dest unreachable / host unreachable (I've already noted why the latter would be worse). > For this specific instance, it is beneficial to interpret the NAT as a router as opposed to as a host. The justification is as follows: #1: NAT as a host (for this specific case): SHOULD send ICMP for non-routable SYN Result: a) CANNOT establish TCP between two NAT'ed hosts. b) Can quickly detect if port is closed SHOULD seems bad, but allowing MAY causes DOS attack opportunities (as above). #2: NAT as router (for this specific case): Unspecified how to handle non-routable SYN (Proposed: silently drop) Er, see RFC1812, 4.3.3.1 Unroutable IP packets MUST generate ICMP error messages. There's no provision for silent drop. There is ONLY a provision for ICMP rate limit (which I already noted won't help much). Result: a) Supports TCP establishment between two NAT'ed hosts b) Can detect (with high probability) if port is closed after 2-3 retransmissions When it comes to best current practice, b) is actually perceived an attack! IMHO b) is an exceptional case of which there are few legitimate uses at the moment. a) is by-far what must be supported today. Case #1 precludes a) to optimize for b). Case #2 supports a) while de-optimizing for b). Both #1 and #2 are equally consistent with the RFCs for the corresponding interpretations of the NAT's role. Can you explain why #2 is not acceptable? Just did ;-) Joe IMHO, the intent of this document is to enable connectivity in a NAT'ed world as opposed to maintaining the status-quo; #2 is consistent with that goal while #1 is not. Can the chairs take a stand? cheers, From saikat@cs.cornell.edu Mon, 22 May 2006 10:51:27 -0700 (PDT) From: Saikat Guha Date: Mon, 22 May 2006 10:51:27 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <1148320286.4095.113.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2006-05-22 at 09:25 -0700, Joe Touch wrote: > Saikat Guha wrote: > > #2: NAT as router (for this specific case): > > Unspecified how to handle non-routable SYN > > (Proposed: silently drop) > > Er, see RFC1812, 4.3.3.1 > > Unroutable IP packets MUST generate ICMP error messages. There's no > provision for silent drop. There is ONLY a provision for ICMP rate limit > (which I already noted won't help much). I suppose if it does come down to finding loopholes, 4.3.3.1 specifies exactly when the ICMP must be sent: "cannot forward a packet because it has no routes at all (including no default route) to the *destination specified in the packet*, then the router MUST generate ..."; which one could claim doesn't hold in this case because the "destination specified in the packet" is that of the router itself to which a route does exist. Alternatively the RFC allows for arbitrary implementation-specific rate-limiting, which could be exploited to create a 0-rate icmp channel for inbound SYN. Following the RFC to the word would still allow for silently dropping inbound SYNs without violating any requirements. But I completely agree with you that the spirit of the RFC is to indicate when an error happens, as is the case here. The right solution IMHO would be to define a new ICMP unrechable type that accurately captures the error (since no other ICMP unreachable captures it), and tell stacks how to handle such errors. Potentially let the application opening the socket indicate to the stack whether or not it expects Sim-Open to be the normal case and whether or not to abort quickly. Is that an option? If not, then perhaps enabling TCP connectivity rather than hindering it while staying compliant with at least the word (regrettably not necessarily the spirit) of the specific RFC is acceptable. Given the two, long debated, options 1. to sent an ICMP error that prevents NAT'ed TCP or 2. to remain silent for inbound SYN packets Does anyone else have any comments to make? How about the following text: REQ-X: If the NAT cannot determine whether the application is attempting a Simultaneous-Open when processing an inbound SYN that cannot be routed, the NAT MUST NOT cause the attempt to be aborted prematurely by the end-host. a) If the NAT can indicate the error to the end-host without causing it to prematurely abort the attempt, it SHOULD do so. b) Otherwise the NAT MUST silently discard the inbound SYN packet. First, the requirement allows the NAT to abort an inbound SYN for application it knows are not attempting a S-O: http, ftp etc. for instance. For other protocols, the above requirement gives priority to informing the end-host of the error. It is forward compatible with new ICMP errors defined for this purpose that are soft-errors during connection establishment. Until then, it prefers to err on the side of caution by allowing a connection (while stalling erroneous ones) rather than aborting all attempts. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00110.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00110.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFY2ZvZG5GbHRxaTY5MS9vUkFudWRBSjlzc1RqczJRN2hkMUlTZmlG Z0YwOFE1N013ZmdDZVBIQ2EKUVN4ZHFyMllGaXlwaVNLeGovaXByWjA9Cj1nVGVtCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Mon, 22 May 2006 10:54:50 -0700 (PDT) From: Saikat Guha Date: Mon, 22 May 2006 10:54:50 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <1148320489.4095.115.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2006-05-22 at 18:51 +0100, Saikat Guha wrote: > REQ-X: If the NAT cannot determine whether the application is > attempting a Simultaneous-Open when processing an inbound SYN > that cannot be routed, the NAT MUST NOT cause the attempt to be > aborted prematurely by the end-host. > a) If the NAT can indicate the error to the end-host without > causing it to prematurely abort the attempt, it SHOULD do so. > b) Otherwise the NAT MUST silently discard the inbound SYN packet. Same thing, with "cause" to be aborted replaced with "force" REQ-X: If the NAT cannot determine whether the application is attempting a Simultaneous-Open when processing an inbound SYN that cannot be routed, the NAT MUST NOT force the attempt to be aborted prematurely by the end-host. a) If the NAT can indicate the error to the end-host without forcing it to prematurely abort the attempt, it SHOULD do so. b) Otherwise the NAT MUST silently discard the inbound SYN packet. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00111.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00111.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFY2ZycG5GbHRxaTY5MS9vUkFpZDhBSjlseEpnN2d4UkREa3FucEdD Sjgrb09meGhnWFFDZmNweFQKVllzbDRSa1FTc2I2VE5sZDhvTzdwQmM9Cj1nSlNWCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From touch@ISI.EDU Mon, 22 May 2006 11:11:52 -0700 (PDT) From: Joe Touch Date: Mon, 22 May 2006 11:11:52 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <4471FE82.2040209@isi.edu> MIME-Version: 1.0 Content-Type: text/plain Saikat Guha wrote: On Mon, 2006-05-22 at 09:25 -0700, Joe Touch wrote: Saikat Guha wrote: #2: NAT as router (for this specific case): Unspecified how to handle non-routable SYN (Proposed: silently drop) Er, see RFC1812, 4.3.3.1 Unroutable IP packets MUST generate ICMP error messages. There's no provision for silent drop. There is ONLY a provision for ICMP rate limit (which I already noted won't help much). I suppose if it does come down to finding loopholes, 4.3.3.1 specifies exactly when the ICMP must be sent: "cannot forward a packet because it has no routes at all (including no default route) to the *destination specified in the packet*, then the router MUST generate ..."; which one could claim doesn't hold in this case because the "destination specified in the packet" is that of the router itself to which a route does exist. Er, then you're arguing that 1122 applies. You can't eat your cake and have it too ;-) Alternatively the RFC allows for arbitrary implementation-specific rate-limiting, which could be exploited to create a 0-rate icmp channel for inbound SYN. Following the RFC to the word would still allow for silently dropping inbound SYNs without violating any requirements. Rate-limiting to 0 is stretching things a bit, but you just argued that 1812 doesn't apply, so that's not an issue. But I completely agree with you that the spirit of the RFC is to indicate when an error happens, as is the case here. The right solution IMHO would be to define a new ICMP unrechable type that accurately captures the error (since no other ICMP unreachable captures it), and tell stacks how to handle such errors. YES!!! But that's new work, and ends up making NATs expose themselves, which (last I recalled) was abhorrent from their perspective. Potentially let the application opening the socket indicate to the stack whether or not it expects Sim-Open to be the normal case and whether or not to abort quickly. Is that an option? Not that I'm aware. If not, then perhaps enabling TCP connectivity rather than hindering it while staying compliant with at least the word (regrettably not necessarily the spirit) of the specific RFC is acceptable. The issue with S-O is important only for the case where both hosts are behind NATs. My general impression is that opening a connection to a host behind a NAT is - in spirit - something NATs prohibit (excepting mapped ports). I see no reason not to just admit that. I appreciate that this interferes with the peer case, but that's a problem NATs are somewhat intended to create. Given the two, long debated, options 1. to sent an ICMP error that prevents NAT'ed TCP or 2. to remain silent for inbound SYN packets Does anyone else have any comments to make? How about the following text: REQ-X: If the NAT cannot determine whether the application is attempting a Simultaneous-Open when processing an inbound SYN that cannot be routed, the NAT MUST NOT cause the attempt to be aborted prematurely by the end-host. a) If the NAT can indicate the error to the end-host without causing it to prematurely abort the attempt, it SHOULD do so. b) Otherwise the NAT MUST silently discard the inbound SYN packet. (a), and the spirit of the MUST NOT above it are against RFC1122 IMO. First, the requirement allows the NAT to abort an inbound SYN for application it knows are not attempting a S-O: http, ftp etc. for instance. IMO, a doc that describes NAT's interaction with TCP _MUST NOT_ proscribe behavior that is either port or application specific. That is an issue for NAT's interaction with apps. I don't see anywhere in 791-793, 1122, or 1812 that indicates transport - or ICMP signalling behavior - that is application-specific (short of 'port not available', of course). For other protocols, the above requirement gives priority to informing the end-host of the error. It is forward compatible with new ICMP errors defined for this purpose that are soft-errors during connection establishment. Until then, it prefers to err on the side of caution by allowing a connection (while stalling erroneous ones) rather than aborting all attempts. I don't see a way around this per se, at least not so far. Joe From fluffy@cisco.com Mon, 22 May 2006 11:56:32 -0700 (PDT) From: Cullen Jennings Date: Mon, 22 May 2006 11:56:32 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <2839EEF2-896E-4AF8-A711-66EF9061B90D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain REQ-X: If the NAT cannot determine whether the application is attempting a Simultaneous-Open when processing an inbound SYN that cannot be routed, the NAT MUST NOT force the attempt to be aborted prematurely by the end-host. a) If the NAT can indicate the error to the end-host without forcing it to prematurely abort the attempt, it SHOULD do so. b) Otherwise the NAT MUST silently discard the inbound SYN packet. I would have no idea how to implement this. I done know how I would know if could determine an SO was happening. I have not idea how I could indicate an error without forcing a premature abort. I'm not objecting to what you are trying to accomplish here but the language propose here will not be useful for the people that build residential NATs. From saikat@cs.cornell.edu Mon, 22 May 2006 12:20:07 -0700 (PDT) From: Saikat Guha Date: Mon, 22 May 2006 12:20:07 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <1148325605.4095.122.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2006-05-22 at 11:10 -0700, Joe Touch wrote: > The issue with S-O is important only for the case where both hosts are > behind NATs. My general impression is that opening a connection to a > host behind a NAT is - in spirit - something NATs prohibit (excepting > mapped ports). The typical policy of a NAT is to allow a connection if the internal endpoint wants it. A convenient way of doing that is to let the internal end to send the first packet that creates the mapping. That is what UDP-traversal (STUN) uses. If an internal host doesn't want to talk, then you cannot do STUN, you cannot traverse a NAT. If an internal host wants to talk, then you can do STUN and get UDP between hosts both behind their NAT. This adheres to the NAT policy of allowing internal hosts to determine whether to talk or not. The policy for TCP is still the same but you cannot do the STUN trick in its simplicity. Even when both ends behind the NAT _want_ to talk, and the NAT policy allows a connection as long as the internal host wants to talk, a strict 3-way handshake will always fail. A Sim-Open is necessary here. This requirement does not define NAT behavior that would contradict the predominant policy. You cannot Sim-Open unless the internal side agrees. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00112.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00112.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFY2c3bG5GbHRxaTY5MS9vUkFsSXhBSjBaZ3VrOVF5YUpHV2lmbzFH VXhyMmlqdDFMendDZmJFaFEKRTZXR2MxbnN0QUZvdnJJdi9POUEvMnM9Cj1PaDdYCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Mon, 22 May 2006 12:30:10 -0700 (PDT) From: Saikat Guha Date: Mon, 22 May 2006 12:30:10 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <1148326205.4095.130.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2006-05-22 at 11:56 -0700, Cullen Jennings wrote: > > REQ-X: If the NAT cannot determine whether the application is > > attempting a Simultaneous-Open when processing an inbound SYN > > that cannot be routed, the NAT MUST NOT force the attempt to be > > aborted prematurely by the end-host. > > a) If the NAT can indicate the error to the end-host without > > forcing it to prematurely abort the attempt, it SHOULD do so. > > b) Otherwise the NAT MUST silently discard the inbound SYN packet. > > > > > > I would have no idea how to implement this. At the very least b) applies and you silently drop packets. That is the fallback case. > I done know how I would > know if could determine an SO was happening. If the NAT is doing some app-level processing (like labling port-80 as http etc.) then it know that an http-server would not do an SO. The doecument does not require the NAT to do any such sort of application-specific behavior (to answer Joe's concern), but simply provides a safe harbor for NATs that want to adhere to 1122 by returning a ICMP asap. > I have not idea how I > could indicate an error without forcing a premature abort. Current TCP stacks, should (and most do) as per spec, consider some ICMP unreachables as a soft-error. A NAT can send that. Ofcourse, if the TCPM soft-errors draft was to override that behavior, then NATs would not be allowed to send that; alternatively, if a new soft-error ICMP was defined in the future, that could be used. But the lowest common denominator for vendors taking extra precautions would be to silently drop. > I'm not objecting to what you are trying to accomplish here but the > language propose here will not be useful for the people that build > residential NATs. Can you propose some text that vendors would be more likely to understand? -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00113.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00113.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFY2hFOW5GbHRxaTY5MS9vUkFwMlFBSjlMS1BCRXdwbzNTbzA4ejJp K2tOelNOM0prVXdDY0NFb04Ka0g0TTUrL3pmNG5Gdy9mY3lVZ0p5Qnc9Cj1WOFEzCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From touch@ISI.EDU Mon, 22 May 2006 12:44:44 -0700 (PDT) From: Joe Touch Date: Mon, 22 May 2006 12:44:44 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <44721456.8010203@isi.edu> MIME-Version: 1.0 Content-Type: text/plain Saikat Guha wrote: On Mon, 2006-05-22 at 11:56 -0700, Cullen Jennings wrote: REQ-X: If the NAT cannot determine whether the application is attempting a Simultaneous-Open when processing an inbound SYN that cannot be routed, the NAT MUST NOT force the attempt to be aborted prematurely by the end-host. a) If the NAT can indicate the error to the end-host without forcing it to prematurely abort the attempt, it SHOULD do so. b) Otherwise the NAT MUST silently discard the inbound SYN packet. I would have no idea how to implement this. At the very least b) applies and you silently drop packets. That is the fallback case. I done know how I would know if could determine an SO was happening. If the NAT is doing some app-level processing (like labling port-80 as http etc.) then it know that an http-server would not do an SO. The doecument does not require the NAT to do any such sort of application-specific behavior (to answer Joe's concern), but simply provides a safe harbor for NATs that want to adhere to 1122 by returning a ICMP asap. I have not idea how I could indicate an error without forcing a premature abort. Current TCP stacks, should (and most do) as per spec, consider some ICMP unreachables as a soft-error. A NAT can send that. Unreachable codes 0,1, and 5 are soft: 0 net unreachable 1 host unreachable 5 source route failed Codes 0,1,4,5 all are sent ONLY from gateways, not hosts. If this is a host, then these can't come from there. All ICMPs sent from hosts are spec'd as hard errors at this time. Joe From touch@ISI.EDU Mon, 22 May 2006 12:54:55 -0700 (PDT) From: Joe Touch Date: Mon, 22 May 2006 12:54:55 -0700 (PDT) Subject: Re: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 In-Reply-To: <446B94F8.3020008@isi.edu> Message-ID: <447216A3.7040206@isi.edu> MIME-Version: 1.0 Content-Type: text/plain Saikat Guha wrote: On Mon, 2006-05-22 at 11:10 -0700, Joe Touch wrote: The issue with S-O is important only for the case where both hosts are behind NATs. My general impression is that opening a connection to a host behind a NAT is - in spirit - something NATs prohibit (excepting mapped ports). The typical policy of a NAT is to allow a connection if the internal endpoint wants it. There are only two ways I know that this is indicated: - manual configuration (port map overrides) - seeing an outgoing SYN A convenient way of doing that is to let the internal end to send the first packet that creates the mapping. Sure - that's the outgoing SYN. That is what UDP-traversal (STUN) uses. If an internal host doesn't want to talk, then you cannot do STUN, you cannot traverse a NAT. If an internal host wants to talk, then you can do STUN and get UDP between hosts both behind their NAT. This adheres to the NAT policy of allowing internal hosts to determine whether to talk or not. The policy for TCP is still the same but you cannot do the STUN trick in its simplicity. Even when both ends behind the NAT _want_ to talk, and the NAT policy allows a connection as long as the internal host wants to talk, a strict 3-way handshake will always fail. A Sim-Open is necessary here. This requirement does not define NAT behavior that would contradict the predominant policy. You cannot Sim-Open unless the internal side agrees. A true simultaneous open would work - IF both ends' SYNs hit their NAT before the incoming SYN arrives. The problem occurs because you can't control when the SYNs arrive at the NATs, and you need to to make this work. That's the reason you want to be silent on an arriving SYN, but IMO that's inappropriate. At best, you might delay sending the ICMP back, e.g., by 1 second or something like that. So long as it's fast enough to hit the retry timer of most TCPs (e.g., 6 seconds with exponential backoff), but slow enough that it allows loose sync between the endpoints, it would work. Would that suffice (again, this is an opportunity for an attack, though - you're keeping state during that period)? Joe From fluffy@cisco.com Mon, 22 May 2006 15:20:13 -0700 (PDT) From: Cullen Jennings Date: Mon, 22 May 2006 15:20:13 -0700 (PDT) Subject: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On May 18, 2006, at 7:44 PM, Keith Moore wrote: If we change this to "address independent", close to 100% of NATs produced will be non behave compliant. At this point applications will have nothing they can rely on and we will be at the same point we are now and the BEHAVE WG will have been reduce to an irrelevant waste of time. what's the point of this exercise? To try and minimize the damage NATs cause - clearly if NATs all acted like a peice of cat 5 cable, that would be optimial from some points of view but this is not likely to happen. So it was a balance to define something that was extremely useful for applications (more on that later) and yet close enough to what NATs do that some, and hopefully most, NAT vendors will do it. to encourage predictable behavior that applications cannot use? The functionaly here defined here allow two hosts behind two differnt NATs to be able to set up a dirrect flow of packets between them. They need an external STUN server in the public space to help them with this but they don't need to realy all the packets through a server. The two hosts use some server that is not NATed to help set up the connection, but once the connection is up, there is real e2e flow of packets and the packets don't have to be relayed by some public server. Clearly this is not as nice for applications as no NAT, but short of no NAT, this is really useful and helps provide the scaleabilyt and reliabilyt that would be achievable in a system with no NATs. VoIP, IM, and online games can all take advantage of this - and using ICE they can do it in a way that provides a smoth transition to v6 or envirnoments with no NATs. I think the behavior defined here is useful for applications. From moore@cs.utk.edu Mon, 22 May 2006 15:41:06 -0700 (PDT) From: Keith Moore Date: Mon, 22 May 2006 15:41:06 -0700 (PDT) Subject: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: Message-ID: <20060522184156.d9e35e43.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain > > what's the point of this exercise? > > To try and minimize the damage NATs cause Well, as far as I can tell, you're not doing that to any significant degree. > > to encourage predictable behavior that applications cannot use? > > The functionaly here defined here allow two hosts behind two differnt > NATs to be able to set up a dirrect flow of packets between them. A solution that only works for pairs of hosts is of fairly limited applicability. Most two-host applications already work through NAT. The biggest set of apps affected by NAT are distributed applications. Again, maybe it's not possible to define a spec that NAT vendors will implement that gets rid of NAT brain damage to any useful degree. If this is the belief of the BEHAVE WG then the correct output of the BEHAVE group is to state that belief, rather than to define a spec that provides the appearance of a solution while only providing a very marginal increase in actual functionality. Personally I'm tired of attempts to avoid solving the NAT problem while glossing over it. I don't think IETF should be endorsing NAT fixes that don't provide a path to a viable long-term solution. From fluffy@cisco.com Tue, 23 May 2006 12:25:02 -0700 (PDT) From: Cullen Jennings Date: Tue, 23 May 2006 12:25:02 -0700 (PDT) Subject: Re: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Pekka, Not sure if your questions about ALG ever got answered so wanted to restart that thread. More inline .... On May 15, 2006, at 3:44 AM, Pekka Savola wrote: NAT ALGs may interfere with UNSAF methods or protocols that try to be NAT-aware and must therefore be used with extreme caution. REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED that all of those ALGs be disabled by default. a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the NAT administrator to enable or disable each ALG separately. ==> this seems like a VERY bad advice. You're assuming that all the protocols used within a site (which DO work with NAT ALGs) would use UNSAF mechanisms, i.e., it's OK for them to fail with native NAT ALGs because they can just fall back to using UNSAF methods. I think the important thing to keep in mind here is this is only scoped to UDP. We are not saying this about TCP ALGs. The WG did talk about this for a long time. There are devices with UDP ALG that everyone agrees are bad (more on this later) - the questions is are there any that we would recommend? The only one that ever came up as DNS and most people did not think this was even really a ALG as the NAT provided (via DHCP) it's address and the request was sent there. I don't recall other UDP based ALGs being brought up. I think that UNSAF mechanisms must be able to work with ALGs enabled by default. If they don't, they're too brittle and should be written in a more generic manner, with non-ALG mechanisms. I have two NATs on my shelf right now that have an interesting ALG in them. If the NAT has a public address of 1.1.1.1 any time it see the string "1.1.1.1" or the 32 bit value 0x01010101 in any packet, it replaces it with the private address. Say you are FTP a file that happens to have the bit sequences, well it gets replaces. I don't think we should design applications to work with this ALG - I think we should encourage people not to deploy something so broken. I also have some NATs with SIP ALGs. I will talk about the one from the vendor I work for but as far as I can tell other vendors are no better. The SIP ALG regularly tampers with things in a way that breaks things in very unpredictable ways. It will rewrite some address but not others - it is very difficult for any UNSAF algorithm to know what parts of the message might get tampered with and to stop that. For example, if you are doing ICE and want to pass your local and public address the ALG tends to rewrite the private address with the public address and some times leaves the public address along and sometimes tries to change it if it matches a flow it recognizes. If we had an RFC that described an specific UDP ALG and said how it worked, I would be all for saying leave that on. However, what we are trying to do is make the NATs somewhat deterministic from point of view of applications using them. We can not meet that goal and have random ALG on the NAT that may make complete unknown transformations to any packet. From saikat@cs.cornell.edu Wed, 24 May 2006 04:22:25 -0700 (PDT) From: Saikat Guha Date: Wed, 24 May 2006 04:22:25 -0700 (PDT) Subject: [Ietf-behave] NAT TCP Simultaneous-Open: Request for comments on proposals. Message-ID: <1148469744.18773.81.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit The discussion on- and off- list had identified a bunch of issues that I quickly summarize below. I would like to get some feedback (particularly on Option 4 from the vendors) on the four potential requirements below. Issues (simplified, see original thread for details): 1. TCP Simultaneous-Open is necessary for P2P apps. NATs shouldn't force such attempts to be aborted. But there is currently no way to do so with ICMP/TCP messages. Barring future work (improbable), facilitating S-O would require NATs ignore the error (perhaps momentarily) 2. The intent of prior RFCs is to signal errors (MUST or SHOULD depending) which would hinder P2P TCP, but would follow the spirit of RFCs. So here are the options: Option 1: Current proposal in the draft ======== "A NAT MUST silently drop inbound SYNs" Issues: Totally against the spirit of old RFCs, making network troubleshooting harder, but allows TCP S-O Option 2: Proposed earlier on the list by myself ========= "A NAT MUST NOT force an end-host to abort a TCP connection that could be a S-O. It SHOULD return an error if the error doesn't force the end abort the attempt. Otherwise, it MUST silently drop the SYN" Issues: Hard to implement and understand. Currently no possible to implement the first two clauses. Still facilitates S-O, but is forwards compatible in the unlikely event that the first two clauses become satisfiable. Option 3: Following the REQ-8 language in the UDP spec ========= "If enabling P2P TCP apps is most important, a NAT MUST silently drop the SYN. If enabling quick diagnosis of network errors is most important, a NAT SHOULD signal an ICMP port unreachable. The behavior MAY be configurable by the administrator." Issues: Let the NAT admin pick whether to allow TCP S-O or signal errors. Option 4: Proposed earlier on list by Joe ========= "A NAT SHOULD signal an ICMP port unreachable. If it does, it MUST delay the ICMP error by at least 3 seconds and MUST cancel the ICMP if in that time an outbound SYN for the connection is seen. If the NAT does not have resources to delay the ICMP, it MUST silently drop the inbound SYN" Issues: Delaying the ICMP gives the internal side's SYN or retransmission a chance to trigger a S-O. This requires bounded state at the NAT. In an attack (when the buffer is full), it allows the NAT to silently discard SYNs. Together, it facilitates S-O regardless of whether the NAT is low on resources or not. When the NAT has resources to spare, it facilitates error detection (delayed by 3s). When out of resources it degrades gracefully to support S-O but not fast error detection. I'd particularly like to know how vendors and others feel about Option 4. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00114.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00114.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZEVId25GbHRxaTY5MS9vUkFpNHBBSjRndkNBN2llVkgvNVQzcjIv dnVrYm0rZWYvV2dDZU9TdVQKTnZPR25MUVBxL28rVTh6WS90d0JYWk09Cj12L2ovCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From Internet-Drafts@ietf.org Wed, 24 May 2006 12:50:05 -0700 (PDT) From: Internet-Drafts@ietf.org Date: Wed, 24 May 2006 12:50:05 -0700 (PDT) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-nat-icmp-00.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for ICMP protocol Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-nat-icmp-00.txt Pages : 17 Date : 2006-5-24 This document identifies the behavioral properties required of the Network Address Translator devices (NATs) in conjunction with the ICMP protocol. The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP and UDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-nat-icmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-nat-icmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From fluffy@cisco.com Wed, 24 May 2006 16:21:16 -0700 (PDT) From: Cullen Jennings Date: Wed, 24 May 2006 16:21:16 -0700 (PDT) Subject: Re: [Ietf-behave] Milestones, ICMP In-Reply-To: <13da01c672fc$35eae770$179a150a@amer.cisco.com> Message-ID: <900C405B-12F8-4560-A2DF-806272DDD7C4@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I strongly object to adopting this without discussion with the WG. Let's give this draft agenda time at the next IETF and then at the end ask the 100 plus members of this WG if they want to adopt it. Cullen On May 8, 2006, at 5:04 PM, Dan Wing wrote: I would like the list to consider having draft-srisuresh-behave-nat-icmp-02.txt become a WG item. I expect its milestone would align with the TCP document, which will have its milestone date pushed out to sometime this fall, as the working group needs to concentrate its efforts on the revision to STUN (rfc3489bis) and on TURN, which are needed for VoIP. Please provide comments to the list. -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Wed, 24 May 2006 16:39:28 -0700 (PDT) From: "Dan Wing" Date: Wed, 24 May 2006 16:39:28 -0700 (PDT) Subject: RE: [Ietf-behave] Milestones, ICMP In-Reply-To: <900C405B-12F8-4560-A2DF-806272DDD7C4@cisco.com> Message-ID: <012301c67f8b$4c83b700$9083200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > I strongly object to adopting this without discussion with the WG. > Let's give this draft agenda time at the next IETF and then at the > end ask the 100 plus members of this WG if they want to adopt it. Decisions are made on-list. As of my email on May 8 (two weeks ago), only two people responded and both were positive: Fernando Gont and Philip Matthews. The draft had agenda time at the last IETF, I'm not sure what else you wanted to discuss. I know the scope of the document is larger than you'd like; as a WG document we can manage its scope in conjunction with other WG documents. The draft will be on the agenda, if there is time. What remains most critical for BEHAVE is to finish off the ICE-related specifications (rfc3489bis, TURN, turn-v6) because it is holding up implementations of VoIP. To my knowledge, turning ICMP into an RFC is not holding up implementations of NATs, VoIP gear, or applications, and our agenda time will be spent accordingly. -d > Cullen > > > On May 8, 2006, at 5:04 PM, Dan Wing wrote: > > > I would like the list to consider having > > draft-srisuresh-behave-nat-icmp-02.txt become a WG item. > > > > I expect its milestone would align with the TCP document, which > > will have > > its milestone date pushed out to sometime this fall, as the > > working group > > needs to concentrate its efforts on the revision to STUN > > (rfc3489bis) and on > > TURN, which are needed for VoIP. > > > > Please provide comments to the list. > > > > -d > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Wed, 24 May 2006 16:52:30 -0700 (PDT) From: Cullen Jennings Date: Wed, 24 May 2006 16:52:30 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <1148469744.18773.81.camel@localhost.localdomain> Message-ID: <7F823570-1557-4D30-8115-3B139EF58E01@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I prefer option 1 and when some appropriate ICMP stuff is defined, change the recommendation to something like 2. 4 is very tricky to know what times would be appropriate. On May 24, 2006, at 4:22 AM, Saikat Guha wrote: The discussion on- and off- list had identified a bunch of issues that I quickly summarize below. I would like to get some feedback (particularly on Option 4 from the vendors) on the four potential requirements below. Issues (simplified, see original thread for details): 1. TCP Simultaneous-Open is necessary for P2P apps. NATs shouldn't force such attempts to be aborted. But there is currently no way to do so with ICMP/TCP messages. Barring future work (improbable), facilitating S-O would require NATs ignore the error (perhaps momentarily) 2. The intent of prior RFCs is to signal errors (MUST or SHOULD depending) which would hinder P2P TCP, but would follow the spirit of RFCs. So here are the options: Option 1: Current proposal in the draft ======== "A NAT MUST silently drop inbound SYNs" Issues: Totally against the spirit of old RFCs, making network troubleshooting harder, but allows TCP S-O Option 2: Proposed earlier on the list by myself ========= "A NAT MUST NOT force an end-host to abort a TCP connection that could be a S-O. It SHOULD return an error if the error doesn't force the end abort the attempt. Otherwise, it MUST silently drop the SYN" Issues: Hard to implement and understand. Currently no possible to implement the first two clauses. Still facilitates S-O, but is forwards compatible in the unlikely event that the first two clauses become satisfiable. Option 3: Following the REQ-8 language in the UDP spec ========= "If enabling P2P TCP apps is most important, a NAT MUST silently drop the SYN. If enabling quick diagnosis of network errors is most important, a NAT SHOULD signal an ICMP port unreachable. The behavior MAY be configurable by the administrator." Issues: Let the NAT admin pick whether to allow TCP S-O or signal errors. Option 4: Proposed earlier on list by Joe ========= "A NAT SHOULD signal an ICMP port unreachable. If it does, it MUST delay the ICMP error by at least 3 seconds and MUST cancel the ICMP if in that time an outbound SYN for the connection is seen. If the NAT does not have resources to delay the ICMP, it MUST silently drop the inbound SYN" Issues: Delaying the ICMP gives the internal side's SYN or retransmission a chance to trigger a S-O. This requires bounded state at the NAT. In an attack (when the buffer is full), it allows the NAT to silently discard SYNs. Together, it facilitates S-O regardless of whether the NAT is low on resources or not. When the NAT has resources to spare, it facilitates error detection (delayed by 3s). When out of resources it degrades gracefully to support S-O but not fast error detection. I'd particularly like to know how vendors and others feel about Option 4. cheers, -- Saikat From pekkas@netcore.fi Thu, 25 May 2006 04:38:43 -0700 (PDT) From: Pekka Savola Date: Thu, 25 May 2006 04:38:43 -0700 (PDT) Subject: Re: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Tue, 23 May 2006, Cullen Jennings wrote: I think that UNSAF mechanisms must be able to work with ALGs enabled by default. If they don't, they're too brittle and should be written in a more generic manner, with non-ALG mechanisms. I have two NATs on my shelf right now that have an interesting ALG in them. If the NAT has a public address of 1.1.1.1 any time it see the string "1.1.1.1" or the 32 bit value 0x01010101 in any packet, it replaces it with the private address. Say you are FTP a file that happens to have the bit sequences, well it gets replaces. I don't think we should design applications to work with this ALG - I think we should encourage people not to deploy something so broken. That kind of NAT box is very broken -- and has very little as such to do with ALG, which are (in my book) application-specific. I also have some NATs with SIP ALGs. I will talk about the one from the vendor I work for but as far as I can tell other vendors are no better. The SIP ALG regularly tampers with things in a way that breaks things in very unpredictable ways. It will rewrite some address but not others - it is very difficult for any UNSAF algorithm to know what parts of the message might get tampered with and to stop that. I don't agree with this line of reasoning. I'd pose the question as follows: Which is worse, application not working AT ALL (because there is no ALG, nor NAT traversal mechanism) or that application works with correctly implemented ALGs (or works "most of the time" implying with typical usage patterns but more advanced ones might not work)? You seem to be assuming that all the applications for which there is an ALG have their own NAT traversal mechanism, so disabling the ALG is OK as the application can work using the NAT-traversal method. While this may or may not be the case for SIP, I do not think this is the case in general -- and you're recommending disabling UDP ALGs in general. For example, if you are doing ICE and want to pass your local and public address the ALG tends to rewrite the private address with the public address and some times leaves the public address along and sometimes tries to change it if it matches a flow it recognizes. We may have a terminology conflict here. First of all, I'm all for strongly disallowing NAT features which blindly replace strings with other strings, or 32 bit binary blobs with other binary blobs. In my book, "ALG" refers to a mechanism that is specific to an application: identified by application identifier strings, the type and content of messaging, or even just a well-known port number. It seems you're saying that a NAT traversal mechanism like ICE is embedded in an application (SIP?) for which there exists an ALG, so that ALG has the possibility of breaking ICE. Maybe in that case you should just recommend that SIP ALG is disabled, or that it must be implemented in such a manner that it doesn't interfere with ICE (or maybe ICE design needs to be changed so it doesn't get mixed in an ALG). Further, I'd say that if we want a generic NAT traversal mechanism to be successful (instead of reinventing it for every single application), it MUST be separate from any application, and therefore unhampered by application-specific ALGs. Therefore I do not see the problem with ALGs in general. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From philip_matthews@magma.ca Thu, 25 May 2006 08:18:21 -0700 (PDT) From: Philip Matthews Date: Thu, 25 May 2006 08:18:21 -0700 (PDT) Subject: Re: [Ietf-behave] Milestones, ICMP In-Reply-To: <012301c67f8b$4c83b700$9083200a@amer.cisco.com> Message-ID: <344A0F1C-70E0-4E44-BEB8-8433E9F5FA1D@magma.ca> MIME-Version: 1.0 Content-Type: text/plain Just to clarify what I meant by my previous vote for support of this document: I support the idea of having a BEHAVE document that covers ICMP, because I feel ICMP is a key protocol that BEHAVE needs to say something about. Right now, draft-srisuresh-behave-nat-icmp-02 is the only document we have that covers ICMP, so I am willing to take it as a starting point. But I do think it needs careful review. What I think Cullen is suggesting is that the contents of this document need careful review. He suggests going over it carefully in a WG meeting. I would also like to see this happen. Perhaps a way forward is to adopt draft-srisuresh-behave-nat-icmp-02 as a WG item, but put it lower on the priority list than the ICE documents and the TCP document? This would mean that the STUN and TURN documents, and the TCP document, would get the bulk of the presentation time at the Montreal meeting, and there might not be time for the ICMP document at that meeting. However, we would try to have a presentation of the type that Cullen is suggesting at a later meeting (hopefully the fall meeting). Just my 2 cents ... - Philip On 24-May-06, at 19:39 , Dan Wing wrote: I strongly object to adopting this without discussion with the WG. Let's give this draft agenda time at the next IETF and then at the end ask the 100 plus members of this WG if they want to adopt it. Decisions are made on-list. As of my email on May 8 (two weeks ago), only two people responded and both were positive: Fernando Gont and Philip Matthews. The draft had agenda time at the last IETF, I'm not sure what else you wanted to discuss. I know the scope of the document is larger than you'd like; as a WG document we can manage its scope in conjunction with other WG documents. The draft will be on the agenda, if there is time. What remains most critical for BEHAVE is to finish off the ICE-related specifications (rfc3489bis, TURN, turn-v6) because it is holding up implementations of VoIP. To my knowledge, turning ICMP into an RFC is not holding up implementations of NATs, VoIP gear, or applications, and our agenda time will be spent accordingly. -d Cullen On May 8, 2006, at 5:04 PM, Dan Wing wrote: I would like the list to consider having draft-srisuresh-behave-nat-icmp-02.txt become a WG item. I expect its milestone would align with the TCP document, which will have its milestone date pushed out to sometime this fall, as the working group needs to concentrate its efforts on the revision to STUN (rfc3489bis) and on TURN, which are needed for VoIP. Please provide comments to the list. -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From philip_matthews@magma.ca Thu, 25 May 2006 12:40:02 -0700 (PDT) From: Philip Matthews Date: Thu, 25 May 2006 12:40:02 -0700 (PDT) Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <1148469744.18773.81.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I feel it is important to make TCP Simultaneous-Open work. Regarding option 4: I feel that coordinating peers so they do things at the same time can be difficult. If peers A and B are trying to set up a connection between them, but peer B gets busy doing something else for a few seconds and misses the 3 second window, then the whole connection attempt fails. In our product (a peer-to- peer telephony system), we see situations where the CPU on one hard-phone can get very overloaded for a few seconds. I could easily see that this option would lead to situations where the connection would be established most of the time, but would randomly fail from time-to-time because the 3 second window was missed. Given this concern, my current preference is for option 1. Saikat: Might I suggest producing a brief presentation describing these options and asking for presentation time at both the BEHAVE and TCPM meetings in Montreal? - Philip On 24-May-06, at 19:52 , Cullen Jennings wrote: I prefer option 1 and when some appropriate ICMP stuff is defined, change the recommendation to something like 2. 4 is very tricky to know what times would be appropriate. On May 24, 2006, at 4:22 AM, Saikat Guha wrote: The discussion on- and off- list had identified a bunch of issues that I quickly summarize below. I would like to get some feedback (particularly on Option 4 from the vendors) on the four potential requirements below. Issues (simplified, see original thread for details): 1. TCP Simultaneous-Open is necessary for P2P apps. NATs shouldn't force such attempts to be aborted. But there is currently no way to do so with ICMP/TCP messages. Barring future work (improbable), facilitating S-O would require NATs ignore the error (perhaps momentarily) 2. The intent of prior RFCs is to signal errors (MUST or SHOULD depending) which would hinder P2P TCP, but would follow the spirit of RFCs. So here are the options: Option 1: Current proposal in the draft ======== "A NAT MUST silently drop inbound SYNs" Issues: Totally against the spirit of old RFCs, making network troubleshooting harder, but allows TCP S-O Option 2: Proposed earlier on the list by myself ========= "A NAT MUST NOT force an end-host to abort a TCP connection that could be a S-O. It SHOULD return an error if the error doesn't force the end abort the attempt. Otherwise, it MUST silently drop the SYN" Issues: Hard to implement and understand. Currently no possible to implement the first two clauses. Still facilitates S-O, but is forwards compatible in the unlikely event that the first two clauses become satisfiable. Option 3: Following the REQ-8 language in the UDP spec ========= "If enabling P2P TCP apps is most important, a NAT MUST silently drop the SYN. If enabling quick diagnosis of network errors is most important, a NAT SHOULD signal an ICMP port unreachable. The behavior MAY be configurable by the administrator." Issues: Let the NAT admin pick whether to allow TCP S-O or signal errors. Option 4: Proposed earlier on list by Joe ========= "A NAT SHOULD signal an ICMP port unreachable. If it does, it MUST delay the ICMP error by at least 3 seconds and MUST cancel the ICMP if in that time an outbound SYN for the connection is seen. If the NAT does not have resources to delay the ICMP, it MUST silently drop the inbound SYN" Issues: Delaying the ICMP gives the internal side's SYN or retransmission a chance to trigger a S-O. This requires bounded state at the NAT. In an attack (when the buffer is full), it allows the NAT to silently discard SYNs. Together, it facilitates S-O regardless of whether the NAT is low on resources or not. When the NAT has resources to spare, it facilitates error detection (delayed by 3s). When out of resources it degrades gracefully to support S-O but not fast error detection. I'd particularly like to know how vendors and others feel about Option 4. cheers, -- Saikat _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Thu, 25 May 2006 14:16:13 -0700 (PDT) From: Cullen Jennings Date: Thu, 25 May 2006 14:16:13 -0700 (PDT) Subject: Re: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: Message-ID: <71CD9FAF-A3AA-4591-BC8D-945BB03ED7B5@cisco.com> MIME-Version: 1.0 Content-Type: text/plain As Pekka suggests, he and I may just be using the wrong words but agree about the fundamentals of this. I put some comments inline then a possible suggestion to resolve this at the bottom. On May 25, 2006, at 4:38 AM, Pekka Savola wrote: autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi On Tue, 23 May 2006, Cullen Jennings wrote: I think that UNSAF mechanisms must be able to work with ALGs enabled by default. If they don't, they're too brittle and should be written in a more generic manner, with non-ALG mechanisms. I have two NATs on my shelf right now that have an interesting ALG in them. If the NAT has a public address of 1.1.1.1 any time it see the string "1.1.1.1" or the 32 bit value 0x01010101 in any packet, it replaces it with the private address. Say you are FTP a file that happens to have the bit sequences, well it gets replaces. I don't think we should design applications to work with this ALG - I think we should encourage people not to deploy something so broken. That kind of NAT box is very broken -- and has very little as such to do with ALG, which are (in my book) application-specific. ok - we might be close to same page then I also have some NATs with SIP ALGs. I will talk about the one from the vendor I work for but as far as I can tell other vendors are no better. The SIP ALG regularly tampers with things in a way that breaks things in very unpredictable ways. It will rewrite some address but not others - it is very difficult for any UNSAF algorithm to know what parts of the message might get tampered with and to stop that. I don't agree with this line of reasoning. I'd pose the question as follows: Which is worse, application not working AT ALL (because there is no ALG, nor NAT traversal mechanism) or that application works with correctly implemented ALGs (or works "most of the time" implying with typical usage patterns but more advanced ones might not work)? I will explain some experience of running code but I suspect you and I both agree on works some of the time is better than never works. The number one NAT vendor (by number of NATs shipped) turned on a SIP ALG one day. This ALG had no real way of knowing if a message was a SIP message or just something that looked like SIP. It looked at the destination port being 5060. If you happen to be running RTSP or HTTP server on 5060, it went and applied the SIP ALG. The SIP ALG conceited of arbitrarily searching for strings in right places and replacing them - it's hard to specify any ALG that does not do this. Although the ALG had good intentions, if you send an IM that contained you IP address, well it got changes in the text of the IM. No one thought this was great and clearly a smarter ALG could have avoided this. However, no ALG could have been smart enough such that a backward compatible extension to the SIP protocol would not result in some situation where the ALG did the wrong thing. The reason there is not an RFC for a SIP ALG is because it is impossible to write a SIP ALG that works and will work in the future. Now you might thing this ALG at least did not make things any worse - well that is where the problems started. It made things way worse. At the point in time this was releases, many existing soft-phone and IM clients works just fine behind NATs. However, this ALG broke them all - it arbitrarily trashed bits in the message and the device could not figure out which bits it trashed and which ones it did not. This made for avery non deterministic experience - There was many howls of complaints from customers and the vendor went and turned off the ALG. Now I know there are more protocols on the internet than just SIP :-), but many other are similar in that there is no defined way to ALG them that does not break the protocol. You seem to be assuming that all the applications for which there is an ALG have their own NAT traversal mechanism, so disabling the ALG is OK as the application can work using the NAT-traversal method. While this may or may not be the case for SIP, I do not think this is the case in general -- and you're recommending disabling UDP ALGs in general. Let me turn the question around - which ALGs to you recommend we turn on? If there are ones that don't cause serious harm and are well specified, I imagine people would be glad to turn them on. For example, if you are doing ICE and want to pass your local and public address the ALG tends to rewrite the private address with the public address and some times leaves the public address along and sometimes tries to change it if it matches a flow it recognizes. We may have a terminology conflict here. First of all, I'm all for strongly disallowing NAT features which blindly replace strings with other strings, or 32 bit binary blobs with other binary blobs. In this case, I think you and I will come to the same end conclusion on this one. In my book, "ALG" refers to a mechanism that is specific to an application: identified by application identifier strings, the type and content of messaging, or even just a well-known port number. Ok - I think that we would agree that something like a HTTP Cache which is well specified, and designed for when updating the HTTP protocol, would be fine to turn on. I realize this is not exactly an ALG but if we had an ALG with the properties of web cache as far as deterministic behavior goes, I would have no problem with it. It seems you're saying that a NAT traversal mechanism like ICE is embedded in an application (SIP?) for which there exists an ALG, so that ALG has the possibility of breaking ICE. Maybe in that case you should just recommend that SIP ALG is disabled, or that it must be implemented in such a manner that it doesn't interfere with ICE (or maybe ICE design needs to be changed so it doesn't get mixed in an ALG). Further, I'd say that if we want a generic NAT traversal mechanism to be successful (instead of reinventing it for every single application), it MUST be separate from any application, and therefore unhampered by application-specific ALGs. Therefore I do not see the problem with ALGs in general Here is my suggestion. We say something like All UDP ALGs other than X,Y,Z be turned off. Any future standards track documents that define an ALG MAY update this draft to recommend that the ALG for that protocol be turned on by default. I'm happy to put any protocol in the X,Y,Z list as long as it has a well defined ALG that will not break applications. Cullen From fluffy@cisco.com Thu, 25 May 2006 14:25:16 -0700 (PDT) From: Cullen Jennings Date: Thu, 25 May 2006 14:25:16 -0700 (PDT) Subject: Re: [Ietf-behave] Milestones, ICMP In-Reply-To: <012301c67f8b$4c83b700$9083200a@amer.cisco.com> Message-ID: <334A868A-6FE2-448E-AFFA-8C5245D5F9C4@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On May 24, 2006, at 4:39 PM, Dan Wing wrote: The draft had agenda time at the last IETF, I'm not sure what else you wanted to discuss. The topic of if the WG wanted to adopt this draft and why some people thought that was a good idea and why others did not. From audet@nortel.com Thu, 25 May 2006 14:38:32 -0700 (PDT) From: "Francois Audet" Date: Thu, 25 May 2006 14:38:32 -0700 (PDT) Subject: RE: [Ietf-behave] Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) In-Reply-To: <71CD9FAF-A3AA-4591-BC8D-945BB03ED7B5@cisco.com> Message-ID: <1ECE0EB50388174790F9694F77522CCF09F79EE8@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I'm reading what Pekka is saying as very different from what you and I are saying. Pekka, can you propose a wording that will be acceptable to us? As Cullen suggest, if you have particular ALGs that you have in mind, let us know. But we couldn't figure out any UDP ALG that should be on by default. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Thursday, May 25, 2006 14:16 > To: Pekka Savola > Cc: Behave WG; Audet, Francois [SC100:3055:EXCH]; Magnus Westerlund > Subject: Re: [Ietf-behave] Re: Last Call: 'NAT Behavioral > Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) > > > > As Pekka suggests, he and I may just be using the wrong words but > agree about the fundamentals of this. I put some comments > inline then > a possible suggestion to resolve this at the bottom. > > > On May 25, 2006, at 4:38 AM, Pekka Savola wrote: > > > autolearn=ham version=3.1.1 > > X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on > > otso.netcore.fi > > > > On Tue, 23 May 2006, Cullen Jennings wrote: > >>> I think that UNSAF mechanisms must be able to work with ALGs > >>> enabled by > >>> default. If they don't, they're too brittle and should be > >>> written in a more > >>> generic manner, with non-ALG mechanisms. > >> > >> I have two NATs on my shelf right now that have an interesting ALG > >> in them. If the NAT has a public address of 1.1.1.1 any time it > >> see the string "1.1.1.1" or the 32 bit value 0x01010101 in any > >> packet, it replaces it with the private address. Say you > are FTP a > >> file that happens to have the bit sequences, well it gets > >> replaces. I don't think we should design applications to > work with > >> this ALG - I think we should encourage people not to deploy > >> something so broken. > > > > That kind of NAT box is very broken -- and has very little as such > > to do with ALG, which are (in my book) application-specific. > > ok - we might be close to same page then > > > > >> I also have some NATs with SIP ALGs. I will talk about the one > >> from the vendor I work for but as far as I can tell other vendors > >> are no better. The SIP ALG regularly tampers with things in a way > >> that breaks things in very unpredictable ways. It will rewrite > >> some address but not others - it is very difficult for any UNSAF > >> algorithm to know what parts of the message might get tampered > >> with and to stop that. > > > > I don't agree with this line of reasoning. I'd pose the question > > as follows: > > > > Which is worse, application not working AT ALL (because > there is no > > ALG, nor NAT traversal mechanism) or that application works with > > correctly implemented ALGs (or works "most of the time" implying > > with typical usage patterns but more advanced ones might > not work)? > > I will explain some experience of running code but I suspect you and > I both agree on works some of the time is better than never works. > > The number one NAT vendor (by number of NATs shipped) turned > on a SIP > ALG one day. This ALG had no real way of knowing if a message was a > SIP message or just something that looked like SIP. It looked at the > destination port being 5060. If you happen to be running RTSP > or HTTP > server on 5060, it went and applied the SIP ALG. The SIP ALG > conceited of arbitrarily searching for strings in right places and > replacing them - it's hard to specify any ALG that does not do this. > Although the ALG had good intentions, if you send an IM that > contained you IP address, well it got changes in the text of the IM. > No one thought this was great and clearly a smarter ALG could have > avoided this. However, no ALG could have been smart enough such that > a backward compatible extension to the SIP protocol would not result > in some situation where the ALG did the wrong thing. The > reason there > is not an RFC for a SIP ALG is because it is impossible to write a > SIP ALG that works and will work in the future. > > Now you might thing this ALG at least did not make things any > worse - > well that is where the problems started. It made things way > worse. At > the point in time this was releases, many existing soft-phone and IM > clients works just fine behind NATs. However, this ALG broke > them all > - it arbitrarily trashed bits in the message and the device > could not > figure out which bits it trashed and which ones it did not. > This made > for avery non deterministic experience - There was many howls of > complaints from customers and the vendor went and turned off the ALG. > > Now I know there are more protocols on the internet than just > SIP :-), but many other are similar in that there is no defined way > to ALG them that does not break the protocol. > > > > > You seem to be assuming that all the applications for which there > > is an ALG have their own NAT traversal mechanism, so disabling the > > ALG is OK as the application can work using the NAT-traversal > > method. While this may or may not be the case for SIP, I do not > > think this is the case in general -- and you're recommending > > disabling UDP ALGs in general. > > Let me turn the question around - which ALGs to you recommend > we turn > on? If there are ones that don't cause serious harm and are well > specified, I imagine people would be glad to turn them on. > > > > >> For example, if you are doing ICE and want to pass your local and > >> public address the ALG tends to rewrite the private address with > >> the public address and some times leaves the public address along > >> and sometimes tries to change it if it matches a flow it > recognizes. > > > > We may have a terminology conflict here. > > > > First of all, I'm all for strongly disallowing NAT features which > > blindly replace strings with other strings, or 32 bit binary blobs > > with other binary blobs. > In this case, I think you and I will come to the same end conclusion > on this one. > > > > > In my book, "ALG" refers to a mechanism that is specific to an > > application: identified by application identifier strings, > the type > > and content of messaging, or even just a well-known port number. > Ok - I think that we would agree that something like a HTTP Cache > which is well specified, and designed for when updating the HTTP > protocol, would be fine to turn on. I realize this is not exactly an > ALG but if we had an ALG with the properties of web cache as far as > deterministic behavior goes, I would have no problem with it. > > > > > It seems you're saying that a NAT traversal mechanism like ICE is > > embedded in an application (SIP?) for which there exists an > ALG, so > > that ALG has the possibility of breaking ICE. > > > > Maybe in that case you should just recommend that SIP ALG is > > disabled, or that it must be implemented in such a manner that it > > doesn't interfere with ICE (or maybe ICE design needs to be > changed > > so it doesn't get mixed in an ALG). > > > > Further, I'd say that if we want a generic NAT traversal mechanism > > to be successful (instead of reinventing it for every single > > application), it MUST be separate from any application, and > > therefore unhampered by application-specific ALGs. Therefore I do > > not see the problem with ALGs in general > > Here is my suggestion. We say something like > > All UDP ALGs other than X,Y,Z be turned off. Any future standards > track documents that define an ALG MAY update this draft to > recommend > that the ALG for that protocol be turned on by default. > > I'm happy to put any protocol in the X,Y,Z list as long as it has a > well defined ALG that will not break applications. > > > Cullen > > > From dwing@cisco.com Thu, 25 May 2006 14:51:42 -0700 (PDT) From: "Dan Wing" Date: Thu, 25 May 2006 14:51:42 -0700 (PDT) Subject: RE: [Ietf-behave] Milestones, ICMP In-Reply-To: <334A868A-6FE2-448E-AFFA-8C5245D5F9C4@cisco.com> Message-ID: <062f01c68045$68fd0930$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > On May 24, 2006, at 4:39 PM, Dan Wing wrote: > > > The draft had agenda time at the last > > IETF, I'm not sure what else you wanted to discuss. > > The topic of if the WG wanted to adopt this draft and why > some people thought that was a good idea and why others > did not. Ok. I will be sure at least 10 minutes are on the agenda for doing that. -d From dwing@cisco.com Thu, 25 May 2006 14:54:15 -0700 (PDT) From: "Dan Wing" Date: Thu, 25 May 2006 14:54:15 -0700 (PDT) Subject: RE: [Ietf-behave] Milestones, ICMP In-Reply-To: <344A0F1C-70E0-4E44-BEB8-8433E9F5FA1D@magma.ca> Message-ID: <063101c68045$c411afb0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Just to clarify what I meant by my previous vote for support of this > document: > > I support the idea of having a BEHAVE document that covers ICMP, > because I feel ICMP is a key protocol that BEHAVE needs to say > something about. > > Right now, draft-srisuresh-behave-nat-icmp-02 is the only document > we have that covers ICMP, so I am willing to take it as a starting > point. But I do think it needs careful review. > > What I think Cullen is suggesting is that the contents of this > document need careful review. He suggests going over it carefully > in a WG meeting. I would also like to see this happen. > > Perhaps a way forward is to adopt draft-srisuresh-behave-nat-icmp-02 > as a WG item, but put it lower on the priority list than the ICE > documents and the TCP document? Yes, that is my intent. There are new milestones for BEHAVE, which have been accepted by our AD (Magnus). I emailed them to iesg-secretary last week and I'm waiting for them to be published. The milestone for ICMP is March, 2007. If (and only if) we aren't busy with our earlier milestones and if ICMP is ready, we can last-call ICMP earlier. With Cullen's objection, though, we will discuss this at the meeting. It's certainly the case that there seem to be few people interested positively (2, plus its authors, I assume) or negatively (1) about this document. > This would mean that the STUN and > TURN documents, and the TCP document, would get the bulk of the > presentation time at the Montreal meeting, and there might not be > time for the ICMP document at that meeting. However, we would try > to have a presentation of the type that Cullen is suggesting at a > later meeting (hopefully the fall meeting). > > Just my 2 cents ... Those cents make good sence. Thanks. -d > - Philip > > > > > On 24-May-06, at 19:39 , Dan Wing wrote: > > >> I strongly object to adopting this without discussion with the WG. > >> Let's give this draft agenda time at the next IETF and then at the > >> end ask the 100 plus members of this WG if they want to adopt it. > > > > Decisions are made on-list. As of my email on May 8 (two weeks > > ago), only two people responded and both were positive: Fernando > > Gont and Philip Matthews. The draft had agenda time at the last > > IETF, I'm not sure what else you wanted to discuss. I know the > > scope of the document is larger than you'd like; as a WG document > > we can manage its scope in conjunction with other WG documents. > > > > The draft will be on the agenda, if there is time. What remains > > most critical for BEHAVE is to finish off the ICE-related > > specifications (rfc3489bis, TURN, turn-v6) because it is holding > > up implementations of VoIP. To my knowledge, turning ICMP into > > an RFC is not holding up implementations of NATs, VoIP gear, or > > applications, and our agenda time will be spent accordingly. > > > > -d > > > > > >> Cullen > >> > >> > >> On May 8, 2006, at 5:04 PM, Dan Wing wrote: > >> > >>> I would like the list to consider having > >>> draft-srisuresh-behave-nat-icmp-02.txt become a WG item. > >>> > >>> I expect its milestone would align with the TCP document, which > >>> will have > >>> its milestone date pushed out to sometime this fall, as the > >>> working group > >>> needs to concentrate its efforts on the revision to STUN > >>> (rfc3489bis) and on > >>> TURN, which are needed for VoIP. > >>> > >>> Please provide comments to the list. > >>> > >>> -d > >>> _______________________________________________ > >>> Ietf-behave mailing list > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Thu, 25 May 2006 16:36:40 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 25 May 2006 16:36:40 -0700 (PDT) Subject: RE: [Ietf-behave] Milestones, ICMP In-Reply-To: <063101c68045$c411afb0$c2f0200a@amer.cisco.com> Message-ID: <20060525233640.50282.qmail@web33302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dan Wing wrote: > > Just to clarify what I meant by my previous vote for support of this > > document: > > > > I support the idea of having a BEHAVE document that covers ICMP, > > because I feel ICMP is a key protocol that BEHAVE needs to say > > something about. > > > > Right now, draft-srisuresh-behave-nat-icmp-02 is the only document > > we have that covers ICMP, so I am willing to take it as a starting > > point. But I do think it needs careful review. > > [suresh] Philip - I sent a revised draft yesterday for publication as WG draft (with Dan's OK). The draft is now available as draft-ietf-behave-nat-icmp-00.txt. Do give this draft a careful review and let us (the authors) know your comments. I am all for people reviewing the draft and sending comments. Decisions should be made on the list. > > What I think Cullen is suggesting is that the contents of this > > document need careful review. He suggests going over it carefully > > in a WG meeting. I would also like to see this happen. > > > > Perhaps a way forward is to adopt draft-srisuresh-behave-nat-icmp-02 > > as a WG item, but put it lower on the priority list than the ICE > > documents and the TCP document? > > Yes, that is my intent. There are new milestones for BEHAVE, which > have been accepted by our AD (Magnus). I emailed them to > iesg-secretary last week and I'm waiting for them to be published. > > The milestone for ICMP is March, 2007. If (and only if) we aren't > busy with our earlier milestones and if ICMP is ready, we can > last-call ICMP earlier. > [suresh] As I said earlier, I welcome comments and review on the list. We cannot know if a draft is ready, unless it is reviewed. The list should be such a forum for review - Not WG meetings, which are held just 3 times a year. It does not make sense to wait for a WG meeting to decide on adapting a document for the WG or any decision for that matter. > With Cullen's objection, though, we will discuss this at the > meeting. It's certainly the case that there seem to be few > people interested positively (2, plus its authors, I assume) > or negatively (1) about this document. > [suresh] Dan - You did a detailed review of the draft before OKing it as WG draft. Does that not count as one more for Yes? If so, that would be 3 for Yes, apart from the authors. (or) would you rather not inlcude a WG chair's opinion? Obviously, the more people review and speak up, the easier it is to proceed forward. Thanks. Cheers, suresh > > This would mean that the STUN and > > TURN documents, and the TCP document, would get the bulk of the > > presentation time at the Montreal meeting, and there might not be > > time for the ICMP document at that meeting. However, we would try > > to have a presentation of the type that Cullen is suggesting at a > > later meeting (hopefully the fall meeting). > > > > Just my 2 cents ... > > Those cents make good sence. Thanks. > > -d > > > > - Philip > > > > > > > > > > On 24-May-06, at 19:39 , Dan Wing wrote: > > > > >> I strongly object to adopting this without discussion with the WG. > > >> Let's give this draft agenda time at the next IETF and then at the > > >> end ask the 100 plus members of this WG if they want to adopt it. > > > > > > Decisions are made on-list. As of my email on May 8 (two weeks > > > ago), only two people responded and both were positive: Fernando > > > Gont and Philip Matthews. The draft had agenda time at the last > > > IETF, I'm not sure what else you wanted to discuss. I know the > > > scope of the document is larger than you'd like; as a WG document > > > we can manage its scope in conjunction with other WG documents. > > > > > > The draft will be on the agenda, if there is time. What remains > > > most critical for BEHAVE is to finish off the ICE-related > > > specifications (rfc3489bis, TURN, turn-v6) because it is holding > > > up implementations of VoIP. To my knowledge, turning ICMP into > > > an RFC is not holding up implementations of NATs, VoIP gear, or > > > applications, and our agenda time will be spent accordingly. > > > > > > -d > > > > > > > > >> Cullen > > >> > > >> > > >> On May 8, 2006, at 5:04 PM, Dan Wing wrote: > > >> > > >>> I would like the list to consider having > > >>> draft-srisuresh-behave-nat-icmp-02.txt become a WG item. > > >>> > > >>> I expect its milestone would align with the TCP document, which > > >>> will have > > >>> its milestone date pushed out to sometime this fall, as the > > >>> working group > > >>> needs to concentrate its efforts on the revision to STUN > > >>> (rfc3489bis) and on > > >>> TURN, which are needed for VoIP. > > >>> > > >>> Please provide comments to the list. > > >>> > > >>> -d > > >>> _______________________________________________ > > >>> Ietf-behave mailing list > > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > >> > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From manjur@eyeball.com Thu, 25 May 2006 17:08:59 -0700 (PDT) From: "Manjur" Date: Thu, 25 May 2006 17:08:59 -0700 (PDT) Subject: [Ietf-behave] draft-ietf-behave-turn-00 In-Reply-To: <059401c66d97$eb6c7240$d960150a@amer.cisco.com> Message-ID: <003201c68058$94de45b0$f901020a@eyeball.com> MIME-Version: 1.0 Content-Type: text/plain Hi, I have taken a part for the draft-ietf-behave-turn-00. It seems that 0x0020 should be 0x001a and so on. Is it right? 9. New Attributes The STUN relay usage defines the following new attributes: 0x000d: LIFETIME 0x0010: BANDWIDTH 0x0011: DESTINATION-ADDRESS 0x0012: REMOTE-ADDRESS 0x0013: DATA 0x0016: RELAY-ADDRESS 0x0018: REQUESTED-PORT 0x0019: REQUESTED-TRANSPORT 0x0020: REQUESTED-IP 0x0021: TIMER-VAL Thank you --Manjur From dwing@cisco.com Thu, 25 May 2006 19:05:11 -0700 (PDT) From: "Dan Wing" Date: Thu, 25 May 2006 19:05:11 -0700 (PDT) Subject: RE: [Ietf-behave] Milestones, ICMP In-Reply-To: <20060525233640.50282.qmail@web33302.mail.mud.yahoo.com> Message-ID: <06f901c68068$d1c06980$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > [suresh] Dan - You did a detailed review of the draft before > OKing it as WG draft. Does that not count as one more for > Yes? If so, that would be 3 for Yes, apart from the authors. > (or) would you rather not inlcude a WG chair's opinion? We're still talking 1-2% of BEHAVE (~200 subscribers, ~100 attendees at IETF), with or without me. -d From srisuresh@yahoo.com Thu, 25 May 2006 20:01:29 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 25 May 2006 20:01:29 -0700 (PDT) Subject: RE: [Ietf-behave] Milestones, ICMP In-Reply-To: <06f901c68068$d1c06980$c2f0200a@amer.cisco.com> Message-ID: <20060526030128.56698.qmail@web33310.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dan Wing wrote: > > [suresh] Dan - You did a detailed review of the draft before > > OKing it as WG draft. Does that not count as one more for > > Yes? If so, that would be 3 for Yes, apart from the authors. > > (or) would you rather not inlcude a WG chair's opinion? > > We're still talking 1-2% of BEHAVE (~200 subscribers, ~100 > attendees at IETF), with or without me. > [suresh] And, there is one person (Cullen as individual contributor) that objected. That would be less than 1%, if you go by % counts. And, the objection is on procedural count, not on technical. For the record, I disagree with Cullen's assertion that decisions should only be made on the WG meeting. This is wrong procedurally. Decisions shoudl be made on the list. And, I did not hear any technical reason why he objects to seeing the draft draft adapted as WG draft. There is a pattern here. Cullen had insisted in the past there is no need for an ICMP behave document on the list. Each time he did this, I or someone on the list responded with a technical reason why that is not so (Refer the several e-mail exchanges before the last IETF WG meeting). He held out on giving the draft a slot/time in the WG meeting till the very end. He repeated the comments again during the last WG meeting. He used similar type of questioning during the private review as well and kept prolonging the discussion. In the end, everyone, inluding himself, agreed there was value to the draft. Now, he objects again - this time on procedural grounds. He has been single handedly filibustering the document. This is not conducive to productive participation. My 2c. regards, suresh > -d > From baford@mit.edu Fri, 26 May 2006 00:14:23 -0700 (PDT) From: Bryan Ford Date: Fri, 26 May 2006 00:14:23 -0700 (PDT) Subject: Re: [Ietf-behave] Milestones, ICMP In-Reply-To: <06f901c68068$d1c06980$c2f0200a@amer.cisco.com> Message-ID: <200605260914.21271.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain FWIW, I too support the adoption of the ICMP draft. As for "counting percentages", my observation is that it is a very rare event indeed that more than around 3-5 people on the BEHAVE list ever to participate actively in *any* given thread during a short period of time, or even take the time to post an "aye" or a "nay" to some proposal, however crucial or non-crucial it may be to the WG. By these standards I think the 1-2% of BEHAVE that has spoken in favor of adopting the ICMP draft represents a veritable "groundswell of support", so to speak. :) And as Suresh pointed out, there have been no technical objections and only one procedural objection to adoption - the latter running directly counter to the group's long-established policy of deciding matters on-list whenever possible and only falling back to the WG meeting to decide long-running technical arguments that fail to reach consensus on the list. That said, I have no objection to bringing up the issue at the WG meeting, as a matter of confirming the decision made on the list (or discovering any serious objections by people not actively participating on the list). Bryan On Friday 26 May 2006 04:05, Dan Wing wrote: > > [suresh] Dan - You did a detailed review of the draft before > > OKing it as WG draft. Does that not count as one more for > > Yes? If so, that would be 3 for Yes, apart from the authors. > > (or) would you rather not inlcude a WG chair's opinion? > > We're still talking 1-2% of BEHAVE (~200 subscribers, ~100 > attendees at IETF), with or without me. > > -d > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From touch@ISI.EDU Fri, 26 May 2006 09:04:28 -0700 (PDT) From: Joe Touch Date: Fri, 26 May 2006 09:04:28 -0700 (PDT) Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <1148469744.18773.81.camel@localhost.localdomain> Message-ID: <447726AF.4080108@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Philip Matthews wrote: > I feel it is important to make TCP Simultaneous-Open work. > > Regarding option 4: > I feel that coordinating peers so they do things at the same time can be > difficult. > If peers A and B are trying to set up a connection between them, but peer B > gets busy doing something else for a few seconds and misses the 3 second > window, > then the whole connection attempt fails. In our product (a peer-to-peer > telephony > system), we see situations where the CPU on one hard-phone can get very > overloaded > for a few seconds. I could easily see that this option would lead to > situations where > the connection would be established most of the time, but would randomly > fail > from time-to-time because the 3 second window was missed. It'd be useful if option 1 is chosen to note that this is "intended to relax TCP requirements to accommodate NATs". For a similar relaxation, see the discussion of ICMP processing in RFC4301. Like for IPsec, this MUST be configurable if chosen. Note, though, that 4301 falls short of defaulting the configuration to 'drop all'. Joe Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00115.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00115.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVkeWF2RTVmNWNJbW5acnNSQW5BdEFLRHdvVWE5bi9TRXNUWHFF UXFlWTdjQnNwWks2d0NmU2k4eApQQjliOHhBUVVNSUlpbGJlZzhJcXltTT0KPWZYUzEKLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From srisuresh@yahoo.com Fri, 26 May 2006 13:37:48 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 26 May 2006 13:37:48 -0700 (PDT) Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: Message-ID: <20060526203747.30831.qmail@web33304.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain I agree. I am in favor of option 1. cheers, suresh --- Philip Matthews wrote: > I feel it is important to make TCP Simultaneous-Open work. > > Regarding option 4: > I feel that coordinating peers so they do things at the same time can > be difficult. > If peers A and B are trying to set up a connection between them, but > peer B > gets busy doing something else for a few seconds and misses the 3 > second window, > then the whole connection attempt fails. In our product (a peer-to- > peer telephony > system), we see situations where the CPU on one hard-phone can get > very overloaded > for a few seconds. I could easily see that this option would lead to > situations where > the connection would be established most of the time, but would > randomly fail > from time-to-time because the 3 second window was missed. > > Given this concern, my current preference is for option 1. > > Saikat: > Might I suggest producing a brief presentation describing these > options and asking > for presentation time at both the BEHAVE and TCPM meetings in Montreal? > > - Philip > > > On 24-May-06, at 19:52 , Cullen Jennings wrote: > > > > > I prefer option 1 and when some appropriate ICMP stuff is defined, > > change the recommendation to something like 2. > > > > 4 is very tricky to know what times would be appropriate. > > > > On May 24, 2006, at 4:22 AM, Saikat Guha wrote: > > > >> The discussion on- and off- list had identified a bunch of issues > >> that I > >> quickly summarize below. I would like to get some feedback > >> (particularly > >> on Option 4 from the vendors) on the four potential requirements > >> below. > >> > >> Issues (simplified, see original thread for details): > >> 1. TCP Simultaneous-Open is necessary for P2P apps. NATs shouldn't > >> force > >> such attempts to be aborted. But there is currently no way to > >> do so > >> with ICMP/TCP messages. Barring future work (improbable), > >> facilitating S-O would require NATs ignore the error (perhaps > >> momentarily) > >> 2. The intent of prior RFCs is to signal errors (MUST or SHOULD > >> depending) which would hinder P2P TCP, but would follow the > >> spirit of > >> RFCs. > >> > >> > >> > >> So here are the options: > >> > >> Option 1: Current proposal in the draft > >> ======== > >> "A NAT MUST silently drop inbound SYNs" > >> > >> Issues: Totally against the spirit of old RFCs, making network > >> troubleshooting harder, but allows TCP S-O > >> > >> > >> Option 2: Proposed earlier on the list by myself > >> ========= > >> "A NAT MUST NOT force an end-host to abort a TCP connection that > >> could > >> be a S-O. It SHOULD return an error if the error doesn't force the > >> end abort the attempt. Otherwise, it MUST silently drop the SYN" > >> > >> Issues: Hard to implement and understand. Currently no possible to > >> implement the first two clauses. Still facilitates S-O, but is > >> forwards > >> compatible in the unlikely event that the first two clauses become > >> satisfiable. > >> > >> > >> Option 3: Following the REQ-8 language in the UDP spec > >> ========= > >> "If enabling P2P TCP apps is most important, a NAT MUST silently > >> drop the SYN. If enabling quick diagnosis of network errors is most > >> important, a NAT SHOULD signal an ICMP port unreachable. The > >> behavior > >> MAY be configurable by the administrator." > >> > >> Issues: Let the NAT admin pick whether to allow TCP S-O or signal > >> errors. > >> > >> > >> Option 4: Proposed earlier on list by Joe > >> ========= > >> > >> "A NAT SHOULD signal an ICMP port unreachable. If it does, it MUST > >> delay the ICMP error by at least 3 seconds and MUST cancel the > >> ICMP if > >> in that time an outbound SYN for the connection is seen. If the NAT > >> does not have resources to delay the ICMP, it MUST silently drop > >> the > >> inbound SYN" > >> > >> Issues: Delaying the ICMP gives the internal side's SYN or > >> retransmission a chance to trigger a S-O. This requires bounded > >> state at > >> the NAT. In an attack (when the buffer is full), it allows the NAT to > >> silently discard SYNs. Together, it facilitates S-O regardless of > >> whether the NAT is low on resources or not. When the NAT has > >> resources > >> to spare, it facilitates error detection (delayed by 3s). When out of > >> resources it degrades gracefully to support S-O but not fast error > >> detection. > >> > >> > >> > >> I'd particularly like to know how vendors and others feel about > >> Option > >> 4. > >> > >> cheers, > >> -- > >> Saikat > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From kbiswas@cisco.com Fri, 26 May 2006 13:44:26 -0700 (PDT) From: "Kaushik Biswas (kbiswas)" Date: Fri, 26 May 2006 13:44:26 -0700 (PDT) Subject: RE: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for commentson proposals. Message-ID: <378E78E5F361564BB066432F6415764B01D6AA87@xmb-sjc-228.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I too am in favor of option # 1. Agree with Philip, Option # 4 can lead to undeterministic behavior. Thanks, Kaushik > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pyda Srisuresh > Sent: Friday, May 26, 2006 1:38 PM > To: Philip Matthews; Saikat Guha > Cc: tcpm-chairs@xxxxxxxxxxxxxx; Lars Eggert; > behave-chairs@xxxxxxxxxxxxxx; Behave; Joe Touch > Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: > Request for commentson proposals. > > I agree. I am in favor of option 1. > > cheers, > suresh > > --- Philip Matthews wrote: > > > I feel it is important to make TCP Simultaneous-Open work. > > > > Regarding option 4: > > I feel that coordinating peers so they do things at the > same time can > > be difficult. > > If peers A and B are trying to set up a connection between > them, but > > peer B gets busy doing something else for a few seconds and > misses the > > 3 second window, then the whole connection attempt fails. In our > > product (a peer-to- peer telephony system), we see situations where > > the CPU on one hard-phone can get very overloaded for a few > seconds. I > > could easily see that this option would lead to situations > where the > > connection would be established most of the time, but would > randomly > > fail from time-to-time because the 3 second window was missed. > > > > Given this concern, my current preference is for option 1. > > > > Saikat: > > Might I suggest producing a brief presentation describing these > > options and asking for presentation time at both the BEHAVE > and TCPM > > meetings in Montreal? > > > > - Philip > > > > > > On 24-May-06, at 19:52 , Cullen Jennings wrote: > > > > > > > > I prefer option 1 and when some appropriate ICMP stuff is > defined, > > > change the recommendation to something like 2. > > > > > > 4 is very tricky to know what times would be appropriate. > > > > > > On May 24, 2006, at 4:22 AM, Saikat Guha wrote: > > > > > >> The discussion on- and off- list had identified a bunch > of issues > > >> that I quickly summarize below. I would like to get some > feedback > > >> (particularly on Option 4 from the vendors) on the four > potential > > >> requirements below. > > >> > > >> Issues (simplified, see original thread for details): > > >> 1. TCP Simultaneous-Open is necessary for P2P apps. NATs > shouldn't > > >> force > > >> such attempts to be aborted. But there is currently > no way to do > > >> so > > >> with ICMP/TCP messages. Barring future work (improbable), > > >> facilitating S-O would require NATs ignore the error (perhaps > > >> momentarily) > > >> 2. The intent of prior RFCs is to signal errors (MUST or SHOULD > > >> depending) which would hinder P2P TCP, but would follow the > > >> spirit of > > >> RFCs. > > >> > > >> > > >> > > >> So here are the options: > > >> > > >> Option 1: Current proposal in the draft ======== > > >> "A NAT MUST silently drop inbound SYNs" > > >> > > >> Issues: Totally against the spirit of old RFCs, making network > > >> troubleshooting harder, but allows TCP S-O > > >> > > >> > > >> Option 2: Proposed earlier on the list by myself > ========= "A NAT > > >> MUST NOT force an end-host to abort a TCP connection that could > > >> be a S-O. It SHOULD return an error if the error > doesn't force the > > >> end abort the attempt. Otherwise, it MUST silently > drop the SYN" > > >> > > >> Issues: Hard to implement and understand. Currently no > possible to > > >> implement the first two clauses. Still facilitates S-O, but is > > >> forwards compatible in the unlikely event that the first two > > >> clauses become satisfiable. > > >> > > >> > > >> Option 3: Following the REQ-8 language in the UDP spec > ========= > > >> "If enabling P2P TCP apps is most important, a NAT MUST silently > > >> drop the SYN. If enabling quick diagnosis of network > errors is most > > >> important, a NAT SHOULD signal an ICMP port unreachable. The > > >> behavior > > >> MAY be configurable by the administrator." > > >> > > >> Issues: Let the NAT admin pick whether to allow TCP S-O > or signal > > >> errors. > > >> > > >> > > >> Option 4: Proposed earlier on list by Joe ========= > > >> > > >> "A NAT SHOULD signal an ICMP port unreachable. If it > does, it MUST > > >> delay the ICMP error by at least 3 seconds and MUST cancel the > > >> ICMP if > > >> in that time an outbound SYN for the connection is > seen. If the NAT > > >> does not have resources to delay the ICMP, it MUST > silently drop > > >> the > > >> inbound SYN" > > >> > > >> Issues: Delaying the ICMP gives the internal side's SYN or > > >> retransmission a chance to trigger a S-O. This requires bounded > > >> state at the NAT. In an attack (when the buffer is > full), it allows > > >> the NAT to silently discard SYNs. Together, it facilitates S-O > > >> regardless of whether the NAT is low on resources or > not. When the > > >> NAT has resources to spare, it facilitates error > detection (delayed > > >> by 3s). When out of resources it degrades gracefully to > support S-O > > >> but not fast error detection. > > >> > > >> > > >> > > >> I'd particularly like to know how vendors and others feel about > > >> Option 4. > > >> > > >> cheers, > > >> -- > > >> Saikat > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From zhouhong@huawei.com Fri, 26 May 2006 20:58:28 -0700 (PDT) From: Harrison Zhou Date: Fri, 26 May 2006 20:58:28 -0700 (PDT) Subject: Re: [Ietf-behave] draft-ietf-behave-turn-00 In-Reply-To: <059401c66d97$eb6c7240$d960150a@amer.cisco.com> Message-ID: <01e501c68141$cb2429c0$0f05a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain hi, Manjur Did you mean why the XOR-MAPPED-ADDRESS attribute is 0x0020 and the REQUESTED-IP attribute also is 0x0020 ? But I think it doesn't matter. Because the XOR-MAPPED-ADDRESS attribute is only present in Binding Responses and the REQUESTED-IP attribute is used by the client to request that a specific IP address be allocated to it. they are used in different direction. Harrison ----- Original Message ----- From: "Manjur" To: "'Behave'" ; "Dan Wing" ; "'Pyda Srisuresh'" ; "'Magnus Westerlund'" Sent: Friday, May 26, 2006 8:08 AM Subject: [Ietf-behave] draft-ietf-behave-turn-00 Hi, I have taken a part for the draft-ietf-behave-turn-00. It seems that 0x0020 should be 0x001a and so on. Is it right? 9. New Attributes The STUN relay usage defines the following new attributes: 0x000d: LIFETIME 0x0010: BANDWIDTH 0x0011: DESTINATION-ADDRESS 0x0012: REMOTE-ADDRESS 0x0013: DATA 0x0016: RELAY-ADDRESS 0x0018: REQUESTED-PORT 0x0019: REQUESTED-TRANSPORT 0x0020: REQUESTED-IP 0x0021: TIMER-VAL Thank you --Manjur _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From philip_matthews@magma.ca Sun, 28 May 2006 18:00:44 -0700 (PDT) From: Philip Matthews Date: Sun, 28 May 2006 18:00:44 -0700 (PDT) Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <1148469744.18773.81.camel@localhost.localdomain> Message-ID: <35B2D485-CBF5-4166-AF8B-355A32B06CD8@magma.ca> MIME-Version: 1.0 Content-Type: text/plain Just one more point about option 4: My concern (expressed below) about option 4 revolves around the short time window (3 seconds) that was suggested. If this window was instead, say, 60 seconds, or perhaps even 30 seconds, I would not have this concern. I don't know if there is any way to make the window larger without losing all the debug advantage of sending the ICMP message in the first place, but if there was, this might be a way forward. - Philip On 26-May-06, at 12:02 , Joe Touch wrote: Philip Matthews wrote: I feel it is important to make TCP Simultaneous-Open work. Regarding option 4: I feel that coordinating peers so they do things at the same time can be difficult. If peers A and B are trying to set up a connection between them, but peer B gets busy doing something else for a few seconds and misses the 3 second window, then the whole connection attempt fails. In our product (a peer-to- peer telephony system), we see situations where the CPU on one hard-phone can get very overloaded for a few seconds. I could easily see that this option would lead to situations where the connection would be established most of the time, but would randomly fail from time-to-time because the 3 second window was missed. It'd be useful if option 1 is chosen to note that this is "intended to relax TCP requirements to accommodate NATs". For a similar relaxation, see the discussion of ICMP processing in RFC4301. Like for IPsec, this MUST be configurable if chosen. Note, though, that 4301 falls short of defaulting the configuration to 'drop all'. Joe From kbiswas@cisco.com Sun, 28 May 2006 20:28:16 -0700 (PDT) From: "Kaushik Biswas (kbiswas)" Date: Sun, 28 May 2006 20:28:16 -0700 (PDT) Subject: RE: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for commentson proposals. Message-ID: <378E78E5F361564BB066432F6415764B01D6AC3E@xmb-sjc-228.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Increasing the delay in sending icmp error may give a chance to the endhost whose CPU is overloaded a chance to process this and lead to more predictable behavior compared one with a shorter window, but then we also say the following in option 4: "If the NAT does not have resources to delay the ICMP, it MUST silently drop the inbound SYN" Doing such, will not be a very deterministic behavior for NATs. Sometimes NATs will generate the ICMP errors and other times it will silently drop the inbound SYNs. I know we haven't yet concluded on which option to take, but if the list agrees on Option 4, my suggestion would be to not put the above line. Thanks, Kaushik > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Philip Matthews > Sent: Sunday, May 28, 2006 6:02 PM > To: Joe Touch; Saikat Guha > Cc: tcpm-chairs@xxxxxxxxxxxxxx; behave-chairs@xxxxxxxxxxxxxx; > Behave WG; Lars Eggert > Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: > Request for commentson proposals. > > Just one more point about option 4: > > My concern (expressed below) about option 4 revolves around > the short time window (3 seconds) that was suggested. If this > window was instead, say, 60 seconds, or perhaps even 30 > seconds, I would not have this concern. > > I don't know if there is any way to make the window larger > without losing all the debug advantage of sending the ICMP > message in the first place, but if there was, this might be a > way forward. > > - Philip > > > > On 26-May-06, at 12:02 , Joe Touch wrote: > > > > > > > Philip Matthews wrote: > >> I feel it is important to make TCP Simultaneous-Open work. > >> > >> Regarding option 4: > >> I feel that coordinating peers so they do things at the > same time can > >> be difficult. > >> If peers A and B are trying to set up a connection between > them, but > >> peer B gets busy doing something else for a few seconds and misses > >> the 3 second window, then the whole connection attempt > fails. In our > >> product (a peer-to- peer telephony system), we see > situations where > >> the CPU on one hard-phone can get very overloaded for a > few seconds. > >> I could easily see that this option would lead to situations where > >> the connection would be established most of the time, but would > >> randomly fail from time-to-time because the 3 second window was > >> missed. > > > > It'd be useful if option 1 is chosen to note that this is > "intended to > > relax TCP requirements to accommodate NATs". For a similar > relaxation, > > see the discussion of ICMP processing in RFC4301. Like for > IPsec, this > > MUST be configurable if chosen. > > > > Note, though, that 4301 falls short of defaulting the > configuration to > > 'drop all'. > > > > Joe > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Mon, 29 May 2006 05:14:07 -0700 (PDT) From: Cullen Jennings Date: Mon, 29 May 2006 05:14:07 -0700 (PDT) Subject: Re: [Ietf-behave] Milestones, ICMP In-Reply-To: <20060525233640.50282.qmail@web33302.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On May 25, 2006, at 4:36 PM, Pyda Srisuresh wrote: Decisions should be made on the list. Decisions should represent consensus of the members of the WG and that includes the people that show up for the WG meetings. From saikat@cs.cornell.edu Mon, 29 May 2006 10:07:32 -0700 (PDT) From: Saikat Guha Date: Mon, 29 May 2006 10:07:32 -0700 (PDT) Subject: RE: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for commentson proposals. In-Reply-To: <378E78E5F361564BB066432F6415764B01D6AC3E@xmb-sjc-228.amer.cisco.com> Message-ID: <1148922450.18773.194.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit (CC list trimmed) On Sun, 2006-05-28 at 20:28 -0700, Kaushik Biswas (kbiswas) wrote: > "If the NAT does not have resources to delay the ICMP, it MUST silently > drop the > inbound SYN" > > Doing such, will not be a very deterministic behavior for NATs. > Sometimes NATs will generate the ICMP errors and other times it will > silently drop the inbound SYNs. While the choice of option is still open, I don't think this construes as non-deterministic behavior any more than that inherent in a router that needs to rate-limit ICMP packets. In any case, while the 'indication of the error' is non-deterministic under heavy load, the behavior of allowing S-O / P2P TCP connectivity is very deterministic from the app developers perspective. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00116.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00116.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZXlwU25GbHRxaTY5MS9vUkFoTS9BSjRnVkxoL3Rwa2RDOTJ2VGNa U0pJS2tibzR0RmdDZUpXY0sKbkJ1KzZMb1NYdkEvUHVNS2N0MjZnaGc9Cj1mSmVoCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From touch@ISI.EDU Mon, 29 May 2006 21:00:31 -0700 (PDT) From: Joe Touch Date: Mon, 29 May 2006 21:00:31 -0700 (PDT) Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <1148469744.18773.81.camel@localhost.localdomain> Message-ID: <447BC2F5.6060106@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Philip Matthews wrote: > Just one more point about option 4: > > My concern (expressed below) about option 4 revolves around the short time > window (3 seconds) that was suggested. If this window was instead, say, > 60 seconds, > or perhaps even 30 seconds, I would not have this concern. The window can be based on things like the TCP retransmission timer, but needs to also take into account the MSL (120 seconds). It is reasonable to respond to an error in a timely fashion; delays of 30 seconds end up rendering the ICMP response essentially useless for a timely use when a S-O isn't what's going on. I.e., I would expect a delay of around 6 seconds to be OK, but longer to be inappropriate. Unless the endpoints are dawdling, that ought to be sufficient, though. That assumes the endpoints have some reason to believe they want to contact each other; if they don't, 6 seconds isn't enough. If that's the case, I can't think of a timeout that would work, though. > I don't know if there is any way to make the window larger without > losing all the > debug advantage of sending the ICMP message in the first place, but if > there was, > this might be a way forward. I don't see one; the issue here is the baby and the bathwater. By silently dropping the SYN, you're saying that NATs value supporting S-O over being responsive to non-SO unsolicited SYNs. Allowing S-O appears to require a NAT to go directly against a SHOULD in RFC1122. It might provide enough condition (only in a NAT, only since it is necessary to support S-O), but that'd be for the IESG to decide. Joe Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00117.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00117.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVlOEw4RTVmNWNJbW5acnNSQXRUWUFKd0tkWloveUlhWElCek5D dDRxK25GckV5WVh5d0NnakFEagpXSGFKbklnTXhhMWovK1NCSGtLaEdzZz0KPVRNNXkKLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From philip_matthews@magma.ca Tue, 30 May 2006 07:09:39 -0700 (PDT) From: Philip Matthews Date: Tue, 30 May 2006 07:09:39 -0700 (PDT) Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <1148469744.18773.81.camel@localhost.localdomain> Message-ID: <290A4F02-2498-48CE-81FB-A649F3973E21@magma.ca> MIME-Version: 1.0 Content-Type: text/plain To be honest, I don't have any solid data that would allow me to make a definite conclusion one way or another whether 6 seconds would be sufficient. It seems short to me, but that is just a gut feeling and not based on hard evidence. - Philip On 29-May-06, at 23:58 , Joe Touch wrote: Philip Matthews wrote: Just one more point about option 4: My concern (expressed below) about option 4 revolves around the short time window (3 seconds) that was suggested. If this window was instead, say, 60 seconds, or perhaps even 30 seconds, I would not have this concern. The window can be based on things like the TCP retransmission timer, but needs to also take into account the MSL (120 seconds). It is reasonable to respond to an error in a timely fashion; delays of 30 seconds end up rendering the ICMP response essentially useless for a timely use when a S-O isn't what's going on. I.e., I would expect a delay of around 6 seconds to be OK, but longer to be inappropriate. Unless the endpoints are dawdling, that ought to be sufficient, though. That assumes the endpoints have some reason to believe they want to contact each other; if they don't, 6 seconds isn't enough. If that's the case, I can't think of a timeout that would work, though. I don't know if there is any way to make the window larger without losing all the debug advantage of sending the ICMP message in the first place, but if there was, this might be a way forward. I don't see one; the issue here is the baby and the bathwater. By silently dropping the SYN, you're saying that NATs value supporting S-O over being responsive to non-SO unsolicited SYNs. Allowing S-O appears to require a NAT to go directly against a SHOULD in RFC1122. It might provide enough condition (only in a NAT, only since it is necessary to support S-O), but that'd be for the IESG to decide. Joe From saikat@cs.cornell.edu Tue, 30 May 2006 07:27:53 -0700 (PDT) From: Saikat Guha Date: Tue, 30 May 2006 07:27:53 -0700 (PDT) Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <1148469744.18773.81.camel@localhost.localdomain> Message-ID: <1148999271.25934.22.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2006-05-30 at 10:10 -0400, Philip Matthews wrote: > To be honest, I don't have any solid data that would allow me to make > a definite conclusion > one way or another whether 6 seconds would be sufficient. It seems > short to me, > but that is just a gut feeling and not based on hard evidence. While 6s is device/app/load-specific to an extent, before S-O can take place the endpoints already need to coordinate (things like port and address information), so they are more-or-less in sync (say to the order of 100ms or so). Devices that go on coffee breaks aside, the 6s provide a buffer to get a single TCP packet out, and perhaps one re-transmission in the unlikely case that the network up to the NAT is congested. That is about a 6000% tolerance from the anticipated case, but indeed it is device specific. My 2c. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00118.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00118.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZkZabm5GbHRxaTY5MS9vUkF2VWNBSjQ5bTNPWGpXdDZpdU0vdGJs SDJGempuc3FVUVFDZlUrbXcKS3NtZWdGMG50SWVyVEhRUGs1SWYrMkU9Cj0xWHVxCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From dwing@cisco.com Tue, 30 May 2006 13:05:54 -0700 (PDT) From: "Dan Wing" Date: Tue, 30 May 2006 13:05:54 -0700 (PDT) Subject: RE: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request forcomments on proposals. In-Reply-To: <1148999271.25934.22.camel@localhost.localdomain> Message-ID: <066701c68424$6742adb0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I'm thinking of a SIP call flow, and I don't see how you'd get within 100ms of synchronization. For SIP, I believe you'd do something like this; in reality there would probably be separate STUNT servers for both Alice and Bob, or they might use UPnP, Bonjour, MIDCOM, or some other mechanism (which isn't relevant) to learn their public IP address and TCP port. And of course there will be multiple SIP proxies, each adding their own processing latency and each causing a likelyhood of a SIP packet drop and requiring a retransmission. Alice STUNT server SIP proxy Bob | | | | 1 |--------->| | | 2 |<---------| | | 3 |----------------------->| | 4 | | |-------->| 5 |X <-------------------------------| 6 | |<----------------------| 7 | |---------------------->| 8 | | |<--------| 9 |<-----------------------| | 10 |--------------------------------->| At message 4, Bob knows everything about Alice and can begin trying to set up a TCP connection with Alice. However, it could be "Quite Awhile" before Alice receives message 9, which contains Bob's IP address and TCP port. -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Tuesday, May 30, 2006 7:28 AM > To: Philip Matthews > Cc: Behave WG > Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: > Request forcomments on proposals. > > On Tue, 2006-05-30 at 10:10 -0400, Philip Matthews wrote: > > To be honest, I don't have any solid data that would allow > me to make > > a definite conclusion > > one way or another whether 6 seconds would be sufficient. It seems > > short to me, > > but that is just a gut feeling and not based on hard evidence. > > While 6s is device/app/load-specific to an extent, before S-O can take > place the endpoints already need to coordinate (things like port and > address information), so they are more-or-less in sync (say > to the order > of 100ms or so). > > Devices that go on coffee breaks aside, the 6s provide a > buffer to get a > single TCP packet out, and perhaps one re-transmission in the unlikely > case that the network up to the NAT is congested. > > That is about a 6000% tolerance from the anticipated case, > but indeed it > is device specific. > > My 2c. > -- > Saikat > From spencer@mcsr-labs.org Tue, 30 May 2006 13:18:16 -0700 (PDT) From: "Spencer Dawkins" Date: Tue, 30 May 2006 13:18:16 -0700 (PDT) Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request forcommentson proposals. In-Reply-To: <066701c68424$6742adb0$c2f0200a@amer.cisco.com> Message-ID: <124e01c68426$27327640$0700a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Dan, When you say, "quite awhile", could you tell us what timeframes you're thinking about? I'm thinking of a SIP call flow, and I don't see how you'd get within 100ms of synchronization. At message 4, Bob knows everything about Alice and can begin trying to set up a TCP connection with Alice. However, it could be "Quite Awhile" before Alice receives message 9, which contains Bob's IP address and TCP port. -d Thanks, Spencer From dwing@cisco.com Tue, 30 May 2006 14:07:02 -0700 (PDT) From: "Dan Wing" Date: Tue, 30 May 2006 14:07:02 -0700 (PDT) Subject: RE: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Requestforcommentson proposals. In-Reply-To: <124e01c68426$27327640$0700a8c0@china.huawei.com> Message-ID: <077001c6842c$fefeb290$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > When you say, "quite awhile", could you tell us what > timeframes you're thinking about? If you don't have PRACK (RFC3262) and you have loss of a single packet, Alice (the caller) won't know Bob's IP address and TCP port number until Bob "answers". If we assume Bob is watching TV when Alice "calls", that means that Bob has to drop the TV's remote control on the floor, spill his beer, and run into the computer room and click "Accept Call". I could see Bob taking several seconds to run into the computer room. -d > > I'm thinking of a SIP call flow, and I don't see how you'd > > get within 100ms of synchronization. > > > > > > At message 4, Bob knows everything about Alice and can > > begin trying to set > > up a TCP connection with Alice. However, it could be > > "Quite Awhile" before > > Alice receives message 9, which contains Bob's IP address > > and TCP port. > > > > -d > > Thanks, > > Spencer > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From philip_matthews@magma.ca Tue, 30 May 2006 14:18:03 -0700 (PDT) From: Philip Matthews Date: Tue, 30 May 2006 14:18:03 -0700 (PDT) Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request forcomments on proposals. In-Reply-To: <066701c68424$6742adb0$c2f0200a@amer.cisco.com> Message-ID: <23C45038-E2CC-44B8-BD8A-BEFC939F4A0D@magma.ca> MIME-Version: 1.0 Content-Type: text/plain On 30-May-06, at 16:05 , Dan Wing wrote: I'm thinking of a SIP call flow, and I don't see how you'd get within 100ms of synchronization. For SIP, I believe you'd do something like this; in reality there would probably be separate STUNT servers for both Alice and Bob, or they might use UPnP, Bonjour, MIDCOM, or some other mechanism (which isn't relevant) to learn their public IP address and TCP port. And of course there will be multiple SIP proxies, each adding their own processing latency and each causing a likelyhood of a SIP packet drop and requiring a retransmission. Alice STUNT server SIP proxy Bob | | | | 1 |--------->| | | 2 |<---------| | | 3 |----------------------->| | 4 | | |-------->| 5 |X <-------------------------------| 6 | |<----------------------| 7 | |---------------------->| 8 | | |<--------| 9 |<-----------------------| | 10 |--------------------------------->| At message 4, Bob knows everything about Alice and can begin trying to set up a TCP connection with Alice. However, it could be "Quite Awhile" before Alice receives message 9, which contains Bob's IP address and TCP port. I agree with Dan's comment that it could be "Quite Awhile" before Alice receives message 9. Specifically, I am thinking of the P2PSIP case where most or nearly all peers are behind NATs, and so peers act both as SIP UAs and also as SIP proxies for other phones. In this case, the signaling messages between A and B may have to hop through quite a few intermediate peers (with all the consequent chances of lost packets). If we are doing ICE-TCP, does generating an error response mean that the particular candidate pair is deemed invalid and never retried?? [I haven't read the ICE-TCP spec yet...] - Philip From dwing@cisco.com Tue, 30 May 2006 15:02:16 -0700 (PDT) From: "Dan Wing" Date: Tue, 30 May 2006 15:02:16 -0700 (PDT) Subject: [Ietf-behave] RE: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <1148469744.18773.81.camel@localhost.localdomain> Message-ID: <07db01c68434$a7bcec60$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Saikat, Joe, (I adjusted the CC list.) Considering my flow again, I had a thought: Alice STUNT server SIP proxy Bob | | | | 1 |--------->| | | 2 |<---------| | | 3 |----------------------->| | 4 | | |-------->| 5 |X <-------------------------------| 6 | |<----------------------| 7 | |---------------------->| 8 | | |<--------| 9 |<-----------------------| | 10 |--------------------------------->| I notice that S-O only occurs after Alice talks to her STUNT server, and after Bob talks to his STUNT server, and after they both use their same (local) socket to attempt to communite with each other. Can we maybe take advantage of this? Detailed thought: Alice's NAT sees Alice generate a TCP connection to the STUNT server (message 1 and 2), and then close it down normally with TCP FINs (which isn't shown, but it happens immediately after message 2). Alice will then start listening on that same port, but of course Alice's NAT doesn't know Alice has started listening on that port. Once message 9 is received by Alice, Alice's NAT will finally see Alice trying to establish a TCP connection with Bob (message 10). In order to prevent Alice's NAT from sending an error at message 5, how about a requirement like this, which combines your (1) with Joe's (4), and makes the delay only occur if Simultaneous-Open could occur -- assuming that, from a NAT's perspective, that TCP S-O can only occur after you talk to a STUNT server! Here is the suggested requirement: * To enable S-O, if a NAT has closed a TCP binding normally (FIN or RST), and the NAT receives a SYN on its public interface to that TCP binding before MSL seconds have elapsed since the binding was closed, the NAT MUST wait at least 3 seconds before generating TCP RST or ICMP error in response to that SYN. -d > -----Original Message----- > From: Saikat Guha [mailto:saikat@xxxxxxxxxxxxxx] > Sent: Wednesday, May 24, 2006 4:22 AM > To: Behave > Cc: Joe Touch; Dan Wing; 'Spencer Dawkins'; 'Cullen > Jennings'; tcpm-chairs@xxxxxxxxxxxxxx; > behave-chairs@xxxxxxxxxxxxxx; 'Lars Eggert' > Subject: NAT TCP Simultaneous-Open: Request for comments on proposals. > > The discussion on- and off- list had identified a bunch of > issues that I > quickly summarize below. I would like to get some feedback > (particularly > on Option 4 from the vendors) on the four potential > requirements below. > > Issues (simplified, see original thread for details): > 1. TCP Simultaneous-Open is necessary for P2P apps. NATs > shouldn't force > such attempts to be aborted. But there is currently no way to do so > with ICMP/TCP messages. Barring future work (improbable), > facilitating S-O would require NATs ignore the error (perhaps > momentarily) > 2. The intent of prior RFCs is to signal errors (MUST or SHOULD > depending) which would hinder P2P TCP, but would follow > the spirit of > RFCs. > > > > So here are the options: > > Option 1: Current proposal in the draft > ======== > "A NAT MUST silently drop inbound SYNs" > > Issues: Totally against the spirit of old RFCs, making network > troubleshooting harder, but allows TCP S-O > > > Option 2: Proposed earlier on the list by myself > ========= > "A NAT MUST NOT force an end-host to abort a TCP connection > that could > be a S-O. It SHOULD return an error if the error doesn't force the > end abort the attempt. Otherwise, it MUST silently drop the SYN" > > Issues: Hard to implement and understand. Currently no possible to > implement the first two clauses. Still facilitates S-O, but > is forwards > compatible in the unlikely event that the first two clauses become > satisfiable. > > > Option 3: Following the REQ-8 language in the UDP spec > ========= > "If enabling P2P TCP apps is most important, a NAT MUST silently > drop the SYN. If enabling quick diagnosis of network errors is most > important, a NAT SHOULD signal an ICMP port unreachable. > The behavior > MAY be configurable by the administrator." > > Issues: Let the NAT admin pick whether to allow TCP S-O or signal > errors. > > > Option 4: Proposed earlier on list by Joe > ========= > > "A NAT SHOULD signal an ICMP port unreachable. If it does, it MUST > delay the ICMP error by at least 3 seconds and MUST cancel > the ICMP if > in that time an outbound SYN for the connection is seen. If the NAT > does not have resources to delay the ICMP, it MUST silently drop the > inbound SYN" > > Issues: Delaying the ICMP gives the internal side's SYN or > retransmission a chance to trigger a S-O. This requires > bounded state at > the NAT. In an attack (when the buffer is full), it allows the NAT to > silently discard SYNs. Together, it facilitates S-O regardless of > whether the NAT is low on resources or not. When the NAT has resources > to spare, it facilitates error detection (delayed by 3s). When out of > resources it degrades gracefully to support S-O but not fast error > detection. > > > > I'd particularly like to know how vendors and others feel about Option > 4. > > cheers, > -- > Saikat > From dwing@cisco.com Tue, 30 May 2006 16:29:56 -0700 (PDT) From: "Dan Wing" Date: Tue, 30 May 2006 16:29:56 -0700 (PDT) Subject: RE: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request forcomments on proposals. In-Reply-To: <23C45038-E2CC-44B8-BD8A-BEFC939F4A0D@magma.ca> Message-ID: <094e01c68440$f589cce0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@xxxxxxxx] > Sent: Tuesday, May 30, 2006 2:20 PM > To: Dan Wing > Cc: 'Saikat Guha'; 'Behave WG' > Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: > Request forcomments on proposals. > > > > On 30-May-06, at 16:05 , Dan Wing wrote: > > > I'm thinking of a SIP call flow, and I don't see how you'd get > > within 100ms of synchronization. > > > > For SIP, I believe you'd do something like this; in reality there > > would probably be separate STUNT servers for both Alice and Bob, > > or they might use UPnP, Bonjour, MIDCOM, or some other mechanism > > (which isn't relevant) to learn their public IP address and TCP > > port. And of course there will be multiple SIP proxies, each > > adding their own processing latency and each causing a likelyhood > > of a SIP packet drop and requiring a retransmission. > > > > Alice STUNT server SIP proxy Bob > > | | | | > > 1 |--------->| | | 2 |<---------| > >| | 3 |----------------------->| | 4 | | > > |-------->| 5 |X <-------------------------------| 6 | > >|<----------------------| 7 | |---------------------->| 8 > >| | |<--------| 9 |<-----------------------| > > | 10 |--------------------------------->| > > > > At message 4, Bob knows everything about Alice and can begin > > trying to set up a TCP connection with Alice. However, it could > > be "Quite Awhile" before Alice receives message 9, which contains > > Bob's IP address and TCP port. > > > > I agree with Dan's comment that it could be "Quite Awhile" before > Alice receives message 9. Specifically, I am thinking of the > P2PSIP case where most or nearly all peers are behind NATs, and so > peers act both as SIP UAs and also as SIP proxies for other > phones. In this case, the signaling messages between A and B may > have to hop through quite a few intermediate peers (with all the > consequent chances of lost packets). If we are doing ICE-TCP, > does generating an error response mean that the particular > candidate pair is deemed invalid and never retried?? [I haven't > read the ICE-TCP spec yet...] It's still an I-D, but draft-ietf-mmusic-ice-tcp-00 does contain these paragraphs on page 13. As you suspected, the receipt of an "error" (TCP RST or ICMP error) causes ICE to give up -- note the paragraph below that I highlighted with "*": ... If the remote transport address is not active, the agent moves this transport address pair into the Valid state. The TCP connection on which the Binding Request was received is then linked with the candidate pair. * If the STUN transaction produces an error, the state machine moves * into the Invalid state. If an agent receives a successful STUN Binding Response, and the native transport address is active, the agent moves this transport address pair into the Invalid state. Furthermore, the agent MUST compute a peer-derived candidate as described in Section 9. In addition, the TCP connection on which the Binding Request was received is then linked with the peer-derived candidate pair. ... If we want ICE-TCP to work with S-O, we'll have to either describe how to (a) get NATs to avoid sending the error, or (b) describe how an endpoint should be aggressive when doing S-O even if it's receiving errors (TCP RST or ICMP errors). I don't think it's a good idea to do (b). -d From touch@ISI.EDU Tue, 30 May 2006 17:22:31 -0700 (PDT) From: Joe Touch Date: Tue, 30 May 2006 17:22:31 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <07db01c68434$a7bcec60$c2f0200a@amer.cisco.com> Message-ID: <447CE177.5070906@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Dan Wing wrote: > Saikat, Joe, > > (I adjusted the CC list.) > > Considering my flow again, I had a thought: > > Alice STUNT server SIP proxy Bob > | | | | > 1 |--------->| | | > 2 |<---------| | | > 3 |----------------------->| | > 4 | | |-------->| > 5 |X <-------------------------------| > 6 | |<----------------------| > 7 | |---------------------->| > 8 | | |<--------| > 9 |<-----------------------| | > 10 |--------------------------------->| > > I notice that S-O only occurs after Alice talks to her STUNT server, and > after Bob talks to his STUNT server, and after they both use their same > (local) socket to attempt to communite with each other. > > Can we maybe take advantage of this? > > > Detailed thought: > > Alice's NAT sees Alice generate a TCP connection to the STUNT server > (message 1 and 2), and then close it down normally with TCP FINs (which > isn't shown, but it happens immediately after message 2). Alice will then > start listening on that same port, but of course Alice's NAT doesn't know > Alice has started listening on that port. Once message 9 is received by > Alice, Alice's NAT will finally see Alice trying to establish a TCP > connection with Bob (message 10). > > > In order to prevent Alice's NAT from sending an error at message 5, how > about a requirement like this, which combines your (1) with Joe's (4), and > makes the delay only occur if Simultaneous-Open could occur -- assuming > that, from a NAT's perspective, that TCP S-O can only occur after you talk > to a STUNT server! > > Here is the suggested requirement: > > * To enable S-O, if a NAT has closed a TCP binding normally (FIN or RST), > and > the NAT receives a SYN on its public interface to that TCP binding > before > MSL seconds have elapsed since the binding was closed, the NAT MUST wait > > at least 3 seconds before generating TCP RST or ICMP error in response > to that SYN. That works only if somebody reuses the TCP socket pair before TIME_WAIT (depending on how the connection closes); that violates RFC793. In specific, NATs ought (IMO) to hold the binding as unusable for a TIME_WAIT interval after the FIN, since they're acting as an endpoint to both ends of the TCP connection, effectively, and they're the only party that knows the port/addr pairs in use. This ought to have been noted somewhere, but I don't know if it ever was. Joe Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00119.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00119.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVmT0YzRTVmNWNJbW5acnNSQXFjOEFKOUVrQkFSZzBRMUprRzJp Rjc0TUttQk5PYWk2d0NnL2dpOQpOU2JhYWYzVEptRzQ5TG9JUHJCSXh2az0KPWFZbjIKLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From dwing@cisco.com Tue, 30 May 2006 17:29:43 -0700 (PDT) From: "Dan Wing" Date: Tue, 30 May 2006 17:29:43 -0700 (PDT) Subject: [Ietf-behave] RE: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <447CE177.5070906@isi.edu> Message-ID: <09a501c68449$4b7844d0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > That works only if somebody reuses the TCP socket pair before > TIME_WAIT (depending on how the connection closes); that violates > RFC793. The alternative is to allocate a fresh socket, learn the public TCP port across your NAT (using STUNT), signal that new TCP port number to your peer (in SIP, let's say), and try another TCP S-O all over again. Or, instead, use SO_REUSEADDR. > In specific, NATs ought (IMO) to hold the binding as unusable for a > TIME_WAIT interval after the FIN, since they're acting as an > endpoint to both ends of the TCP connection, effectively, and > they're the only party that knows the port/addr pairs in use. > This ought to have been noted somewhere, but I don't know if it > ever was. I doubt it was specified, either. The IETF has tried to speak no NAT, hear no NAT, and see no NAT. The BEHAVE-TCP document seems like a good place to document such a requirement. On a similar note, though -- if the host re-used that local socket on purpose (SO_REUSEADDR), the NAT should re-use that same local socket -- that is, take it out of TIME_WAIT. -d From touch@ISI.EDU Tue, 30 May 2006 18:30:21 -0700 (PDT) From: Joe Touch Date: Tue, 30 May 2006 18:30:21 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <09a501c68449$4b7844d0$c2f0200a@amer.cisco.com> Message-ID: <447CF176.2040205@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Dan Wing wrote: >> That works only if somebody reuses the TCP socket pair before >> TIME_WAIT (depending on how the connection closes); that violates >> RFC793. > > The alternative is to allocate a fresh socket, learn the public > TCP port across your NAT (using STUNT), signal that new TCP port > number to your peer (in SIP, let's say), and try another TCP S-O > all over again. Or, instead, use SO_REUSEADDR. SO_REUSEADDR allows you to reuse the local side of the socket at *bind* time. The 4-tuple must still be unique. I.e., this allows you to bind to a socket when it is in TIME_WAIT, but the new connection will still be blocked. SO_REUSEPORT overrides the 4-tuple, but it's for multicast apps (i.e., not TCP anyway). >> In specific, NATs ought (IMO) to hold the binding as unusable for a >> TIME_WAIT interval after the FIN, since they're acting as an >> endpoint to both ends of the TCP connection, effectively, and >> they're the only party that knows the port/addr pairs in use. >> This ought to have been noted somewhere, but I don't know if it >> ever was. > > I doubt it was specified, either. The IETF has tried to speak no > NAT, hear no NAT, and see no NAT. The BEHAVE-TCP document seems > like a good place to document such a requirement. > > On a similar note, though -- if the host re-used that local socket > on purpose (SO_REUSEADDR), the NAT should re-use that same local socket > -- that is, take it out of TIME_WAIT. Not as per above; only for UDP (which doesn't have TIME_WAIT anyway, tbhough). Joe Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00120.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00120.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVmUEYyRTVmNWNJbW5acnNSQXJFWEFLRGQ5UFZEN2dYejB5SFBF dnl1SGlVSTJQNk1ud0NndWFPdwpHRVFpb3ZLRGM2UGl0eXkxZmpwRSszZz0KPWRGazkKLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Wed, 31 May 2006 02:31:13 -0700 (PDT) From: Saikat Guha Date: Wed, 31 May 2006 02:31:13 -0700 (PDT) Subject: RE: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request forcomments on proposals. In-Reply-To: <066701c68424$6742adb0$c2f0200a@amer.cisco.com> Message-ID: <1149067869.30805.38.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2006-05-30 at 13:05 -0700, Dan Wing wrote: > Alice STUNT server SIP proxy Bob > | | | | > 1 |--------->| | | > 2 |<---------| | | > 3 |----------------------->| | > 4 | | |-------->| > 5 |X <-------------------------------| > 6 | |<----------------------| > 7 | |---------------------->| > 8 | | |<--------| > 9 |<-----------------------| | > 10 |--------------------------------->| What you mentioned is true for the particular SIP callflow you provided, but it doesn't necessarily have to be that callflow. Consider this modified callflow. Alice STUNT server SIP proxy Bob | | | | 1 |--------->| | | 2 |<---------| | | 3 |---------INVITE-------->| | 4 | | |-------->| 5 |X <-------------------------------| 6 | |<----------------------| 7 | |---------------------->| 8 | | |<--1xx---| 9 |<-----------------------| | 10 |---------UPDATE-------->| | 11 | |-------->| 12 | |<--200 U-| 13 |<-----------------------| | 14 |---------UPDATE-------->| | 15 ... |-------->| 16 |<================================>| In the above callflow, Bob realizes he must perform STUNT after packet 5 as before. He responds to Allice with a 1xx Ringing or some such message (Packet 8) that includes his public address. Alice sends a "SIP ping" that comprises packets 10--13. The "ping" is a SIP UPDATE packet that Bob responds to ASAP. Alice measures the SIP RTT for this ping. Alice then sends another UPDATE (packet 14) to Bob. Alice then waits RTT/2 before starting TCP S-O. Bob will receive the packet roughly at RTT/2 (note that while the SIP path is symmetric, there may be some IP asymmetry on each hop). As soon as bob receives the second UPDATE, Bob initiates his end of TCP S-O ASAP. Essentially, Alice and Bob invoke TCP S-O roughly at the same time. This is independent of the delay between packets 1 and 9 which you pointed out could be quite large. I am not saying this callflow has to be followed, but even with SIP and proxies, it is _possible_ to get synced to within a few tens of milliseconds. We were actually able to get it down to about .5--1 milliseconds on a LAN without any IP asymmetry. This was much lower than a single IP RTT between the two ends on the LAN, and obviously much much lower than the time it takes between SIP packets 1 and 9 (4 RTTs-ish). On the internet, this sync will depend some on the IP asymmetry, but 100ms is certainly possible. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00121.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00121.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZldKZG5GbHRxaTY5MS9vUkFncW9BSjlJSk9RbHJKTm1GOS9xdjlI UHRJVi9SbVVoVkFDZUlyUEoKMHdOS2RPQk9wajE5WWN3RzZNSE1HYTg9Cj03Z1djCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From philip_matthews@magma.ca Wed, 31 May 2006 05:40:30 -0700 (PDT) From: Philip Matthews Date: Wed, 31 May 2006 05:40:30 -0700 (PDT) Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request forcomments on proposals. In-Reply-To: <066701c68424$6742adb0$c2f0200a@amer.cisco.com> Message-ID: <2888ED3F-8B5F-40A5-81AA-CB8B648ED2B5@magma.ca> MIME-Version: 1.0 Content-Type: text/plain Saikat: Very interesting! Would I be correct in saying that your modified call flow increases the chances of a connection being established, at the cost of a longer overall delay in setting up the connection, especially if there are multiple SIP proxies involved? Any other comments on the pros and cons of the two call flows? - Philip On 31-May-06, at 05:31 , Saikat Guha wrote: On Tue, 2006-05-30 at 13:05 -0700, Dan Wing wrote: Alice STUNT server SIP proxy Bob | | | | 1 |--------->| | | 2 |<---------| | | 3 |----------------------->| | 4 | | |-------->| 5 |X <-------------------------------| 6 | |<----------------------| 7 | |---------------------->| 8 | | |<--------| 9 |<-----------------------| | 10 |--------------------------------->| What you mentioned is true for the particular SIP callflow you provided, but it doesn't necessarily have to be that callflow. Consider this modified callflow. Alice STUNT server SIP proxy Bob | | | | 1 |--------->| | | 2 |<---------| | | 3 |---------INVITE-------->| | 4 | | |-------->| 5 |X <-------------------------------| 6 | |<----------------------| 7 | |---------------------->| 8 | | |<--1xx---| 9 |<-----------------------| | 10 |---------UPDATE-------->| | 11 | |-------->| 12 | |<--200 U-| 13 |<-----------------------| | 14 |---------UPDATE-------->| | 15 ... |-------->| 16 |<================================>| In the above callflow, Bob realizes he must perform STUNT after packet 5 as before. He responds to Allice with a 1xx Ringing or some such message (Packet 8) that includes his public address. Alice sends a "SIP ping" that comprises packets 10--13. The "ping" is a SIP UPDATE packet that Bob responds to ASAP. Alice measures the SIP RTT for this ping. Alice then sends another UPDATE (packet 14) to Bob. Alice then waits RTT/2 before starting TCP S-O. Bob will receive the packet roughly at RTT/2 (note that while the SIP path is symmetric, there may be some IP asymmetry on each hop). As soon as bob receives the second UPDATE, Bob initiates his end of TCP S-O ASAP. Essentially, Alice and Bob invoke TCP S-O roughly at the same time. This is independent of the delay between packets 1 and 9 which you pointed out could be quite large. I am not saying this callflow has to be followed, but even with SIP and proxies, it is _possible_ to get synced to within a few tens of milliseconds. We were actually able to get it down to about .5--1 milliseconds on a LAN without any IP asymmetry. This was much lower than a single IP RTT between the two ends on the LAN, and obviously much much lower than the time it takes between SIP packets 1 and 9 (4 RTTs-ish). On the internet, this sync will depend some on the IP asymmetry, but 100ms is certainly possible. cheers, -- Saikat From saikat@cs.cornell.edu Wed, 31 May 2006 05:50:44 -0700 (PDT) From: Saikat Guha Date: Wed, 31 May 2006 05:50:44 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <07db01c68434$a7bcec60$c2f0200a@amer.cisco.com> Message-ID: <1149079842.30805.73.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2006-05-30 at 17:21 -0700, Joe Touch wrote: > Dan Wing wrote: > > Here is the suggested requirement: > > > > * To enable S-O, if a NAT has closed a TCP binding normally (FIN or RST), > > and > > the NAT receives a SYN on its public interface to that TCP binding > > before > > MSL seconds have elapsed since the binding was closed, the NAT MUST wait > > > > at least 3 seconds before generating TCP RST or ICMP error in response > > to that SYN. > > That works only if somebody reuses the TCP socket pair before TIME_WAIT > (depending on how the connection closes); that violates RFC793. TIME_WAIT is for a 4-tuple IIRC. I believe what Dan is suggesting is that once the internal endpoint X:x establishes a connection to an external Y1:y1 (STUNT server), and is allocated the mapping X1:x1, and then closes the connection, then when the remote peer Y2:y2 sends a SYN to X1:x1, the NAT should delay the RST/ICMP for 3 seconds. In that 3 seconds, the internal endpoint X:x may be able to send the SYN to Y2:y2. So the TIME_WAIT state for (X:x-Y1:y1) shouldn't affect the new TCP between (X:x-Y2:y2) unless I am mistaken. The internal endpoint still needs to use SO_REUSEADDR to get around with bind() limitations to re-acquire X:x, but that is not to circumvent T-W. If I understand Dan's proposal right, this is essentially the same as Option 4 mentioned earlier on the list with the optimization that allows the NAT to signal the error before the 3s is up in the case where the internal endpoint hasn't demonstrated any interest in S-O (identified by a prior connection to a STUNT server). This proposal IMHO would be a way forward if we were to consider a blanket 3s/6s delay of the ICMP error unacceptable. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00122.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00122.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZlpFaW5GbHRxaTY5MS9vUkFzenlBSjBkOVVtbHBudXRkNHVPK3kw T2VjZzBwU051R2dDZlFJNFcKZWxCZWJaaGhpcmZkS096OFN3OXZtUjg9Cj1HaHBkCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Wed, 31 May 2006 05:54:50 -0700 (PDT) From: Saikat Guha Date: Wed, 31 May 2006 05:54:50 -0700 (PDT) Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request forcomments on proposals. In-Reply-To: <066701c68424$6742adb0$c2f0200a@amer.cisco.com> Message-ID: <1149080083.30805.78.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-05-31 at 08:42 -0400, Philip Matthews wrote: > Would I be correct in saying that your modified call flow > increases the chances of a connection being established, > at the cost of a longer overall delay in setting up the > connection, especially if there are multiple > SIP proxies involved? I believe that is an accurate statement. Although, the exact magnitude of this extra delay can likely be tweaked with alternate callflows or some timestamping at the SIP proxies; but absent special proxy help, the callflow I mentioned is one end-host-only mechanism to boost connectivity chances. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00123.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00123.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZlpJVG5GbHRxaTY5MS9vUkFwMzFBSjlzQTN6SEhMbCtvMW5mNGNp SGVENW5TUjNpQUFDZEgzcjUKN255Y0M5NDUweWhZdmEzYkdoL3FLaFk9Cj0xemJWCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From touch@ISI.EDU Wed, 31 May 2006 08:18:47 -0700 (PDT) From: Joe Touch Date: Wed, 31 May 2006 08:18:47 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <07db01c68434$a7bcec60$c2f0200a@amer.cisco.com> Message-ID: <447DB369.4000707@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Saikat Guha wrote: > On Tue, 2006-05-30 at 17:21 -0700, Joe Touch wrote: >> Dan Wing wrote: >>> Here is the suggested requirement: >>> >>> * To enable S-O, if a NAT has closed a TCP binding normally (FIN or RST), >>> and >>> the NAT receives a SYN on its public interface to that TCP binding >>> before >>> MSL seconds have elapsed since the binding was closed, the NAT MUST wait >>> >>> at least 3 seconds before generating TCP RST or ICMP error in response >>> to that SYN. >> That works only if somebody reuses the TCP socket pair before TIME_WAIT >> (depending on how the connection closes); that violates RFC793. > > TIME_WAIT is for a 4-tuple IIRC. I believe what Dan is suggesting is > that once the internal endpoint X:x establishes a connection to an > external Y1:y1 (STUNT server), and is allocated the mapping X1:x1, and > then closes the connection, then when the remote peer Y2:y2 sends a SYN > to X1:x1, the NAT should delay the RST/ICMP for 3 seconds. In that 3 > seconds, the internal endpoint X:x may be able to send the SYN to Y2:y2. > So the TIME_WAIT state for (X:x-Y1:y1) shouldn't affect the new TCP > between (X:x-Y2:y2) unless I am mistaken. The internal endpoint still > needs to use SO_REUSEADDR to get around with bind() limitations to > re-acquire X:x, but that is not to circumvent T-W. The NAT ought to have two states for the two sides of the connection: X:x-Y1:y1 X1:x1-Y1:y1 The first is as seen by X; the other is as seen by Y1. Once that connection is closed with a FIN, both 4-tuples (known as a socket pair in RFC793) ought to be in TIME_WAIT, IMO. Then when Y2:y2 sends a SYN to X1:x1, wait 3 seconds for the ICMP. During those 3 seconds, X sends a SYN to Y2:y2 using X:x (which may require SO_REUSEADDR, but as you observe it's not a TCP issue). Now we have X:x talking to Y2:y2 - the translation entry X:x-Y1:y1/X1:x1 doesn't appear to help. How does the S-O connect? > If I understand Dan's proposal right, this is essentially the same as > Option 4 mentioned earlier on the list with the optimization that allows > the NAT to signal the error before the 3s is up in the case where the > internal endpoint hasn't demonstrated any interest in S-O (identified by > a prior connection to a STUNT server). This proposal IMHO would be a way > forward if we were to consider a blanket 3s/6s delay of the ICMP error > unacceptable. The reasons the delay were unacceptable were (AFAICT): 1) too hard to deploy this version is a superset of option 4 in complexity 2) 3/6 seconds is too short this version uses that number too I'm unclear how this addresses those concerns; as noted above, I'm also a bit unclear how it works ;-) Can you explain either? Joe Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00124.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00124.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVmYk5wRTVmNWNJbW5acnNSQWhqWUFKOUYwSjlFUDdzWnRMVU1O cUlIUEM2SVlTYXhBQUNnNlF4TgpKK3lpMGd6S3V0RTV4MDNqcGhoNERBND0KPTZVZXkKLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From dwing@cisco.com Wed, 31 May 2006 09:15:59 -0700 (PDT) From: "Dan Wing" Date: Wed, 31 May 2006 09:15:59 -0700 (PDT) Subject: [Ietf-behave] TCP S-O; Dan's two ideas In-Reply-To: <1149079842.30805.73.camel@localhost.localdomain> Message-ID: <017101c684cd$809ea300$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I have two ideas floating around in my head. I hope this email clarifies them. Let's call this first idea "TIME_WAIT SYN drop". The important part is highlighted with "*": In order for Alice to learn her public IP address and TCP port, Alice needs to first talk to a STUNT server, which tells her that information. She does that over TCP and then closes down that TCP connection. Alice's NAT puts that TCP socket into TIME_WAIT, so that Alice's NAT doesn't purposefully re-use that source TCP port for another TCP connection. (Note that for TCP S-O to work, Alice will need to re- use that same ephemeral port (SO_REUSEADDR) on her host, and on the NAT, when she does TCP S-O to Bob. To accomplish this, Alice's NAT will need to meet requirement REQ-1 of draft-ietf-behave-tcp-00, "External NAT mapping is endpoint independent". Many NATs on the market already meet that requirement.) She communicates her public IP address and TCP port to Bob somehow. Bob will immediately send a TCP SYN to that IP address and TCP port. Bob's TCP SYN will be received by Alice's NAT. Alice's NAT has that TCP port in TIME_WAIT state. * I am proposing that a NAT has a TCP port in TIME_WAIT * state, and that NAT is trying to assist with TCP S-O, * and receives a TCP SYN to that port, the TCP SYN * should be silently dropped. For other incoming TCP SYNs, Alice's NAT would behave normally -- per RFC1122. This is the idea I was describing on the BEHAVE mailing list. This idea is similar to your option 1, but instead of dropping all incoming TCP SYNs, we're only dropping TCP SYNs that arrive at ports that are in TIME_WAIT state. Let's call this second idea "delay receiving errors". The important part is also highlighted with "*": A separate, but somewhat similar idea, which I had emailed you directly, uses another tact. This one is similar to option 4 in your original email, but involves the NAT receiving the error, rather than involving the NAT sending the error. Alice learns and communicates her public IP address and TCP port to Bob. Bob immediately sends a TCP SYN to that IP address and TCP port (which is Alice's NAT or Alice herself - it doesn't matter in this case). Alice will immediately generate an error (TCP RST or ICMP error). Bob's NAT will receive the error, and will convey that error to Bob. * If Bob sends another SYN with a matching 4-tuple, * Bob's NAT will NAT the SYN normally, but if that * SYN also elicits an error, Bob's NAT will _delay_ * conveying that error to Bob for ~5 seconds. This * delay allows Bob (the host) to have an additional * 5 seconds to establish TCP S-O with Alice. Bob's host was told about the error immediately (the first error was conveyed to Bob) and in the event that first error was lost (802.11 network, for example), Bob's host will receive the ~5 second delayed errors. This is similar to Saikat's number 4 (Joe Touch's idea to delay ICMP errors), except that it involves Bob's NAT (which receives the error) rather than Alice's NAT (which sends the error). -d From dwing@cisco.com Wed, 31 May 2006 09:47:20 -0700 (PDT) From: "Dan Wing" Date: Wed, 31 May 2006 09:47:20 -0700 (PDT) Subject: RE: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Requestforcomments on proposals. In-Reply-To: <1149067869.30805.38.camel@localhost.localdomain> Message-ID: <019901c684d1$dabe3e50$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > On Tue, 2006-05-30 at 13:05 -0700, Dan Wing wrote: > > Alice STUNT server SIP proxy Bob > > | | | | > > 1 |--------->| | | > > 2 |<---------| | | > > 3 |----------------------->| | > > 4 | | |-------->| > > 5 |X <-------------------------------| > > 6 | |<----------------------| > > 7 | |---------------------->| > > 8 | | |<--------| > > 9 |<-----------------------| | > > 10 |--------------------------------->| > > What you mentioned is true for the particular SIP callflow > you provided, > but it doesn't necessarily have to be that callflow. Consider this > modified callflow. > > Alice STUNT server SIP proxy Bob > | | | | > 1 |--------->| | | > 2 |<---------| | | > 3 |---------INVITE-------->| | > 4 | | |-------->| > 5 |X <-------------------------------| > 6 | |<----------------------| > 7 | |---------------------->| > 8 | | |<--1xx---| > 9 |<-----------------------| | > 10 |---------UPDATE-------->| | > 11 | |-------->| > 12 | |<--200 U-| > 13 |<-----------------------| | > 14 |---------UPDATE-------->| | > 15 ... |-------->| > 16 |<================================>| > > > > In the above callflow, Bob realizes he must perform STUNT > after packet 5 as before. He responds to Allice with a 1xx > Ringing or some such message (Packet 8) that includes his > public address. Yes, of course. But unless both Alice and Bob implement PRACK (RFC3262), or we assume a non-lossy transport of signaling messages (such as TCP) that 1xx message (message 8 and 9) is sent unreliably and could be dropped between Bob and Alice. That is what I was referring to in my reply to Spencer. > Alice sends a "SIP ping" that comprises packets 10--13. The > "ping" is a SIP UPDATE packet that Bob responds to ASAP. PRACK (RFC3262) uses a 2xx message for this purpose. I believe you're describing something else? > Alice measures the SIP RTT for this ping. > > Alice then sends another UPDATE (packet 14) to Bob. Alice then waits > RTT/2 before starting TCP S-O. Bob will receive the packet roughly at > RTT/2 (note that while the SIP path is symmetric, there may be some IP > asymmetry on each hop). As soon as bob receives the second UPDATE, Bob > initiates his end of TCP S-O ASAP. > > Essentially, Alice and Bob invoke TCP S-O roughly at the same > time. This > is independent of the delay between packets 1 and 9 which you pointed > out could be quite large. > > I am not saying this callflow has to be followed, but even > with SIP and > proxies, it is _possible_ to get synced to within a few tens of > milliseconds. Ok, I admit it's possible. But that's a lot of SIP signaling in order to try to synchronize those TCP SYNs. -d > We were actually able to get it down to about .5--1 milliseconds on a > LAN without any IP asymmetry. This was much lower than a single IP RTT > between the two ends on the LAN, and obviously much much > lower than the > time it takes between SIP packets 1 and 9 (4 RTTs-ish). On > the internet, > this sync will depend some on the IP asymmetry, but 100ms is certainly > possible. > > cheers, > -- > Saikat > From saikat@cs.cornell.edu Wed, 31 May 2006 10:10:02 -0700 (PDT) From: Saikat Guha Date: Wed, 31 May 2006 10:10:02 -0700 (PDT) Subject: RE: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Requestforcomments on proposals. In-Reply-To: <019901c684d1$dabe3e50$c2f0200a@amer.cisco.com> Message-ID: <1149095400.30805.104.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-05-31 at 09:47 -0700, Dan Wing wrote: > But that's a lot of SIP signaling > in order to try to synchronize those TCP SYNs. That's true. Perhaps something like this can be a fallback if a more optimistic version fails. One optimistic one could be where the end-hosts are using NTP (most recent OSs do); Bob (or his proxy) could stamp his packet 8 with its local clock. Alice could then estimate RTT/2 to within NTP+skew+RTT and skip packets 10--13. 6 seconds still leaves quite a margin for NTP+skew+RTT IMHO. In any case, SIP+TCP-SO does both rendezvous and connection setup; and will likely be comparable in connection latency to (SIP+)ICE+STUN/TURN etc. For some classes of of applications (background apps like bittorrent, or app's that "ring" for a while like IP phones) connection setup overhead may be acceptable. But I admit that the signaling can be heavy-weight for certain other apps (peer-to-peer instant messages etc.) -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00125.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00125.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZmMzb25GbHRxaTY5MS9vUkFyQmlBSjljakVzSkgxTzJnS0JZak96 aTNxd1BkdWhFa0FDZVA4cWgKbHBxai9uS3dJdGNnR21Fc1B5S01ZS2s9Cj1tWkEyCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From touch@ISI.EDU Wed, 31 May 2006 10:14:42 -0700 (PDT) From: Joe Touch Date: Wed, 31 May 2006 10:14:42 -0700 (PDT) Subject: [Ietf-behave] Re: TCP S-O; Dan's two ideas In-Reply-To: <017101c684cd$809ea300$c2f0200a@amer.cisco.com> Message-ID: <447DCEDD.20200@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Dan Wing wrote: > I have two ideas floating around in my head. I hope this email clarifies > them. > > Let's call this first idea "TIME_WAIT SYN drop". The important part is > highlighted with "*": > > In order for Alice to learn her public IP address and > TCP port, Alice needs to first talk to a STUNT server, > which tells her that information. She does that over TCP > and then closes down that TCP connection. Alice's NAT > puts that TCP socket into TIME_WAIT, so that Alice's NAT > doesn't purposefully re-use that source TCP port for > another TCP connection. > > (Note that for TCP S-O to work, Alice will need to re- > use that same ephemeral port (SO_REUSEADDR) on her > host, and on the NAT, when she does TCP S-O to Bob. To > accomplish this, Alice's NAT will need to meet > requirement REQ-1 of draft-ietf-behave-tcp-00, > "External NAT mapping is endpoint independent". Many > NATs on the market already meet that requirement.) > > She communicates her public IP address and TCP port to Bob > somehow. Bob will immediately send a TCP SYN to that IP > address and TCP port. > > Bob's TCP SYN will be received by Alice's NAT. Alice's > NAT has that TCP port in TIME_WAIT state. > > * I am proposing that a NAT has a TCP port in TIME_WAIT > * state, and that NAT is trying to assist with TCP S-O, > * and receives a TCP SYN to that port, the TCP SYN > * should be silently dropped. > > For other incoming TCP SYNs, Alice's NAT would behave > normally -- per RFC1122. It is more important to respond to TIME_WAIT with a RST than in other states. This also requires that the NAT keep state on closed connections for the TIME_WAIT interval (which I would agree they should anyway). That said, I'm unclear on how this successfully helps S-O; the TCP socket pair (the 4-tuple) can't be reused during TIME_WAIT anyway. > This is the idea I was describing on the BEHAVE > mailing list. This idea is similar to your option 1, > but instead of dropping all incoming TCP SYNs, we're > only dropping TCP SYNs that arrive at ports that are > in TIME_WAIT state. > > Let's call this second idea "delay receiving errors". The important part is > also highlighted with "*": > > A separate, but somewhat similar idea, which I had > emailed you directly, uses another tact. This one is > similar to option 4 in your original email, but > involves the NAT receiving the error, rather than > involving the NAT sending the error. > > Alice learns and communicates her public IP address > and TCP port to Bob. Bob immediately sends a TCP SYN > to that IP address and TCP port (which is Alice's NAT > or Alice herself - it doesn't matter in this case). > Alice will immediately generate an error (TCP RST or > ICMP error). > > Bob's NAT will receive the error, and will convey > that error to Bob. > > * If Bob sends another SYN with a matching 4-tuple, > * Bob's NAT will NAT the SYN normally, but if that > * SYN also elicits an error, Bob's NAT will _delay_ > * conveying that error to Bob for ~5 seconds. This > * delay allows Bob (the host) to have an additional > * 5 seconds to establish TCP S-O with Alice. Bob's > host was told about the error immediately (the > first error was conveyed to Bob) and in the event > that first error was lost (802.11 network, for > example), Bob's host will receive the ~5 second > delayed errors. > > This is similar to Saikat's number 4 (Joe Touch's > idea to delay ICMP errors), except that it involves > Bob's NAT (which receives the error) rather than > Alice's NAT (which sends the error). There are two parts to this: 1) move the delay to the NAT that receives the error Delaying sending the error happens exactly once - wherever the error would have been generated. Delayed receipt can happen multiple places (consider multiple layers of NATs). How do you know you're the right NAT to delay receipt? 2) pass the first error, but delay the second one The first error will shut Bob's connection that's issuing the SYNs, so subsequent SYNs won't happen. What is the benefit for either component? Joe Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00126.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00126.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVmYzdkRTVmNWNJbW5acnNSQWs4OUFKc0dIMm8rK3FhQlJwM2x4 S3JVUHp1aFczeHNBd0NmYWY5eApyM1JEbjZuNlRJVDgwYXRxQVJWSHVxcz0KPXhjVHMKLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Wed, 31 May 2006 10:32:29 -0700 (PDT) From: Saikat Guha Date: Wed, 31 May 2006 10:32:29 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <07db01c68434$a7bcec60$c2f0200a@amer.cisco.com> Message-ID: <1149096748.30805.126.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-05-31 at 08:16 -0700, Joe Touch wrote: > > The NAT ought to have two states for the two sides of the connection: It may be easier to think of NAT state in terms of "mapping" and "connection"/"session". #1: For each internal port (X:x) each NAT maintains one and exactly one "mapping" to the allocated external address (X1:x1). That is if the NAT adheres to REQ-1 which mandates endpoint-independent behavior. (non compliant NATs would include in the "mapping" the remote end's address as well, but they are irrelevant) -- (1) #2: For each TCP connection, the NAT maintains the remote end's address (Y1:y1), a pointer to the mapping for the local end, and connection state (sequence numbers, flags seen etc.). > Once that connection is closed with a FIN, both 4-tuples (known as a > socket pair in RFC793) ought to be in TIME_WAIT, IMO. When the connection is closed with a FIN, the connection-state (#2) is updated to reflect that fact. > Then when Y2:y2 sends a SYN to X1:x1, wait 3 seconds for the ICMP. An unsolicited SYN is one that doesn't match any entry in #2, and either matches no entry in #1 or matches an entry in #1 but the endpoint filtering policy of the NAT forbids it from accepting SYNs from Y2:y2. Now say, it waits 3s for the ICMP. For S-O, the case likely is that the SYN matches a mapping in #1 but nothing in #2 (X:x just finished a STUNT address discovery so a mapping in #1 exists). (Dan's proposal says that if the unsolicited SYN is a result of a non-existent entry in #1 then there is no need to wait for those 3s) > During those 3 seconds, X sends a SYN to Y2:y2 using X:x (which may > require SO_REUSEADDR, but as you observe it's not a TCP issue). When the SYN goes out, the NAT finds an already existing mapping in #1. It creates a new entry in #2 with (Y2:y2, pointer to the mapping, SYN_SENT) etc. So at the end of all this, the NAT state looks like: #1: Mapping table M1 X:x <=> X1:x1 #2: Connection Table C1: Y1:y1, M1, TIME_WAIT C2: Y2:y2, M1, SYN_SENT > Now we have X:x talking to Y2:y2 - the translation entry X:x-Y1:y1/X1:x1 > doesn't appear to help. How does the S-O connect? Say the 3s timeout for the ICMP is now over. The NAT checks table #2, finds a connection entry for that connection (C2) and kills the ICMP. Y2 hits a TCP retransmission and resends his SYN. The SYN matches entry C2 and forwarded to X:x. S-O can now connect. > The reasons the delay were unacceptable were (AFAICT): > > 1) too hard to deploy > this version is a superset of option 4 in complexity Agreed. It requires additional state at the NAT to delay the ICMP, kill it if a connection entry appears, or send it otherwise. > 2) 3/6 seconds is too short > this version uses that number too Agreed. 3/6s may or may not be too short for various devices, or lossy wireless networks or a combination. > I'm unclear how this addresses those concerns; as noted above, I'm also > a bit unclear how it works ;-) Can you explain either? Dan's suggestion does allow the 3/6s to be increased to, say, 30s while not impacting apps that almost certainly are not doing S-O (i.e. didn't query a STUNT server). (PS: Request -- Lets not go back into the mapping vs. session vs. binding debate :-p) -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00127.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00127.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZmRNc25GbHRxaTY5MS9vUkFoZ05BSjRqTENjdm9qUmdHdXRiRHg0 YUJLUnl1ZmVncmdDZllDcksKRDBCVk5aZmdyMDBLTXlrb0Q5VmM0T0E9Cj0rUk02Ci0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From dwing@cisco.com Wed, 31 May 2006 11:08:16 -0700 (PDT) From: "Dan Wing" Date: Wed, 31 May 2006 11:08:16 -0700 (PDT) Subject: [Ietf-behave] RE: TCP S-O; Dan's two ideas In-Reply-To: <447DCEDD.20200@isi.edu> Message-ID: <01e701c684dd$2f5f4750$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Joe Touch wrote: > Dan Wing wrote: > > I have two ideas floating around in my head. I hope this > > email clarifies them. > > > > Let's call this first idea "TIME_WAIT SYN drop". The > > important part is highlighted with "*": > > > > In order for Alice to learn her public IP address and > > TCP port, Alice needs to first talk to a STUNT server, > > which tells her that information. She does that over TCP > > and then closes down that TCP connection. Alice's NAT > > puts that TCP socket into TIME_WAIT, so that Alice's NAT > > doesn't purposefully re-use that source TCP port for > > another TCP connection. > > > > (Note that for TCP S-O to work, Alice will need to re- > > use that same ephemeral port (SO_REUSEADDR) on her > > host, and on the NAT, when she does TCP S-O to Bob. To > > accomplish this, Alice's NAT will need to meet > > requirement REQ-1 of draft-ietf-behave-tcp-00, > > "External NAT mapping is endpoint independent". Many > > NATs on the market already meet that requirement.) > > > > She communicates her public IP address and TCP port to Bob > > somehow. Bob will immediately send a TCP SYN to that IP > > address and TCP port. > > > > Bob's TCP SYN will be received by Alice's NAT. Alice's > > NAT has that TCP port in TIME_WAIT state. > > > > * I am proposing that a NAT has a TCP port in TIME_WAIT > > * state, and that NAT is trying to assist with TCP S-O, > > * and receives a TCP SYN to that port, the TCP SYN > > * should be silently dropped. > > > > For other incoming TCP SYNs, Alice's NAT would behave > > normally -- per RFC1122. > > It is more important to respond to TIME_WAIT with a RST than in other > states. I understand the importance of sending RST in response to receiving data packets when you're in TIME_WAIT. But can you explain the importance of sending RST in response to receiving a SYN when you're in TIME_WAIT? > This also requires that the NAT keep state on closed > connections for the TIME_WAIT interval (which I would agree they > should anyway). Right. > That said, I'm unclear on how this successfully helps S-O; the TCP > socket pair (the 4-tuple) can't be reused during TIME_WAIT anyway. It's my understanding that unless you get the SYNs to cross in the network the *first time* you send a SYN, you need to reuse the same local socket (same 4-tuple) for your next attempt to get SYNs to cross in the network. (It's unfortunate we don't have a paper to cite which discusses what we're trying to accomplish, as it would make this design- by-email easier.) > > This is the idea I was describing on the BEHAVE > > mailing list. This idea is similar to your option 1, > > but instead of dropping all incoming TCP SYNs, we're > > only dropping TCP SYNs that arrive at ports that are > > in TIME_WAIT state. > > > > Let's call this second idea "delay receiving errors". The > > important part is also highlighted with "*": > > > > A separate, but somewhat similar idea, which I had > > emailed you directly, uses another tact. This one is > > similar to option 4 in your original email, but > > involves the NAT receiving the error, rather than > > involving the NAT sending the error. > > > > Alice learns and communicates her public IP address > > and TCP port to Bob. Bob immediately sends a TCP SYN > > to that IP address and TCP port (which is Alice's NAT > > or Alice herself - it doesn't matter in this case). > > Alice will immediately generate an error (TCP RST or > > ICMP error). > > > > Bob's NAT will receive the error, and will convey > > that error to Bob. > > > > * If Bob sends another SYN with a matching 4-tuple, > > * Bob's NAT will NAT the SYN normally, but if that > > * SYN also elicits an error, Bob's NAT will _delay_ > > * conveying that error to Bob for ~5 seconds. This > > * delay allows Bob (the host) to have an additional > > * 5 seconds to establish TCP S-O with Alice. Bob's > > host was told about the error immediately (the > > first error was conveyed to Bob) and in the event > > that first error was lost (802.11 network, for > > example), Bob's host will receive the ~5 second > > delayed errors. > > > > This is similar to Saikat's number 4 (Joe Touch's > > idea to delay ICMP errors), except that it involves > > Bob's NAT (which receives the error) rather than > > Alice's NAT (which sends the error). > > There are two parts to this: > > 1) move the delay to the NAT that receives the error > > Delaying sending the error happens exactly once - wherever the error > would have been generated. Delayed receipt can happen multiple places > (consider multiple layers of NATs). How do you know you're > the right NAT to delay receipt? I hadn't considered that and that's a good point. I'm not sure it's severe enough to kill the idea outright, though. An advantage of this technique is it's "my NAT" that implements this function so I can do S-O with someone else, rather than relying on someone else to have an upgraded their NAT to be capable of S-O. > 2) pass the first error, but delay the second one > > The first error will shut Bob's connection that's issuing the SYNs, so > subsequent SYNs won't happen. Based on my understanding of how TCP S-O would work -- even without NATs at all -- Bob's TCP stack will get RSTs (or ICMP errors) until Alice and Bob's SYNs happen to cross in the network. Thus Bob's application will have to loop, re-using the same 4-tuple, and cause Bob's TCP stack to send another SYN and try to get the SYNs to cross in the network. The benefit of delaying the second error is to allow Bob's application to only have to enter this loop maybe once: the first SYN will elicit an error (which Bob's application will see) and Bob's application will then retry using the same 4-tuple but now his stack (and application) won't see an error again for ~5 seconds. Perhaps we can adjust your earlier idea to include this behavior, so we avoid the double-NAT problem you found with my idea. Your original idea, per Saikat's email: > Option 4: Proposed earlier on list by Joe > ========= > > "A NAT SHOULD signal an ICMP port unreachable. If it > does, it MUST delay the ICMP error by at least 3 > seconds and MUST cancel the ICMP if in that time an > outbound SYN for the connection is seen. If the NAT > does not have resources to delay the ICMP, it MUST > silently drop the inbound SYN" Let me know if the following works for you. With this new text I'm having the NAT delay sending an error only if there is a reason to suspect the remote endpoint is trying to establish a TCP S-O connection with us. Upon receipt of a TCP SYN to a TCP port that is in TIME_WAIT, a NAT SHOULD signal an error (ICMP port unreachable or TCP RST) immediately. If the NAT receives another TCP SYN with a matching 4-tuple of a previous TCP SYN the NAT SHOULD delay sending an error in response to that TCP SYN for 3 seconds. This does mean the NAT has to maintain information about the incoming SYN for each of its public TCP ports that are in TIME_WAIT, in order to decide what action to take when another SYN happens to arrive on that TCP port (send an error immediately versus delay for 3 seconds). Maintaining that additional information isn't pleasant, especially considering it's coming from the public side of the NAT (which is where attacks come from). Elsewhere we would have a requirement that receiving any TCP traffic while a TCP binding is in TIME_WAIT should elicit an error response, as that is important for TCP. However, that isn't important for our needs to do simultaneous-open, so I didn't include it in the paragraph above. For S-O to work better, we only care about delaying (or dropping) error messages in response to TCP SYN. Saikat, would that help with TCP S-O, or does that make things worse? -d From dwing@cisco.com Wed, 31 May 2006 11:21:32 -0700 (PDT) From: "Dan Wing" Date: Wed, 31 May 2006 11:21:32 -0700 (PDT) Subject: [Ietf-behave] new BEHAVE milestones Message-ID: <021101c684df$0ac42d00$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Our new milestones are now posted at : Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Aug 2006 Submit revision of RFC 3489 to IESG Sep 2006 Submit BCP that defines multicast UDP behavioral requirements for NATs to IESG Oct 2006 Submit relay protocol to IESG Oct 2006 Submit IPv6 relay protocol to IESG Dec 2006 Submit a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches to IESG Mar 2007 Submit a BCP that defines TCP behavioral requirements for NATs to IESG Mar 2007 Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Apr 2007 Close WG or recharter -d From dwing@cisco.com Wed, 31 May 2006 15:30:09 -0700 (PDT) From: "Dan Wing" Date: Wed, 31 May 2006 15:30:09 -0700 (PDT) Subject: [Ietf-behave] FW: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada Message-ID: <047a01c68501$c5c4d330$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-secretariat@xxxxxxxx [mailto:ietf-secretariat@xxxxxxxx] > Sent: Thursday, May 25, 2006 9:00 PM > To: ietf-announce@xxxxxxxx > Subject: Internet-Drafts Submission Cutoff Dates for the 66th > IETF Meeting in Montreal, Quebec, Canada > > > There are two (2) Internet-Draft cutoff dates for the 66th > IETF Meeting in Montreal, Quebec, Canada: > > June 19th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted > by Monday, > June 19th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 12th at 9:00 AM ET. > > June 26th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be > submitted > by Monday, June 26th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 10th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@xxxxxxxxx > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other > significant dates > for the 66th IETF Meeting can be found at > http://www.ietf.org/meetings/cutoff_dates_66.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf-announce From touch@ISI.EDU Wed, 31 May 2006 21:26:43 -0700 (PDT) From: Joe Touch Date: Wed, 31 May 2006 21:26:43 -0700 (PDT) Subject: [Ietf-behave] Re: TCP S-O; Dan's two ideas In-Reply-To: <01e701c684dd$2f5f4750$c2f0200a@amer.cisco.com> Message-ID: <447E6C60.1090300@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Dan Wing wrote: ... >>> * I am proposing that a NAT has a TCP port in TIME_WAIT >>> * state, and that NAT is trying to assist with TCP S-O, >>> * and receives a TCP SYN to that port, the TCP SYN >>> * should be silently dropped. >>> >>> For other incoming TCP SYNs, Alice's NAT would behave >>> normally -- per RFC1122. >> It is more important to respond to TIME_WAIT with a RST than in other >> states. > > I understand the importance of sending RST in response to receiving data > packets when you're in TIME_WAIT. > > But can you explain the importance of sending RST in response to receiving > a SYN when you're in TIME_WAIT? It's at the bottom of page 71 of RFC793. It allows the other side to pick a different set of ports more quickly, since these - even retried - won't succeed until TIME-WAIT expires. Normally, a lost SYN would result in a retry, which just keeps the same ports. I.e., an application that didn't get a RST for a TIME-WAIT will end up waiting about a minute for TCP to timeout on the connection attempt overall. ... >> That said, I'm unclear on how this successfully helps S-O; the TCP >> socket pair (the 4-tuple) can't be reused during TIME_WAIT anyway. > > It's my understanding that unless you get the SYNs to cross in the > network the *first time* you send a SYN, you need to reuse the same > local socket (same 4-tuple) for your next attempt to get SYNs to > cross in the network. Yes, but if one side ends up in TIME-WAIT, you have to wait until it expires to reuse the port pair. ... >>> * If Bob sends another SYN with a matching 4-tuple, >>> * Bob's NAT will NAT the SYN normally, but if that >>> * SYN also elicits an error, Bob's NAT will _delay_ >>> * conveying that error to Bob for ~5 seconds. This >>> * delay allows Bob (the host) to have an additional >>> * 5 seconds to establish TCP S-O with Alice. Bob's >>> host was told about the error immediately (the >>> first error was conveyed to Bob) and in the event >>> that first error was lost (802.11 network, for >>> example), Bob's host will receive the ~5 second >>> delayed errors. >>> >>> This is similar to Saikat's number 4 (Joe Touch's >>> idea to delay ICMP errors), except that it involves >>> Bob's NAT (which receives the error) rather than >>> Alice's NAT (which sends the error). >> There are two parts to this: >> >> 1) move the delay to the NAT that receives the error >> >> Delaying sending the error happens exactly once - wherever the error >> would have been generated. Delayed receipt can happen multiple places >> (consider multiple layers of NATs). How do you know you're >> the right NAT to delay receipt? > > I hadn't considered that and that's a good point. I'm not sure it's > severe enough to kill the idea outright, though. An advantage of > this technique is it's "my NAT" that implements this function so > I can do S-O with someone else, rather than relying on someone > else to have an upgraded their NAT to be capable of S-O. That makes S-O depend on which side starts first, which is a bit odd for a P2P net or the concept of the "S" in S-O. ;-) >> 2) pass the first error, but delay the second one >> >> The first error will shut Bob's connection that's issuing the SYNs, so >> subsequent SYNs won't happen. > > Based on my understanding of how TCP S-O would work -- even without > NATs at all -- Bob's TCP stack will get RSTs (or ICMP errors) until > Alice and Bob's SYNs happen to cross in the network. Thus Bob's > application will have to loop, re-using the same 4-tuple, and > cause Bob's TCP stack to send another SYN and try to get the SYNs > to cross in the network. The first RST/ICMP will make Bob go into TIME-WAIT. REUSEADDR won't help that. > The benefit of delaying the second error is to allow Bob's > application to only have to enter this loop maybe once: the > first SYN will elicit an error (which Bob's application will see) > and Bob's application will then retry using the same 4-tuple but > now his stack (and application) won't see an error again for ~5 > seconds. > > > Perhaps we can adjust your earlier idea to include this behavior, > so we avoid the double-NAT problem you found with my idea. Your > original idea, per Saikat's email: > > > Option 4: Proposed earlier on list by Joe > > ========= > > > > "A NAT SHOULD signal an ICMP port unreachable. If it > > does, it MUST delay the ICMP error by at least 3 > > seconds and MUST cancel the ICMP if in that time an > > outbound SYN for the connection is seen. If the NAT > > does not have resources to delay the ICMP, it MUST > > silently drop the inbound SYN" > > Let me know if the following works for you. With this new > text I'm having the NAT delay sending an error only if there > is a reason to suspect the remote endpoint is trying to > establish a TCP S-O connection with us. > > Upon receipt of a TCP SYN to a TCP port that is in > TIME_WAIT, a NAT SHOULD signal an error (ICMP port > unreachable or TCP RST) immediately. If the NAT receives > another TCP SYN with a matching 4-tuple of a previous TCP > SYN the NAT SHOULD delay sending an error in response > to that TCP SYN for 3 seconds. Besides the state (noted below, though I think a NAT ought to have that anyway), there's the issue of the first immediate error. That seems to kill the other side - as noted above. Or did I miss something? Joe > This does mean the NAT has to maintain information about the incoming SYN > for each of its public TCP ports that are in TIME_WAIT, in order to decide > what action to take when another SYN happens to arrive on that TCP port > (send an error immediately versus delay for 3 seconds). Maintaining that > additional information isn't pleasant, especially considering it's coming > from the public side of the NAT (which is where attacks come from). > > Elsewhere we would have a requirement that receiving any TCP traffic while a > TCP binding is in TIME_WAIT should elicit an error response, as that is > important for TCP. However, that isn't important for our needs to do > simultaneous-open, so I didn't include it in the paragraph above. For S-O > to work better, we only care about delaying (or dropping) error messages in > response to TCP SYN. > > Saikat, would that help with TCP S-O, or does that make things worse? > > -d Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00128.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00128.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVmbXhnRTVmNWNJbW5acnNSQW01T0FKNGgvREF3eWJ0Vkp3eTB6 WDR1MEVRdVlzaXBzZ0NkRnFTZgo2SHNScUFkVURyYkxCcDRmQ2xMRFBaZz0KPVlFdy8KLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From touch@ISI.EDU Wed, 31 May 2006 22:03:33 -0700 (PDT) From: Joe Touch Date: Wed, 31 May 2006 22:03:33 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <07db01c68434$a7bcec60$c2f0200a@amer.cisco.com> Message-ID: <447E7509.5080706@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Saikat Guha wrote: > On Wed, 2006-05-31 at 08:16 -0700, Joe Touch wrote: >> The NAT ought to have two states for the two sides of the connection: > > It may be easier to think of NAT state in terms of "mapping" and > "connection"/"session". > > #1: For each internal port (X:x) That's address X and port x, isn't it? > each NAT maintains one and exactly one > "mapping" to the allocated external address (X1:x1). That's address X1 and port x1, isn't it? > That is if the NAT > adheres to REQ-1 which mandates endpoint-independent behavior. (non > compliant NATs would include in the "mapping" the remote end's address > as well, but they are irrelevant) -- (1) REQ-1 requires that the map (external address _and_ port) be independent of the endpoint (Y1:y1). I hadn't realized you're talking about only a subset of NATs. > #2: For each TCP connection, the NAT maintains the remote end's address > (Y1:y1), a pointer to the mapping for the local end, and connection > state (sequence numbers, flags seen etc.). OK. >> Once that connection is closed with a FIN, both 4-tuples (known as a >> socket pair in RFC793) ought to be in TIME_WAIT, IMO. > > When the connection is closed with a FIN, the connection-state (#2) is > updated to reflect that fact. The T-W affects two views of the TCP connection: X:x--Y1:y1 (as seen from inside the NAT) X1:x1--Y1:y1 (as seen from outside the NAT) >> Then when Y2:y2 sends a SYN to X1:x1, wait 3 seconds for the ICMP. > > An unsolicited SYN is one that doesn't match any entry in #2, and either > matches no entry in #1 or matches an entry in #1 but the endpoint > filtering policy of the NAT forbids it from accepting SYNs from Y2:y2. > > Now say, it waits 3s for the ICMP. > > For S-O, the case likely is that the SYN matches a mapping in #1 but > nothing in #2 (X:x just finished a STUNT address discovery so a mapping > in #1 exists). I didn't see anything in the udp doc that required that the mapping in #1 be static, only that two concurrent connections have the property that they would use the same source addr/port remapping pair. That loophole needs to be closed for this to work. Second, S-O after an open isn't really a S-O anymore. That's now making a requirement to the behavior of the endpoints to 'tickle' the state on the NATs a certain way - a way that they're not currently designed to implement. IMO, it's simpler to just delay all SYN-based ICMPs for 3 seconds. > (Dan's proposal says that if the unsolicited SYN is a result of a > non-existent entry in #1 then there is no need to wait for those 3s) Yes; that's an optimization of what I proposed that adds a lot of state at the NAT (albeit state it ought to keep) _and_ a 'protocol' that requires sequences of connections to make a S-O work. That's along run for a short slide ;-) >> During those 3 seconds, X sends a SYN to Y2:y2 using X:x (which may >> require SO_REUSEADDR, but as you observe it's not a TCP issue). > > When the SYN goes out, the NAT finds an already existing mapping in #1. > It creates a new entry in #2 with (Y2:y2, pointer to the mapping, > SYN_SENT) etc. So at the end of all this, the NAT state looks like: > > #1: Mapping table > M1 X:x <=> X1:x1 > > #2: Connection Table > C1: Y1:y1, M1, TIME_WAIT > C2: Y2:y2, M1, SYN_SENT OK. >> Now we have X:x talking to Y2:y2 - the translation entry X:x-Y1:y1/X1:x1 >> doesn't appear to help. How does the S-O connect? > > Say the 3s timeout for the ICMP is now over. The NAT checks table #2, > finds a connection entry for that connection (C2) and kills the ICMP. Yeah - we agreed that the ICMPs be held for 3 seconds anyway, and if a connection comes that overrides the ICMP then it should be dropped. That's the same as I proposed. > Y2 hits a TCP retransmission and resends his SYN. The SYN matches > entry C2 and forwarded to X:x. S-O can now connect. Ah - yes, you're describing what we already assumed was the case. I.e., the only difference here is whether you decide to send the ICMP immediately because you don't have the state from a previous connection. As noted above, that helps only in some cases, but then also requires that the TCP use two connections to establish one - where other out-of-band coordination could suffice. It's fine as an optimization, but IMO it's overkill to require it. >> The reasons the delay were unacceptable were (AFAICT): >> >> 1) too hard to deploy >> this version is a superset of option 4 in complexity > > Agreed. It requires additional state at the NAT to delay the ICMP, kill > it if a connection entry appears, or send it otherwise. The part you describe here is the same as option 4; the difference is that option 4 doesn't bother with the optimization case. >> 2) 3/6 seconds is too short >> this version uses that number too > > Agreed. 3/6s may or may not be too short for various devices, or lossy > wireless networks or a combination. > >> I'm unclear how this addresses those concerns; as noted above, I'm also >> a bit unclear how it works ;-) Can you explain either? > > Dan's suggestion does allow the 3/6s to be increased to, say, 30s while > not impacting apps that almost certainly are not doing S-O (i.e. didn't > query a STUNT server). Adding 30 seconds is substantial - it ends up not helping much in cases where ICMP is supposed to help. The issue with the optimization is that it may help, but you're really assuming two things: a) that all S-Os are preceded by a STUNT query that shouldn't be strictly required if the apps have enough info to coordinate some other way b) that all previous connections by a host are prefaces to S-Os i.e., any active host will probably always have an entry in #1, which means the use of that table to decide whether or not to send the ICMP immediately will be moot anyway > (PS: Request -- Lets not go back into the mapping vs. session vs. > binding debate :-p) I'm glad I have no idea what this means ;-) Joe Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00129.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00129.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVmblVKRTVmNWNJbW5acnNSQXJoMkFKOXlZVEJRajhpNVI4cnhH ZngySERwcWZyc3Z0d0NnbElLWQpHdEJMZmJ0T0gybHQ3eCsvMXErVllMST0KPUoyRDgKLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Thu, 1 Jun 2006 03:08:30 -0700 (PDT) From: Saikat Guha Date: Thu, 1 Jun 2006 03:08:30 -0700 (PDT) Subject: [Ietf-behave] Re: TCP S-O; Dan's two ideas In-Reply-To: <01e701c684dd$2f5f4750$c2f0200a@amer.cisco.com> Message-ID: <1149156508.30805.147.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-05-31 at 21:26 -0700, Joe Touch wrote: > Dan Wing wrote: > > > Option 4: Proposed earlier on list by Joe > > > ========= > > > > > > "A NAT SHOULD signal an ICMP port unreachable. If it > > > does, it MUST delay the ICMP error by at least 3 > > > seconds and MUST cancel the ICMP if in that time an > > > outbound SYN for the connection is seen. If the NAT > > > does not have resources to delay the ICMP, it MUST > > > silently drop the inbound SYN" > > > > Let me know if the following works for you. With this new > > text I'm having the NAT delay sending an error only if there > > is a reason to suspect the remote endpoint is trying to > > establish a TCP S-O connection with us. > > > > Upon receipt of a TCP SYN to a TCP port that is in > > TIME_WAIT, a NAT SHOULD signal an error (ICMP port > > unreachable or TCP RST) immediately. What happens if the connection to the STUNT server isn't closed by the time the S-O is attempted? With current stacks you can bind two TCP sockets to the same port and initiate a connection to two different destinations at the same time last I tried. > > If the NAT receives > > another TCP SYN with a matching 4-tuple of a previous TCP > > SYN the NAT SHOULD delay sending an error in response > > to that TCP SYN for 3 seconds. Also, last I tried the Windows stack (XP SP1 I think) would send 3 SYNs for an app-initiated connection even when each SYN was met with an RST. So the app doesn't see the error until all three SYNs get their RSTs. Your approach would consequently shave off 3s out of 9s in detecting an error. On Linux, it may shave off 3s out of 3s in certain, which is probably what you were aiming for. Overall, for an optimization that, as Joe mentioned, affects only some connections, assumes how the address must have been learned, adds a fair bit of state and complexity, requires the app to follow a certain "port-knocking" protocol (i.e try twice), I am not convinced it provides proportional real-world benefit (i.e. to Windows apps and in the multiple-NAT scenario that Joe identified). Certainly not enough to make it a requirement IMHO. But it might make sense to tweak the wording of Option #4 to not preclude such an optimization if the vendor were to make it. My 2c. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00130.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00130.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZnJ5Y25GbHRxaTY5MS9vUkFvNFJBSnNIZDdHZzZIQ213YUJCNXRm SVhEZUVDRnkxNGdDZlhjaGcKZnVOQ1FRNkpJUlM4YVlLMHM2eDVYZDA9Cj1URUdqCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Thu, 1 Jun 2006 03:39:41 -0700 (PDT) From: Saikat Guha Date: Thu, 1 Jun 2006 03:39:41 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <07db01c68434$a7bcec60$c2f0200a@amer.cisco.com> Message-ID: <1149158380.30805.168.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-05-31 at 22:03 -0700, Joe Touch wrote: > Saikat Guha wrote: > > On Wed, 2006-05-31 at 08:16 -0700, Joe Touch wrote: > > That is if the NAT > > adheres to REQ-1 which mandates endpoint-independent behavior. (non > > compliant NATs would include in the "mapping" the remote end's address > > as well, but they are irrelevant) -- (1) > > REQ-1 requires that the map (external address _and_ port) be independent > of the endpoint (Y1:y1). I hadn't realized you're talking about only a > subset of NATs. The subset I am talking about behave compliant NATs. There are legacy NATs that don't follow REQ-1. > > An unsolicited SYN is one that doesn't match any entry in #2, and > > either > > matches no entry in #1 or matches an entry in #1 but the endpoint > > filtering policy of the NAT forbids it from accepting SYNs from > > Y2:y2. > > I didn't see anything in the udp doc that required that the mapping in > #1 be static, only that two concurrent connections have the property > that they would use the same source addr/port remapping pair. That > loophole needs to be closed for this to work. By static, I assume you mean that the internal address and port (X:x) uniquely determines the mapped address and port (X1:x1) for all time. That is not possible -- by definition that mapping has to be mane-to-one (the NAT has more internal hosts than external IPs). Say two internal endpoints (X:x) and (Z:z) get the same "static" mapping (X1:x1). Then the two can no longer talk to the same external endpoint Y1:y1 simultaneously. Whats the UDP draft does say is that the mapping must remain active for some period of time after the last activity -- i.e. for a few minutes (5-ish), all connections from X:x will use that mapping and all incoming packets (for new connections, policy permitting) will be routed to the internal endpoint. > IMO, it's simpler to just delay all SYN-based ICMPs for 3 seconds. /agreed. Makes the fewest assumptions on why the SYN came, has IMHO acceptable error notification lag, and supports S-O. > As noted above, [Dan's proposal] helps only in some cases, but then also > requires > that the TCP use two connections to establish one - where other > out-of-band coordination could suffice. Now that I think about it, Dan's proposal blocks a very time-saving optimization. A large fraction of NATs are "port preserving" i.e. if you use internal port :x then the NAT too will use external port :x for the mapping (if available). Also, home NATs typically have one IP address. So an application can opportunistically predict the mapping it is going to get without ever talking to a STUNT server!! (almost 90% of the NATs do this already; see section 5 in our IMC paper) With this optimization, an endpoint can signal the necessary address and port information OOB without incurring one RTT to the public server at connection initiation, and also lessens the load on the STUNT server. For home NATs with few active connections through it, such port prediction will almost always succeed. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00131.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00131.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZnNQc25GbHRxaTY5MS9vUkFpcmpBSjQvWW81OUxNY08vQ0pLMWh6 VndDRGRDWEdqVXdDZEdZSmcKb1JmR2RYWVZDTkN6eFRXakZWczJpNms9Cj1zZ1FnCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From touch@ISI.EDU Thu, 1 Jun 2006 07:34:47 -0700 (PDT) From: Joe Touch Date: Thu, 1 Jun 2006 07:34:47 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <07db01c68434$a7bcec60$c2f0200a@amer.cisco.com> Message-ID: <447EFAB3.8090607@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Saikat Guha wrote: > On Wed, 2006-05-31 at 22:03 -0700, Joe Touch wrote: >> Saikat Guha wrote: >>> On Wed, 2006-05-31 at 08:16 -0700, Joe Touch wrote: >>> That is if the NAT >>> adheres to REQ-1 which mandates endpoint-independent behavior. (non >>> compliant NATs would include in the "mapping" the remote end's address >>> as well, but they are irrelevant) -- (1) >> REQ-1 requires that the map (external address _and_ port) be independent >> of the endpoint (Y1:y1). I hadn't realized you're talking about only a >> subset of NATs. > > The subset I am talking about behave compliant NATs. There are legacy > NATs that don't follow REQ-1. I've never heard of anything more than "there are four kinds of NATs". Is there really reason to assert that violation of REQ-1 correlates to "legacy" NATs only? >>> An unsolicited SYN is one that doesn't match any entry in #2, and >>> either >>> matches no entry in #1 or matches an entry in #1 but the endpoint >>> filtering policy of the NAT forbids it from accepting SYNs from >>> Y2:y2. >> I didn't see anything in the udp doc that required that the mapping in >> #1 be static, only that two concurrent connections have the property >> that they would use the same source addr/port remapping pair. That >> loophole needs to be closed for this to work. > > By static, I assume you mean that the internal address and port (X:x) > uniquely determines the mapped address and port (X1:x1) for all time. > That is not possible -- by definition that mapping has to be mane-to-one > (the NAT has more internal hosts than external IPs). > > Say two internal endpoints (X:x) and (Z:z) get the same "static" mapping > (X1:x1). Then the two can no longer talk to the same external endpoint > Y1:y1 simultaneously. > > Whats the UDP draft does say is that the mapping must remain active for > some period of time after the last activity -- i.e. for a few minutes > (5-ish), all connections from X:x will use that mapping and all incoming > packets (for new connections, policy permitting) will be routed to the > internal endpoint. Is that also implemented in all currently manufactured NATs? What is the incentive for the NAT to keep that state around at all once the connection is closed? ... >> As noted above, [Dan's proposal] helps only in some cases, but then also >> requires >> that the TCP use two connections to establish one - where other >> out-of-band coordination could suffice. > > Now that I think about it, Dan's proposal blocks a very time-saving > optimization. A large fraction of NATs are "port preserving" i.e. if you > use internal port :x then the NAT too will use external port :x for the > mapping (if available). Also, home NATs typically have one IP address. > So an application can opportunistically predict the mapping it is going > to get without ever talking to a STUNT server!! (almost 90% of the NATs > do this already; see section 5 in our IMC paper) Regarding citing percentages... (which seems to be prevalent in the IETF), in this case: Section 5 measures your sample of home users; 90% of the _cases_ != 90% of the NATs [deployed in use]. Even if you normalize for the market info earlier in your paper, the study you cite is based on market penetration of home WLAN NATs, which are only a fraction of where NATs are deployed (consider a single enterprise, NATs built into cable or DSL boxes that don't include WLAN, etc.) (IMC reviewers should have caught that!) I don't know how many NATs do anything in particular. I haven't heard any convincing evidence that any researcher does (someone at a large company that deploys software that calls-in from behind NATs could try to figure this out, e.g., MS during a windows update, but I haven't heard them talk about it). > With this optimization, an endpoint can signal the necessary address and > port information OOB without incurring one RTT to the public server at > connection initiation, and also lessens the load on the STUNT server. > For home NATs with few active connections through it, such port > prediction will almost always succeed. Sure. Opportunistic is one way. Joe Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00132.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00132.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVmdnF6RTVmNWNJbW5acnNSQXNPNUFLRFFadUlMRmpMMW80b1Nh UGM4ZXhSR25vWjNIZ0NnN09ReQp0Z1ZqSGxxZjJzOStoY0NJS3RyaVYzZz0KPWFHaS8KLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Thu, 1 Jun 2006 08:30:10 -0700 (PDT) From: Saikat Guha Date: Thu, 1 Jun 2006 08:30:10 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <07db01c68434$a7bcec60$c2f0200a@amer.cisco.com> Message-ID: <1149175805.23856.23.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2006-06-01 at 07:33 -0700, Joe Touch wrote: > I've never heard of anything more than "there are four kinds of NATs". There are two independent axis: Axis 1: mapping = (independent, address dependent, address and port dependent, and connection dependent (for TCP) ) Axis 2: filtering = (indep, addr dep, addr and port dep, conn dep) you can mix and match -- 16 possible, some nonsensical. The oft-heard "four kinds" are - indep. mapping, indep. filtering - indep. mapping, addr dep filtering - indep. mapping, addr and port dep filtering - everything not indep. mapping (note the "four kinds" doesn't cover all possible kinds. like indep. mapping and conn dep. filtering for example; nor does it differentiate 'good' nats from 'bad' nats inside that 'everything not indep. mapping' class. See the IMC'05 paper for details.) > Is there really reason to assert that violation of REQ-1 correlates to > "legacy" NATs only? REQ-1 forbids the "everything not indep. mapping". By "legacy" I mean NATs that don't adhere to REQ-1 here. > > Whats the UDP draft does say is that the mapping must remain active for > > some period of time after the last activity -- i.e. for a few minutes > > (5-ish), all connections from X:x will use that mapping and all incoming > > packets (for new connections, policy permitting) will be routed to the > > internal endpoint. > > Is that also implemented in all currently manufactured NATs? What is the > incentive for the NAT to keep that state around at all once the > connection is closed? You cannot "close" a UDP connection at the NAT; it can only time-out. > > So an application can opportunistically predict the mapping it is going > > to get without ever talking to a STUNT server!! (almost 90% of the NATs > > do this already; see section 5 in our IMC paper) > > Regarding citing percentages... (which seems to be prevalent in the > IETF), in this case: > > Section 5 measures your sample of home users; 90% of the _cases_ != 90% > of the NATs [deployed in use]. Correct, I should have clarified. The paper indeed makes it clear that this is for home NATs and not enterprise NATs. That said, with the UDP requirements REQ-3, REQ-4 (i.e. port-ranges SHOULD be preserved, and port-parity SHOULD be preserved), the draft falls just short of suggesting that preserving ports when possible is not a bad thing. While app developers cannot depend on this (most of the related behavior is a SHOULD and not a MUST anyway), predicting ports opportunistically without contacting a STUNT server is certainly is one optimization that is a) beneficial, b) likely to succeed for most home users today, and possibly in the future. IMHO, coming up with a SHOULD that makes S-O contingent on the app contacting a STUNT server and thereby blocking a useful, potentially opportunistic, optimization is not the right solution. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00133.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00133.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZndmOG5GbHRxaTY5MS9vUkFoa1hBSjBSMFA5ZzhteXBKRlRWY0lk OVEva2Y5MGdSVFFDY0RnZTIKdmYxVTZEU0s3TnQzSUljUlowaW10Rmc9Cj1YbDl4Ci0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From dwing@cisco.com Thu, 1 Jun 2006 08:59:10 -0700 (PDT) From: "Dan Wing" Date: Thu, 1 Jun 2006 08:59:10 -0700 (PDT) Subject: [Ietf-behave] port prediction [was RE: NAT TCP Simultaneous-Open: Request for comments on proposals.] In-Reply-To: <1149175805.23856.23.camel@localhost.localdomain> Message-ID: <158001c68594$4cd77340$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > While app developers cannot depend on this (most of the > related behavior > is a SHOULD and not a MUST anyway), predicting ports opportunistically > without contacting a STUNT server is certainly is one > optimization that > is a) beneficial, b) likely to succeed for most home users today, and > possibly in the future. As individual contributor: But port prediction only works well if the NAT is quiescent. If you add another user surfing the web, doing BitTorrent, or an active PVR-like automaton, port prediction becomes fragile and you will have TCP connections from your intended peer coming into your other clients. That's a mess unless you want to do some ICE-like magic cookie handshaking at the beginning of your TCP connection to verify you're talking to the correct application. "Hey, everyone else in the house, please get your hands off your keyboards, I need to run my S-O application now and the NAT is too busy." > IMHO, coming up with a SHOULD that makes S-O contingent on the app > contacting a STUNT server and thereby blocking a useful, potentially > opportunistic, optimization is not the right solution. -d From touch@ISI.EDU Thu, 1 Jun 2006 09:26:46 -0700 (PDT) From: Joe Touch Date: Thu, 1 Jun 2006 09:26:46 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <07db01c68434$a7bcec60$c2f0200a@amer.cisco.com> Message-ID: <447F1522.8070601@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Saikat Guha wrote: > On Thu, 2006-06-01 at 07:33 -0700, Joe Touch wrote: .. >>> Whats the UDP draft does say is that the mapping must remain active for >>> some period of time after the last activity -- i.e. for a few minutes >>> (5-ish), all connections from X:x will use that mapping and all incoming >>> packets (for new connections, policy permitting) will be routed to the >>> internal endpoint. >> Is that also implemented in all currently manufactured NATs? What is the >> incentive for the NAT to keep that state around at all once the >> connection is closed? > > You cannot "close" a UDP connection at the NAT; it can only time-out. The place where this draft refers to the UDP needs to make that differentiation clear - at what point should NATs handle TCP connections differently. Or are you saying that NATs should treat TCP the way they treat UDP, with a 5-minute idle timeout? i.e., IMO they ought to have a much longer timeout, in the half-hour to hour range, or not timeout at all until state needs to be cleaned up for space savings or because a TCP segment comes through that matches the addr/port of the map but not the sequence numbers. -- it's useful to keep in mind that - in general - TCP doesn't 'clean up' state of old connections until they get in the way of new ones. IMO, NATs ought to follow that same principle for TCP entries. >>> So an application can opportunistically predict the mapping it is going >>> to get without ever talking to a STUNT server!! (almost 90% of the NATs >>> do this already; see section 5 in our IMC paper) >> Regarding citing percentages... (which seems to be prevalent in the >> IETF), in this case: >> >> Section 5 measures your sample of home users; 90% of the _cases_ != 90% >> of the NATs [deployed in use]. > > Correct, I should have clarified. The paper indeed makes it clear that > this is for home NATs and not enterprise NATs. That said, with the UDP > requirements REQ-3, REQ-4 (i.e. port-ranges SHOULD be preserved, and > port-parity SHOULD be preserved), the draft falls just short of > suggesting that preserving ports when possible is not a bad thing. > > While app developers cannot depend on this (most of the related behavior > is a SHOULD and not a MUST anyway), predicting ports opportunistically > without contacting a STUNT server is certainly is one optimization that > is a) beneficial, b) likely to succeed for most home users today, and > possibly in the future. Agreed. > IMHO, coming up with a SHOULD that makes S-O contingent on the app > contacting a STUNT server and thereby blocking a useful, potentially > opportunistic, optimization is not the right solution. Agreed. Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00134.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00134.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVmeFVpRTVmNWNJbW5acnNSQW1TT0FLRHVKd0tTbUM0NVdTbm5C bmxsN0NoRzk3SnFkUUNiQnhPOQpGMTRTbUdoeDhrelExVUVYRzF2RDVWaz0KPUdzclMKLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Thu, 1 Jun 2006 09:36:25 -0700 (PDT) From: Saikat Guha Date: Thu, 1 Jun 2006 09:36:25 -0700 (PDT) Subject: [Ietf-behave] Re: port prediction [was RE: NAT TCP Simultaneous-Open: Request for comments on proposals.] In-Reply-To: <158001c68594$4cd77340$c2f0200a@amer.cisco.com> Message-ID: <1149179783.23856.31.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2006-06-01 at 08:59 -0700, Dan Wing wrote: > But port prediction only works well if the NAT is quiescent. Agreed. > If > you add another user surfing the web, doing BitTorrent, or an > active PVR-like automaton, port prediction becomes fragile and > you will have TCP connections from your intended peer coming > into your other clients. Not necessarily. The particular port prediction I was referring to in this thread is different from the port prediction mentioned in the paper. PP in this Thread: (#1) - NAT has independent mapping. App binds to local port, knows the number of the external port. PP in the Paper: (#2) - To handle NON endpoint independent mapping nats. App binds to port, _finds_ external port by talking to STUNT. Rebinds to same local port, and predicts the new port the (broken) NAT will assign as old port + 1 or something. (#2) is fragile -- if two users initiate a bittorrent connection at the same time, they can interfere with each other. A uses :x, talks to STUNT server, finds out his external port is :x1'. Just then B uses :y, talks to STUNT and gets port :x1'+1. A (incorrectly) predicts his port for the next TCP to be :x1'+1 (#1) is not fragile. Say two users initiate a bittorrent connection at the same time. A uses local port :x and B uses :y. Each independently predicts his external port to :x and :y. No problems here. The only problem is when box A and B uses the _same_ internal port at the _same_ time -- rather unlikely except for applications that bind outbound TCP sockets to a hard-coded local port. So the PP in type #1 is NOT affected by simultaneous BitTorrent/web/PVR/whatever sessions. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00135.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00135.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZnhlSG5GbHRxaTY5MS9vUkFuWUlBSjR6anpVVktkNy8waitTUGlO cEpCdXA2VkJnZGdDZU1seXMKZXptY01jZWNKRHcvdHIzcFRLYXBUVWM9Cj1iUEs0Ci0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Thu, 1 Jun 2006 09:47:16 -0700 (PDT) From: Saikat Guha Date: Thu, 1 Jun 2006 09:47:16 -0700 (PDT) Subject: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for comments on proposals. In-Reply-To: <07db01c68434$a7bcec60$c2f0200a@amer.cisco.com> Message-ID: <1149180434.23856.43.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2006-06-01 at 09:26 -0700, Joe Touch wrote: > Saikat Guha wrote: > The place where this draft refers to the UDP needs to make that > differentiation clear - at what point should NATs handle TCP connections > differently. Or are you saying that NATs should treat TCP the way they > treat UDP, with a 5-minute idle timeout? Timeouts for TCP are a bit more complicated. The draft mentions this in some detail, but you may be working off of a rather old version. UDP timeouts are simple. 5 minutes no traffic, kill connection. Reap mapping once all sessions for that mapping are dead. TCP timeouts are as follows. - TCP pending: at least 4 minutes no traffic, kill connection (MAY) - TCP established: at least 2 hours no traffic, kill connection (MAY) - TCP shutdown: at least 4 minutes no traffic, kill connection (MAY) - TCP RST/reset: up to vendor (explicitly UNSPECIFIED) > -- it's useful to keep in mind that - in general - TCP doesn't 'clean > up' state of old connections until they get in the way of new ones. IMO, > NATs ought to follow that same principle for TCP entries. That was suggested a long time ago. The draft allows for NATs to do just that -- i.e. a NAT MAY or MAY NOT close the connection after it is idle for a while; it may even send a TCP keepalive and await an RST to see if the endpoint crashed. The draft still allows vendors to proactively clean up state, perhaps in preparation for a burst of new connections, if they wish -- one possible definition for "in the way". The draft just sets the minimum values for how long a connection should be held open; the upper bound is for the vendor to decide. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00136.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00136.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFZnhvU25GbHRxaTY5MS9vUkFpZDdBSjl4dWR4QWUzQTRCbFVCRVFJ L2l3dnhMVmNTTEFDZlFlcysKai9kUkVNaTB4clI4Q1dQeFhRK1d6WEE9Cj1MOWFxCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From Internet-Drafts@ietf.org Fri, 2 Jun 2006 12:50:05 -0700 (PDT) From: Internet-Drafts@ietf.org Date: Fri, 2 Jun 2006 12:50:05 -0700 (PDT) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-nat-udp-07.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for Unicast UDP Author(s) : F. Audet, C. Jennings Filename : draft-ietf-behave-nat-udp-07.txt Pages : 29 Date : 2006-6-2 This document defines basic terminology for describing different types of NAT behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or on-line gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-nat-udp-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-nat-udp-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From dwing@cisco.com Tue, 6 Jun 2006 12:17:34 -0700 (PDT) From: "Dan Wing" Date: Tue, 6 Jun 2006 12:17:34 -0700 (PDT) Subject: [Ietf-behave] port preservation In-Reply-To: <1149158380.30805.168.camel@localhost.localdomain> Message-ID: <013701c6899d$dd148c60$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > > As noted above, [Dan's proposal] helps only in some cases, > > but then also requires > > that the TCP use two connections to establish one - where other > > out-of-band coordination could suffice. > > Now that I think about it, Dan's proposal blocks a very time-saving > optimization. A large fraction of NATs are "port preserving" > i.e. If you use internal port :x then the NAT too will use external > Port :x for the mapping (if available). Also, home NATs typically > have one IP address. So an application can opportunistically > predict the mapping it is going to get without ever talking to a > STUNT server!! (Almost 90% of the NATs do this already; see section > 5 in our IMC paper) So, would you recommend that an application be coded expecting this behavior? I wouldn't -- it's too fragile and breaks if there are two active hosts behind that same NAT. By "breaks", I mean that you will have TCP connections going to the wrong host. Note that BEHAVE has a milestone to write a document describing how applications should be coded to work over a NAT -- expecting some kind of port predictability is one of the things we'll have to address in that document. > With this optimization, an endpoint can signal the necessary > address and port information OOB without incurring one RTT to the > public server at connection initiation, and also lessens the load > on the STUNT server. > For home NATs with few active connections through it, such port > prediction will almost always succeed. Yep, if you're not using the NAT too much, I admit this works pretty well. But you can't tell if some other host is using the NAT a lot and consuming those same TCP port numbers. That's the rub. -d From dwing@cisco.com Tue, 6 Jun 2006 12:21:33 -0700 (PDT) From: "Dan Wing" Date: Tue, 6 Jun 2006 12:21:33 -0700 (PDT) Subject: [Ietf-behave] RE: port prediction [was RE: NAT TCP Simultaneous-Open: Requestfor comments on proposals.] In-Reply-To: <1149179783.23856.31.camel@localhost.localdomain> Message-ID: <013f01c6899e$6b982910$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Saikat Guha [mailto:saikat@xxxxxxxxxxxxxx] > Sent: Thursday, June 01, 2006 9:36 AM > To: Dan Wing > Cc: 'Joe Touch'; 'Behave' > Subject: Re: port prediction [was RE: NAT TCP > Simultaneous-Open: Requestfor comments on proposals.] > > On Thu, 2006-06-01 at 08:59 -0700, Dan Wing wrote: > > But port prediction only works well if the NAT is quiescent. > Agreed. > > > If > > you add another user surfing the web, doing BitTorrent, or an > > active PVR-like automaton, port prediction becomes fragile and > > you will have TCP connections from your intended peer coming > > into your other clients. > > Not necessarily. The particular port prediction I was referring to in > this thread is different from the port prediction mentioned in the > paper. > > PP in this Thread: (#1) > - NAT has independent mapping. App binds to local port, knows > the number of the external port. He "knows" this without talking to a STUNT server? If he's not talking to a STUNT server, he's assuming a quiet NAT. That is fragile. > PP in the Paper: (#2) > - To handle NON endpoint independent mapping nats. App binds to port, > _finds_ external port by talking to STUNT. Rebinds to same local > port, and predicts the new port the (broken) NAT will assign as > old port + 1 or something. > > > (#2) is fragile -- if two users initiate a bittorrent > connection at the same time, they can interfere with each other. > A uses :x, talks to STUNT > server, finds out his external port is :x1'. Just then B uses > :y, talks > to STUNT and gets port :x1'+1. A (incorrectly) predicts his > port for the next TCP to be :x1'+1 > > > > (#1) is not fragile. Say two users initiate a bittorrent connection at > the same time. A uses local port :x and B uses :y. Each independently > predicts his external port to :x and :y. No problems here. The only > problem is when box A and B uses the _same_ internal port at > the _same_ > time -- rather unlikely except for applications that bind outbound TCP > sockets to a hard-coded local port. I don't understand or agree with your argument that it's unlikely that two applications will use the same ephemeral source port. Ephemeral ports are assigned by the TCP stack, and unlike ISNs they aren't assigned randomly but rather the first available prot in that stacks ephemeral range is assigned. Thus, if the same two applications are running on the same OS they will both start using the same port source numbers. -d > So the PP in type #1 is NOT affected by simultaneous > BitTorrent/web/PVR/whatever sessions. > > > cheers, > -- > Saikat > From audet@nortel.com Tue, 6 Jun 2006 13:02:41 -0700 (PDT) From: "Francois Audet" Date: Tue, 6 Jun 2006 13:02:41 -0700 (PDT) Subject: RE: [Ietf-behave] port preservation In-Reply-To: <013701c6899d$dd148c60$c2f0200a@amer.cisco.com> Message-ID: <1ECE0EB50388174790F9694F77522CCF0A4C557A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Also, NATs that do these types of tricks are also the ones who tend to be unpredictable (e.g., ones that start off as Indpoint independent and even plain broken, as the number of endpoits trying to use the same port increases). > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wing > Sent: Tuesday, June 06, 2006 12:18 > To: 'Saikat Guha'; 'Joe Touch' > Cc: 'Behave' > Subject: [Ietf-behave] port preservation > > > > > > As noted above, [Dan's proposal] helps only in some cases, > > > but then also requires > > > that the TCP use two connections to establish one - where other > > > out-of-band coordination could suffice. > > > > Now that I think about it, Dan's proposal blocks a very time-saving > > optimization. A large fraction of NATs are "port > preserving" i.e. If > > you use internal port :x then the NAT too will use external Port :x > > for the mapping (if available). Also, home NATs typically > have one IP > > address. So an application can opportunistically predict > the mapping > > it is going to get without ever talking to a STUNT server!! > (Almost > > 90% of the NATs do this already; see section 5 in our IMC paper) > > So, would you recommend that an application be coded > expecting this behavior? I wouldn't -- it's too fragile and > breaks if there are > two active hosts behind that same NAT. By "breaks", I mean > that you will have TCP connections going to the wrong host. > > Note that BEHAVE has a milestone to write a document > describing how applications should be coded to work over a > NAT -- expecting some kind of port predictability is one of > the things we'll have to > address in that document. > > > With this optimization, an endpoint can signal the necessary > > address and port information OOB without incurring one RTT to the > > public server at connection initiation, and also lessens the load > > on the STUNT server. > > For home NATs with few active connections through it, such port > > prediction will almost always succeed. > > Yep, if you're not using the NAT too much, I admit this works > pretty well. > > But you can't tell if some other host is using the NAT a lot > and consuming those same TCP port numbers. That's the rub. > > -d > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From francis@cs.cornell.edu Tue, 6 Jun 2006 15:04:57 -0700 (PDT) From: "Paul Francis" Date: Tue, 6 Jun 2006 15:04:57 -0700 (PDT) Subject: [Ietf-behave] Offpath BoF at Montreal IETF Message-ID: MIME-Version: 1.0 Content-Type: text/plain Gang, The offpath BoF, titled "Path-decoupled Signaling for Data", as been approved for the next IETF. The proposed topic for the BoF is copied below, and is also available at http://www.cs.cornell.edu/people/francis/offpath/. This message is being sent (separately) to the nsis, behave, p2psip, e2e-interest, and ietf mailing lists. The purpose of this message is to solicite feedback about the topics and agenda for the BoF. Note that the immediate goal of the BoF is to create an IRTF research group. Nevertheless, possible alternative goals (i.e. IETF activity) can be discussed. A BoF mailing list has been created (see below). Thanks, PF --------------------------------------------------------------------- Path-decoupled Signaling for Data (offpath) To be held at the 66th (Montreal) IETF, under the auspices of the Transport Area (Lars Eggert), and coordinated with the IRTF (Aaron Falk). BoF Chair: TBD BoF Initiators: Paul Francis and Saikat Guha (both of Cornell University) @cs.cornell.edu General Discussion: off-path-bof@xxxxxxxx To Subscribe: off-path-bof-request@xxxxxxxx In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/off-path-bof/index.html This page at: http://www.cs.cornell.edu/people/francis/offpath Purpose of BoF: Gauge interest in creating an IRTF research group on this topic. Synopsis: Path-decoupled (or off-path) signaling, in the form of SIP, has proven to be a very powerful mechanism for facilitating media connection establishment between hosts. It provides friendly naming, discovery, user mobility, authentication, transport and application negotiation, and even NAT/FW traversal for UDP and, more recently, TCP. Furthermore, it is network independent, working equally well for IPv4 and IPv6. This set of features, however, would be attractive to all types of data sessions, not just media. The purpose of this BoF is to gauge interest in the design of off-path signaling (probably but not necessarily using SIP) for establishing all kinds of non-public-server data sessions. A positive outcome of this BoF would be the formation of an IRTF group, though other outcomes will of course be considered. We are particularly interested in models of off-path signaling that improve security beyond today's address/port/deep-inspection model. The use of path-decoupled signaling gives both the middle and the ends the opportunity to assert policy and negotiate an acceptable session. We would like to explore cases where the off-path signaling operates alone (i.e. NAT/FW traversal with legacy NAT/FW's), as well as where it operates in conjunction with subsequent path-coupled signaling (either in-band or out-of-band). Considering that an application can always lie about what it is, we would also like to explore how to couple the signaling primitives with emerging OS security features (i.e. trusted computing platforms). Beyond security, we would like to explore the use of off-path signaling for such features as user and host mobility, transport negotiation (i.e. TCP versus SCTP), anycast and multicast, billing, and time-delayed communications messaging). The ultimate goal here is that some or all of these features become part of the standard sockets API of typical OS's, and that infrastructure support for the signaling becomes ubiquitous (in the same sense that DNS is ubiquitous). This would allow application developers, security vendors (middlebox and endhost), users, and network administrators to converge on a unified method of naming and connection establishment over the Internet. (By contrast, naming and connection establishment through NATs and firewalls today is ad hoc and usually application specific, variously involving email, IM services, dynamic DNS services, manual configuration of ports, and so on.) Of the IETF working groups, this BoF is most closely aligned with the nsis WG in the Transport Area, especially the NAT/FW NSLP. The following gives an example of how an off-path signaling protocol would work in conjunction with the NAT/FW NSLP. This is only an example...there are other approaches and variants on this example. Say an application wishes to establish a TCP connection with a "peer", where both peers are behind NAT/FW's. The initiating peer off-path signals a connection request. The request contains the application name, user names, authentication information (Certs or Diameter), and information about the preferred transport (TCP, SSL, IPSec, etc.). The off-path request is checked by the initiating endhost's policy, and then flows through policy boxes representing the initiator's and the recipient's networks. This gives both sides an opportunity to reject the request, or to request different transport or security characteristics, or to accept and pass on the request as-is. Note that the policy boxes could both be far from either ends' physical network, thus not revealing the IP addresses of either end until the connection is approved. The policy boxes could also be widely replicated. Assuming the connection request is approved, the endhosts use the NAT/FW NSLP to obtain address and port mappings from their respective NAT boxes. These are conveyed through the off-path signaling channel. In addition, the policy boxes create secure tokens that firewalls can use to allow the approved connection. These tokens are passed to the endhosts through off-path signaling, which then convey them on-path, either in-band or out-of-band (i.e. the NAT/FW NSLP), to traverse the firewall. Supporting material: http://nutss.gforge.cis.cornell.edu/ From saikat@cs.cornell.edu Wed, 7 Jun 2006 01:51:49 -0700 (PDT) From: Saikat Guha Date: Wed, 7 Jun 2006 01:51:49 -0700 (PDT) Subject: [Ietf-behave] Re: port preservation In-Reply-To: <013701c6899d$dd148c60$c2f0200a@amer.cisco.com> Message-ID: <1149670307.23856.282.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2006-06-06 at 12:17 -0700, Dan Wing wrote: > > Now that I think about it, Dan's proposal blocks a very time-saving > > optimization. A large fraction of NATs are "port preserving" > > i.e. If you use internal port :x then the NAT too will use external > > Port :x for the mapping (if available). Also, home NATs typically > > have one IP address. So an application can opportunistically > > predict the mapping it is going to get without ever talking to a > > STUNT server!! (Almost 90% of the NATs do this already; see section > > 5 in our IMC paper) > > So, would you recommend that an application be coded expecting this > behavior? I wouldn't -- it's too fragile and breaks if there are > two active hosts behind that same NAT. By "breaks", I mean that > you will have TCP connections going to the wrong host. Certainly an application shouldn't require it, but the likelihood of having TCP go to the wrong host depends on the application. Skype, for example, randomly picks a source port at time of installation and always uses that source port. Therefore it would be very unlikely for two Skype clients behind a NAT to collide. In any case, as with other NAT traversal mechanisms, there needs to be a final verification of the data-path (after it is established) to ensure that you have the right guy. ICE/STUN do this with a nonce that is sent along the signaling-path and echoed back on-path. > Note that BEHAVE has a milestone to write a document describing how > applications should be coded to work over a NAT -- expecting some > kind of port predictability is one of the things we'll have to > address in that document. Port-prediction is an optimization that can cause (fixable) problems if the prediction is incorrect. The behave-app document should mention this. > But you can't tell if some other host is using the NAT a lot > and consuming those same TCP port numbers. That's the rub. True, you cannot tell until after the TCP is established and you verify the nonces; by then you have already incurred a few RTTs and need to restart the procedure sans port-prediction. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00137.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00137.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFaHBPam5GbHRxaTY5MS9vUkFpbFRBSjlUVW5pZUY4aUFwdVhmYVlB V1hMdUFpcXAvcGdDZmRYQjUKQmU1QWZSM2kxQzA2cTN6T2lIeDZhRVU9Cj1mNG5VCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From spencer@mcsr-labs.org Wed, 7 Jun 2006 04:54:34 -0700 (PDT) From: "Spencer Dawkins" Date: Wed, 7 Jun 2006 04:54:34 -0700 (PDT) Subject: Re: [Ietf-behave] Re: port preservation In-Reply-To: <013701c6899d$dd148c60$c2f0200a@amer.cisco.com> Message-ID: <12df01c68a29$182c3380$0700a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain Re: Skype picking a random port number at installation time and using it for every connection, to reduce the chances of collisions behind a NAT... - I wish we could provide meaningful BCP guidance to application developers about this, and - I wish we had discussions about the Birthday problem about that guidance (the problem isn't that someone collides with YOU, 1/65K, it's that someone collides with anyone else also behind the NAT, which is a lot bigger problem). Thanks, Spencer From audet@nortel.com Wed, 7 Jun 2006 09:06:27 -0700 (PDT) From: "Francois Audet" Date: Wed, 7 Jun 2006 09:06:27 -0700 (PDT) Subject: RE: [Ietf-behave] Re: port preservation In-Reply-To: <1149670307.23856.282.camel@localhost.localdomain> Message-ID: <1ECE0EB50388174790F9694F77522CCF0A566260@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Are you talking about port prediction in the App, as opposed to port preservation in the NAT, or both? > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Wednesday, June 07, 2006 01:52 > To: Dan Wing > Cc: 'Behave'; 'Joe Touch' > Subject: [Ietf-behave] Re: port preservation > > > On Tue, 2006-06-06 at 12:17 -0700, Dan Wing wrote: > > > Now that I think about it, Dan's proposal blocks a very > time-saving > > > optimization. A large fraction of NATs are "port > preserving" i.e. > > > If you use internal port :x then the NAT too will use > external Port > > > :x for the mapping (if available). Also, home NATs > typically have > > > one IP address. So an application can opportunistically > predict the > > > mapping it is going to get without ever talking to a > STUNT server!! > > > (Almost 90% of the NATs do this already; see section 5 in our IMC > > > paper) > > > > So, would you recommend that an application be coded expecting this > > behavior? I wouldn't -- it's too fragile and breaks if > there are two > > active hosts behind that same NAT. By "breaks", I mean > that you will > > have TCP connections going to the wrong host. > > Certainly an application shouldn't require it, but the > likelihood of having TCP go to the wrong host depends on the > application. > > Skype, for example, randomly picks a source port at time of > installation and always uses that source port. Therefore it > would be very unlikely for two Skype clients behind a NAT to collide. > > In any case, as with other NAT traversal mechanisms, there > needs to be a final verification of the data-path (after it > is established) to ensure that you have the right guy. > ICE/STUN do this with a nonce that is sent along the > signaling-path and echoed back on-path. > > > > Note that BEHAVE has a milestone to write a document describing how > > applications should be coded to work over a NAT -- > expecting some kind > > of port predictability is one of the things we'll have to > address in > > that document. > > Port-prediction is an optimization that can cause (fixable) > problems if the prediction is incorrect. The behave-app > document should mention this. > > > But you can't tell if some other host is using the NAT a lot and > > consuming those same TCP port numbers. That's the rub. > > True, you cannot tell until after the TCP is established and > you verify the nonces; by then you have already incurred a > few RTTs and need to restart the procedure sans port-prediction. > > -- > Saikat > From dwing@cisco.com Wed, 7 Jun 2006 09:42:04 -0700 (PDT) From: "Dan Wing" Date: Wed, 7 Jun 2006 09:42:04 -0700 (PDT) Subject: [Ietf-behave] RE: port preservation In-Reply-To: <1149670307.23856.282.camel@localhost.localdomain> Message-ID: <05fa01c68a51$4afc4a70$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > > So, would you recommend that an application be coded expecting this > > behavior? I wouldn't -- it's too fragile and breaks if there are > > two active hosts behind that same NAT. By "breaks", I mean that > > you will have TCP connections going to the wrong host. > > Certainly an application shouldn't require it, but the likelihood of > having TCP go to the wrong host depends on the application. > > Skype, for example, randomly picks a source port at time of > installation and always uses that source port. Therefore it > would be very unlikely for two Skype clients behind a NAT to > collide. But with that implementation you have another problem -- once they do collide, they will continue to collide until you uninstall and re-install Skype on one of those boxes, replace your Skype hardphone, or something functionally identical to those operations. There are, of course, other applications running on other hosts behind the NAT -- PVR applications, refigerators communicating with the local grocery store, web surfing, and so on. Any one of those might also choose that same port as a normal function of its operation. Large ISPs, such as a cable company in Germany that I know about and, supposedly, some ISPs in Korea, don't give their users real IP addresses but rather give their users private IP addresses. There is a high chance that ephemeral ports in those situations will already be allocated to other subscribers -- those NATs are _very_ busy. > In any case, as with other NAT traversal mechanisms, there > needs to be a final verification of the data-path (after it > is established) to ensure that you have the right guy. > ICE/STUN do this with a nonce that is sent along the > signaling-path and echoed back on-path. Yep, I agree that some kind of nonce is necessary. > > Note that BEHAVE has a milestone to write a document describing how > > applications should be coded to work over a NAT -- expecting some > > kind of port predictability is one of the things we'll have to > > address in that document. > > Port-prediction is an optimization that can cause (fixable) > problems if the prediction is incorrect. I can see how to detect you're talking to the wrong peer -- he doesn't echo back the correct nonce or doesn't echo back a nonce at all (timeout or runs a different protocol on the port you happened to connect with). > The behave-app document should mention this. > > > But you can't tell if some other host is using the NAT a lot > > and consuming those same TCP port numbers. That's the rub. > > True, you cannot tell until after the TCP is established and > you verify > the nonces; by then you have already incurred a few RTTs and need to > restart the procedure sans port-prediction. Ah, so that's what you mean by 'fixable'. -d From dwing@cisco.com Wed, 7 Jun 2006 09:42:35 -0700 (PDT) From: "Dan Wing" Date: Wed, 7 Jun 2006 09:42:35 -0700 (PDT) Subject: RE: [Ietf-behave] Re: port preservation In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0A566260@zrc2hxm0.corp.nortel.com> Message-ID: <05fd01c68a51$5bcbba20$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Are you talking about port prediction in the App, as opposed to > port preservation in the NAT, or both? Saikat is assuming the NAT does port preservation. -d From audet@nortel.com Wed, 7 Jun 2006 09:56:00 -0700 (PDT) From: "Francois Audet" Date: Wed, 7 Jun 2006 09:56:00 -0700 (PDT) Subject: RE: [Ietf-behave] Re: port preservation In-Reply-To: <05fd01c68a51$5bcbba20$c2f0200a@amer.cisco.com> Message-ID: <1ECE0EB50388174790F9694F77522CCF0A5663A0@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain This is not a good assumption at all. > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Wednesday, June 07, 2006 09:42 > To: Audet, Francois [SC100:3055:EXCH]; 'Saikat Guha' > Cc: 'Behave'; 'Joe Touch' > Subject: RE: [Ietf-behave] Re: port preservation > > > > Are you talking about port prediction in the App, as opposed to > > port preservation in the NAT, or both? > > Saikat is assuming the NAT does port preservation. > > -d > > From dwing@cisco.com Wed, 7 Jun 2006 10:08:43 -0700 (PDT) From: "Dan Wing" Date: Wed, 7 Jun 2006 10:08:43 -0700 (PDT) Subject: RE: [Ietf-behave] Re: port preservation In-Reply-To: <12df01c68a29$182c3380$0700a8c0@china.huawei.com> Message-ID: <064501c68a55$037dff00$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Re: Skype picking a random port number at installation time > and using it for every connection, to reduce the chances of > collisions behind a NAT... > > - I wish we could provide meaningful BCP guidance to > application developers about this, and > > - I wish we had discussions about the Birthday problem about > that guidance (the problem isn't that someone collides with YOU, > 1/65K, it's that someone collides with anyone else also behind > the NAT, which is a lot bigger problem). I agree with both your points. The BEHAVE how-to-write-applications-for-BEHAVE-NATs document, which has been one of our milestones for awhile, is the best place for such guidance and discussion, I think. We don't yet have a WG document for this milestone, although draft-ford-behave-app-02.txt might be close. -d From saikat@cs.cornell.edu Wed, 7 Jun 2006 15:05:49 -0700 (PDT) From: Saikat Guha Date: Wed, 7 Jun 2006 15:05:49 -0700 (PDT) Subject: RE: [Ietf-behave] Re: port preservation In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0A5663A0@zrc2hxm0.corp.nortel.com> Message-ID: <1149717947.23856.293.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-06-07 at 11:55 -0500, Francois Audet wrote: > > -----Original Message----- > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > Saikat is assuming the NAT does port preservation. > > This is not a good assumption at all. Not a good assumption by any stretch of imagination, no. Nevertheless, about 60% of the NATs afford this luxury. That said, the original discussion was of whether it is reasonable to require that an application _MUST_ perform a STUNT lookup before S-O is allowed to work. The argument here is that a STUNT lookup before being able to invoke a TCP S-O should not be a MUST. Advisable or not, exploiting port preservation opportunistically is one example why; there may be others. I agree with Dan that the behave-app document should point out the potential pitfalls of this particular assumption. But more on topic of the possible alternatives to REQ-4 in the TCP draft (about how to handle unsolicited SYNs that may or may not be part of a S-O) ... I'll include Dan's proposal with the other ones and flag it as an OPEN ISSUE. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00138.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00138.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFaDAyN25GbHRxaTY5MS9vUkFwTmpBSjR5N2dvSFJwek5KUmpSRVNq clY4eUZuVTFxeWdDY0RmRzcKa2Z2Y1FRMThmNTdoWVpHZkVpT1p5ZVE9Cj15WHlDCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From touch@ISI.EDU Wed, 7 Jun 2006 16:01:29 -0700 (PDT) From: Joe Touch Date: Wed, 7 Jun 2006 16:01:29 -0700 (PDT) Subject: Re: [Ietf-behave] Re: port preservation In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0A5663A0@zrc2hxm0.corp.nortel.com> Message-ID: <44875956.3020503@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Saikat Guha wrote: > On Wed, 2006-06-07 at 11:55 -0500, Francois Audet wrote: >>> -----Original Message----- >>> From: Dan Wing [mailto:dwing@xxxxxxxxx] >>> >>> Saikat is assuming the NAT does port preservation. >> This is not a good assumption at all. > > Not a good assumption by any stretch of imagination, no. Nevertheless, > about 60% of the NATs afford this luxury. > > That said, the original discussion was of whether it is reasonable to > require that an application _MUST_ perform a STUNT lookup before S-O is > allowed to work. The argument here is that a STUNT lookup before being > able to invoke a TCP S-O should not be a MUST. Advisable or not, > exploiting port preservation opportunistically is one example why; there > may be others. My interpretation of this thread is that: an app MUST perform a STUNT before S-O reliably works That doesn't prohibit alternatives that don't reliably work. It does say that an app that needs S-O to work MUST do a STUNT to know that it will succeed (again, if I follow the thread right). Joe Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00139.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00139.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVoMWxXRTVmNWNJbW5acnNSQXVSRkFKNG1tMjc4eWFFUm9mZ20x ME15ZkNJZTdRYXpZZ0NmZldXRgpyYVB4ODg2b2xDQ0lrYzZSMFExZjEwbz0KPWJya1oKLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Wed, 7 Jun 2006 16:16:10 -0700 (PDT) From: Saikat Guha Date: Wed, 7 Jun 2006 16:16:10 -0700 (PDT) Subject: Re: [Ietf-behave] Re: port preservation In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0A5663A0@zrc2hxm0.corp.nortel.com> Message-ID: <1149722169.23856.328.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-06-07 at 15:55 -0700, Joe Touch wrote: > > My interpretation of this thread is that: > > an app MUST perform a STUNT before S-O reliably works Agreed. Along the same line, the proposal to send back an instant-RST if a STUNT hasn't been performed would roughly be: unless an app performs STUNT, S-O will not be possible (although you could say that the first failed S-O attempt could be made to look like a STUNT to the NAT so the second attempt succeeds. That would require mandating how the NAT treats the RST, which the proposal doesn't cover yet.) > That doesn't prohibit alternatives that don't reliably work. I could be mistaken here, but if I understand Dan's original proposal correctly, it _would prohibit_ the unreliable port-preservation approach mentioned earlier in this thread. -- Saikat (who is slowly getting confused with all the double negatives) Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00140.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00140.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFaDE0NW5GbHRxaTY5MS9vUkF0WUpBSjQwTFR3OEoxZkxEczNnVXJm b2pUdGowczVWbHdDZVBLbmIKMG44c2gyN0xJTHM0WUJpdmh4am5TaGM9Cj1XWkd2Ci0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From rrg@avaya.com Wed, 7 Jun 2006 16:22:28 -0700 (PDT) From: "Robert R. Gilman" Date: Wed, 7 Jun 2006 16:22:28 -0700 (PDT) Subject: Re: [Ietf-behave] RE: port preservation In-Reply-To: <05fa01c68a51$4afc4a70$c2f0200a@amer.cisco.com> Message-ID: <44875FAD.5010005@avaya.com> MIME-Version: 1.0 Content-Type: text/plain I'd think that a practical port-preserving NAT would require a new ICMP message, e.g. "port already in use", to inform the transport layer to try some other source port. Perhaps it could suggest an available port; even so, it might take some time to find one common to the host and the NAT before a packet went through the NAT. How much code would have to be modified to do this? :-) -Bob ---------------------------------------------------- Bob Gilman rrg@xxxxxxxxx +1 303 538 3868 Dan Wing wrote: So, would you recommend that an application be coded expecting this behavior? I wouldn't -- it's too fragile and breaks if there are two active hosts behind that same NAT. By "breaks", I mean that you will have TCP connections going to the wrong host. Certainly an application shouldn't require it, but the likelihood of having TCP go to the wrong host depends on the application. Skype, for example, randomly picks a source port at time of installation and always uses that source port. Therefore it would be very unlikely for two Skype clients behind a NAT to collide. But with that implementation you have another problem -- once they do collide, they will continue to collide until you uninstall and re-install Skype on one of those boxes, replace your Skype hardphone, or something functionally identical to those operations. There are, of course, other applications running on other hosts behind the NAT -- PVR applications, refigerators communicating with the local grocery store, web surfing, and so on. Any one of those might also choose that same port as a normal function of its operation. Large ISPs, such as a cable company in Germany that I know about and, supposedly, some ISPs in Korea, don't give their users real IP addresses but rather give their users private IP addresses. There is a high chance that ephemeral ports in those situations will already be allocated to other subscribers -- those NATs are _very_ busy. In any case, as with other NAT traversal mechanisms, there needs to be a final verification of the data-path (after it is established) to ensure that you have the right guy. ICE/STUN do this with a nonce that is sent along the signaling-path and echoed back on-path. Yep, I agree that some kind of nonce is necessary. Note that BEHAVE has a milestone to write a document describing how applications should be coded to work over a NAT -- expecting some kind of port predictability is one of the things we'll have to address in that document. Port-prediction is an optimization that can cause (fixable) problems if the prediction is incorrect. I can see how to detect you're talking to the wrong peer -- he doesn't echo back the correct nonce or doesn't echo back a nonce at all (timeout or runs a different protocol on the port you happened to connect with). The behave-app document should mention this. But you can't tell if some other host is using the NAT a lot and consuming those same TCP port numbers. That's the rub. True, you cannot tell until after the TCP is established and you verify the nonces; by then you have already incurred a few RTTs and need to restart the procedure sans port-prediction. Ah, so that's what you mean by 'fixable'. -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From audet@nortel.com Wed, 7 Jun 2006 16:27:09 -0700 (PDT) From: "Francois Audet" Date: Wed, 7 Jun 2006 16:27:09 -0700 (PDT) Subject: RE: [Ietf-behave] Re: port preservation In-Reply-To: <1149717947.23856.293.camel@localhost.localdomain> Message-ID: <1ECE0EB50388174790F9694F77522CCF0A566B91@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain OK, I think I get it. You want some optimization for cases when port preservation is done, right > -----Original Message----- > From: Saikat Guha [mailto:saikat@xxxxxxxxxxxxxx] > Sent: Wednesday, June 07, 2006 15:06 > To: Audet, Francois [SC100:3055:EXCH] > Cc: Dan Wing; Behave; Joe Touch > Subject: RE: [Ietf-behave] Re: port preservation > > > On Wed, 2006-06-07 at 11:55 -0500, Francois Audet wrote: > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > > > Saikat is assuming the NAT does port preservation. > > > > This is not a good assumption at all. > > Not a good assumption by any stretch of imagination, no. > Nevertheless, about 60% of the NATs afford this luxury. > > That said, the original discussion was of whether it is > reasonable to require that an application _MUST_ perform a > STUNT lookup before S-O is allowed to work. The argument here > is that a STUNT lookup before being able to invoke a TCP S-O > should not be a MUST. Advisable or not, exploiting port > preservation opportunistically is one example why; there may > be others. > > I agree with Dan that the behave-app document should point > out the potential pitfalls of this particular assumption. But > more on topic of the possible alternatives to REQ-4 in the > TCP draft (about how to handle unsolicited SYNs that may or > may not be part of a S-O) ... I'll include Dan's proposal > with the other ones and flag it as an OPEN ISSUE. > > cheers, > -- > Saikat > From touch@ISI.EDU Wed, 7 Jun 2006 16:27:59 -0700 (PDT) From: Joe Touch Date: Wed, 7 Jun 2006 16:27:59 -0700 (PDT) Subject: Re: [Ietf-behave] RE: port preservation In-Reply-To: <05fa01c68a51$4afc4a70$c2f0200a@amer.cisco.com> Message-ID: <448760C4.80605@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Robert R. Gilman wrote: > I'd think that a practical port-preserving NAT would require a new > ICMP message, e.g. "port already in use", to inform the transport > layer to try some other source port. IMO, that's an existing 'port unreachable' message. There is - and should be - no reason why the port is unreachable indicated. > Perhaps it could suggest an > available port; even so, it might take some time to find one common > to the host and the NAT before a packet went through the NAT. > How much code would have to be modified to do this? :-) I would be very wary of an ICMP solution that suggested alternate ways around a port that was not available. That's too much of an opportunity for attack, IMO. Joe > -Bob > ---------------------------------------------------- > Bob Gilman rrg@xxxxxxxxx +1 303 538 3868 > > Dan Wing wrote: >>>> So, would you recommend that an application be coded expecting this >>>> behavior? I wouldn't -- it's too fragile and breaks if there are >>>> two active hosts behind that same NAT. By "breaks", I mean that >>>> you will have TCP connections going to the wrong host. >>> >>> Certainly an application shouldn't require it, but the likelihood of >>> having TCP go to the wrong host depends on the application. >>> >>> Skype, for example, randomly picks a source port at time of >>> installation and always uses that source port. Therefore it would be >>> very unlikely for two Skype clients behind a NAT to collide. >> >> >> But with that implementation you have another problem -- once they do >> collide, they will continue to collide until you uninstall and >> re-install Skype on one of those boxes, replace your Skype hardphone, >> or something functionally identical to >> those operations. >> >> There are, of course, other applications running on other >> hosts behind the NAT -- PVR applications, refigerators communicating >> with the local grocery store, web surfing, >> and so on. Any one of those might also choose that same >> port as a normal function of its operation. >> >> Large ISPs, such as a cable company in Germany that I know >> about and, supposedly, some ISPs in Korea, don't give their >> users real IP addresses but rather give their users private >> IP addresses. There is a high chance that ephemeral ports >> in those situations will already be allocated to other >> subscribers -- those NATs are _very_ busy. >> >> >>> In any case, as with other NAT traversal mechanisms, there needs to >>> be a final verification of the data-path (after it is established) to >>> ensure that you have the right guy. ICE/STUN do this with a nonce >>> that is sent along the signaling-path and echoed back on-path. >> >> >> Yep, I agree that some kind of nonce is necessary. >> >> >>>> Note that BEHAVE has a milestone to write a document describing how >>>> applications should be coded to work over a NAT -- expecting some >>>> kind of port predictability is one of the things we'll have to >>>> address in that document. >>> >>> Port-prediction is an optimization that can cause (fixable) problems >>> if the prediction is incorrect. >> >> >> I can see how to detect you're talking to the wrong peer -- he >> doesn't echo back the correct nonce or doesn't echo back a nonce >> at all (timeout or runs a different protocol on the port you >> happened to connect with). >> >> >>> The behave-app document should mention this. >>> >>> >>>> But you can't tell if some other host is using the NAT a lot >>>> and consuming those same TCP port numbers. That's the rub. >>> >>> True, you cannot tell until after the TCP is established and you verify >>> the nonces; by then you have already incurred a few RTTs and need to >>> restart the procedure sans port-prediction. >> >> >> Ah, so that's what you mean by 'fixable'. >> -d >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@xxxxxxxxxxxxxxxxxxx >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00141.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00141.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVoMkRJRTVmNWNJbW5acnNSQXQ0NUFKNHYxNGRUYUs1Szd0RWts STBOT244L3lySjVpQUNndG1sNApicHlTMm9ERGswcUNIOFN1aE1MSmVhdz0KPWgrZVcKLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From zhouhong@huawei.com Wed, 7 Jun 2006 19:30:48 -0700 (PDT) From: Harrison Zhou Date: Wed, 7 Jun 2006 19:30:48 -0700 (PDT) Subject: [Ietf-behave] RE: [Sip] outbound-keepalive question In-Reply-To: <8A0592DF-8999-441C-BE99-4A9335A8E4C6@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi, My question's true intent is: can we send Binding Requests using TCP or TLS in Outbound. Because rfc3489bis-03 doesn't say " Binding Requests, sent over TCP or TLS" and it only says " Binding Requests, sent over UDP". Regards, Hong -----Original Message----- From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] Sent: Wednesday, June 07, 2006 10:37 PM To: zhou hong Cc: sip@xxxxxxxx Subject: Re: [Sip] outbound-keepalive question On Jun 5, 2006, at 6:51 PM, zhou hong wrote: > But in draft-ietf-behave-rfc3489bis-03 says " There are two types of > requests defined in this specification - Binding Requests, sent over > UDP, and Shared Secret Requests, sent over TLS [6] over TCP ". I think that outbound would not us the shared secret requests. Other STUN usages might. From dwing@cisco.com Wed, 7 Jun 2006 22:54:34 -0700 (PDT) From: "Dan Wing" Date: Wed, 7 Jun 2006 22:54:34 -0700 (PDT) Subject: RE: [Ietf-behave] RE: [Sip] outbound-keepalive question In-Reply-To: Message-ID: <042601c68ac0$04657630$95ab6b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > My question's true intent is: can we send Binding Requests > using TCP or TLS in Outbound. Because rfc3489bis-03 doesn't say > "Binding Requests, sent over TCP or TLS" and it only says " Binding > Requests, sent over UDP". Consensus at the Dallas IETF SIP meeting was to send STUN over TCP connections, too. . -behave-rfc3489bis- hasn't been updated since that meeting. Reference http://www3.ietf.org/proceedings/06mar/minutes/sip.txt which says: ... Proposal: Do STUN for TCP and UDP Do CRLF for TCP and STUN for UDP TCP KeepAlive if supported, 1 or 2 otherwise Resolutions: OS TCP KeepAlive should be used if the client supports it. Need something more because OS TCP KeepAlive is not supported in every client OS. Consensus to use STUN for UDP Consensus to use STUN for TCP, with use of OS TCP keep alive above. ... -d From dhudson@ubicom.com Thu, 8 Jun 2006 02:48:08 -0700 (PDT) From: "Dave Hudson" Date: Thu, 8 Jun 2006 02:48:08 -0700 (PDT) Subject: RE: [Ietf-behave] RE: port preservation In-Reply-To: <05fa01c68a51$4afc4a70$c2f0200a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain UDP P2P apps are an interesting class of application that benefit from port preservation (where possible). If a NAT gets restarted the preservation of port mappings means that external hosts are far less likely to send packets that get dropped by the NAT (assuming a local host re-establishes the original binding - quite likely if there aren't many hosts behind the NAT). In situations where there's a port clash as long as the second host establishes a new random binding that maintains that binding consistently then we end up with behaviour identical to a non port-preserving NAT that randomly picked the same port number for the first local client. FWIW my experiences with building and testing SOHO NATs is that port preservation generally gives a better end-user experience as more applications tend to "just work" and not require either ALGs or users to configure things such as port forwarding rules or DMZ host features that effectively do nothing but guarantee port preservation, but do so with considerable security problems. Clearly for a NAT with a large number of hosts behind it these advantages rapidly diminish because there's a much higher probability of port collisions but for NATs supporting small numbers of hosts these advantages shouldn't be dismissed (since at the worst we end up with a NAT that maintains consistent mappings still). I would definitely agree that applications shouldn't be coded to expect this sort of behaviour but there are a lot of apps around that already do make these sorts of assumptions (it's really dismaying how many games expect well-known ports if you wish to host a game server or P2P apps if you want them to work properly). Regards, Dave * -----Original Message----- * From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx * [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wing * Sent: 07 June 2006 17:42 * To: 'Saikat Guha' * Cc: 'Behave'; 'Joe Touch' * Subject: [Ietf-behave] RE: port preservation * * > > So, would you recommend that an application be coded * expecting this * > > behavior? I wouldn't -- it's too fragile and breaks if there are * > > two active hosts behind that same NAT. By "breaks", I * mean that you * > > will have TCP connections going to the wrong host. * > * > Certainly an application shouldn't require it, but the * likelihood of * > having TCP go to the wrong host depends on the application. * > * > Skype, for example, randomly picks a source port at time of * > installation and always uses that source port. Therefore * it would be * > very unlikely for two Skype clients behind a NAT to collide. * * But with that implementation you have another problem -- once * they do collide, they will continue to collide until you * uninstall and re-install Skype on one of those boxes, replace * your Skype hardphone, or something functionally identical to * those operations. * * There are, of course, other applications running on other * hosts behind the NAT -- PVR applications, refigerators * communicating with the local grocery store, web surfing, and * so on. Any one of those might also choose that same port as * a normal function of its operation. * * Large ISPs, such as a cable company in Germany that I know * about and, supposedly, some ISPs in Korea, don't give their * users real IP addresses but rather give their users private * IP addresses. There is a high chance that ephemeral ports in * those situations will already be allocated to other * subscribers -- those NATs are _very_ busy. * * > In any case, as with other NAT traversal mechanisms, there * needs to be * > a final verification of the data-path (after it is established) to * > ensure that you have the right guy. * > ICE/STUN do this with a nonce that is sent along the signaling-path * > and echoed back on-path. * * Yep, I agree that some kind of nonce is necessary. * * > > Note that BEHAVE has a milestone to write a document * describing how * > > applications should be coded to work over a NAT -- expecting some * > > kind of port predictability is one of the things we'll have to * > > address in that document. * > * > Port-prediction is an optimization that can cause (fixable) * problems * > if the prediction is incorrect. * * I can see how to detect you're talking to the wrong peer -- * he doesn't echo back the correct nonce or doesn't echo back a * nonce at all (timeout or runs a different protocol on the * port you happened to connect with). * * > The behave-app document should mention this. * > * > > But you can't tell if some other host is using the NAT a lot and * > > consuming those same TCP port numbers. That's the rub. * > * > True, you cannot tell until after the TCP is established and you * > verify the nonces; by then you have already incurred a few RTTs and * > need to restart the procedure sans port-prediction. * * Ah, so that's what you mean by 'fixable'. * * -d * _______________________________________________ * Ietf-behave mailing list * Ietf-behave@xxxxxxxxxxxxxxxxxxx * https://list.sipfoundry.org/mailman/listinfo/ietf-behave * * From rrg@avaya.com Thu, 8 Jun 2006 08:35:57 -0700 (PDT) From: "Robert R. Gilman" Date: Thu, 8 Jun 2006 08:35:57 -0700 (PDT) Subject: Re: [Ietf-behave] RE: port preservation In-Reply-To: <05fa01c68a51$4afc4a70$c2f0200a@amer.cisco.com> Message-ID: <448843D5.7010203@avaya.com> MIME-Version: 1.0 Content-Type: text/plain Joe- The messages refer to different ports: the "port unreachable" is a destination port; the "port already in use" is the 'source' port, which is to be 'replicated' by the NAT. The two conditions require much different responses from the host, and I didn't see an obvious way to get both meanings out of the existing "port unreachable" message. -Bob ---------------------------------------------------- Bob Gilman rrg@xxxxxxxxx +1 303 538 3868 Joe Touch wrote: Robert R. Gilman wrote: I'd think that a practical port-preserving NAT would require a new ICMP message, e.g. "port already in use", to inform the transport layer to try some other source port. IMO, that's an existing 'port unreachable' message. There is - and should be - no reason why the port is unreachable indicated. [rrg]: That's why I suggested a new message. Perhaps it could suggest an available port; even so, it might take some time to find one common to the host and the NAT before a packet went through the NAT. How much code would have to be modified to do this? :-) I would be very wary of an ICMP solution that suggested alternate ways around a port that was not available. That's too much of an opportunity for attack, IMO. [rrg]: I'm not sure I see the attack you do. Are you thinking of a DoS attack in which the attacker returns ICMP "port unavailable" messages to cause the host to retry on another port, ad nauseam? It seems to me the "port unreachable" will have the same effect (with only one fake message required.) Joe -Bob ---------------------------------------------------- Bob Gilman rrg@xxxxxxxxx +1 303 538 3868 Dan Wing wrote: So, would you recommend that an application be coded expecting this behavior? I wouldn't -- it's too fragile and breaks if there are two active hosts behind that same NAT. By "breaks", I mean that you will have TCP connections going to the wrong host. Certainly an application shouldn't require it, but the likelihood of having TCP go to the wrong host depends on the application. Skype, for example, randomly picks a source port at time of installation and always uses that source port. Therefore it would be very unlikely for two Skype clients behind a NAT to collide. But with that implementation you have another problem -- once they do collide, they will continue to collide until you uninstall and re-install Skype on one of those boxes, replace your Skype hardphone, or something functionally identical to those operations. There are, of course, other applications running on other hosts behind the NAT -- PVR applications, refigerators communicating with the local grocery store, web surfing, and so on. Any one of those might also choose that same port as a normal function of its operation. Large ISPs, such as a cable company in Germany that I know about and, supposedly, some ISPs in Korea, don't give their users real IP addresses but rather give their users private IP addresses. There is a high chance that ephemeral ports in those situations will already be allocated to other subscribers -- those NATs are _very_ busy. In any case, as with other NAT traversal mechanisms, there needs to be a final verification of the data-path (after it is established) to ensure that you have the right guy. ICE/STUN do this with a nonce that is sent along the signaling-path and echoed back on-path. Yep, I agree that some kind of nonce is necessary. Note that BEHAVE has a milestone to write a document describing how applications should be coded to work over a NAT -- expecting some kind of port predictability is one of the things we'll have to address in that document. Port-prediction is an optimization that can cause (fixable) problems if the prediction is incorrect. I can see how to detect you're talking to the wrong peer -- he doesn't echo back the correct nonce or doesn't echo back a nonce at all (timeout or runs a different protocol on the port you happened to connect with). The behave-app document should mention this. But you can't tell if some other host is using the NAT a lot and consuming those same TCP port numbers. That's the rub. True, you cannot tell until after the TCP is established and you verify the nonces; by then you have already incurred a few RTTs and need to restart the procedure sans port-prediction. Ah, so that's what you mean by 'fixable'. -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From touch@ISI.EDU Thu, 8 Jun 2006 09:06:44 -0700 (PDT) From: Joe Touch Date: Thu, 8 Jun 2006 09:06:44 -0700 (PDT) Subject: Re: [Ietf-behave] RE: port preservation In-Reply-To: <05fa01c68a51$4afc4a70$c2f0200a@amer.cisco.com> Message-ID: <44884AD7.3060805@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit I'm not sure it matters that this is a source port issue. According to RFC1122: 3 (Port Unreachable), when the designated transport protocol (e.g., UDP) is unable to demultiplex the datagram but has no protocol mechanism to inform the sender. "Unable to demux" is what the NAT is experiencing; IMO, it is acting as a host at this point (it's looking at the port numbers), so port unreachable is the best error to provide. Another option is reply with a TCP RST to that connection - which is what would happen if this were a conventional host and such a collision occurred. If either response seems cryptic, then you could also send an error indicating that the destination service is unreachable given the parameters of the packet, in which case you can use pointer-error (Code 12, Type 0), and point to the source port. There's no other fundamental "reason" to deny a particular source port so I wouldn't suggest a new ICMP error number for this. Joe Robert R. Gilman wrote: > Joe- > The messages refer to different ports: the "port unreachable" is a > destination port; the "port already in use" is the 'source' port, > which is to be 'replicated' by the NAT. The two conditions > require much different responses from the host, and I didn't see > an obvious way to get both meanings out of the existing "port > unreachable" message. > -Bob > ---------------------------------------------------- > Bob Gilman rrg@xxxxxxxxx +1 303 538 3868 > > Joe Touch wrote: >> >> Robert R. Gilman wrote: >> >>> I'd think that a practical port-preserving NAT would require a new >>> ICMP message, e.g. "port already in use", to inform the transport >>> layer to try some other source port. >> >> >> IMO, that's an existing 'port unreachable' message. There is - and >> should be - no reason why the port is unreachable indicated. > [rrg]: That's why I suggested a new message. >> >> >>> Perhaps it could suggest an >>> available port; even so, it might take some time to find one common >>> to the host and the NAT before a packet went through the NAT. >>> How much code would have to be modified to do this? :-) >> >> >> I would be very wary of an ICMP solution that suggested alternate ways >> around a port that was not available. That's too much of an opportunity >> for attack, IMO. > [rrg]: I'm not sure I see the attack you do. Are you thinking of a DoS > attack in which the attacker returns ICMP "port unavailable" > messages to cause the host to retry on another port, ad nauseam? > It seems to me the "port unreachable" will have the same effect > (with only one fake message required.) >> >> Joe >> >> >>> -Bob >>> ---------------------------------------------------- >>> Bob Gilman rrg@xxxxxxxxx +1 303 538 3868 >>> >>> Dan Wing wrote: >>> >>>>>> So, would you recommend that an application be coded expecting this >>>>>> behavior? I wouldn't -- it's too fragile and breaks if there are >>>>>> two active hosts behind that same NAT. By "breaks", I mean that >>>>>> you will have TCP connections going to the wrong host. >>>>> >>>>> Certainly an application shouldn't require it, but the likelihood of >>>>> having TCP go to the wrong host depends on the application. >>>>> >>>>> Skype, for example, randomly picks a source port at time of >>>>> installation and always uses that source port. Therefore it would be >>>>> very unlikely for two Skype clients behind a NAT to collide. >>>> >>>> >>>> But with that implementation you have another problem -- once they do >>>> collide, they will continue to collide until you uninstall and >>>> re-install Skype on one of those boxes, replace your Skype hardphone, >>>> or something functionally identical to >>>> those operations. >>>> >>>> There are, of course, other applications running on other >>>> hosts behind the NAT -- PVR applications, refigerators communicating >>>> with the local grocery store, web surfing, >>>> and so on. Any one of those might also choose that same >>>> port as a normal function of its operation. >>>> >>>> Large ISPs, such as a cable company in Germany that I know >>>> about and, supposedly, some ISPs in Korea, don't give their >>>> users real IP addresses but rather give their users private >>>> IP addresses. There is a high chance that ephemeral ports >>>> in those situations will already be allocated to other >>>> subscribers -- those NATs are _very_ busy. >>>> >>>> >>>> >>>>> In any case, as with other NAT traversal mechanisms, there needs to >>>>> be a final verification of the data-path (after it is established) to >>>>> ensure that you have the right guy. ICE/STUN do this with a nonce >>>>> that is sent along the signaling-path and echoed back on-path. >>>> >>>> >>>> Yep, I agree that some kind of nonce is necessary. >>>> >>>> >>>> >>>>>> Note that BEHAVE has a milestone to write a document describing how >>>>>> applications should be coded to work over a NAT -- expecting some >>>>>> kind of port predictability is one of the things we'll have to >>>>>> address in that document. >>>>> >>>>> Port-prediction is an optimization that can cause (fixable) problems >>>>> if the prediction is incorrect. >>>> >>>> >>>> I can see how to detect you're talking to the wrong peer -- he >>>> doesn't echo back the correct nonce or doesn't echo back a nonce >>>> at all (timeout or runs a different protocol on the port you >>>> happened to connect with). >>>> >>>> >>>> >>>>> The behave-app document should mention this. >>>>> >>>>> >>>>> >>>>>> But you can't tell if some other host is using the NAT a lot >>>>>> and consuming those same TCP port numbers. That's the rub. >>>>> >>>>> True, you cannot tell until after the TCP is established and you >>>>> verify >>>>> the nonces; by then you have already incurred a few RTTs and need to >>>>> restart the procedure sans port-prediction. >>>> >>>> >>>> Ah, so that's what you mean by 'fixable'. -d >>>> _______________________________________________ >>>> Ietf-behave mailing list >>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx >>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >>> >> > Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00142.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00142.pgp" Content-Description: "Description: OpenPGP digital signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4zIChNaW5n VzMyKQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwu bW96ZGV2Lm9yZwoKaUQ4REJRRkVpRXJYRTVmNWNJbW5acnNSQXZCZUFLQ3Z4WUVnMHZxOHJrdnVV UFFtV0ZVTHlvWmlCZ0NiQkpVWQpTTDNSMDZNcGdIOXp5V0RwRWJVL2g0MD0KPTltbzcKLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tCg== --Boundary..27398.1163630136.multipart/signed-- From tthome@ktrc-na.com Wed, 7 Jun 2006 23:45:37 -0700 (PDT) From: Tim Thome Date: Wed, 7 Jun 2006 23:45:37 -0700 (PDT) Subject: Re: [Ietf-behave] RE: [Sip] outbound-keepalive question In-Reply-To: <042601c68ac0$04657630$95ab6b80@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On 6/7/06 10:54 PM, "Dan Wing" wrote: >> My question's true intent is: can we send Binding Requests >> using TCP or TLS in Outbound. Because rfc3489bis-03 doesn't say >> "Binding Requests, sent over TCP or TLS" and it only says " Binding >> Requests, sent over UDP". > > Consensus at the Dallas IETF SIP meeting was to send STUN over TCP > connections, too. . -behave-rfc3489bis- hasn't been updated since that > meeting. Concur... Tim From dwing@cisco.com Thu, 8 Jun 2006 12:29:12 -0700 (PDT) From: "Dan Wing" Date: Thu, 8 Jun 2006 12:29:12 -0700 (PDT) Subject: RE: [Ietf-behave] RE: port preservation In-Reply-To: Message-ID: <033201c68b31$c5db9bc0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain ... > Clearly for a NAT with a large number of hosts behind it these > advantages rapidly diminish because there's a much higher > probability of port collisions but for NATs supporting small > numbers of hosts these advantages shouldn't be dismissed > (since at the worst we end up with a NAT that maintains > consistent mappings still). Something worse happens on a busy NAT. The application that 'just works' (on a quiet NAT) now no longer works, and its intended session is going to a different host or a different application. That different host or different application might misbehave. I mean, imagine you're doing iSCSI or NAT and all of a sudden the wrong sessions are talking to each other. It really calls for nonces to be exchanged, but you're still creating a larger risk of injecting invalid data into an application that may not have been coded well enough to expect such invalid data and discard it. > I would definitely agree that applications shouldn't be coded > to expect this sort of behaviour but there are a lot of apps > around that already do make these sorts of assumptions (it's > really dismaying how many games expect well-known ports if > you wish to host a game server or P2P apps if you want > them to work properly). I believe we're on the cusp of defining the difference between "current practice" and "best current practice". -d From dhudson@ubicom.com Thu, 8 Jun 2006 14:30:49 -0700 (PDT) From: "Dave Hudson" Date: Thu, 8 Jun 2006 14:30:49 -0700 (PDT) Subject: RE: [Ietf-behave] RE: port preservation In-Reply-To: <033201c68b31$c5db9bc0$c2f0200a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain * -----Original Message----- * From: Dan Wing [mailto:dwing@xxxxxxxxx] * Sent: 08 June 2006 20:29 * To: Dave Hudson; 'Saikat Guha' * Cc: 'Behave'; 'Joe Touch' * Subject: RE: [Ietf-behave] RE: port preservation * * ... * > Clearly for a NAT with a large number of hosts behind it these * > advantages rapidly diminish because there's a much higher * probability * > of port collisions but for NATs supporting small numbers of hosts * > these advantages shouldn't be dismissed (since at the worst * we end up * > with a NAT that maintains consistent mappings still). * * Something worse happens on a busy NAT. The application that * 'just works' (on a quiet NAT) now no longer works, and its * intended session is going to a different host or a different * application. That different host or different application * might misbehave. I mean, imagine you're doing iSCSI or NAT * and all of a sudden the wrong sessions are talking to each * other. It really calls for nonces to be exchanged, but * you're still creating a larger risk of injecting invalid data * into an application that may not have been coded well enough * to expect such invalid data and discard it. Hmm - this will be true for any NAT that doesn't maintain an active binding though. Any new session established after an old session existed can randomly be given the NAT'd port number of some previous session. In fact I've seen exactly this behaviour very frequently when NATs are restarted if they sequentially allocate NAT port numbers to new sessions. Similar behaviour occurs (albeit on average less frequently) when random ports are allocated for new sessions. In short for UDP if a port binding ages out then chaos can ensue no matter what. If we have a really busy NAT we're going to have a very high probability of such rebinding no matter what. In the case of the P2P apps and though these tend to have been written to keep bindings active (in fact I've observed many apps tend to be quite chatty in this way). * > I would definitely agree that applications shouldn't be coded to * > expect this sort of behaviour but there are a lot of apps * around that * > already do make these sorts of assumptions (it's really * dismaying how * > many games expect well-known ports if you wish to host a * game server * > or P2P apps if you want them to work properly). * * I believe we're on the cusp of defining the difference * between "current practice" and "best current practice". This is an interesting point of course (and one that seems to come up quite frequently). As a NAT implementor I find the primary concern of customers and end users is that the NATs we deliver are able to give the best end-user experience with their existing applications. Now equally I would dearly love to see more applications designed in a way that means they can traverse NATs much more effectively - my ideal solution in fact would be to design a NAT that recognizes when a NAT traversal scheme is in use and drops down to some nice clean mode of operation while making best efforts in all other circumstances. This is much like I may not like UPnP being enabled by default (it's insecure) as a means of setting up NAT traversals but there's no question that end-users love the fact that things "just work". Regards, Dave From dwing@cisco.com Thu, 8 Jun 2006 15:07:52 -0700 (PDT) From: "Dan Wing" Date: Thu, 8 Jun 2006 15:07:52 -0700 (PDT) Subject: RE: [Ietf-behave] RE: port preservation In-Reply-To: Message-ID: <045301c68b47$fc760650$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > * ... > * > Clearly for a NAT with a large number of hosts behind it these > * > advantages rapidly diminish because there's a much higher > * > probability > * > of port collisions but for NATs supporting small numbers of hosts > * > these advantages shouldn't be dismissed (since at the worst > * > we end up > * > with a NAT that maintains consistent mappings still). > * > * Something worse happens on a busy NAT. The application that > * 'just works' (on a quiet NAT) now no longer works, and its > * intended session is going to a different host or a different > * application. That different host or different application > * might misbehave. I mean, imagine you're doing iSCSI or NAT > * and all of a sudden the wrong sessions are talking to each > * other. It really calls for nonces to be exchanged, but > * you're still creating a larger risk of injecting invalid data > * into an application that may not have been coded well enough > * to expect such invalid data and discard it. > > Hmm - this will be true for any NAT that doesn't maintain an active > binding though. Yep. An application that allows its NAT binding to expire is also causing a problem for itself and for whatever other application (or host) now has that binding. > Any new session established after an old session > existed can randomly be given the NAT'd port number of some previous > session. In fact I've seen exactly this behaviour very > frequently when > NATs are restarted if they sequentially allocate NAT port > numbers to new > sessions. Similar behaviour occurs (albeit on average less > frequently) > when random ports are allocated for new sessions. In short > for UDP if a > port binding ages out then chaos can ensue no matter what. > If we have a really busy NAT we're going to have a very high > probability of such rebinding no matter what. > > In the case of the P2P apps and though these tend to have been written > to keep bindings active (in fact I've observed many apps tend to be > quite chatty in this way). Yep. There isn't much else they can do. > * > I would definitely agree that applications shouldn't be coded to > * > expect this sort of behaviour but there are a lot of apps > * around that > * > already do make these sorts of assumptions (it's really > * dismaying how > * > many games expect well-known ports if you wish to host a > * game server > * > or P2P apps if you want them to work properly). > * > * I believe we're on the cusp of defining the difference > * between "current practice" and "best current practice". > > This is an interesting point of course (and one that seems to come up > quite frequently). As a NAT implementor I find the primary concern of > customers and end users is that the NATs we deliver are able > to give the > best end-user experience with their existing applications. > Now equally > I would dearly love to see more applications designed in a way that > means they can traverse NATs much more effectively - my ideal solution > in fact would be to design a NAT that recognizes when a NAT traversal > scheme is in use and drops down to some nice clean mode of operation > while making best efforts in all other circumstances. > This is much like I may not like UPnP being enabled by default > (it's insecure) as a means of setting up NAT traversals but > there's no question that end-users love the fact that things > "just work". Your guidance and contributions to the BEHAVE 'application guidance' document would be quite valuable. It is one of our milestones but we haven't yet adopted a working group document. -d From rrg@avaya.com Fri, 9 Jun 2006 08:44:44 -0700 (PDT) From: "Robert R. Gilman" Date: Fri, 9 Jun 2006 08:44:44 -0700 (PDT) Subject: Re: [Ietf-behave] RE: port preservation In-Reply-To: <05fa01c68a51$4afc4a70$c2f0200a@amer.cisco.com> Message-ID: <4489975F.50804@avaya.com> MIME-Version: 1.0 Content-Type: text/plain Joe- Thanks for your reply. My comments are embedded below. Regardless of the details, I think the only way to make a port-preserving NAT work is to pass information back to the originator that lets it retry when there is a conflict, while not disturbing existing connections with unexpected traffic. -Bob ---------------------------------------------------- Bob Gilman rrg@xxxxxxxxx +1 303 538 3868 Joe Touch wrote: I'm not sure it matters that this is a source port issue. According to RFC1122: 3 (Port Unreachable), when the designated transport protocol (e.g., UDP) is unable to demultiplex the datagram but has no protocol mechanism to inform the sender. "Unable to demux" is what the NAT is experiencing; IMO, it is acting as a host at this point (it's looking at the port numbers), so port unreachable is the best error to provide. [rrg]: But that error is typically expected from the destination host, where it refers to the destination port. The responses to the two possibilities would be quite different. The error really should say "the NAT will be unable to demux any reply." Should we define a new code to identify the particular problem? Another option is reply with a TCP RST to that connection - which is what would happen if this were a conventional host and such a collision occurred. [rrg]: That would work for TCP, but not UDP, and it presumes the NAT knows the protocol procedures beyond locating the addresses and ports. If either response seems cryptic, then you could also send an error indicating that the destination service is unreachable given the parameters of the packet, in which case you can use pointer-error (Code 12, Type 0), and point to the source port. [rrg]: That would make sense, I suppose, if we can't think of any other flaw we might have in the source port. There's no other fundamental "reason" to deny a particular source port so I wouldn't suggest a new ICMP error number for this. [rrg]: I agree that a new type is not needed, but I would suggest a new code to specifically identify the problem, so the sender knows how to react. Joe Robert R. Gilman wrote: Joe- The messages refer to different ports: the "port unreachable" is a destination port; the "port already in use" is the 'source' port, which is to be 'replicated' by the NAT. The two conditions require much different responses from the host, and I didn't see an obvious way to get both meanings out of the existing "port unreachable" message. -Bob ---------------------------------------------------- Bob Gilman rrg@xxxxxxxxx +1 303 538 3868 Joe Touch wrote: Robert R. Gilman wrote: I'd think that a practical port-preserving NAT would require a new ICMP message, e.g. "port already in use", to inform the transport layer to try some other source port. IMO, that's an existing 'port unreachable' message. There is - and should be - no reason why the port is unreachable indicated. [rrg]: That's why I suggested a new message. Perhaps it could suggest an available port; even so, it might take some time to find one common to the host and the NAT before a packet went through the NAT. How much code would have to be modified to do this? :-) I would be very wary of an ICMP solution that suggested alternate ways around a port that was not available. That's too much of an opportunity for attack, IMO. [rrg]: I'm not sure I see the attack you do. Are you thinking of a DoS attack in which the attacker returns ICMP "port unavailable" messages to cause the host to retry on another port, ad nauseam? It seems to me the "port unreachable" will have the same effect (with only one fake message required.) Joe -Bob ---------------------------------------------------- Bob Gilman rrg@xxxxxxxxx +1 303 538 3868 Dan Wing wrote: So, would you recommend that an application be coded expecting this behavior? I wouldn't -- it's too fragile and breaks if there are two active hosts behind that same NAT. By "breaks", I mean that you will have TCP connections going to the wrong host. Certainly an application shouldn't require it, but the likelihood of having TCP go to the wrong host depends on the application. Skype, for example, randomly picks a source port at time of installation and always uses that source port. Therefore it would be very unlikely for two Skype clients behind a NAT to collide. But with that implementation you have another problem -- once they do collide, they will continue to collide until you uninstall and re-install Skype on one of those boxes, replace your Skype hardphone, or something functionally identical to those operations. There are, of course, other applications running on other hosts behind the NAT -- PVR applications, refigerators communicating with the local grocery store, web surfing, and so on. Any one of those might also choose that same port as a normal function of its operation. Large ISPs, such as a cable company in Germany that I know about and, supposedly, some ISPs in Korea, don't give their users real IP addresses but rather give their users private IP addresses. There is a high chance that ephemeral ports in those situations will already be allocated to other subscribers -- those NATs are _very_ busy. In any case, as with other NAT traversal mechanisms, there needs to be a final verification of the data-path (after it is established) to ensure that you have the right guy. ICE/STUN do this with a nonce that is sent along the signaling-path and echoed back on-path. Yep, I agree that some kind of nonce is necessary. Note that BEHAVE has a milestone to write a document describing how applications should be coded to work over a NAT -- expecting some kind of port predictability is one of the things we'll have to address in that document. Port-prediction is an optimization that can cause (fixable) problems if the prediction is incorrect. I can see how to detect you're talking to the wrong peer -- he doesn't echo back the correct nonce or doesn't echo back a nonce at all (timeout or runs a different protocol on the port you happened to connect with). The behave-app document should mention this. But you can't tell if some other host is using the NAT a lot and consuming those same TCP port numbers. That's the rub. True, you cannot tell until after the TCP is established and you verify the nonces; by then you have already incurred a few RTTs and need to restart the procedure sans port-prediction. Ah, so that's what you mean by 'fixable'. -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Thu, 15 Jun 2006 20:56:58 -0700 (PDT) From: "Dan Wing" Date: Thu, 15 Jun 2006 20:56:58 -0700 (PDT) Subject: [Ietf-behave] review of the "NAT/Firewall NSISSignaling Layer Protocol (NSLP) " In-Reply-To: <615BD9B54CB01B41838C323DB9E91AAB40768F@esebe100.NOE.Nokia.com> Message-ID: <07ca01c690f8$e9dde380$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain John, I read through parts of draft-ietf-nsis-ntlp-09.txt to understand how NATs are handled in NTLP. In that document's section 7.2, "NAT Traversal", it says: 5. Add a NAT-Traversal payload, listing the objects which have been modified and including the unmodified MRI and any other data needed to interpret the response. (If a NAT-Traversal object is already present, in the case of a sequence of NATs, the list of modified objects may be updated and further opaque data added, but the MRI contained in it is left unchanged.) which sounds like you would be disclosing my 'private' IP address on the public side of an NSIS-aware NAT. I believe I'm misinterpreting that, as in -ietf-nsis-nslp-natfw- I found text that alluded to avoiding such information leakage by having the outer-most NAT or firewall configured to know that it is the outer-most NAT (or firewall) and to terminate REA processing. Section 1.1 mentions STUN and TURN only being able to process two IP addresses; have you looked at ICE and would it be useful. I noticed the reference to TURN should be updated to draft-ietf-behave-turn. On to -nsis-nslp-natfw-11: My first concern with this is Appendix A and section 3.8.2, which outlines the fundamental problem of NAT traversal -- how to "leave" your network, on the correct path, in order to get the NSLP messages to traverse the NATs that are on-path between you and your intended peer. This problem is similar to STUN, am I correct? Section 3.8.2 uses words that almost say it, as well: o It may be necessary to use a signaling destination address (SDA) as the actual target of the REA message (NR+) if the DR is located behind a NAT and the address of the DS is unknown. The SDA is an arbitrary address in the outermost address realm on the other side of the NAT from the DR. Typically this will be a suitable public IP address when the 'outside' realm is the public Internet. This choice of address causes the REA message to be routed through the NATs towards the outermost realm and would force interception of the message by the outermost NAT in the network at the boundary between the private address and the public address realm (the edge-NAT). It may also be intercepted by other NATs and firewalls on the path to the edge-NAT. It seems that applications will need to collect several different routable addresses and exchange those addressees with their intended peers in order to optimize the network path. This is what ICE does, and a generalization of this technique is described in draft-ford-behave-app-02.txt section 2.3. I'm also concerned by configuration information that is necessary, such as this (in 3.8.2): The data receiver is challenged to determine whether it is solely located behind firewalls or NATs, for choosing the right message routing method. This decision can depend on a local configuration parameter, possibly given through DHCP, or it could be discovered through other non-NSLP related testing of the network configuration. and The end host cannot be assumed to know this [[the NAT device]] device - instead the NAT or firewall box itself is assumed to know that it is located at the outer perimeter of the network. For example, I am typing this message from my house, where I have two NATs and a hardware VPN with split tunneling. If both of my NATs were NSIS and NSLP aware, I don't know how they would successfully send the appropriate NSIS messages in this configuration; can you elaborate what my application or my NSIS-aware OS stack would do in this situation? From my experience, my application would need to gather different IP addresses (one from my 'internal' network that I'm IPsec'd into, another from my local interface, and another from my connection to the Internet). Even if this _isn't_ necessary -- and I don't see how you'd have success otherwise, but I'm interested in hearing -- I'm curious what information would be in this as-yet-undefined DHCP option (I didn't notice any NSIS-related DHCP document). On page 7 is this sentence fragment: However, if the data receiver resides in a public addressing realm. Figure 3 and its associated text would be clearer if the middleboxes were numbered and the text referred to each middlebox explicitly. Specifically, the sentences: Note that this IP address is not the private IP address of the responder. Instead a NAT binding (including a public IP address) has to be previously installed on the NAT that subsequently allows packets reaching the NAT to be forwarded to the receiver within the private address realm. have too many "this" and "a NAT binding" and "the NAT" to be clearly understood. The other diagrams in surrounding figures 2 through 6 might also benefit from similar changes. Section 2.8, "Multihomed Network with NAT" promises that section 3.8.2 has an extended discussion of such multihoming, but I didn't find anything in that section related to multihomed NATs. -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > john.loughney@xxxxxxxxx > Sent: Tuesday, May 02, 2006 4:28 AM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] Request for a review of the > "NAT/Firewall NSISSignaling Layer Protocol (NSLP) " > > Hi all, > > Currently, the NSIS working group is finalizing the "NAT/Firewall > NSIS Signaling Layer Protocol (NSLP)" for signaling middleboxes. > The current document can be found here: > > Http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt > > NSIS is working on a path-coupled signaling protocol, to signal > nodes along the data patch. As both NAT and Firewalls are along the > data path, NSIS signaling is developing a protocol for allow end > nodes to signal these boxes. > > As both BEHAVE and MIDCOM have been working on related issues, I'd > like to encourage people to read the document and send comments and > questions to the mailing list - nsis@xxxxxxxxx As long as your > subject lines are clearly marked, I'll enable posting rights so that > you don't have to join the NSIS mailing list. > > Additionally, please try not to cross-post discussion on the other > mailing lists; unless the BEHAVE & MIDCOM chairs feel that > cross-posting would be beneficial. > > thanks, > John > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From dbarrett@quinthar.com Sun, 18 Jun 2006 02:14:15 -0700 (PDT) From: "David Barrett" Date: Sun, 18 Jun 2006 02:14:15 -0700 (PDT) Subject: [Ietf-behave] SNMP and consumer NATs Message-ID: <20060618091415.58660102FFC@beta.sipfoundry.org> MIME-Version: 1.0 Content-Type: text/plain I’m not sure if it’s within the scope of BEHAVE, but do we offer any guidance to device manufacturers regarding the support of SNMP?  In your experience, what fraction of consumer NAT devices (DSL routers, wireless routers, etc) support SNMP?   In addition to NAT penetration (which has been discussed extensively) I’m thinking another problem we’re facing is sharing upstream gateways; I’m curious if there’s any way for a client to query its gateway and get a sense of its current upstream and downstream bandwidth utilization.  Ideally, there would be some way (perhaps UPnP or SNMP?) to do this that is reasonable standardized across devices.   Has this already been done or am I barking up the wrong tree?   -david From Internet-Drafts@ietf.org Tue, 20 Jun 2006 12:51:10 -0700 (PDT) From: Internet-Drafts@ietf.org Date: Tue, 20 Jun 2006 12:51:10 -0700 (PDT) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-tcp-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for TCP Author(s) : S. Guha, et al. Filename : draft-ietf-behave-tcp-01.txt Pages : 19 Date : 2006-6-20 This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-tcp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-tcp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From Andreas.Pashalidis@siemens.com Mon, 19 Jun 2006 02:04:44 -0700 (PDT) From: "Pashalidis, Andreas" Date: Mon, 19 Jun 2006 02:04:44 -0700 (PDT) Subject: [Ietf-behave] RE: [NSIS] review of the "NAT/Firewall NSISSignaling Layer Protocol(NSLP) " Message-ID: <69D2C30BFA177E4DB3E6C93A94C87F1F858267@MCHP7IEA.ww002.siemens.net> MIME-Version: 1.0 Content-Type: text/plain Dear all, This is to give a short answer to Dan Wing's comment below. -----Original Message----- From: Dan Wing [mailto:dwing@xxxxxxxxx] To: john.loughney@xxxxxxxxx; nsis@xxxxxxxx Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: [NSIS] review of the "NAT/Firewall NSISSignaling Layer Protocol(NSLP) " > I read through parts of draft-ietf-nsis-ntlp-09.txt to understand > how NATs are handled in NTLP. In that document's section 7.2, > "NAT Traversal", it says: > 5. Add a NAT-Traversal payload, listing the objects which have been > modified and including the unmodified MRI and any other data > needed to interpret the response. (If a NAT-Traversal object is > already present, in the case of a sequence of NATs, the list of > modified objects may be updated and further opaque data added, > but the MRI contained in it is left unchanged.) > which sounds like you would be disclosing my 'private' IP address on the > public side of an NSIS-aware NAT. I believe I'm misinterpreting that, as in > -ietf-nsis-nslp-natfw- I found text that alluded to avoiding such > information leakage by having the outer-most NAT or firewall configured to > know that it is the outer-most NAT (or firewall) and to terminate REA > processing. In the draft http://www.ietf.org/internet-drafts/draft-pashalidis-nsis-gimps-nattrave rsal-02.txt (which discusses NAT traversal for GIST in detail), two different "modes of operation" for GIST-aware NATs are described (see sections 5 and 6 respectively). The mode of operation described in section 5 does not suffer from "private address disclosure" on the public side. Best Regards, Andreas Pashalidis From dwing@cisco.com Tue, 20 Jun 2006 13:22:39 -0700 (PDT) From: "Dan Wing" Date: Tue, 20 Jun 2006 13:22:39 -0700 (PDT) Subject: [Ietf-behave] =?iso-8859-1?q?Montr=E9al_BEHAVE_agenda_time?= Message-ID: <0af501c694a7$4355bee0$67e7460a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Please email me if you would like agenda time in Montreal. I have asked for a two-hour slot. So far I have the following requests: * TCP (draft-ietf-behave-tcp) -- Saikat, 30 minutes * RFC3489bis (draft-ietf-behave-rfc3489bis) -- Jonathan, 30 minutes * TURN (draft-ietf-behave-turn) -- Rohan, 30 minutes * ICMP Cullen, 15 minutes If you want agenda time and you're not on the list please email me directly. -d From srisuresh@yahoo.com Wed, 21 Jun 2006 18:22:45 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 21 Jun 2006 18:22:45 -0700 (PDT) Subject: ICMP draft slot (WAS:: Re: [Ietf-behave] Montral BEHAVE agenda time) In-Reply-To: <0af501c694a7$4355bee0$67e7460a@amer.cisco.com> Message-ID: <20060622012244.74919.qmail@web33310.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Dan, I object to assigning the ICMP slot to Cullen. Saikat presented the ICMP draft in the last IETF meeting. Per Saikat, there was general consensus in the last IETF meeting to have an ICMP draft for the WG. This is clearly reflected in the WG roadmap now. The people that reviewed the draft and participated in the discussions supported the draft to become a WG item. At least two people on the mailing list responded affirmatively in adapting this as WG item. And, the ICMP draft is published as WG item now. Cullen, who was the lone objector, had no technical objections to the draft. What would be the purpose of assigning the time slot on ICMP to Cullen? regards, suresh --- Dan Wing wrote: > Please email me if you would like agenda time in Montreal. I have asked for > a two-hour slot. > > So far I have the following requests: > > * TCP > (draft-ietf-behave-tcp) -- Saikat, 30 minutes > * RFC3489bis > (draft-ietf-behave-rfc3489bis) -- Jonathan, 30 minutes > * TURN > (draft-ietf-behave-turn) -- Rohan, 30 minutes > * ICMP > Cullen, 15 minutes > > If you want agenda time and you're not on the list please email me directly. > > -d > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Wed, 21 Jun 2006 20:39:55 -0700 (PDT) From: Cullen Jennings Date: Wed, 21 Jun 2006 20:39:55 -0700 (PDT) Subject: =?ISO-8859-1?Q?Re:_ICMP_draft_slot__=28WAS::_Re:_[Ietf-behave]_M?= =?ISO-8859-1?Q?ontr=E9al_BEHAVE_agenda_time=29?= In-Reply-To: <20060622012244.74919.qmail@web33310.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi suresh, I think several of your statements are wrong but don't really matter for the important question you are asking of what do I want to accomplish with this agenda time request - which is a very fair question. I have no intention of asking the WG to "un adopt" this if that is your concern. The chair made a call on this, if I was going to appeal it, I would of. It's a done decision - I hate WG constantly revisiting decisions that were already made. It's a WG document. I hope everyone sticks with the same position on not trying to remake decisions that were already made. I do however think there are some open issues with this document. Primarily I think the open issues are largely the ones that Saikat presented at the last meeting. You can find his presentation at http://www3.ietf.org/proceedings/06mar/slides/behave-2.pdf You can see it ask several questions and most of them were not resolved as you can see from the minutes at http://www3.ietf.org/proceedings/06mar/minutes/behave.txt I plan to more or less go through the same slides Saikat did in the same style and see if, now that we have the draft, people can come to conclusion on some of these. As always, I expect any input that comes up in the room to be brought back to the list and Chair (which will not be me) to help combine the two inputs and make a consensus call. I will also go through the emails list and try and find any other open issues or issues that we have managed to close and can be ignored and update the slides a bit. If the authors think there are open issues that they need WG input on to finish the draft, please send them on to me and the list. I have an excellent understanding of this draft and have probably been one of the most involved with people that will be at the meeting - I could not think of a better person to walk though these issues and try and drive them to conclusion so I requested the time. Cullen (with my individual contributor hat on) On Jun 21, 2006, at 6:22 PM, Pyda Srisuresh wrote: Dan, I object to assigning the ICMP slot to Cullen. Saikat presented the ICMP draft in the last IETF meeting. Per Saikat, there was general consensus in the last IETF meeting to have an ICMP draft for the WG. This is clearly reflected in the WG roadmap now. The people that reviewed the draft and participated in the discussions supported the draft to become a WG item. At least two people on the mailing list responded affirmatively in adapting this as WG item. And, the ICMP draft is published as WG item now. Cullen, who was the lone objector, had no technical objections to the draft. What would be the purpose of assigning the time slot on ICMP to Cullen? regards, suresh --- Dan Wing wrote: Please email me if you would like agenda time in Montreal. I have asked for a two-hour slot. So far I have the following requests: * TCP (draft-ietf-behave-tcp) -- Saikat, 30 minutes * RFC3489bis (draft-ietf-behave-rfc3489bis) -- Jonathan, 30 minutes * TURN (draft-ietf-behave-turn) -- Rohan, 30 minutes * ICMP Cullen, 15 minutes If you want agenda time and you're not on the list please email me directly. -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Wed, 21 Jun 2006 20:45:11 -0700 (PDT) From: Cullen Jennings Date: Wed, 21 Jun 2006 20:45:11 -0700 (PDT) Subject: Re: [Ietf-behave] SNMP and consumer NATs In-Reply-To: <20060618091415.58660102FFC@beta.sipfoundry.org> Message-ID: <12C03A20-6CCF-4B07-A569-39E87101B423@cisco.com> MIME-Version: 1.0 Content-Type: text/plain inline...On Jun 18, 2006, at 2:14 AM, David Barrett wrote: I’m not sure if it’s within the scope of BEHAVE, but do we offer any guidance to device manufacturers regarding the support of SNMP?  In your experience, what fraction of consumer NAT devices (DSL routers, wireless routers, etc) support SNMP?I have not kept track of any stats on this and I have never test what SNMP work but a large percentage of the consumer NATs I have used have had config section to configure SNMP on the so they must do something. From saikat@cs.cornell.edu Thu, 22 Jun 2006 04:07:44 -0700 (PDT) From: Saikat Guha Date: Thu, 22 Jun 2006 04:07:44 -0700 (PDT) Subject: [Ietf-behave] Re: I-D ACTION:draft-ietf-behave-tcp-01.txt In-Reply-To: Message-ID: <1150974463.5163.35.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi folks, An updated version of the BEHAVE-TCP draft is now available. The major changes from -00 are listed below. The primary open issue is that of handling unsolicited inbound SYN packets -- i.e. to report an error, or silently drop, or something in between. (Note: these SYN packets are different from SYN packets that are part of a TCP Simultaneous-Open attempt, which are in fact solicited.) The draft addresses the concerns in Section 4.3, REQ-4 and presents several alternatives. We expect to resolve this issue at the BEHAVE WG meeting at IETF. If you have any opinions on the matter please attend the session or email the list in advance. We will summarize the decision taken in the TCPM meeting for those that cannot attend BEHAVE. On Tue, 2006-06-20 at 15:50 -0400, Internet-Drafts@xxxxxxxx wrote: > Title : NAT Behavioral Requirements for TCP > Author(s) : S. Guha, et al. > Filename : draft-ietf-behave-tcp-01.txt > Pages : 19 > Date : 2006-6-20 > > This document defines a set of requirements for NATs that handle TCP > that would allow many applications, such as peer-to-peer applications > and on-line games, to work consistently. Developing NATs that meet > this set of requirements will greatly increase the likelihood that > these applications will function properly. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-01.txt Discussion points on- and off- list since -00 have been merged. Big changes from -00 are: 1. Document is self standing. Understanding BEHAVE-UDP is no longer a prerequisite for this document. 2. Handling of unsolicited inbound SYN (REQ-4) is an open issue. The alternative wordings are mentioned in the document. (This email is being sent to BEHAVE and TCPM) cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00143.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00143.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFbW5uL25GbHRxaTY5MS9vUkFvTkZBSjkvdzFQdHdFSHlsTDZCZGx3 MTNMRm43S282RFFDZlQwWnQKZ25zK1BsZ2FqWlY3aWJobXpFbHorcnc9Cj1YakxpCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From Internet-Drafts@ietf.org Thu, 22 Jun 2006 12:50:06 -0700 (PDT) From: Internet-Drafts@ietf.org Date: Thu, 22 Jun 2006 12:50:06 -0700 (PDT) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-multicast-02.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Multicast Requirements for a Network Address Port Translator (NAPT) Author(s) : D. Wing Filename : draft-ietf-behave-multicast-02.txt Pages : 7 Date : 2006-6-22 This document places requirements on a Network Address Translator (NAT) and Network Address and Port Translator (NAPT) that supports IP multicast by implementing an IGMP proxy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-multicast-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-multicast-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From srisuresh@yahoo.com Fri, 23 Jun 2006 10:51:09 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 23 Jun 2006 10:51:09 -0700 (PDT) Subject: Re: ICMP draft slot (WAS:: Re: [Ietf-behave] Montral BEHAVE agenda time) In-Reply-To: Message-ID: <20060623175108.99363.qmail@web33306.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Cullen, Good to hear that you are not intending to un-adopt the draft. That is a relief. As for the open issues from the last WG meeting, that is precisely what the authors and reviewers went through to address each and every one of them in great detail. I dont undersdtand why you want to start all over again, resetting the base to 4 months ago. If there are open issues still remaining from the last meeting, I want to know about them first hand, preferably on the list where I can participate. I will start a seperate thread addressing all issues raised in the last WG meeting, so we know which of these still remain open and what newer issues have arised since then. This way, the WG meeting can be used effectively to discuss only the current outstanding open issues. You say: > I have an excellent understanding of this draft and have probably > been one of the most involved with people that will be at the meeting > - I could not think of a better person to walk though these issues > and try and drive them to conclusion so I requested the time. You claim to have excellent understanding of the draft and to be the most involved with people that will be at the meeting. I donot know what to make of this assertion. Based on your comments and actions in the past, I am very uncomfortable with your driving this slot. I would like this to be an objective meeting, where issues are addressed without bias and with an intent to bring closure. Dan Wing, the WG chair, has a thorough understanding of the subject matter and has gone through each and every one of the issues with the authors in detail. Dan was also very effective in bringing closure to the issues that were discussed. As individual and as Wg chair, Dan is most qualified to walk through the issues in the meeting. I request Dan to carry out this slot of the meeting. If not, I would request one of the co-authors (Saikat, most likely) to walk through the issues. Thanks. regards, suresh --- Cullen Jennings wrote: > > Hi suresh, > > I think several of your statements are wrong but don't really matter > for the important question you are asking of what do I want to > accomplish with this agenda time request - which is a very fair > question. > > I have no intention of asking the WG to "un adopt" this if that is > your concern. The chair made a call on this, if I was going to appeal > it, I would of. It's a done decision - I hate WG constantly > revisiting decisions that were already made. It's a WG document. I > hope everyone sticks with the same position on not trying to remake > decisions that were already made. > > I do however think there are some open issues with this document. > Primarily I think the open issues are largely the ones that Saikat > presented at the last meeting. > > You can find his presentation at > http://www3.ietf.org/proceedings/06mar/slides/behave-2.pdf > > You can see it ask several questions and most of them were not > resolved as you can see from the minutes at > http://www3.ietf.org/proceedings/06mar/minutes/behave.txt > > I plan to more or less go through the same slides Saikat did in the > same style and see if, now that we have the draft, people can come to > conclusion on some of these. As always, I expect any input that comes > up in the room to be brought back to the list and Chair (which will > not be me) to help combine the two inputs and make a consensus call. > I will also go through the emails list and try and find any other > open issues or issues that we have managed to close and can be > ignored and update the slides a bit. If the authors think there are > open issues that they need WG input on to finish the draft, please > send them on to me and the list. > > I have an excellent understanding of this draft and have probably > been one of the most involved with people that will be at the meeting > - I could not think of a better person to walk though these issues > and try and drive them to conclusion so I requested the time. > > Cullen (with my individual contributor hat on) > > > On Jun 21, 2006, at 6:22 PM, Pyda Srisuresh wrote: > > > Dan, > > > > I object to assigning the ICMP slot to Cullen. > > > > Saikat presented the ICMP draft in the last IETF meeting. Per > > Saikat, there was > > general consensus in the last IETF meeting to have an ICMP draft > > for the WG. > > This is clearly reflected in the WG roadmap now. > > > > The people that reviewed the draft and participated in the discussions > > supported the draft to become a WG item. At least two people on the > > mailing > > list responded affirmatively in adapting this as WG item. And, the > > ICMP draft > > is published as WG item now. Cullen, who was the lone objector, had no > > technical objections to the draft. > > > > What would be the purpose of assigning the time slot on ICMP to > > Cullen? > > > > regards, > > suresh > > > > --- Dan Wing wrote: > > > >> Please email me if you would like agenda time in Montreal. I have > >> asked for > >> a two-hour slot. > >> > >> So far I have the following requests: > >> > >> * TCP > >> (draft-ietf-behave-tcp) -- Saikat, 30 minutes > >> * RFC3489bis > >> (draft-ietf-behave-rfc3489bis) -- Jonathan, 30 minutes > >> * TURN > >> (draft-ietf-behave-turn) -- Rohan, 30 minutes > >> * ICMP > >> Cullen, 15 minutes > >> > >> If you want agenda time and you're not on the list please email me > >> directly. > >> > >> -d > >> > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Fri, 23 Jun 2006 12:12:36 -0700 (PDT) From: Cullen Jennings Date: Fri, 23 Jun 2006 12:12:36 -0700 (PDT) Subject: =?ISO-8859-1?Q?Re:_ICMP_draft_slot__=28WAS::_Re:_[Ietf-behave]_M?= =?ISO-8859-1?Q?ontr=E9al_BEHAVE_agenda_time=29?= In-Reply-To: <20060623175108.99363.qmail@web33306.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Jun 23, 2006, at 10:51 AM, Pyda Srisuresh wrote: Cullen, Good to hear that you are not intending to un-adopt the draft. That is a relief. As for the open issues from the last WG meeting, that is precisely what the authors and reviewers went through to address each and every one of them in great detail. I dont undersdtand why you want to start all over again, resetting the base to 4 months ago. If there are open issues still remaining from the last meeting, I want to know about them first hand, preferably on the list where I can participate. As to what the open issue are - I already provided a link to the minutes from the last meeting. I will start a seperate thread addressing all issues raised in the last WG meeting, so we know which of these still remain open and what newer issues have arised since then. Right - however, if 5 people on the list think it is closed, and 50 people in the room think it is open - I would appeal any consensus decision that claimed the 5 people on list override 50 people in room. (And likewise I would appeal any consensus decision that ignored the people on the list that were not in the room). This way, the WG meeting can be used effectively to discuss only the current outstanding open issues. You say: I have an excellent understanding of this draft and have probably been one of the most involved with people that will be at the meeting - I could not think of a better person to walk though these issues and try and drive them to conclusion so I requested the time. You claim to have excellent understanding of the draft and to be the most involved with people that will be at the meeting. I donot know what to make of this assertion. Personal opinion of course. It's the wonderful thing about IETF, everyone gets to have an opinion no matter how stupid it is. Based on your comments and actions in the past, I am very uncomfortable with your driving this slot. I would like this to be an objective meeting, where issues are addressed without bias and with an intent to bring closure. Dan Wing, the WG chair, has a thorough understanding of the subject matter and has gone through each and every one of the issues with the authors in detail. Dan was also very effective in bringing closure to the issues that were discussed. As individual and as Wg chair, Dan is most qualified to walk through the issues in the meeting. I request Dan to carry out this slot of the meeting. If not, I would request one of the co-authors (Saikat, most likely) to walk through the issues. I am a member of this WG, I have requested agenda time. I expect the chairs to prioritize time of course but my request stands and unless the time needs to be used for other things, I see no reason I should not be allowed to request agenda time on any WG document. You point out that Dan is very effective at bringing closure to the open issues - keep in mind he will be chairing this discussion and I have full connivence he will keep it on point. I think you might, as usual, confuse my intentions as well - my intention is to drive the points to consensus and so this document can be done. Thanks. regards, suresh --- Cullen Jennings wrote: Hi suresh, I think several of your statements are wrong but don't really matter for the important question you are asking of what do I want to accomplish with this agenda time request - which is a very fair question. I have no intention of asking the WG to "un adopt" this if that is your concern. The chair made a call on this, if I was going to appeal it, I would of. It's a done decision - I hate WG constantly revisiting decisions that were already made. It's a WG document. I hope everyone sticks with the same position on not trying to remake decisions that were already made. I do however think there are some open issues with this document. Primarily I think the open issues are largely the ones that Saikat presented at the last meeting. You can find his presentation at http://www3.ietf.org/proceedings/06mar/slides/behave-2.pdf You can see it ask several questions and most of them were not resolved as you can see from the minutes at http://www3.ietf.org/proceedings/06mar/minutes/behave.txt I plan to more or less go through the same slides Saikat did in the same style and see if, now that we have the draft, people can come to conclusion on some of these. As always, I expect any input that comes up in the room to be brought back to the list and Chair (which will not be me) to help combine the two inputs and make a consensus call. I will also go through the emails list and try and find any other open issues or issues that we have managed to close and can be ignored and update the slides a bit. If the authors think there are open issues that they need WG input on to finish the draft, please send them on to me and the list. I have an excellent understanding of this draft and have probably been one of the most involved with people that will be at the meeting - I could not think of a better person to walk though these issues and try and drive them to conclusion so I requested the time. Cullen (with my individual contributor hat on) On Jun 21, 2006, at 6:22 PM, Pyda Srisuresh wrote: Dan, I object to assigning the ICMP slot to Cullen. Saikat presented the ICMP draft in the last IETF meeting. Per Saikat, there was general consensus in the last IETF meeting to have an ICMP draft for the WG. This is clearly reflected in the WG roadmap now. The people that reviewed the draft and participated in the discussions supported the draft to become a WG item. At least two people on the mailing list responded affirmatively in adapting this as WG item. And, the ICMP draft is published as WG item now. Cullen, who was the lone objector, had no technical objections to the draft. What would be the purpose of assigning the time slot on ICMP to Cullen? regards, suresh --- Dan Wing wrote: Please email me if you would like agenda time in Montreal. I have asked for a two-hour slot. So far I have the following requests: * TCP (draft-ietf-behave-tcp) -- Saikat, 30 minutes * RFC3489bis (draft-ietf-behave-rfc3489bis) -- Jonathan, 30 minutes * TURN (draft-ietf-behave-turn) -- Rohan, 30 minutes * ICMP Cullen, 15 minutes If you want agenda time and you're not on the list please email me directly. -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Fri, 23 Jun 2006 13:34:22 -0700 (PDT) From: Pyda Srisuresh Date: Fri, 23 Jun 2006 13:34:22 -0700 (PDT) Subject: Re: ICMP draft slot (WAS:: Re: [Ietf-behave] Montral BEHAVE agenda time) In-Reply-To: Message-ID: <20060623203422.50153.qmail@web33307.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > > On Jun 23, 2006, at 10:51 AM, Pyda Srisuresh wrote: > > > Cullen, > > > > Good to hear that you are not intending to un-adopt the draft. That > > is a > > relief. As for the open issues from the last WG meeting, that is > > precisely what > > the authors and reviewers went through to address each and every > > one of them in > > great detail. I dont undersdtand why you want to start all over again, > > resetting the base to 4 months ago. If there are open issues still > > remaining > > from the last meeting, I want to know about them first hand, > > preferably on the > > list where I can participate. > > As to what the open issue are - I already provided a link to the > minutes from the last meeting. > [suresh] Understood. > > I will start a seperate thread addressing all > > issues raised in the last WG meeting, so we know which of these > > still remain > > open and what newer issues have arised since then. > > Right - however, if 5 people on the list think it is closed, and 50 > people in the room think it is open - I would appeal any consensus > decision that claimed the 5 people on list override 50 people in > room. (And likewise I would appeal any consensus decision that > ignored the people on the list that were not in the room). > [suresh] Just so what I said is not misunderstood, let me clarify one more time. I said, a closed group of people reviewed all ICMP items that came up in the last WG meeting and the current ICMP document is a result of that detailed review. I also said, I was going to review the items once again in conjunction with the current draft with the list - that is, everyone on the list gets to review and determine which of the items is closed and which is not. Getting consensus on the the list is the IETF way. Do you feel that every consensus item on the list needs to be appealed in a WG meeting until it is agreed upon and approved be people in the WG meeting? That is not the IETF way, AFAIK. Perhaps the WG chair or the AD can comment or offer advice on this. Thanks. > > This way, the WG meeting can > > be used effectively to discuss only the current outstanding open > > issues. > > > > You say: > >> I have an excellent understanding of this draft and have probably > >> been one of the most involved with people that will be at the meeting > >> - I could not think of a better person to walk though these issues > >> and try and drive them to conclusion so I requested the time. > > > > You claim to have excellent understanding of the draft and to be > > the most > > involved with people that will be at the meeting. I donot know what > > to make of > > this assertion. > > > > Personal opinion of course. It's the wonderful thing about IETF, > everyone gets to have an opinion no matter how stupid it is. > > > Based on your comments and actions in the past, I am very > > uncomfortable with > > your driving this slot. I would like this to be an objective > > meeting, where > > issues are addressed without bias and with an intent to bring > > closure. Dan > > Wing, the WG chair, has a thorough understanding of the subject > > matter and has > > gone through each and every one of the issues with the authors in > > detail. Dan > > was also very effective in bringing closure to the issues that were > > discussed. > > As individual and as Wg chair, Dan is most qualified to walk > > through the issues > > in the meeting. I request Dan to carry out this slot of the > > meeting. If not, I > > would request one of the co-authors (Saikat, most likely) to walk > > through the > > issues. > > I am a member of this WG, I have requested agenda time. I expect the > chairs to prioritize time of course but my request stands and unless > the time needs to be used for other things, I see no reason I should > not be allowed to request agenda time on any WG document. You point > out that Dan is very effective at bringing closure to the open issues > - keep in mind he will be chairing this discussion and I have full > connivence he will keep it on point. I think you might, as usual, > confuse my intentions as well - my intention is to drive the points > to consensus and so this document can be done. > [suresh] Cullen - I am not attributing any intent to you at this point. From what you say above, we both agree on one thing - Driving open items to consensus, so the ICMP document can be done. I am requesting Dan to drive this slot (or) allow one of the co-authors (Saikat) to drive the slot. It is not unusual for a WG chair or draft author to drive time slot for a draft. Thanks. regards, suresh > > > > > Thanks. > > > > regards, > > suresh > > > > --- Cullen Jennings wrote: > > > >> > >> Hi suresh, > >> > >> I think several of your statements are wrong but don't really matter > >> for the important question you are asking of what do I want to > >> accomplish with this agenda time request - which is a very fair > >> question. > >> > >> I have no intention of asking the WG to "un adopt" this if that is > >> your concern. The chair made a call on this, if I was going to appeal > >> it, I would of. It's a done decision - I hate WG constantly > >> revisiting decisions that were already made. It's a WG document. I > >> hope everyone sticks with the same position on not trying to remake > >> decisions that were already made. > >> > >> I do however think there are some open issues with this document. > >> Primarily I think the open issues are largely the ones that Saikat > >> presented at the last meeting. > >> > >> You can find his presentation at > >> http://www3.ietf.org/proceedings/06mar/slides/behave-2.pdf > >> > >> You can see it ask several questions and most of them were not > >> resolved as you can see from the minutes at > >> http://www3.ietf.org/proceedings/06mar/minutes/behave.txt > >> > >> I plan to more or less go through the same slides Saikat did in the > >> same style and see if, now that we have the draft, people can come to > >> conclusion on some of these. As always, I expect any input that comes > >> up in the room to be brought back to the list and Chair (which will > >> not be me) to help combine the two inputs and make a consensus call. > >> I will also go through the emails list and try and find any other > >> open issues or issues that we have managed to close and can be > >> ignored and update the slides a bit. If the authors think there are > >> open issues that they need WG input on to finish the draft, please > >> send them on to me and the list. > >> > >> I have an excellent understanding of this draft and have probably > >> been one of the most involved with people that will be at the meeting > >> - I could not think of a better person to walk though these issues > >> and try and drive them to conclusion so I requested the time. > >> > >> Cullen (with my individual contributor hat on) > >> > >> > >> On Jun 21, 2006, at 6:22 PM, Pyda Srisuresh wrote: > >> > >>> Dan, > >>> > >>> I object to assigning the ICMP slot to Cullen. > >>> > >>> Saikat presented the ICMP draft in the last IETF meeting. Per > >>> Saikat, there was > >>> general consensus in the last IETF meeting to have an ICMP draft > >>> for the WG. > >>> This is clearly reflected in the WG roadmap now. > >>> > >>> The people that reviewed the draft and participated in the > >>> discussions > >>> supported the draft to become a WG item. At least two people on the > >>> mailing > >>> list responded affirmatively in adapting this as WG item. And, the > >>> ICMP draft > >>> is published as WG item now. Cullen, who was the lone objector, > >>> had no > >>> technical objections to the draft. > >>> > >>> What would be the purpose of assigning the time slot on ICMP to > >>> Cullen? > >>> > >>> regards, > >>> suresh > >>> > >>> --- Dan Wing wrote: > >>> > >>>> Please email me if you would like agenda time in Montreal. I have > >>>> asked for > >>>> a two-hour slot. > >>>> > >>>> So far I have the following requests: > >>>> > >>>> * TCP > >>>> (draft-ietf-behave-tcp) -- Saikat, 30 minutes > >>>> * RFC3489bis > >>>> (draft-ietf-behave-rfc3489bis) -- Jonathan, 30 minutes > >>>> * TURN > >>>> (draft-ietf-behave-turn) -- Rohan, 30 minutes > >>>> * ICMP > >>>> Cullen, 15 minutes > >>>> > >>>> If you want agenda time and you're not on the list please email me > >>>> directly. > >>>> > >>>> -d > >>>> > >>>> _______________________________________________ > >>>> Ietf-behave mailing list > >>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ietf-behave mailing list > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > > > From narten@us.ibm.com Sat, 24 Jun 2006 03:28:24 -0700 (PDT) From: Thomas Narten Date: Sat, 24 Jun 2006 03:28:24 -0700 (PDT) Subject: Re: ICMP draft slot (WAS:: Re: [Ietf-behave] Montr al BEHAVE agenda time) In-Reply-To: <20060623203422.50153.qmail@web33307.mail.mud.yahoo.com> Message-ID: <200606241028.k5OASIpE020411@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain Pyda Srisuresh writes: > [suresh] Just so what I said is not misunderstood, let me clarify > one more time. I said, a closed group of people reviewed all ICMP > items that came up in the last WG meeting and the current ICMP > document is a result of that detailed review. In cases like this, an issue tracker would be a big help. That way folk could go look at the issue, and the specific changed text that resulted, and decide whether they agree that the issue has been adequately closed. Sorry, but I have a knee jerk whenever I hear "we considered the comments and they have been addressed in the revised ID." Do the people who raised the issues originally agree with the conclusion/resolution of the raised issues? Have they confirmed that they are in agreement? (Seems like this could be done outside of the meeting as part of the prep for discussion.) Thomas From srisuresh@yahoo.com Sat, 24 Jun 2006 06:47:12 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 24 Jun 2006 06:47:12 -0700 (PDT) Subject: [Ietf-behave] Issue 0 - ICMP draft issues from the IETF 65 WG meeting In-Reply-To: <20060623203422.50153.qmail@web33307.mail.mud.yahoo.com> Message-ID: <20060624134706.7886.qmail@web33308.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain ISSUE-0 1. same thing with timeouts as UDP/TCP, namely administrator- configured timeout. Want feedback from BEHAVE. Cullen asked what applications beyond ICMP PING and ICMP traceroute need this draft. Saikat agreed with Cullen, but said some ICMP errors are useful. Francois suggested we make sure something is broken before we take this as a WG item. Saikat skipped to end of presentation, asking room to adopt this as WG item. Philip Matthews (?) said the document is important if vendors screw up ICMP, or ICMP needs more predictable behavior. Saikat said the UDP and TCP documents identified what needs to change, at minimum, to make UDP and TCP work. For ICMP, we're less sure what those problems are. RESOLUTION: The discussion was mainly to do with whether or not the ICMP draft should be adapted as WG item. There was consensus to add ICMP draft to the WG. The WG chair added ICMP draft to the revised milestones list. draft-ietf-behave-nat-icmp-00.txt is now a WG item. From srisuresh@yahoo.com Sat, 24 Jun 2006 07:01:32 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 24 Jun 2006 07:01:32 -0700 (PDT) Subject: [Ietf-behave] Issue 1 - ICMP draft issues from the IETF 65 WG meeting Message-ID: <20060624140132.83578.qmail@web33303.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain ISSUE-1 1. PING sends an echo request, next PING goes to a different mapping; what default timeout should exist for the mappings? Magnus - should give consideration to using Maximum Segment Lifetime. RESOLUTION: REQ-2 of the ICMP draft states the timer requirement as follows. ICMP query applications (such as ping and ICMP traceroute) are request-response kind and often complete within a few seconds. S0, 60 secs was set as the bar for ICMP query session timeout. REQ-2: An ICMP Query session mapping timer MUST NOT expire in less than 60 seconds. a) The value of NAT ICMP mapping timer MAY be configurable. From srisuresh@yahoo.com Sat, 24 Jun 2006 07:11:14 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 24 Jun 2006 07:11:14 -0700 (PDT) Subject: [Ietf-behave] Issue 2 - ICMP draft issues from the IETF 65 WG meeting Message-ID: <20060624141113.83729.qmail@web33312.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain ISSUE-2 2. NAT MUST NOT modify ICMP 'type' values. Saikat asked if anyone was familiar with a NAT that actually had this behavior, and if we should mention this in the draft. Magnus said perhaps it should stay in the draft. Cullen said he hadn't seen a NAT that does this. RESOLUTION: REQ-4 and REQ-5 of the ICMP describe the requirements for translationg ICMP error packets inbound and outbound as follows. NAT is mandated to not translate ICMP error type or ICMP code. REQ-4: If a NAT device receives an ICMP error packet from external realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP error packet. If the the NAT has active mapping for the embedded payload, then the NAT MUST transparently forward the ICMP error message, without modifying the ICMP error type or code as follows. a) The NAT MUST revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping. b) The NAT device MUST modify the destination IP address of the outer IP header to be same as the source IP address of the embedded IP packet after the translation. c) Lastly, the NAT MUST update the IP and ICMP checksums in the outer headers to reflect the above changes. REQ-5: If a NAT device receives an ICMP error packet from private realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP error packet. If the the NAT has active mapping for the embedded payload, then the NAT MUST transparently forward the ICMP error message, without modifying the ICMP error type or code as follows. a) The NAT MUST revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping. b) If the NAT device has active mapping for the ICMP error packet originator, the NAT MUST translate the source IP address of the ICMP error packet with the public IP address in the mapping. Otherwise, the NAT MUST translate the source IP address of the ICMP error packet with its own public IP address. c) Lastly, the NAT MUST update the IP and ICMP checksums in the outer headers to reflect the above changes. From srisuresh@yahoo.com Sat, 24 Jun 2006 07:16:31 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 24 Jun 2006 07:16:31 -0700 (PDT) Subject: [Ietf-behave] Issue 3 - ICMP draft issues from the IETF 65 WG meeting Message-ID: <20060624141631.19871.qmail@web33308.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain ISSUE-3 3. Outbound ICMP messages need to have their IP source rewritten to the NAT's public IP address. Dan - ingress filtering (RFC2827) will cause these packets to be dropped, if the NAT doesn't follow this behavior. So this is why such behavior is necessary. RESOLUTION: Req-5 of the ICMP draft reflects the above consensus as follows. REQ-5: If a NAT device receives an ICMP error packet from private realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP error packet. If the the NAT has active mapping for the embedded payload, then the NAT MUST transparently forward the ICMP error message, without modifying the ICMP error type or code as follows. a) The NAT MUST revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping. b) If the NAT device has active mapping for the ICMP error packet originator, the NAT MUST translate the source IP address of the ICMP error packet with the public IP address in the mapping. Otherwise, the NAT MUST translate the source IP address of the ICMP error packet with its own public IP address. c) Lastly, the NAT MUST update the IP and ICMP checksums in the outer headers to reflect the above changes. From srisuresh@yahoo.com Sat, 24 Jun 2006 07:22:14 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 24 Jun 2006 07:22:14 -0700 (PDT) Subject: [Ietf-behave] Issue 4 - ICMP draft issues from the IETF 65 WG meeting Message-ID: <20060624142213.71886.qmail@web33304.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain ISSUE-4 4. ICMP messages shouldn't cause a binding to be refreshed or deleted. Saikat pointed out that the UDP draft already mentions this, for UDP. This requirement would generalize this behavior for NAT binding tables. Dan pointed out that some protocols may need different behavior. Saikat said the ICMP draft would allow protocol-specific drafts to override its behavior RESOLUTION: REQ-6 of the ICMP draft states the requirement as follows. REQ-6: While processing an ICMP error packet, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP error packet. In addition, the section on "Introduction and Scope" states the following with regard to the scope of the ICMP draft requirements. In case a requirement in this document conflicts with protocol specific behave requirement(s), protocol specific behave documents will take precedence. Note, the authors are not aware of any conflicts between this and any other IETF document at the time of this writing. From srisuresh@yahoo.com Sat, 24 Jun 2006 07:31:40 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 24 Jun 2006 07:31:40 -0700 (PDT) Subject: [Ietf-behave] Issue 5 - ICMP draft issues from the IETF 65 WG meeting Message-ID: <20060624143140.36698.qmail@web33309.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain ISSUE-5: 5. Send ICMP error code 10 if NAT is exhausted of resources. This is a soft error; Saikat pointed out TCPM is modifying the interpretation of this ICMP error, and that this message is only sent at session initiation. Saikat suggested bringing discussion to the list. RESOLUTION: After consulting with Fernando and reviewing the recommendations in RFC 1812, we concluded that ICMP error code 13 is the correct error code to use. REQ-7 of the ICMP draft states the requirement as follows. REQ-7: When a NAT device is unable to establish a NAT Session for a new flow due to resource constraints or administrative restrictions, the NAT device SHOULD send an ICMP destination unreachable message, with a code of 13 (Communication administratively prohibited) to the sender, and drop the original packet. The justification for using error code 13 is as follows. Section 5.2.7.1 of [RFC1812] recommends routers to use ICMP code 13 (Communication administratively prohibited) when they administratively filter packets. From srisuresh@yahoo.com Sat, 24 Jun 2006 07:35:02 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 24 Jun 2006 07:35:02 -0700 (PDT) Subject: [Ietf-behave] Issue 6 - ICMP draft issues from the IETF 65 WG meeting Message-ID: <20060624143500.92392.qmail@web33312.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain ISSUE-6: 6. DF behavior, follows normal router behavior. Question: keep this in the draft, or pull it out. Lars suggested that RFC1812 should be the baseline here - "NATs should look like routers". And that instead of duplicating what RFC1812 says, just point out the differences from RFC1812. RESOLUTION: REQ-8 of the ICMP draft reflects the above consensus as follows. REQ-8: A NAT device MUST conform to RFC 1812 in IP packet handling. Below are specific instances where a NAT device MUST conform to RFC 1812. a) If DF bit is set on a transit IP packet and the NAT device cannot forward the packet without fragmentation, the NAT device MUST send a "Packet too big" ICMP message (ICMP type 3, Code 4) with a suggested MTU back to the sender and drop the original IP packet. b) A NAT device MUST, by default, generate "Time Exceeded" ICMP error message when it discards a packet due to an expired TTL field, unless explicitly configured otherwise. From srisuresh@yahoo.com Sat, 24 Jun 2006 07:39:52 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 24 Jun 2006 07:39:52 -0700 (PDT) Subject: [Ietf-behave] Issue 7 - ICMP draft issues from the IETF 65 WG meeting Message-ID: <20060624143952.92977.qmail@web33301.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain ISSUE-7: 7. TTL behavior, should NAT return 'TTL exceeded' when TTL is exceeded at the NAT itself. RESOLUTION: The TTL behvaior on a NAT device must be in conformace with RFC 1812. REQ-8 of the ICMP draft reflects this consensus as follows. REQ-8: A NAT device MUST conform to RFC 1812 in IP packet handling. Below are specific instances where a NAT device MUST conform to RFC 1812. a) If DF bit is set on a transit IP packet and the NAT device cannot forward the packet without fragmentation, the NAT device MUST send a "Packet too big" ICMP message (ICMP type 3, Code 4) with a suggested MTU back to the sender and drop the original IP packet. b) A NAT device MUST, by default, generate "Time Exceeded" ICMP error message when it discards a packet due to an expired TTL field, unless explicitly configured otherwise. From magnus.westerlund@ericsson.com Sun, 25 Jun 2006 23:40:35 -0700 (PDT) From: Magnus Westerlund Date: Sun, 25 Jun 2006 23:40:35 -0700 (PDT) Subject: =?ISO-8859-1?Q?Re=3A_ICMP_draft_slot__=28WAS=3A=3A_R?= =?ISO-8859-1?Q?e=3A_=5BIetf-behave=5D_Montr=E9al_BEHAVE_agenda_?= =?ISO-8859-1?Q?time=29?= In-Reply-To: <20060623203422.50153.qmail@web33307.mail.mud.yahoo.com> Message-ID: <449F815E.4040809@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, I think this whole discussion have been unfortunate. It shows a lack of communication. I think Cullen should not have requested the slot without first discussing it with the current authors of the document. I am also a bit disappointed in Srisuresh of thinking the worst, instead of asking in a more civil tone why Cullen has requested the slot. Can everyone please be more considerate in your postings. I do want cooperation. Can we please move on. The authors have presented how they propose to solve the issues raised. I kindly ask the WG participants to review those proposals and continue to discuss the issues if they are not agreeing on the resolution. And raise any remaining issues with the draft. That way we can hopefully more correctly asses what issues if any is still problematic and need face to face discussion in Montreal. Please sort out between yourself who is going to summarize the open issues. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From fluffy@cisco.com Mon, 26 Jun 2006 00:44:24 -0700 (PDT) From: Cullen Jennings Date: Mon, 26 Jun 2006 00:44:24 -0700 (PDT) Subject: =?ISO-8859-1?Q?Re:_ICMP_draft_slot__=28WAS::_Re:_[Ietf-behave]_M?= =?ISO-8859-1?Q?ontr=E9al_BEHAVE_agenda_time=29?= In-Reply-To: <20060623203422.50153.qmail@web33307.mail.mud.yahoo.com> Message-ID: <4F05718C-DC58-4B2F-81D2-518481A27826@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Jun 25, 2006, at 11:40 PM, Magnus Westerlund wrote: I think Cullen should not have requested the slot without first discussing it with the current authors of the document. I have an a huge number of emails discussing this draft with the authors. Mostly off list however the chairs were on many of them. I requested a slot to discuss issues related to a WG draft. I got the idea that the authors would not be at meeting so they would not be able to deal with this. I was trying to get the request information in to the chairs early instead of late to make scheduling easier. I'm busy. I certainly could have tried to arrange a phone call with the authors - in the past they have rejected that. I though about what is it that I would discuss with them and would that change me wanted to request a slot. I decided it would not change my desire to have discussion on this. I don't see the point of what I would have accomplished in a discussion prior to asking for agenda time. If you have an idea what you want to accomplish on that, we can easily fix this, I'm glad to set up a bridge at some time that works for everyone. Thanks, Cullen From rohan.mahy@gmail.com Mon, 26 Jun 2006 02:38:31 -0700 (PDT) From: "Rohan Mahy" Date: Mon, 26 Jun 2006 02:38:31 -0700 (PDT) Subject: [Ietf-behave] updated Message-ID: <953beacc0606260238o4e74b291v1a6193f7c9a0dfa2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Hi Folks, I just submitted a significant revision of TURN. Until it appears in the archive, you can find it here: http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-turn-01.txt http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-turn-01.html While there are some major changes, the draft still has several open issues and will need another heavy editing pass. The highlights: 1) Disallowed relaying UDP between the client and server to TCP between the server and the peer. 2) Added lightweight TCP framing and simplified rules for wrapping UDP with a magic cookie in Data or Send indiciations. 3) Removed the Connect Request. This did not make sense. If the peer could accept an inbound TCP connection, the client could probably just open its connection directly to the peer. 4) Reintroduced the concept of a door. The TURN server will accept a connection to the door once, establishes a binding, an then no further requests are allowed unless there is an explicit permission. 5) Added Connection Status Indication, so you can tell if the TCP connection from the relay to the peer dies. 6) Added ability to move/refresh your allocation to a new source address/port. 7) Hopefully clearer Overview section. 8) Added more motivation for odd/even port alignment 9) Got rid of DESTINATION-ADDRESS. REMOTE-ADDRESS is now used in its place. 10) Use XOR-MAPPED-ADDRESS consistently instead of MAPPED-ADDRESS 11) I added explicit Open Binding and Close Binding requests for completeness Selected OPEN ISSUES: A) Can we get rid of the state machine for Set Active Destination? (See proposal in the draft) B) Do we want Open/Close Binding? C) Is it OK if clients have to use STUN messages to keep allocations alive? (Data used to keep them alive). ok, enough for now. thanks, -rohan From Remi.Denis-Courmont@nokia.com Mon, 26 Jun 2006 03:46:41 -0700 (PDT) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Date: Mon, 26 Jun 2006 03:46:41 -0700 (PDT) Subject: Re: [Ietf-behave] updated In-Reply-To: <953beacc0606260238o4e74b291v1a6193f7c9a0dfa2@mail.gmail.com> Message-ID: <200606261347.13672.Remi.Denis-Courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain Le Monday 26 June 2006 12:38, ext Rohan Mahy a crit: > A) Can we get rid of the state machine for Set Active Destination? > (See proposal in the draft) Is there any reason to actually not always encapsulate TURN client-to-server packets? For sure, it would add extra on-the-wire overhead in the case of non-encapsulated data, but it would also simplify implementations further, and kill the need for the magic cookie. > B) Do we want Open/Close Binding? > > C) Is it OK if clients have to use STUN messages to keep allocations > alive? (Data used to keep them alive). This might add the requirement that client implementations run a TURN-dedicated thread/timer to keep sending refresh packets in the background, unless something else already requires such a thing (does it bother anyone?). I agree that this simplifies and cleans up things, though. -- Rmi Denis-Courmont From fwmiller@cornfed.com Mon, 26 Jun 2006 07:39:48 -0700 (PDT) From: fwmiller@cornfed.com Date: Mon, 26 Jun 2006 07:39:48 -0700 (PDT) Subject: RE: [Ietf-behave] updated Message-ID: <200606261439.k5QEdix11166@smapp01.siteprotect.com> MIME-Version: 1.0 Content-Type: text/plain Just out of curiosity, can anyone provide me with a reference to a NAT that behaves in a way that requires this relay service? A freely available NAT implementation that does this would be great if such a thing exists... Thanks, FM ------------------------------------------------ On Mon, 26 Jun 2006 02:38:30 -0700, "Rohan Mahy" wrote: > Hi Folks, > > I just submitted a significant revision of TURN. Until it appears in > the archive, you can find it here: > > http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-turn-01.txt > http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-turn-01.html > > While there are some major changes, the draft still has several open > issues and will need another heavy editing pass. The highlights: > > 1) Disallowed relaying UDP between the client and server to TCP > between the server and the peer. > > 2) Added lightweight TCP framing and simplified rules for wrapping UDP > with a magic cookie in Data or Send indiciations. > > 3) Removed the Connect Request. This did not make sense. If the peer > could accept an inbound TCP connection, the client could probably just > open its connection directly to the peer. > > 4) Reintroduced the concept of a door. The TURN server will accept a > connection to the door once, establishes a binding, an then no further > requests are allowed unless there is an explicit permission. > > 5) Added Connection Status Indication, so you can tell if the TCP > connection from the relay to the peer dies. > > 6) Added ability to move/refresh your allocation to a new source address/port. > > 7) Hopefully clearer Overview section. > > 8) Added more motivation for odd/even port alignment > > 9) Got rid of DESTINATION-ADDRESS. REMOTE-ADDRESS is now used in its place. > > 10) Use XOR-MAPPED-ADDRESS consistently instead of MAPPED-ADDRESS > > 11) I added explicit Open Binding and Close Binding requests for completeness > > Selected OPEN ISSUES: > A) Can we get rid of the state machine for Set Active Destination? > (See proposal in the draft) > > B) Do we want Open/Close Binding? > > C) Is it OK if clients have to use STUN messages to keep allocations > alive? (Data used to keep them alive). > > > ok, enough for now. > > thanks, > -rohan > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From saikat@cs.cornell.edu Mon, 26 Jun 2006 08:57:45 -0700 (PDT) From: Saikat Guha Date: Mon, 26 Jun 2006 08:57:45 -0700 (PDT) Subject: Re: [Ietf-behave] Issue 1 - ICMP draft issues from the IETF 65 WG meeting In-Reply-To: <20060624140132.83578.qmail@web33303.mail.mud.yahoo.com> Message-ID: <1151328675.5163.191.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2006-06-24 at 07:01 -0700, Pyda Srisuresh wrote: > ISSUE-1 > 1. PING sends an echo request, next PING goes to a different > mapping; what default timeout should exist for the mappings? Does this affect NATs with only one external IP? There is no notion of an ICMP "port" so the mapping is only between the external IP and the internal IP. For NATs with multiple external IPs, the requirement can be to enforce that mapping behavior is endpoint address independent i.e. if the NAT allocates a mapping (picks an external address) for an outbound ICMP from an internal address, then it must continue to use that same external address for subsequent ping or other ICMPs until the mapping expires. REQ-x: A NAT must have endpoint independent mapping behavior for ICMP requests. This requirement applies only to NATs that have multiple external IP addresses. > REQ-2: An ICMP Query session mapping timer MUST NOT expire in less > than 60 seconds. > a) The value of NAT ICMP mapping timer MAY be configurable. In light of the recent UDP changes that allows "well-known" request-response protocols to have a shorter timeout. Also, the 60s is not consistent with the MSL values in other RFC. perhaps something along the lines of: REQ-x: MUST NOT be less than 60s unless a) applies. a) Can be shorter for well-known request-response types b) SHOULD NOT be less than 4min -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00144.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00144.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFbitHam5GbHRxaTY5MS9vUkFnTWlBSjRpdmQ3SEw2Y0lhR09QNG9w SmRWOHFOd2doa0FDZldQaFIKMmZOeVFac3dkS29SSGZtRlF2L0t6TEE9Cj1CT1NBCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Mon, 26 Jun 2006 08:57:49 -0700 (PDT) From: Saikat Guha Date: Mon, 26 Jun 2006 08:57:49 -0700 (PDT) Subject: Re: [Ietf-behave] Issue 2 - ICMP draft issues from the IETF 65 WG meeting In-Reply-To: <20060624141113.83729.qmail@web33312.mail.mud.yahoo.com> Message-ID: <1151329835.5163.208.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2006-06-24 at 07:11 -0700, Pyda Srisuresh wrote: > REQ-4: If a NAT device receives an ICMP error packet from external > realm, and the NAT does not have an active mapping for the embedded > payload, the NAT SHOULD silently drop the ICMP error packet. If the > the NAT has active mapping for the embedded payload, then the NAT > MUST transparently forward the ICMP error message, without modifying > the ICMP error type or code as follows. > a) The NAT MUST revert the IP and transport headers of the embedded > IP packet to their original form, using the matching mapping. It should be made clear that the 'mapping' here refers to the mapping used by the TCP or UDP protocol modules and not the ICMP mapping (the ICMP mapping is for ICMP request-response packets only). Also, the 'exteral realm' business doesn't specify what happens to ICMP errors on hairpinned UDP/TCP connection. Perhaps something along the lines of: REQ-x: If a NAT device receives an ICMP error packet, it must use the mapping that matches the embedded packet for translating the ICMP error. If such a mapping does not exist, the NAT SHOULD silently drop the ICMP error packet. If the mapping exists, the NAT MUST transparently forward the ICMP error. a) A NAT must translate both the other header and the embedded packet according to the mapping. > b) The NAT device MUST modify the destination IP address of the > outer IP header to be same as the source IP address of the embedded > IP packet after the translation. > c) Lastly, the NAT MUST update the IP and ICMP checksums in the > outer headers to reflect the above changes. Requirement b) and c) seem out of place -- they read like pseudo-code for a NAT implementation written in prose. Unless the idea is to give a complete pseudo-code implementation of a NAT, they can likely be dropped in favor of the principles behind them. > REQ-5: If a NAT device receives an ICMP error packet from private > realm, and the NAT does not have an active mapping for the embedded > payload, the NAT SHOULD silently drop the ICMP error packet. If the > the NAT has active mapping for the embedded payload, then the NAT > MUST transparently forward the ICMP error message, without modifying > the ICMP error type or code as follows. > a) The NAT MUST revert the IP and transport headers of the embedded > IP packet to their original form, using the matching mapping. > b) If the NAT device has active mapping for the ICMP error packet > originator, the NAT MUST translate the source IP address of the > ICMP error packet with the public IP address in the mapping. > Otherwise, the NAT MUST translate the source IP address of the ICMP > error packet with its own public IP address. > c) Lastly, the NAT MUST update the IP and ICMP checksums in the > outer headers to reflect the above changes. See the proposed REQ-x above. It subsumes this case. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00145.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00145.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFbitZcW5GbHRxaTY5MS9vUkFwNTlBSjlWcE5DVk1NTm9hMGg4QkV3 NVc1ODFEVURQYXdDYkJQQ08KOGlUaXZrY25XTy9BZzF1WFliWFdtTzQ9Cj1tNUh1Ci0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From saikat@cs.cornell.edu Mon, 26 Jun 2006 08:57:51 -0700 (PDT) From: Saikat Guha Date: Mon, 26 Jun 2006 08:57:51 -0700 (PDT) Subject: Re: [Ietf-behave] Issue 5 - ICMP draft issues from the IETF 65 WG meeting In-Reply-To: <20060624143140.36698.qmail@web33309.mail.mud.yahoo.com> Message-ID: <1151332037.26969.7.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2006-06-24 at 07:31 -0700, Pyda Srisuresh wrote: > REQ-7: When a NAT device is unable to establish a NAT Session for a > new flow due to resource constraints or administrative > restrictions, the NAT device SHOULD send an ICMP destination > unreachable message, with a code of 13 (Communication > administratively prohibited) to the sender, and drop the original > packet. Is this for flows initiated internally, or for flows initiated externally as well? The TCP draft currently recommends port unreachable for externally initiated flows (currently an open issue), but that can be changed to admin-prohibited. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00146.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00146.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFbis3Rm5GbHRxaTY5MS9vUkFpUUtBSjlZbldsU0NEd0dscGV3c1lJ LzdSczYySmQ2b1FDZEhrYTAKNUZCa1ZmWC9lRTNDL3h2MDE0Z0kyOUk9Cj16NTZhCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From dwing@cisco.com Mon, 26 Jun 2006 10:39:55 -0700 (PDT) From: "Dan Wing" Date: Mon, 26 Jun 2006 10:39:55 -0700 (PDT) Subject: RE: [Ietf-behave] updated In-Reply-To: <200606261439.k5QEdix11166@smapp01.siteprotect.com> Message-ID: <067101c69947$88bcf350$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Just out of curiosity, can anyone provide me with a reference > to a NAT that behaves in a way that requires this relay > service? A freely available NAT implementation that does > this would be great if such a thing exists... See the analysis at http://www.watersprings.org/pub/id/draft-jennings-behave-test-results-01.txt which includes test results showing NATs that are symmetric. TURN, or some other kind of media relay, would be necessary if two hosts behind symmetric NATs want to communicate with each other. -d From saikat@cs.cornell.edu Mon, 26 Jun 2006 13:58:33 -0700 (PDT) From: Saikat Guha Date: Mon, 26 Jun 2006 13:58:33 -0700 (PDT) Subject: RE: [Ietf-behave] updated In-Reply-To: <067101c69947$88bcf350$c2f0200a@amer.cisco.com> Message-ID: <1151355511.26969.16.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2006-06-26 at 10:39 -0700, Dan Wing wrote: > > Just out of curiosity, can anyone provide me with a reference > > to a NAT that behaves in a way that requires this relay > > service? A freely available NAT implementation that does > > this would be great if such a thing exists... > > See the analysis at > http://www.watersprings.org/pub/id/draft-jennings-behave-test-results-01.txt > which includes test results showing NATs that are symmetric. TURN, or some > other kind of media relay, would be necessary if two hosts behind symmetric > NATs want to communicate with each other. The TCP list is at https://nutss.net/stunt-results.php ; the NATs with non-Independent binding type would need TURN in many cases. If you are looking for free implementations to toy with, OpenBSD's pf is one such NAT. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00147.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00147.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFb0VwM25GbHRxaTY5MS9vUkF0NjJBSjlGaXlELzgyWGNncWtqNGY0 TXdiTjRDWVkvQ0FDZlNKdHMKckozZXNwZkFwMmhUcjVRcXRqY05tZ0U9Cj0zWmFMCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From dwing@cisco.com Mon, 26 Jun 2006 14:03:01 -0700 (PDT) From: "Dan Wing" Date: Mon, 26 Jun 2006 14:03:01 -0700 (PDT) Subject: RE: [Ietf-behave] updated In-Reply-To: <1151355511.26969.16.camel@localhost.localdomain> Message-ID: <07cc01c69963$e7b48fa0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > >http://www.watersprings.org/pub/id/draft-jennings-behave-test- > >results-01.txt > > which includes test results showing NATs that are > > symmetric. TURN, or some > > other kind of media relay, would be necessary if two hosts > > behind symmetric NATs want to communicate with each other. > > The TCP list is at https://nutss.net/stunt-results.php ; the NATs with > non-Independent binding type would need TURN in many cases. With ICE-08, _both_ NATs would need to be non-Independent to need TURN, correct? -d > If you are looking for free implementations to toy with, > OpenBSD's pf is one such NAT. > > cheers, > -- > Saikat > From fluffy@cisco.com Mon, 26 Jun 2006 14:29:54 -0700 (PDT) From: Cullen Jennings Date: Mon, 26 Jun 2006 14:29:54 -0700 (PDT) Subject: Re: [Ietf-behave] Re: port preservation In-Reply-To: <013701c6899d$dd148c60$c2f0200a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Jun 7, 2006, at 4:54 AM, Spencer Dawkins wrote: - I wish we could provide meaningful BCP guidance to application developers about this, and We do have a goal for the WG to produce a BCP with guidance like this so I hope this will happen. From fluffy@cisco.com Mon, 26 Jun 2006 14:41:44 -0700 (PDT) From: Cullen Jennings Date: Mon, 26 Jun 2006 14:41:44 -0700 (PDT) Subject: [Ietf-behave] ICMP issues threads... Message-ID: <93AAE4BF-1904-426D-8125-4D0AE0402842@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Thanks for starting these - I will try and reply over the next week or so. From saikat@cs.cornell.edu Mon, 26 Jun 2006 15:09:21 -0700 (PDT) From: Saikat Guha Date: Mon, 26 Jun 2006 15:09:21 -0700 (PDT) Subject: RE: [Ietf-behave] updated In-Reply-To: <07cc01c69963$e7b48fa0$c2f0200a@amer.cisco.com> Message-ID: <1151359760.26969.37.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2006-06-26 at 14:02 -0700, Dan Wing wrote: > > the NATs with > > non-Independent binding type would need TURN in many cases. > > With ICE-08, _both_ NATs would need to be non-Independent to need TURN, > correct? I don't remember all of ICE-08, but I think that direct connections will still succeed with one non-independent-mapping as long as the other has address-dependent filtering or some such. If both are non-Independent, then you almost certainly need TURN (unless you want to risk port-prediction). For TCP, you may additionally require S-O support on one of them. There are a whole bunch of these corner cases where certain pairings will necessitate TURN, especially, as you mentioned, when both are non-Independent. -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00148.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00148.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFb0ZzUW5GbHRxaTY5MS9vUkFxdStBSjRzZ000SE5mYUtzWmtaL1hQ dlpCd0QrVCtQbEFDZlpZdnEKVmtsSWpUY01EdUFQZU5ud0tyWTdvNXc9Cj1pTFkrCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From dwing@cisco.com Mon, 26 Jun 2006 15:18:04 -0700 (PDT) From: "Dan Wing" Date: Mon, 26 Jun 2006 15:18:04 -0700 (PDT) Subject: RE: [Ietf-behave] updated In-Reply-To: <1151359760.26969.37.camel@localhost.localdomain> Message-ID: <003c01c6996e$6476d700$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > > > the NATs with > > > non-Independent binding type would need TURN in many cases. > > > > With ICE-08, _both_ NATs would need to be non-Independent > > to need TURN, correct? > > I don't remember all of ICE-08, Sorry, I should have been more precise. I was referring to section 7.10 of ICE-08, "Learning New Candidates from Connectivity Checks". -d > But I think that direct connections will still succeed with one > non-independent-mapping as long as the other has address-dependent > filtering or some such. If both are non-Independent, then you > almost certainly need TURN (unless you want to risk > port-prediction). For TCP, you may additionally require S-O support > on one of them. There are a whole bunch of these corner cases where > certain pairings will necessitate TURN, especially, as you > mentioned, when both are non-Independent. > > -- > Saikat > From dwing@cisco.com Mon, 26 Jun 2006 17:22:29 -0700 (PDT) From: "Dan Wing" Date: Mon, 26 Jun 2006 17:22:29 -0700 (PDT) Subject: [Ietf-behave] -behave-multicast-02 In-Reply-To: Message-ID: <013201c6997f$c591a270$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain As background, I started -behave-multicast prior to becoming working group chair. During WGLC, Brian Haberman pointed out that MAGMA had an I-D that covered much of the same material. I recently submitted -02 as an individual contributor, not as WG chair. Per the consensus at the Dallas IETF meeting, I revised the BEHAVE multicast document to normatively cite the MAGMA IGMP Proxy document (draft-ietf-magma-igmp-proxy-06, which is in the RFC Editor's queue). The BEHAVE document now merely points out the one where a NAT might need to do something specific to NATting, which is only this: 3.1. Keep NAT Binding Open The NAT UDP requirements [I-D.ietf-behave-nat-udp] document only requires that a NAT binding be kept open for inside-to-outside UDP flows. However, with multicast traffic, UDP traffic will only arrive outside-to-inside. Hosts will periodically send IGMP Report messages to indicate continued interest in receiving the multicast traffic. As long as the IGMP Proxy sees a host is interested in receiving the flow, the NAT MUST continue to receive multicast traffic from the WAN and send it to the interfaces with interested hosts. Per IGMPv3, the default transmission interval for the periodic Membership Report is one second. Per IGMPv2, the default transmission interval for the periodic Unsolicited Report Interval is 10 seconds. If a host no longer sends its periodic messages within those timeframes, the NAT MAY consider the host no longer wants to receive the multicast traffic and can inform the upstream WAN router and close the NAT binding. However, it is suggested that the NAT wait until 3 missing unsolicited reports (to account for packet loss on the LAN, especially wireless LANs), or that the NAT first query the host using IGMPv2 or IGMPv3. Comments welcome. -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Internet-Drafts@xxxxxxxx > Sent: Thursday, June 22, 2006 12:50 PM > To: i-d-announce@xxxxxxxx > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-multicast-02.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Behavior Engineering for > Hindrance Avoidance Working Group of the IETF. > > Title : Multicast Requirements for a Network > Address Port Translator (NAPT) > Author(s) : D. Wing > Filename : draft-ietf-behave-multicast-02.txt > Pages : 7 > Date : 2006-6-22 > > This document places requirements on a Network Address Translator > (NAT) and Network Address and Port Translator (NAPT) that supports IP > multicast by implementing an IGMP proxy. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@xxxxxxxx with the word unsubscribe in > the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-behave-multicast-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@xxxxxxxxx > In the body type: > "FILE /internet-drafts/draft-ietf-behave-multicast-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From srisuresh@yahoo.com Mon, 26 Jun 2006 19:42:47 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 26 Jun 2006 19:42:47 -0700 (PDT) Subject: Re: ICMP draft slot (WAS:: Re: [Ietf-behave] Montral BEHAVE agenda time) In-Reply-To: <449F815E.4040809@ericsson.com> Message-ID: <20060627024243.68313.qmail@web33302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Magnus Westerlund wrote: > Hi, > > I think this whole discussion have been unfortunate. It shows a lack of > communication. I think Cullen should not have requested the slot without > first discussing it with the current authors of the document. I am also > a bit disappointed in Srisuresh of thinking the worst, instead of asking > in a more civil tone why Cullen has requested the slot. Can everyone > please be more considerate in your postings. I do want cooperation. > [suresh] Magnus - I was highly surprised and concerned with the announcement that Cullen has sought a slot for the ICMP draft. This is odd. I had not seen anything like this before. I had no clue why he would do somthing like this. I was certainly not consulted (even privately). Until Cullen indicated that he wanted to review the open issues, I did not know the intent. Had I known the specific intent, I would have sent the issues and resolutions out to the list right away. As soon as I learnt of the intent, I posted the issues to the list. I prefer reviewing issues and concluding issues on the list. I am not not in favor of using WG meetings as the main source of discussion or conclusions. I do believe, I have been civil throughout in my e-mails. > Can we please move on. The authors have presented how they propose to > solve the issues raised. I kindly ask the WG participants to review > those proposals and continue to discuss the issues if they are not > agreeing on the resolution. And raise any remaining issues with the > draft. That way we can hopefully more correctly asses what issues if any > is still problematic and need face to face discussion in Montreal. > > Please sort out between yourself who is going to summarize the open > issues. > [suresh] Fair enough. We will do that. regards, suresh > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx > From srisuresh@yahoo.com Mon, 26 Jun 2006 19:43:27 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 26 Jun 2006 19:43:27 -0700 (PDT) Subject: Re: ICMP draft slot (WAS:: Re: [Ietf-behave] Montral BEHAVE agenda time) In-Reply-To: <4F05718C-DC58-4B2F-81D2-518481A27826@cisco.com> Message-ID: <20060627024323.84455.qmail@web33306.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > > On Jun 25, 2006, at 11:40 PM, Magnus Westerlund wrote: > > > I think Cullen should not have requested the slot without first > > discussing it with the current authors of the document. > > I have an a huge number of emails discussing this draft with the > authors. Mostly off list however the chairs were on many of them. I > requested a slot to discuss issues related to a WG draft. I got the > idea that the authors would not be at meeting so they would not be > able to deal with this. [suresh] Cullen - Yes, we did have private e-mail discussions before the ICMP draft was out. But, none that I can recall afterwards. I truely had no clue why you would ask for a slot. As for assuming the authors wouldnt be at the meeting - I decided I wouldnt be able to attend the IETF only recently, just a few days ago. Why would I tell others anything of my plans before I decide it myself. I also do not recall saying anything about the plans of my co-authors to anyone. > I was trying to get the request information > in to the chairs early instead of late to make scheduling easier. I'm > busy. I certainly could have tried to arrange a phone call with the > authors - in the past they have rejected that. [suresh] I do not recall rejecting your phone conversation offer. I do recall, Your suggesting to talk over the phone sometime back on a different occasion. In the past when I tried to contact you, it was not easy to get to you over the phone without prior appointment. So, I just didnt follow up with a call. Anyways, I will be happy to talk. I will hook up with you offlien to setup the time. > I though about what is > it that I would discuss with them and would that change me wanted to > request a slot. I decided it would not change my desire to have > discussion on this. I don't see the point of what I would have > accomplished in a discussion prior to asking for agenda time. [suresh] There is a lot that woudl have been different, had you enquired first. If I knew that you had intended to discuss the last WG meetign issues, I would have posted the issues/resolution to the list right away. Second, you woudl have learnt what the authors are thinking. We could have discussed and figured out the best way to review. > If you > have an idea what you want to accomplish on that, we can easily fix > this, I'm glad to set up a bridge at some time that works for everyone. [suresh] That works for me. I will be happy to be on the call. Thank you. regards, suresh > > Thanks, Cullen > > From philip_matthews@magma.ca Tue, 27 Jun 2006 14:39:40 -0700 (PDT) From: Philip Matthews Date: Tue, 27 Jun 2006 14:39:40 -0700 (PDT) Subject: Re: [Ietf-behave] updated In-Reply-To: <003c01c6996e$6476d700$c2f0200a@amer.cisco.com> Message-ID: <247F9855-CFC4-48DD-A3FB-4FA4568AB21D@magma.ca> MIME-Version: 1.0 Content-Type: text/plain On 26-Jun-06, at 18:18 , Dan Wing wrote: the NATs with non-Independent binding type would need TURN in many cases. With ICE-08, _both_ NATs would need to be non-Independent to need TURN, correct? I don't remember all of ICE-08, Sorry, I should have been more precise. I was referring to section 7.10 of ICE-08, "Learning New Candidates from Connectivity Checks". -d It depends on the exact network configuration (of course). If L and R are behind separate NATs which connect directly to the Internet, both NATs have just one public address, and both phones are configured to use a STUN server in the Internet, then L's NAT can be endpoint-independent mapping, address-dependent filtering, and R's can be address-and-port-dependent mapping and address- and-port-dependent filtering. (L sends a binding-request to R's server-reflexive candidate, which get dropped, but installs a filtering entry. R then sends a binding-request to L's server-reflexive candidate, which gets through because of the previously installed filtering entry. This allows L to learn R's peer-reflexive candidate, which is paired with L's server-reflexive candidate to form the working candidate pair). If L's NAT has address-dependent mapping, or if R's NAT assigns a different IP addresses to the server-reflexive candidate and the peer-reflexive candidate, then this doesn't work and a TURN server is pretty much required. - Philip From srisuresh@yahoo.com Wed, 28 Jun 2006 07:04:53 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 28 Jun 2006 07:04:53 -0700 (PDT) Subject: Re: [Ietf-behave] Issue 1 - ICMP draft issues from the IETF 65 WG meeting In-Reply-To: <1151328675.5163.191.camel@localhost.localdomain> Message-ID: <20060628140453.78923.qmail@web33303.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Sat, 2006-06-24 at 07:01 -0700, Pyda Srisuresh wrote: > > ISSUE-1 > > 1. PING sends an echo request, next PING goes to a different > > mapping; what default timeout should exist for the mappings? > > Does this affect NATs with only one external IP? There is no notion > of an ICMP "port" so the mapping is only between the external IP and > the internal IP. > [suresh] "Query Id" in ICMP Queries is the equivalent of ports in TCP/UDP flows. Just as a NAT provides port mapping for TCP/UDP plows, the NAT also provides Query ID mapping for ICMP Query flows. > For NATs with multiple external IPs, the requirement can be to enforce > that mapping behavior is endpoint address independent i.e. if the NAT > allocates a mapping (picks an external address) for an outbound ICMP > from an internal address, then it must continue to use that same > external address for subsequent ping or other ICMPs until the mapping > expires. > > REQ-x: A NAT must have endpoint independent mapping behavior for ICMP > requests. This requirement applies only to NATs that have > multiple external IP addresses. > [suresh] When a NAT has a single external address, the NAT does port mapping for TCP/UDP flows and Query ID mapping for ICMP flows (NAPT). When a NAT has multiple external addresses, the NAT does address mapping for TCP/UDP flows and ICMP Query flows (Basic NAT). In the latter case, the ports and ICMP query IDs are not modified. Only the IP address is translated. As you can see, the analogy is identical to TCP/UDP flows and ICMP Query flows. Hence, the text used in the ICMP draft is similar to that of TCP and UDP drafts. > > > REQ-2: An ICMP Query session mapping timer MUST NOT expire in less > > than 60 seconds. > > a) The value of NAT ICMP mapping timer MAY be configurable. > > In light of the recent UDP changes that allows "well-known" > request-response protocols to have a shorter timeout. Also, the 60s is > not consistent with the MSL values in other RFC. perhaps something along > the lines of: > > REQ-x: MUST NOT be less than 60s unless a) applies. > a) Can be shorter for well-known request-response types > b) SHOULD NOT be less than 4min > [suresh] ICMP Query messages are meant to be used only in the context of request-response type of applications. Are you saying you like to draw distinction between "well-known request-response" type applications and "other request-response" type applications? I dont believe that is necessity. cheers, suresh > -- > Saikat > From srisuresh@yahoo.com Wed, 28 Jun 2006 08:19:12 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 28 Jun 2006 08:19:12 -0700 (PDT) Subject: Re: [Ietf-behave] Issue 2 - ICMP draft issues from the IETF 65 WG meeting In-Reply-To: <1151329835.5163.208.camel@localhost.localdomain> Message-ID: <20060628151858.57206.qmail@web33301.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Sat, 2006-06-24 at 07:11 -0700, Pyda Srisuresh wrote: > > REQ-4: If a NAT device receives an ICMP error packet from external > > realm, and the NAT does not have an active mapping for the embedded > > payload, the NAT SHOULD silently drop the ICMP error packet. If the > > the NAT has active mapping for the embedded payload, then the NAT > > MUST transparently forward the ICMP error message, without modifying > > the ICMP error type or code as follows. > > a) The NAT MUST revert the IP and transport headers of the embedded > > IP packet to their original form, using the matching mapping. > > It should be made clear that the 'mapping' here refers to the mapping > used by the TCP or UDP protocol modules and not the ICMP mapping (the > ICMP mapping is for ICMP request-response packets only). [suresh] The text "active mapping for the embedded payload" refers eactly that. If the embedded payload is a TCP/UDP packet, the text refers the active mapping for the TCP/UDP packet. If the embedded payload is an ICMP query packet, the text refers the active mapping for the ICMP query packet. No matter what the embedded packet is, the text refers the active mapping for the embedded packet. > Also, the > 'exteral realm' business doesn't specify what happens to ICMP errors on > hairpinned UDP/TCP connection. [suresh] Hairpinning is required for TCP/UDP flows. So, when a NAT supports hairpining for a TCP/UDP flow, Req-5a enforces translation for the embedded TCP/UDP packet automagically. As for Hairpinning with regard to ICMP error messages, NAT sees this as an ICMP error message coming from a private realm. So, Req-5 addresses the hairpinning for ICMP error messages. > Perhaps something along the lines of: > > REQ-x: If a NAT device receives an ICMP error packet, it must use the > mapping that matches the embedded packet for translating the ICMP error. > If such a mapping does not exist, the NAT SHOULD silently drop the ICMP > error packet. If the mapping exists, the NAT MUST transparently forward > the ICMP error. > a) A NAT must translate both the other header and the embedded packet > according to the mapping. > [suresh] Please see my note above. > > b) The NAT device MUST modify the destination IP address of the > > outer IP header to be same as the source IP address of the embedded > > IP packet after the translation. > > c) Lastly, the NAT MUST update the IP and ICMP checksums in the > > outer headers to reflect the above changes. > > Requirement b) and c) seem out of place -- they read like pseudo-code > for a NAT implementation written in prose. Unless the idea is to give a > complete pseudo-code implementation of a NAT, they can likely be dropped > in favor of the principles behind them. > [suresh] The three subsection of Req-4 and Req-5 identify specfic requirements. Req-4a and Req-5a specify the requirement on how the embedded payload should be translated. Req-4b and Req-5b specify how the outer IP adresses must be selected for translation. See sections 4.2.1 and 4.2.2 for details leading up to Req-4b and 5b. Req-4c and Req-5c specify that the IP/ICMP checksums should be updated to reflect the previous two changes (i.e.,4a+4b or 5a+5b). Potentially, Req-4c and Req-5c could be dropped, as they are assumed to be done by all NAT devices. However, when a NAT does not update ICMP checksum, many end host stacks woudl drop the ICMP error packets. Refer Fernano's draft. Hence, REQ-4c and REQ-5c are included to reinforce the requirement to update ICMP checksum. > > > REQ-5: If a NAT device receives an ICMP error packet from private > > realm, and the NAT does not have an active mapping for the embedded > > payload, the NAT SHOULD silently drop the ICMP error packet. If the > > the NAT has active mapping for the embedded payload, then the NAT > > MUST transparently forward the ICMP error message, without modifying > > the ICMP error type or code as follows. > > a) The NAT MUST revert the IP and transport headers of the embedded > > IP packet to their original form, using the matching mapping. > > b) If the NAT device has active mapping for the ICMP error packet > > originator, the NAT MUST translate the source IP address of the > > ICMP error packet with the public IP address in the mapping. > > Otherwise, the NAT MUST translate the source IP address of the ICMP > > error packet with its own public IP address. > > c) Lastly, the NAT MUST update the IP and ICMP checksums in the > > outer headers to reflect the above changes. > > See the proposed REQ-x above. It subsumes this case. > [suresh] Please see my notes above. cheers, suresh > -- > Saikat > From saikat@cs.cornell.edu Wed, 28 Jun 2006 08:58:09 -0700 (PDT) From: Saikat Guha Date: Wed, 28 Jun 2006 08:58:09 -0700 (PDT) Subject: Re: [Ietf-behave] Issue 1 - ICMP draft issues from the IETF 65 WG meeting In-Reply-To: <20060628140453.78923.qmail@web33303.mail.mud.yahoo.com> Message-ID: <1151510287.26969.131.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-06-28 at 07:04 -0700, Pyda Srisuresh wrote: > > On Sat, 2006-06-24 at 07:01 -0700, Pyda Srisuresh wrote: > > > ISSUE-1 > > > 1. PING sends an echo request, next PING goes to a different > > > mapping; what default timeout should exist for the mappings? > > > > Does this affect NATs with only one external IP? There is no notion > > of an ICMP "port" so the mapping is only between the external IP and > > the internal IP. > > > [suresh] "Query Id" in ICMP Queries is the equivalent of ports in TCP/UDP > flows. Just as a NAT provides port mapping for TCP/UDP plows, the NAT also > provides Query ID mapping for ICMP Query flows. Right. The ICMP mapping only makes sense for ICMP request-response exchanges, and those all have the query identifier. Agreed that the concern holds for NATs with single IP addresses as well and maps onto the TCP/UDP analog of ports to some extent. There is a difference in TCP/UDP ports and ICMP request-response though. TCP/UDP ports are important to the destination -- the port is stored at the application level (think FTP), communicated to other endpoints (think bittorrent) etc. That is why the NAT must have endpoint independent mapping for TCP/UDP; so that if the application at B conveys A's external port (as seen by B) to C, then C can expect to receive a packet from A from that external port and no other. That is the justification behind endpoint independent mapping. I am not aware of any ICMP applications that have similar requirements. Ping, traceroute, etc. simply echo back the identifier in the response -- as a mechanism to demultiplex the response. It doesn't matter, AFAIK, if different ping packets arrive at the (same or different) destination with different identifiers even if the source use the same identifier so long as the response is translated back appropriately. And now that I think about it, back to your original question, I don't see any problem if the "next ping goes to a different mapping" .. even if the next ping gets assigned a whole new IP address or identifier. Are there any P2P (or otherwise) applications that require subsequent ICMP packets sent from the same source (IP/identifier) to appear to come from the same external address/identifier? Suggest: Either removing REQ-1 (because it doesn't affect applications) or upgrading REQ-1 to a MUST (if we want to be pedantic) > [suresh] ICMP Query messages are meant to be used only in the context of > request-response type of applications. Are you saying you like to draw > distinction between "well-known request-response" type applications and "other > request-response" type applications? I dont believe that is necessity. Requiring 60s for all req-resp (especially ping) is just asking for a DoS attack (an unintentional one at that). A simple application that sends one ping packet to every box on a subnet to check for liveness would quickly DoS the NAT: for i in $(seq 0 255); ping -c 1 10.10.1.$i; done or while true; do ping -c 3 A; ping -c 3 B; sleep 1; done Both potentially useful shell-script that could ICMP DoS a NAT. TCP/UDP applications typically have much smaller fanout -- the UDP equivalent of the above would likely be a DoS attack, the ICMP version is likely to be diagnostic and legitimate for the most part. Suggest: Allow NAT to close mapping as soon as ping-response is received -- Saikat Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgp00149.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp00149.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUJFb3FjUG5GbHRxaTY5MS9vUkFzcElBSjlCT1F1cmtFbnB1QW9HSWta eE53V3g1N0E3WVFDZmRnTzkKTmRkUWhiR29HOS9wc0hscHVpM1lNaUU9Cj1ocG9sCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630136.multipart/signed-- From srisuresh@yahoo.com Wed, 28 Jun 2006 09:44:17 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 28 Jun 2006 09:44:17 -0700 (PDT) Subject: Re: [Ietf-behave] Issue 5 - ICMP draft issues from the IETF 65 WG meeting In-Reply-To: <1151332037.26969.7.camel@localhost.localdomain> Message-ID: <20060628164412.15862.qmail@web33307.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Saikat Guha wrote: > On Sat, 2006-06-24 at 07:31 -0700, Pyda Srisuresh wrote: > > > REQ-7: When a NAT device is unable to establish a NAT Session for a > > new flow due to resource constraints or administrative > > restrictions, the NAT device SHOULD send an ICMP destination > > unreachable message, with a code of 13 (Communication > > administratively prohibited) to the sender, and drop the original > > packet. > > > Is this for flows initiated internally, or for flows initiated > externally as well? > [suresh] This is for flows initiated internally, but are not permitted due to resource constraints as well as flows that are administratively prohibited. cheers, suresh > The TCP draft currently recommends port unreachable for externally > initiated flows (currently an open issue), but that can be changed to > admin-prohibited. > > -- > Saikat > From Internet-Drafts@ietf.org Wed, 28 Jun 2006 15:50:05 -0700 (PDT) From: Internet-Drafts@ietf.org Date: Wed, 28 Jun 2006 15:50:05 -0700 (PDT) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-turn-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-turn-01.txt Pages : 49 Date : 2006-6-28 This specification defines a usage of the Simple Traversal of UDP Through NAT (STUN) Protocol for asking the STUN server to relay packets towards a client. This usage is useful for elements behind NATs whose mapping behavior is address and port dependent. The extension purposefully restricts the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the STUN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-turn-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-turn-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From neildeason@gmail.com Wed, 28 Jun 2006 21:38:04 -0700 (PDT) From: "Neil Deason" Date: Wed, 28 Jun 2006 21:38:04 -0700 (PDT) Subject: [Ietf-behave] Comments on draft-ietf-behave-turn-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hello folks. - The intended usage of LIFETIME In the previous draft this attribute was referred to as "the duration that a mapping is valid". Now it is referred to as "the duration for which the server will maintain an allocation in the absence of data traffic either from or to the client". These two definitions appear to be different. The first being the total duration timeout for a session and the second an idle timeout for a session. Perhaps actually having both would be useful? Either way the intended usage of LIFETIME needs to be clarified and consistent. (In the new draft section 9.1.2.2 still refers to this being refreshed by an Allocate request, which is more inline with the previous draft's definition.) - Length and padding of attributes This came up previously in relation to changes in the STUN bis03 draft. ( http://list.sipfoundry.org/archive/ietf-behave/msg01206.html) Unfortunately TURN inherits the same issue and has the added problem that padding to a 4 byte boundary can mess up the data relayed to a remote address via a Send Indication. Is the intention to still fix this by encoding actual attribute lengths, but padding out to multiple of 4 bytes if the length of the attribute is not 0 or already a multiple of 4 bytes? That makes sense, but if so when/where ;) Cheers, Neil. From rohan.mahy@gmail.com Thu, 29 Jun 2006 14:04:34 -0700 (PDT) From: "Rohan Mahy" Date: Thu, 29 Jun 2006 14:04:34 -0700 (PDT) Subject: [Ietf-behave] Re: Comments on draft-ietf-behave-turn-01.txt In-Reply-To: Message-ID: <953beacc0606291404l719f55a6i8097d0f95851ed0b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Hi Neil, Comments inline.. On 6/28/06, Neil Deason wrote: - The intended usage of LIFETIME In the previous draft this attribute was referred to as "the duration that a mapping is valid". Now it is referred to as "the duration for which the server will maintain an allocation in the absence of data traffic either from or to the client". These two definitions appear to be different. The first being the total duration timeout for a session and the second an idle timeout for a session. Perhaps actually having both would be useful? Either way the intended usage of LIFETIME needs to be clarified and consistent. (In the new draft section 9.1.2.2 still refers to this being refreshed by an Allocate request, which is more inline with the previous draft's definition.) Agreed this needs to be clarified. Do you have a preference? - Length and padding of attributes This came up previously in relation to changes in the STUN bis03 draft. ( http://list.sipfoundry.org/archive/ietf-behave/msg01206.html) Unfortunately TURN inherits the same issue and has the added problem that padding to a 4 byte boundary can mess up the data relayed to a remote address via a Send Indication. Is the intention to still fix this by encoding actual attribute lengths, but padding out to multiple of 4 bytes if the length of the attribute is not 0 or already a multiple of 4 bytes? That makes sense, but if so when/where ;) Yes, Send and Data indications will be consistent with padding rules in 3489bis. I can restate this explicitly. Also, I need to explicitly state this for the lightweight TCP framing. This was an oversight on my part. thanks, -rohan From neildeason@gmail.com Thu, 29 Jun 2006 16:37:38 -0700 (PDT) From: "Neil Deason" Date: Thu, 29 Jun 2006 16:37:38 -0700 (PDT) Subject: [Ietf-behave] Re: Comments on draft-ietf-behave-turn-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Rohan. Regarding the semantics of LIFETIME I actually see value in having 2 defined values: One for total permitted duration of a session and one for idle timeout. That would be my preferred choice. If we really can only have one then making LIFETIME the total duration of the session is probably the way to go as thena Server has the option of making this relatively short to enforce Allocate request refreshes as a form of keep alives to timeout idle connections as well as ultimately refusing the refresh request if the session has exceeded max permitted duration. - Neil. On 6/29/06, Rohan Mahy wrote: Hi Neil,Comments inline..On 6/28/06, Neil Deason < neildeason@xxxxxxxxx> wrote:> - The intended usage of LIFETIME>> In the previous draft this attribute was referred to as "the duration that a> mapping is valid". Now it is referred to as "the duration for which the > server will maintain an allocation in the absence of data traffic either> from or to the client".>> These two definitions appear to be different. The first being the total> duration timeout for a session and the second an idle timeout for a session. > Perhaps actually having both would be useful?>> Either way the intended usage of LIFETIME needs to be clarified and> consistent. (In the new draft section 9.1.2.2 still refers to this being> refreshed by an Allocate request, which is more inline with the previous> draft's definition.)Agreed this needs to be clarified.Do you have a preference? > - Length and padding of attributes >> This came up previously in relation to changes in the STUN bis03 draft. (> http://list.sipfoundry.org/archive/ietf-behave/msg01206.html )>> Unfortunately TURN inherits the same issue and has the added problem that> padding to a 4 byte boundary can mess up the data relayed to a remote > address via a Send Indication.>> Is the intention to still fix this by encoding actual attribute lengths, but> padding out to multiple of 4 bytes if the length of the attribute is not 0> or already a multiple of 4 bytes? That makes sense, but if so when/where ;) Yes, Send and Data indications will be consistent with padding rulesin 3489bis.I can restate this explicitly.Also, I need toexplicitly state this for the lightweight TCP framing.This was anoversight on my part. thanks,-rohan From fernando@gont.com.ar Thu, 29 Jun 2006 18:15:42 -0700 (PDT) From: Fernando Gont Date: Thu, 29 Jun 2006 18:15:42 -0700 (PDT) Subject: Re: ICMP draft slot (WAS:: Re: [Ietf-behave] =?iso-8859-1?Q?Montr=E9al?= BEHAVE agenda time) In-Reply-To: <20060623175108.99363.qmail@web33306.mail.mud.yahoo.com> Message-ID: <7.0.1.0.0.20060629212957.065031e8@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain At 16:12 23/06/2006, Cullen Jennings wrote: I will start a seperate thread addressing all issues raised in the last WG meeting, so we know which of these still remain open and what newer issues have arised since then. Right - however, if 5 people on the list think it is closed, and 50 people in the room think it is open - I would appeal any consensus decision that claimed the 5 people on list override 50 people in room. (And likewise I would appeal any consensus decision that ignored the people on the list that were not in the room). IIRC, decisions are supposed to be taken on-list. Everybody has access to e-mail. Not everybody is sponsored/financed to travel three times a year to attend the IETF meetings. not be allowed to request agenda time on any WG document. You point out that Dan is very effective at bringing closure to the open issues - keep in mind he will be chairing this discussion and I have full connivence he will keep it on point. I think you might, as usual, confuse my intentions as well - my intention is to drive the points to consensus and so this document can be done. Why can't these points be raised here? And why should the authors (and all of us that won't attend the next IETF) wait till the next IETF for those points to be raised? Kindest regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From peter.livesey@tandberg.net Fri, 30 Jun 2006 01:48:45 -0700 (PDT) From: "Peter Livesey" Date: Fri, 30 Jun 2006 01:48:45 -0700 (PDT) Subject: [Ietf-behave] Conflicting Error Codes Message-ID: <01C679F7AECF2B47B489F735B7EE49000131D632@47mail.eu.tandberg.int> MIME-Version: 1.0 Content-Type: text/plain Rohan, There is a clash of error codes between the base STUN (well draft 03) and the TURN usage (turn-01). In 3489bis error 437 indicates a "stale nonce", this clashes with the "no binding" error in turn-01. It could be confusing to a client who receives an error response to an authenticated SetActiveDestination request. Did the request fail due to the binding not being there or because the authentication failed? I guess in the stale nonce case the error response would contain another nonce, but would it not be cleaner to not have to do this? Forgive me if this is already being addressed in the next revision of rfc3489bis. Cheers, Pete L. Peter Livesey Senior Software Engineer Phone: +441189348712 Fax: +441189348716 Video: peter.livesey@xxxxxxxxxxxxxxxxxx E-mail: peter.livesey@xxxxxxxxxxxx Video Phone: +441189348712 Unit 8a Castle End Business Park, Castle End Road Ruscombe, Berkshire RG10 9XQ, United Kingdom From fluffy@cisco.com Sat, 1 Jul 2006 12:57:15 -0700 (PDT) From: Cullen Jennings Date: Sat, 1 Jul 2006 12:57:15 -0700 (PDT) Subject: =?ISO-8859-1?Q?Re:_ICMP_draft_slot__=28WAS::_Re:_[Ietf-behave]_M?= =?ISO-8859-1?Q?ontr=E9al_BEHAVE_agenda_time=29?= In-Reply-To: <20060627024323.84455.qmail@web33306.mail.mud.yahoo.com> Message-ID: <2725FA4A-EC04-45C1-B0D6-34D6EDCCCF4E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Jun 26, 2006, at 7:43 PM, Pyda Srisuresh wrote: Anyways, I will be happy to talk. I will hook up with you offlien to setup the time. I've been traveling this week - how about Thursday 1-2 PST or friday 2-3 PST? From srisuresh@yahoo.com Mon, 3 Jul 2006 07:44:16 -0700 (PDT) From: Pyda Srisuresh Date: Mon, 3 Jul 2006 07:44:16 -0700 (PDT) Subject: Re: [Ietf-behave] Issue 1 - ICMP draft issues from the IETF 65 WG meeting In-Reply-To: <1151510287.26969.131.camel@localhost.localdomain> Message-ID: <20060703144416.57215.qmail@web33313.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Hi Saikat, Apologies for my delayed response. Please see my comments in line. cheers, suresh --- Saikat Guha wrote: > On Wed, 2006-06-28 at 07:04 -0700, Pyda Srisuresh wrote: > > > On Sat, 2006-06-24 at 07:01 -0700, Pyda Srisuresh wrote: > > > > ISSUE-1 > > > > 1. PING sends an echo request, next PING goes to a different > > > > mapping; what default timeout should exist for the mappings? > > > > > > Does this affect NATs with only one external IP? There is no notion > > > of an ICMP "port" so the mapping is only between the external IP and > > > the internal IP. > > > > > [suresh] "Query Id" in ICMP Queries is the equivalent of ports in TCP/UDP > > flows. Just as a NAT provides port mapping for TCP/UDP plows, the NAT also > > provides Query ID mapping for ICMP Query flows. > > Right. The ICMP mapping only makes sense for ICMP request-response > exchanges, and those all have the query identifier. Agreed that the > concern holds for NATs with single IP addresses as well and maps onto > the TCP/UDP analog of ports to some extent. > [suresh] OK. We are in agreement so far. > There is a difference in TCP/UDP ports and ICMP request-response though. > > TCP/UDP ports are important to the destination -- the port is stored at > the application level (think FTP), communicated to other endpoints > (think bittorrent) etc. That is why the NAT must have endpoint > independent mapping for TCP/UDP; so that if the application at B conveys > A's external port (as seen by B) to C, then C can expect to receive a > packet from A from that external port and no other. That is the > justification behind endpoint independent mapping. > > I am not aware of any ICMP applications that have similar requirements. > [suresh] When NAT was originally conceived or when the initial NAT RFCs were published, majority of the applications were client-server based. Port-binding was not a big issue. A number of client-server apps just worked with symmetric NATs. Now, we know of many TCP/UDP applications can have multiple peers and they could send and receive connections simultaneously from/to remote peers. So, we know port binding is an issue and we are promoting Port binding now. Likewise, there arent any ICMP applications today (that I know of) that talk with more than one node simultaneously. NATs currently assign different Query ID mapping for each new external host. However, ICMP applications of the future could change. ICMP applications could be interfacing with multiple peers simultaneously using the same query ID. In such a case, the applications would desire NATs to retain the same Query ID mapping across all remote nodes the originating host is interfacing with. SO, keeping this in view, REQ-1a recommends NATs to make the Query ID mapping external host independent. RFC 792 says the following about Query Identifier field. The defintion does not prohibit a sender from using the same Query Identifier to communicate with multiple target nodes. The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests. For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each echo request sent. The echoer returns these same values in the echo reply. > Ping, traceroute, etc. simply echo back the identifier in the response > -- as a mechanism to demultiplex the response. It doesn't matter, AFAIK, > if different ping packets arrive at the (same or different) destination > with different identifiers even if the source use the same identifier so > long as the response is translated back appropriately. And now that I > think about it, back to your original question, I don't see any problem > if the "next ping goes to a different mapping" .. even if the next ping > gets assigned a whole new IP address or identifier. [suresh] Please see my comment above. For independent client-server pings, what you say is true. But, this is not appliable to applications that reuse the same mesage identifier with multiple external nodes. > > Are there any P2P (or otherwise) applications that require subsequent > ICMP packets sent from the same source (IP/identifier) to appear to come > from the same external address/identifier? > > Suggest: Either removing REQ-1 (because it doesn't affect applications) > or upgrading REQ-1 to a MUST (if we want to be pedantic) > [suresh] REQ-1a is not made a MUST because existing ICMP apps do not requie it. REQ-1a is made a SHOULD, so fully compliant NATs would make query ID mapping end host independent. > > > > [suresh] ICMP Query messages are meant to be used only in the context of > > request-response type of applications. Are you saying you like to draw > > distinction between "well-known request-response" type applications and > "other > > request-response" type applications? I dont believe that is necessity. > > Requiring 60s for all req-resp (especially ping) is just asking for a > DoS attack (an unintentional one at that). A simple application that > sends one ping packet to every box on a subnet to check for liveness > would quickly DoS the NAT: > > for i in $(seq 0 255); ping -c 1 10.10.1.$i; done > or > while true; do ping -c 3 A; ping -c 3 B; sleep 1; done > > Both potentially useful shell-script that could ICMP DoS a NAT. TCP/UDP > applications typically have much smaller fanout -- the UDP equivalent of > the above would likely be a DoS attack, the ICMP version is likely to be > diagnostic and legitimate for the most part. > > Suggest: Allow NAT to close mapping as soon as ping-response is received > [suresh] Right, DoS attacks are possible with all protocols, including TCP, UDP and ICMP. What you suggest above is a way to defend. Not the only way. It is not our objective to tell NAT vendors how they should defend a particular DoS attack. As I recall, it was decided in one of the WG meetings that requirements concerning DoS attacks is considered out of scope of the Behave drafts. SO, the the UDP and TCP drafts do not mention requirement to defend against Dos attacks. Neither does the ICMP draft. cheers, suresh > -- > Saikat > From nils@iptel.org Tue, 4 Jul 2006 06:02:35 -0700 (PDT) From: Nils Ohlmeier Date: Tue, 4 Jul 2006 06:02:35 -0700 (PDT) Subject: [Ietf-behave] Question regarding rfc3489bis-03 Message-ID: <200607041502.32615.nils@iptel.org> MIME-Version: 1.0 Content-Type: text/plain Hello, while reading through the document draft-ietf-behave-rfc3489bis-03.txt we stumbled across the sentence "The most significant two bits of every STUN message are 0b00." on page 10. I think this an error because '0b00' implies that the value is given in hexadecimal (because of the b). But in this case '0b00' would two bytes and not two bits. No matter if we are talking about two bits or bytes I do not get how the value 0x0b00 should appear in the beginning of a STUN message (in the message type field). Any comment or thoughts about this are welcome. Thanks Nils Ohlmeier From nils@iptel.org Tue, 4 Jul 2006 07:26:34 -0700 (PDT) From: Nils Ohlmeier Date: Tue, 4 Jul 2006 07:26:34 -0700 (PDT) Subject: Re: [Ietf-behave] Question regarding rfc3489bis-03 In-Reply-To: <200607041502.32615.nils@iptel.org> Message-ID: <200607041626.27083.nils@iptel.org> MIME-Version: 1.0 Content-Type: text/plain On Tuesday 04 July 2006 15:02, Nils Ohlmeier wrote: > while reading through the document draft-ietf-behave-rfc3489bis-03.txt we > stumbled across the sentence "The most significant two bits of every STUN > message are 0b00." on page 10. > I think this an error because '0b00' implies that the value is given in > hexadecimal (because of the b). But in this case '0b00' would two bytes and > not two bits. If the b stands for binary notation forget my posting :-) Allthough it seems like this notation is not very obvious ;-) Nils From jdd@dixons.org Tue, 4 Jul 2006 07:39:36 -0700 (PDT) From: Jim Dixon Date: Tue, 4 Jul 2006 07:39:36 -0700 (PDT) Subject: Re: [Ietf-behave] Question regarding rfc3489bis-03 In-Reply-To: <200607041502.32615.nils@iptel.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Tue, 4 Jul 2006, Nils Ohlmeier wrote: > while reading through the document draft-ietf-behave-rfc3489bis-03.txt we > stumbled across the sentence "The most significant two bits of every STUN > message are 0b00." on page 10. > I think this an error because '0b00' implies that the value is given in > hexadecimal (because of the b). But in this case '0b00' would two bytes and > not two bits. It's common practice to represent binary numbers as a string beginning with "0b", just as hex numbers are represented as strings beginning with "0x". > No matter if we are talking about two bits or bytes I do not get how the value > 0x0b00 should appear in the beginning of a STUN message (in the message type > field). The field beginning with 0b00 is interpreted as a big-endian binary number. Its two high order bits are both zero. -- Jim Dixon jdd@xxxxxxxxxx tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure From guibv@comunip.com.br Wed, 5 Jul 2006 04:51:12 -0700 (PDT) From: Guilherme Balena Versiani Date: Wed, 5 Jul 2006 04:51:12 -0700 (PDT) Subject: Re: [Ietf-behave] Question regarding rfc3489bis-03 In-Reply-To: <200607041502.32615.nils@iptel.org> Message-ID: <44ABA799.5060003@comunip.com.br> MIME-Version: 1.0 Content-Type: text/plain Maybe if you use some pseudo-code in draft-ietf-behave-rfc3489bis-03.txt things become clear: #define IS_STUN(packet) (((packet)[0] & 0xc0) == 0x00) /* 0xc0 = 0b11000000 */ Regards, Guilherme Balena Versiani. ComunIP S/A Jim Dixon escreveu: On Tue, 4 Jul 2006, Nils Ohlmeier wrote: hile reading through the document draft-ietf-behave-rfc3489bis-03.txt we stumbled across the sentence "The most significant two bits of every STUN message are 0b00." on page 10. It's common practice to represent binary numbers as a string beginning with "0b", just as hex numbers are represented as strings beginning with "0x". o matter if we are talking about two bits or bytes I do not get how the value 0x0b00 should appear in the beginning of a STUN message (in the message type field). The field beginning with 0b00 is interpreted as a big-endian binary number. Its two high order bits are both zero. begin:vcard fn:Guilherme Balena Versiani n:Versiani;Guilherme org:ComunIP S/A adr;quoted-printable;quoted-printable:Bairro Funcion=C3=A1rios;;Rua Cl=C3=A1udio Manoel, 237;Belo Horizonte;MG;30140-100;Brasil email;internet:guibv@xxxxxxxxxxxxxx tel;work:(+55/31) 3284-1007 url:http://www.comunip.com.br version:2.1 end:vcard From guibv@comunip.com.br Wed, 5 Jul 2006 04:56:56 -0700 (PDT) From: Guilherme Balena Versiani Date: Wed, 5 Jul 2006 04:56:56 -0700 (PDT) Subject: Re: [Ietf-behave] Question regarding rfc3489bis-03 In-Reply-To: <200607041502.32615.nils@iptel.org> Message-ID: <44ABA8F2.3040507@comunip.com.br> MIME-Version: 1.0 Content-Type: text/plain Just another version, this time considering the STUN magic cookie: #define STUN_MAGIC_COOKIE 0x2112A442 #define IS_STUN(packet) \ ((((packet)[0] & 0xc0) == 0x00) && \ (((uint32_t *) packet)[1] == htonl(STUN_MAGIC_COOKIE)) Guilherme Balena Versiani escreveu: Maybe if you use some pseudo-code in draft-ietf-behave-rfc3489bis-03.txt things become clear: #define IS_STUN(packet) (((packet)[0] & 0xc0) == 0x00) /* 0xc0 = 0b11000000 */ Regards, Guilherme Balena Versiani. ComunIP S/A Jim Dixon escreveu: On Tue, 4 Jul 2006, Nils Ohlmeier wrote: hile reading through the document draft-ietf-behave-rfc3489bis-03.txt we stumbled across the sentence "The most significant two bits of every STUN message are 0b00." on page 10. It's common practice to represent binary numbers as a string beginning with "0b", just as hex numbers are represented as strings beginning with "0x". o matter if we are talking about two bits or bytes I do not get how the value 0x0b00 should appear in the beginning of a STUN message (in the message type field). The field beginning with 0b00 is interpreted as a big-endian binary number. Its two high order bits are both zero. begin:vcard fn:Guilherme Balena Versiani n:Versiani;Guilherme org:ComunIP S/A adr;quoted-printable;quoted-printable:Bairro Funcion=C3=A1rios;;Rua Cl=C3=A1udio Manoel, 237;Belo Horizonte;MG;30140-100;Brasil email;internet:guibv@xxxxxxxxxxxxxx tel;work:(+55/31) 3284-1007 url:http://www.comunip.com.br version:2.1 end:vcard From srisuresh@yahoo.com Wed, 5 Jul 2006 06:41:48 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 5 Jul 2006 06:41:48 -0700 (PDT) Subject: Re: [Ietf-behave] Issue 2 - ICMP draft issues from the IETF 65 WG meeting In-Reply-To: <20060628151858.57206.qmail@web33301.mail.mud.yahoo.com> Message-ID: <20060705134144.27951.qmail@web33309.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Folks, I will make an explicit mention of the mandatory requirement to support ICMP error messages for "hairpinned flows". I could do this by including this statement within Req-5. Thanks. cheers, suresh --- Pyda Srisuresh wrote: > > > --- Saikat Guha wrote: > > > On Sat, 2006-06-24 at 07:11 -0700, Pyda Srisuresh wrote: > > > REQ-4: If a NAT device receives an ICMP error packet from external > > > realm, and the NAT does not have an active mapping for the embedded > > > payload, the NAT SHOULD silently drop the ICMP error packet. If the > > > the NAT has active mapping for the embedded payload, then the NAT > > > MUST transparently forward the ICMP error message, without modifying > > > the ICMP error type or code as follows. > > > a) The NAT MUST revert the IP and transport headers of the embedded > > > IP packet to their original form, using the matching mapping. > > > > It should be made clear that the 'mapping' here refers to the mapping > > used by the TCP or UDP protocol modules and not the ICMP mapping (the > > ICMP mapping is for ICMP request-response packets only). > > [suresh] The text "active mapping for the embedded payload" refers eactly > that. > If the embedded payload is a TCP/UDP packet, the text refers the active > mapping > for the TCP/UDP packet. If the embedded payload is an ICMP query packet, the > text refers the active mapping for the ICMP query packet. No matter what the > embedded packet is, the text refers the active mapping for the embedded > packet. > > > Also, the > > 'exteral realm' business doesn't specify what happens to ICMP errors on > > hairpinned UDP/TCP connection. > > [suresh] Hairpinning is required for TCP/UDP flows. So, when a NAT supports > hairpining for a TCP/UDP flow, Req-5a enforces translation for the embedded > TCP/UDP packet automagically. > > As for Hairpinning with regard to ICMP error messages, NAT sees this as an > ICMP > error message coming from a private realm. So, Req-5 addresses the > hairpinning > for ICMP error messages. > > > Perhaps something along the lines of: > > > > REQ-x: If a NAT device receives an ICMP error packet, it must use the > > mapping that matches the embedded packet for translating the ICMP error. > > If such a mapping does not exist, the NAT SHOULD silently drop the ICMP > > error packet. If the mapping exists, the NAT MUST transparently forward > > the ICMP error. > > a) A NAT must translate both the other header and the embedded packet > > according to the mapping. > > > [suresh] Please see my note above. > > > > b) The NAT device MUST modify the destination IP address of the > > > outer IP header to be same as the source IP address of the embedded > > > IP packet after the translation. > > > c) Lastly, the NAT MUST update the IP and ICMP checksums in the > > > outer headers to reflect the above changes. > > > > Requirement b) and c) seem out of place -- they read like pseudo-code > > for a NAT implementation written in prose. Unless the idea is to give a > > complete pseudo-code implementation of a NAT, they can likely be dropped > > in favor of the principles behind them. > > > [suresh] The three subsection of Req-4 and Req-5 identify specfic > requirements. > Req-4a and Req-5a specify the requirement on how the embedded payload should > be > translated. Req-4b and Req-5b specify how the outer IP adresses must be > selected for translation. See sections 4.2.1 and 4.2.2 for details leading > up > to Req-4b and 5b. Req-4c and Req-5c specify that the IP/ICMP checksums should > be updated to reflect the previous two changes (i.e.,4a+4b or 5a+5b). > > Potentially, Req-4c and Req-5c could be dropped, as they are assumed to be > done > by all NAT devices. However, when a NAT does not update ICMP checksum, many > end > host stacks woudl drop the ICMP error packets. Refer Fernano's draft. Hence, > REQ-4c and REQ-5c are included to reinforce the requirement to update ICMP > checksum. > > > > > > REQ-5: If a NAT device receives an ICMP error packet from private > > > realm, and the NAT does not have an active mapping for the embedded > > > payload, the NAT SHOULD silently drop the ICMP error packet. If the > > > the NAT has active mapping for the embedded payload, then the NAT > > > MUST transparently forward the ICMP error message, without modifying > > > the ICMP error type or code as follows. > > > a) The NAT MUST revert the IP and transport headers of the embedded > > > IP packet to their original form, using the matching mapping. > > > b) If the NAT device has active mapping for the ICMP error packet > > > originator, the NAT MUST translate the source IP address of the > > > ICMP error packet with the public IP address in the mapping. > > > Otherwise, the NAT MUST translate the source IP address of the ICMP > > > error packet with its own public IP address. > > > c) Lastly, the NAT MUST update the IP and ICMP checksums in the > > > outer headers to reflect the above changes. > > > > See the proposed REQ-x above. It subsumes this case. > > > [suresh] Please see my notes above. > > cheers, > suresh > > -- > > Saikat > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From jdrosen@cisco.com Wed, 5 Jul 2006 14:10:05 -0700 (PDT) From: Jonathan Rosenberg Date: Wed, 5 Jul 2006 14:10:05 -0700 (PDT) Subject: Re: [Ietf-behave] Conflicting Error Codes In-Reply-To: <01C679F7AECF2B47B489F735B7EE49000131D632@47mail.eu.tandberg.int> Message-ID: <44AC2AAA.9030003@cisco.com> MIME-Version: 1.0 Content-Type: text/plain This is an error in the stun spec, which has been corrected to use 438 for stale nonce. -Jonathan R. Peter Livesey wrote: Rohan, There is a clash of error codes between the base STUN (well draft 03) and the TURN usage (turn-01). In 3489bis error 437 indicates a "stale nonce", this clashes with the "no binding" error in turn-01. It could be confusing to a client who receives an error response to an authenticated SetActiveDestination request. Did the request fail due to the binding not being there or because the authentication failed? I guess in the stale nonce case the error response would contain another nonce, but would it not be cleaner to not have to do this? Forgive me if this is already being addressed in the next revision of rfc3489bis. Cheers, Pete L. Peter Livesey Senior Software Engineer Phone: +441189348712 Fax: +441189348716 Video: peter.livesey@xxxxxxxxxxxxxxxxxx E-mail: peter.livesey@xxxxxxxxxxxx Video Phone: +441189348712 Unit 8a Castle End Business Park, Castle End Road Ruscombe, Berkshire RG10 9XQ, United Kingdom _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Wed, 5 Jul 2006 14:11:22 -0700 (PDT) From: Jonathan Rosenberg Date: Wed, 5 Jul 2006 14:11:22 -0700 (PDT) Subject: Re: [Ietf-behave] Question regarding rfc3489bis-03 In-Reply-To: <200607041502.32615.nils@iptel.org> Message-ID: <44AC2AF4.3030509@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Generally IESG frowns upon pseudcocode. Here its really not needed anyway. I removed the 0b00 terminology and simply stated that the first two bits are both zeroes. -Jonathan R. Guilherme Balena Versiani wrote: Just another version, this time considering the STUN magic cookie: #define STUN_MAGIC_COOKIE 0x2112A442 #define IS_STUN(packet) \ ((((packet)[0] & 0xc0) == 0x00) && \ (((uint32_t *) packet)[1] == htonl(STUN_MAGIC_COOKIE)) Guilherme Balena Versiani escreveu: Maybe if you use some pseudo-code in draft-ietf-behave-rfc3489bis-03.txt things become clear: #define IS_STUN(packet) (((packet)[0] & 0xc0) == 0x00) /* 0xc0 = 0b11000000 */ Regards, Guilherme Balena Versiani. ComunIP S/A Jim Dixon escreveu: On Tue, 4 Jul 2006, Nils Ohlmeier wrote: hile reading through the document draft-ietf-behave-rfc3489bis-03.txt we stumbled across the sentence "The most significant two bits of every STUN message are 0b00." on page 10. It's common practice to represent binary numbers as a string beginning with "0b", just as hex numbers are represented as strings beginning with "0x". o matter if we are talking about two bits or bytes I do not get how the value 0x0b00 should appear in the beginning of a STUN message (in the message type field). The field beginning with 0b00 is interpreted as a big-endian binary number. Its two high order bits are both zero. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Wed, 5 Jul 2006 14:17:17 -0700 (PDT) From: Jonathan Rosenberg Date: Wed, 5 Jul 2006 14:17:17 -0700 (PDT) Subject: Re: [Ietf-behave] REALM in draft-ietf-behave-rfc3489bis-03 In-Reply-To: <445F6E5B.7050703@research.panasonic.com> Message-ID: <44AC2C5C.2010702@cisco.com> MIME-Version: 1.0 Content-Type: text/plain inline. Greg Daley wrote: Hi, I've got a question about use of REALM in RFC3489bis-03, which was raised by one of our developers. Is it necessary to test for the REALM attribute in received Request messages, even if Short Term credentials are being used? REALM is not used with short term credentials, no. When using method two from Section 8.1.2: 2. use a short term credential, as determined by the STUN usage. In this case, the STUN Request or STUN Indication would contain the USERNAME and MESSAGE-INTEGRITY attributes. The message would not contain the NONCE attribute. The key for MESSAGE-INTEGRITY is the password. There's no REALM, but in section 9.1.1 (paragraph 2 of page 18): If the MESSAGE-INTEGRITY attribute was present, the server checks for the existence of the REALM attribute. If the attribute is not present, the server MUST generate an error response. That error response MUST include an ERROR-CODE attribute with response code of 434. That error response MUST also include a NONCE and a REALM attribute. This seems to conflict, in that it implies that the REALM is always present if MESSAGE-INTEGRITY is present. Yes, this was a bug. I have fixed it in -04. -03 had two sections on authentication which were in conflict. One focused entirely on long term credential authentication, and the other had the more general procedures. Also, it's not exactly obvious in the document, what constitutes Short Term and Long Term authentication. It is possible to infer that Short Term authentication is using Shared Secret Request, ICE or equivalent, but there's little description of Long Term authentication (reference to 3261 section 22 is probably appropriate). The most appropriate description of the terms I found was in: http://permalink.gmane.org/gmane.ietf.nat.behave/776 Clarification within the document would be appreciated. Hopefully -04 is clearer in this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From rohan.mahy@gmail.com Wed, 5 Jul 2006 14:35:21 -0700 (PDT) From: "Rohan Mahy" Date: Wed, 5 Jul 2006 14:35:21 -0700 (PDT) Subject: Re: [Ietf-behave] Question regarding rfc3489bis-03 In-Reply-To: <200607041502.32615.nils@iptel.org> Message-ID: <953beacc0607051435v4241c3bfw5f5a48be31db2b7e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Hi Jim, Well it really isn't *common* practice to represent binary this way. It is a convention, but it is hardly used these days and is likely to be unfamiliar to many. the 0x notation for hex is common practice, but binary and octal notation are going the way of the dodo. thanks, -rohan On 7/4/06, Jim Dixon wrote: On Tue, 4 Jul 2006, Nils Ohlmeier wrote: > while reading through the document draft-ietf-behave-rfc3489bis-03.txt we > stumbled across the sentence "The most significant two bits of every STUN > message are 0b00." on page 10. > I think this an error because '0b00' implies that the value is given in > hexadecimal (because of the b). But in this case '0b00' would two bytes and > not two bits. It's common practice to represent binary numbers as a string beginning with "0b", just as hex numbers are represented as strings beginning with "0x". > No matter if we are talking about two bits or bytes I do not get how the value > 0x0b00 should appear in the beginning of a STUN message (in the message type > field). The field beginning with 0b00 is interpreted as a big-endian binary number. Its two high order bits are both zero. -- Jim Dixon jdd@xxxxxxxxxx tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From jdrosen@cisco.com Wed, 5 Jul 2006 15:07:28 -0700 (PDT) From: Jonathan Rosenberg Date: Wed, 5 Jul 2006 15:07:28 -0700 (PDT) Subject: [Ietf-behave] rfc3489bis-04 available Message-ID: <44AC3812.9090902@cisco.com> MIME-Version: 1.0 Content-Type: text/plain A few folks commented to me that they never saw rfc3489bis-04 appear in the I-D announcements. Thats because I missed the deadline :( However, I did finally finish -04, and I've posted it on my website. I'll submit it during IETF week once the blackout period ends. You can pick it up right now at: http://www.jdrosen.net/papers/draft-ietf-behave-rfc3489bis-04.txt Mostly this revision was about completing the concept of a base specification and the various usages. However, there is some new stuff in here. The full set of changes is: * changed protocol name to Simple Traversal Underneath NAT - same acronym, but reflects fact that even binding requests now run over tcp * fixed the major bug on attribute lengths not being byte aligned. The solution in the document is that, if an attribute value is not a multiple of four bytes, you pad to a multiple of four, and then the length refers to the length *prior* to padding. This IS backwards compatible with rfc3489, since it required attributes to be 32 bit aligned. However it is not forward compatible, but nothing would be for values that are not 32 bit aligned. * massive cleanup on introduction * added notion of tcp transactions failing if there is no response whatsoever after 9500ms. * added notion of indications failing due to icmp errors, allowed to retry on a different server just like requests * removed redundant message number allocations for shared secret requests/responses/error * SRV processing is now per my proposal in Dallas. There is an SRV usage for the binding discovery with the service name "stun" and one for password determination called "stun-pass" (previously stun-tls). The transport protocol can be udp, tcp or tls for the binding discovery, and only tls for stun-pass. There is no NAPTR defined. Recommending that other stun usages that require dns service names have them start with "stun". Default port is 3478 for ALL usages if there is no SRV record, but only for tcp/udp. No default for TLS. This will require STUN server to have separate ports in DNS for tcp and tcp/tls. Note however that the tcp/tls port can be shared across different application usages (i.e., shared secret and binding discovery both of which can run over tls). * added more detailed procedures for TLS, on verifying certificates and baseline ciphersuite * lots more details on the authentication procedures, including detailed client behaviors for each response code, specific nonce handling procedures, linkages into the stun usage, clear handling for the two different types of credentials. A fallout of this update is the indications can be authenticated using short-term credentials, since those don't require challenges. This might come in handy in the future. * added Adam's proposed text on computation of the key for the HMAC, and clarified that the binary output of the md5 hash is used * removed XOR-ONLY remnants, removed REALM from table of attributes applicable to success responses. Add indication messages to table of attributes * removed RESPONSE-ADDRESS, CHANGED-ADDRESS, CHANGE-REQUEST, SOURCE-ADDRESS, REFLECTED-FROM * 500 response can trigger client to try request on a different server if the server was found through DNS SRV. 600 responses should never trigger a retry on another server * removed open issue about XOR-MAPPED-ADDR including the port: better safe than sorry * renamed BINDING-LIFETIME to REFRESH-INTERVAL and better defined its usage and motivation * for binding discovery usage, spceify that if a client isn't explicitly configured with the hostname of a stun server, it justs the domain portion of the AOR in the SRV processing. This allows for discovery of stun servers with sip as long as the client knows its AOR. * for short-term password usage, authentication of Shared Secret request is possible using long-term password now. Added in needed details on server processing, construction of username and password, and security considerations. * ALTERNATE-SERVER code is 0x8023 (was listed twice before) * updated security considerations and IAB considerations to reflect split into usages * changed stale nonce error code from 437 to 438 to avoid conflict with turn * added FINGERPRINT attribute to facilitiate in STUn demux. It is a SHA-1 hash of the STUN message, without any kind of shared secret. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From Remi.Denis-Courmont@nokia.com Thu, 6 Jul 2006 03:51:36 -0700 (PDT) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Date: Thu, 6 Jul 2006 03:51:36 -0700 (PDT) Subject: Re: [Ietf-behave] rfc3489bis-04 available In-Reply-To: <44AC3812.9090902@cisco.com> Message-ID: <200607061351.20995.Remi.Denis-Courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain Hello, Le Thursday 06 July 2006 01:07, ext Jonathan Rosenberg a crit: > http://www.jdrosen.net/papers/draft-ietf-behave-rfc3489bis-04.txt > * added notion of indications failing due to icmp errors, allowed to > retry on a different server just like requests If IPv6 is to be retained, ICMPv6 should be added. There is however, IMHO, one big open issue with allowing STUN over IPv6: in case involving DNS SRV queries, the document defines no guidelines as to how the STUN servers should be deployed wrt the two IP versions, and/or how dual-stack STUN clients should handle a STUN server that would have both AAAA and A record. it is my understanding that applying standard RFC 3493-ish getaddrinfo() iteration would be highly suboptimal: in the (more and more common nowadays) case of a dual-stack host with a public IPv6 address and a private NATed IPv4 address, we'd most likely end up with STUN returning the public IPv6 mapping. That mapping would be the same as the internal transport socket address on the client. That means not only that STUN would be quite redundant, but that it would fail to return useful informations if the client later tries to contact an IPv4 only node. An obvious solution would be to query either AAAA or A records only based on the address family that the clients wishes to use. Unfortunately, this does not work because of the NAT-PT-style support that is now explicitly added into STUN. So the only (slow and complicated) solution seems to be to perform STUN binding allocation for both IPv4 and IPv6 in any case, whenever both the client and the server are operating dual-stack. Because this is far from obvious, I think it should definitely be discussed and referred to in the new STUN spec (regardless of what ICE does/does not do - that's separated). > * (...) other stun usages that require dns service > names have them start with "stun". It should probably be "stun-" for the sake of readability and consistency with "stun-pass". On page 18, "8.1as" should be "8.1 as". Unless it breaks backward compatibility, the first byte of MAPPED-ADDRESS might rather have to be zeroed when sending, and ignored on receival, the same way most other IETF protocols defines undefined bits. Same remarks wrt XOR-MAPPED-ADDRESS (which has no backward compat. consideration). -- Rmi Denis-Courmont Assistant Research Engineer From Remi.Denis-Courmont@nokia.com Thu, 6 Jul 2006 05:44:02 -0700 (PDT) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Date: Thu, 6 Jul 2006 05:44:02 -0700 (PDT) Subject: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP Message-ID: <200607061544.09721.Remi.Denis-Courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain Hello again, I see that the odd/even allocation "feature" was re-introduced into the TURN draft as it switched to the BEHAVE wg. I understand people want to be interoperable (in this case with very old RTCP implementations), but there are some big problems with the whole odd/even ports thing. First, that does really not fit at all within the BSD socket API, which virtually every body uses nowadays; you have no way to request a odd port (it's either one particular port though it might be in use by another agent, or any available port). The idea of linking the RTCP port to the RTP port is OK when sending multicast (where there is no port allocation from the socket API), but it's quite disturbing when doing unicast, regardless of the NAT traversal issue (and hence even with IPv6). Secondly, introducing support for this into TURN (besides extra complexity) means people will have to use TURN *always* if they are behind a NAT. It is my understanding that we want UAs to limit usage of TURN to when there is really no other options (as determined via ICE). Yet, there is obviously no way to support a odd/even port tuple from one's NAT, meaning the only way to get it to work are UPnP and TURN. If one stick to relaying-less STUN, that does not work anyhow, so why implement it in TURN at all? Ultimately, there is no way to be 100% compatible with old NAT-unfriendly UAs (asymmetric RTP UA being another case of backward compatibility breakage). Besides, RTCP should not be absolutely required for RTP to basically work in most real-life cases. IMHO, the extra complexity of implementing this into TURN implementations, the fact that it incites blind use of TURN regardless of otherwise better NAT traversal solutions, and the lack of simple way to determine when it is actually needed pretty much outweigh the little benefit provided. -- Rmi Denis-Courmont From petithug@acm.org Thu, 6 Jul 2006 05:46:41 -0700 (PDT) From: Marc Petit-Huguenin Date: Thu, 6 Jul 2006 05:46:41 -0700 (PDT) Subject: Re: [Ietf-behave] rfc3489bis-04 available In-Reply-To: <44AC3812.9090902@cisco.com> Message-ID: <44AD062E.9060003@acm.org> MIME-Version: 1.0 Content-Type: text/plain Hi Jonathan, Some comments on this draft: o Section 8.3.1: The 2nd procedure says about short term credential that "The message would not contain the NONCE attribute." But paragraph 7 says that "The NONCE is included in the request only if a short or long term credential is being used..." o Section 12.1.1.11.9, paragraph 10: "That allows the server to meet the requirements specified in section 8.1 for constructing the REFLECTED-FROM attribute." As this attribute no longer exist, I thing this sentence should be removed. o Section 15.2: The RESPONSE-ADDRESS attribute is no longer used and should be removed. The INTEGRITY and BINDING-LIFETIME attributes are missing. Some nits: o Section 6, paragraph 12: "...that they are a multiple of 4 btyes." o Section 8.3.2, paragraph 4: "If the REALM attribute was absent in the resposne..." o Section 9.1.1, paragraph 9: "...an error response with an ERROR-CDE..." o Section 9.1.2, paragraph 3: "...carrying the souce IP address..." o Section 11.12, paragraph 2: "This attribute is MUST only appear..." o Section 11.13, paragraph 1: "The REFRESH-INTERVAL provies..." o Section 12.1.1.9.1, paragraph 1: "...are viable for direct communciations." o 12.1.1.9.3, paragraph 1: "...because it signalsed..." Jonathan Rosenberg wrote: > A few folks commented to me that they never saw rfc3489bis-04 appear in > the I-D announcements. Thats because I missed the deadline :( > > However, I did finally finish -04, and I've posted it on my website. > I'll submit it during IETF week once the blackout period ends. You can > pick it up right now at: > > http://www.jdrosen.net/papers/draft-ietf-behave-rfc3489bis-04.txt > -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx From srisuresh@yahoo.com Thu, 6 Jul 2006 07:48:51 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 6 Jul 2006 07:48:51 -0700 (PDT) Subject: [Ietf-behave] TCP Issue #1 - Repetetion of ICMP requirements in the TCP draft In-Reply-To: <200607061351.20995.Remi.Denis-Courmont@nokia.com> Message-ID: <20060706144847.98336.qmail@web33304.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Folks, I have taken the liberty of numbering this as issue #1 for TCP, purely for the sake of tracking. That is not to say, there are no prior issues. We just have to start somewhere for tracking by number. Thanks. Anyways, below is the issue with the latest rev of the TCP draft. A new requirement (Req-9) was added to the latest TCP draft (draft-ietf-behave-tcp-01.txt) that overlaps ICMP requirement(s). The requirement was pretty much lifted from the UDP draft (REQ-12 and Req-12. For some reason, REQ-12b was dropped). I raised the issue with regard to repeating ICMP requirements in the protocol drafts during the IESG review of the UDP draft. But, UDP draft was an exception because it was the first draft and folks wanted to get the UDP RFC out soon. I believe, it would be a bad precedent to repeat ICMP requirements in the TCP draft. ICMP draft is a WG draft now. I donot see why the ICMP requirements should be repeated in the TCP draft, and other future protocol drafts. I believe, protocol drafts (TCP and onwards) ought to simply refer the ICMP draft for ICMP requirements unless there is a specific exception. Below is REQ-9 from the TCP draft. REQ-9: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping or TCP connection for which the ICMP was generated. a) The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address. REQ-4 and REQ-5 of the ICMP draft state the requirements for forwarding ICMP error messages. These ICMP reeuirements overlap with REQ-9a above from the TCP draft. REQ-6 of the ICMP draft directly overlaps with the first sentence of REQ-9 from the TCP draft. Below is REQ-6 from the ICMP draft. REQ-6: While processing an ICMP error packet, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP error packet. cheers, suresh From jdrosen@cisco.com Thu, 6 Jul 2006 09:25:00 -0700 (PDT) From: Jonathan Rosenberg Date: Thu, 6 Jul 2006 09:25:00 -0700 (PDT) Subject: [Ietf-behave] STUN/TURN unified attribute list Message-ID: <44AD395B.6030302@cisco.com> MIME-Version: 1.0 Content-Type: text/plain We seem to constantly have problems getting the attribute numbering across TURN, STUN and turn-v6 consistent, non-overlapping and complete. I have gone through the most recent revisions of each of the drafts along with the old rfc3489 and enumerated what I think is the complete set. If folks see any omissions or problems please advise: stun-04 0x0001: MAPPED-ADDRESS HISTORIC 0x0002: RESPONSE-ADDRESS HISTORIC 0x0003: CHANGE-REQUEST HISTORIC 0x0004: SOURCE-ADDRESS HISTORIC 0x0005: CHANGED-ADDRESS stun-04 0x0006: USERNAME stun-04 0x0007: PASSWORD stun-04 0x0008: MESSAGE-INTEGRITY stun-04 0x0009: ERROR-CODE stun-04 0x000a: UNKNOWN-ATTRIBUTES HISTORIC 0x000b: REFLECTED-FROM turn-01 0x000c: LIFETIME turn-01 0x0010: BANDWIDTH turn-01 0x0012: REMOTE-ADDRESS turn-01 0x0013: DATA stun-04 0x0014: REALM stun-04 0x0015: NONCE turn-01 0x0016: RELAY-ADDRESS v4/v6-00 0x0017: REQUESTED-ADDRESS-TYPE turn-01 0x0018: REQUESTED-PORT turn-01 0x0019: REQUESTED-TRANSPORT stun-04 0x0020: XOR-MAPPED-ADDRESS turn-01 0x0021: TIMER-VAL turn-01 0x0022: REQUESTED-IP stun-04 0x0023: FINGERPRINT stun-04 0x8022: SERVER stun-04 0x8023: ALTERNATE-SERVER stun-04 0x8024: REFRESH-INTERVAL Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From petithug@acm.org Thu, 6 Jul 2006 09:48:10 -0700 (PDT) From: Marc Petit-Huguenin Date: Thu, 6 Jul 2006 09:48:10 -0700 (PDT) Subject: Re: [Ietf-behave] STUN/TURN unified attribute list In-Reply-To: <44AD395B.6030302@cisco.com> Message-ID: <44AD3EC8.70705@acm.org> MIME-Version: 1.0 Content-Type: text/plain Hi Jonathan, Inline. Jonathan Rosenberg wrote: > We seem to constantly have problems getting the attribute numbering > across TURN, STUN and turn-v6 consistent, non-overlapping and complete. > I have gone through the most recent revisions of each of the drafts > along with the old rfc3489 and enumerated what I think is the complete > set. If folks see any omissions or problems please advise: > > stun-04 0x0001: MAPPED-ADDRESS > HISTORIC 0x0002: RESPONSE-ADDRESS > HISTORIC 0x0003: CHANGE-REQUEST > HISTORIC 0x0004: SOURCE-ADDRESS > HISTORIC 0x0005: CHANGED-ADDRESS > stun-04 0x0006: USERNAME > stun-04 0x0007: PASSWORD > stun-04 0x0008: MESSAGE-INTEGRITY > stun-04 0x0009: ERROR-CODE > stun-04 0x000a: UNKNOWN-ATTRIBUTES > HISTORIC 0x000b: REFLECTED-FROM > turn-01 0x000c: LIFETIME > turn-01 0x0010: BANDWIDTH > turn-01 0x0012: REMOTE-ADDRESS > turn-01 0x0013: DATA > stun-04 0x0014: REALM > stun-04 0x0015: NONCE REALM was 0x0015 and NONCE 0x0014 in draft-rosenberg-midcom-turn-08. There is existing deployments of turn-08, so perhaps it would be less confusing to keep the same values. Also for the same reasons, perhaps some historical attributes existing only in turn-08 should be documented (DESTINATION-ADDRESS=0x0011, MAGIC-COOKIE=0x000F, LIFETIME=0x000D, XOR-ONLY=0x0021) > turn-01 0x0016: RELAY-ADDRESS > v4/v6-00 0x0017: REQUESTED-ADDRESS-TYPE > turn-01 0x0018: REQUESTED-PORT > turn-01 0x0019: REQUESTED-TRANSPORT > stun-04 0x0020: XOR-MAPPED-ADDRESS > turn-01 0x0021: TIMER-VAL > turn-01 0x0022: REQUESTED-IP > stun-04 0x0023: FINGERPRINT > > stun-04 0x8022: SERVER > stun-04 0x8023: ALTERNATE-SERVER > stun-04 0x8024: REFRESH-INTERVAL -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx From fluffy@cisco.com Fri, 7 Jul 2006 22:24:10 -0700 (PDT) From: Cullen Jennings Date: Fri, 7 Jul 2006 22:24:10 -0700 (PDT) Subject: [Ietf-behave] Question about ICMP scope and how we split it over documents Message-ID: <72AAADE2-08D8-4DA9-BE5E-50F9CEE99496@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Some folk were discussing the ICMP draft on a call the other day and it came up that there was some lack of agreement about the overall scope. We wanted to sort out the WG as a whole view of the scope here. I'll try to describe the two views - no doubt I will get the words less than perfect but hopefully I will get them close enough. S o the questions is about which documents get different parts of the ICMP behavior defined in them. Everyone on the call agreed that the scope was limited to describing the overall behaviors of NATs such that NATs would, as much as possible and still be deployable NATs, not break applications or protocols that used ICMP and define the NAT handling of ICMP such that the NATs did not have non deterministic behavior from the point of view of the applications. Everyone also agreed that the draft-ietf-behave-nat-icmp draft should define the behavior of NAT when handling ICMP requests and also handing ICMP responses that were generated by hosts in response to these ICMP requests - clearly things like ICMP ping is in the scope of the behave-nat-icmp draft. Where everyone did not agree had to do with the question of which document defines the handling of ICMP messages that were generated in response to messages sent by some other protocol type such as UDP or TCP. View 1) This view was that the ICMP handling messages caused by protocol X should be described in the behave document for protocol X. The argument for this view was more or less that long ago we had tried to do this all in an ICMP document, it looked confusing to implementers to have them in separate documents and the WG had decided to move that part of the ICMP handling into the protocol documents (such as UDP and TCP). View 2) Did not remember a decision to organize the WG documents that way. They were uncomfortable with that organization. I'm not sure anyone actually said it on the call but I expect the proponents of this view would point out that having the stuff you need for ICMP spread across multiple documents seems like a bad idea. None of the people on the call are big fans of going back and remaking decisions that are already made - So the question is, what are others people recollection of our plan here? Was a decision made on this? Thanks, Cullen From srisuresh@yahoo.com Sat, 8 Jul 2006 09:15:04 -0700 (PDT) From: Pyda Srisuresh Date: Sat, 8 Jul 2006 09:15:04 -0700 (PDT) Subject: Re: [Ietf-behave] Question about ICMP scope and how we split it over documents In-Reply-To: <72AAADE2-08D8-4DA9-BE5E-50F9CEE99496@cisco.com> Message-ID: <20060708161502.18327.qmail@web33303.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > > Some folk were discussing the ICMP draft on a call the other day and > it came up that there was some lack of agreement about the overall > scope. We wanted to sort out the WG as a whole view of the scope > here. I'll try to describe the two views - no doubt I will get the > words less than perfect but hopefully I will get them close enough. S > [suresh] Thanks, Cullen. > o the questions is about which documents get different parts of the > ICMP behavior defined in them. Everyone on the call agreed that the > scope was limited to describing the overall behaviors of NATs such > that NATs would, as much as possible and still be deployable NATs, > not break applications or protocols that used ICMP and define the NAT > handling of ICMP such that the NATs did not have non deterministic > behavior from the point of view of the applications. Everyone also > agreed that the draft-ietf-behave-nat-icmp draft should define the > behavior of NAT when handling ICMP requests and also handing ICMP > responses that were generated by hosts in response to these ICMP > requests - clearly things like ICMP ping is in the scope of the > behave-nat-icmp draft. Where everyone did not agree had to do with > the question of which document defines the handling of ICMP messages > that were generated in response to messages sent by some other > protocol type such as UDP or TCP. [suresh] Your comment is whether processing of ICMP error messages is in the scope of ICMP draft or not. Well, we did discuss this specific issue extensively during the draft review with the WG chair. You were also on all the e-mails. The conclusion of the discussion was to make ICMP error hadling text protocol agnostic as in REQ-4 and REQ-5 (stated below,for ease of reference). The main body of the text in REQ-4 and REQ-5 refers to looking up the embedded payload amongst active mappings, no matter what protocol or application the payload belongs to. Req-4a and Req-5a says that NAT MUST revert the embedded IP packet to its original form, using the matching mapping. Once again, this is completely protocol agnostic. REQ-4: If a NAT device receives an ICMP error packet from external realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP error packet. If the the NAT has active mapping for the embedded payload, then the NAT MUST transparently forward the ICMP error message, without modifying the ICMP error type or code as follows. a) The NAT MUST revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping. b) The NAT device MUST modify the destination IP address of the outer IP header to be same as the source IP address of the embedded IP packet after the translation. c) Lastly, the NAT MUST update the IP and ICMP checksums in the outer headers to reflect the above changes. REQ-5: If a NAT device receives an ICMP error packet from private realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP error packet. If the the NAT has active mapping for the embedded payload, then the NAT MUST transparently forward the ICMP error message, without modifying the ICMP error type or code as follows. a) The NAT MUST revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping. b) If the NAT device has active mapping for the ICMP error packet originator, the NAT MUST translate the source IP address of the ICMP error packet with the public IP address in the mapping. Otherwise, the NAT MUST translate the source IP address of the ICMP error packet with its own public IP address. c) Lastly, the NAT MUST update the IP and ICMP checksums in the outer headers to reflect the above changes. > > View 1) This view was that the ICMP handling messages caused by > protocol X should be described in the behave document for protocol X. > The argument for this view was more or less that long ago we had > tried to do this all in an ICMP document, it looked confusing to > implementers to have them in separate documents and the WG had > decided to move that part of the ICMP handling into the protocol > documents (such as UDP and TCP). > > View 2) Did not remember a decision to organize the WG documents that > way. They were uncomfortable with that organization. I'm not sure > anyone actually said it on the call but I expect the proponents of > this view would point out that having the stuff you need for ICMP > spread across multiple documents seems like a bad idea. > [suresh] Yes, I do believe, it is a bad idea to repeat ICMP error handling in protocol specific documents. ICMP error handliong as described in REQ-4 and REQ-5 in the ICMP draft is protocol agnostic and applies to all protocols. > None of the people on the call are big fans of going back and > remaking decisions that are already made - So the question is, what > are others people recollection of our plan here? Was a decision made > on this? [suresh] Cullen - This is not the question of who recalls what from the past. We have the ICMP draft as WG document, for the first time, now. Let us review what should be in the scope of this document and whether the document is covering material that is protocol specific. The specific issue you raise apparantly did come up during the last WG meeting. Dan had specifically raised this point with me during the internal draft review. We agreed the initial wording that was used (ether in the presentation or in earlier versions of the draft) was the teh cause of confusion. So, we fixed the the wording in REQ-4 and REQ-5 such that such that they are prorocol agnostic. I believe, the questions are really the following. a) IS ICMP error message handling within the scope of the ICMP draft? b) Are any of the requirements in the ICMP draft protocol specific? Thanks. regards, suresh > > Thanks, > Cullen > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From fluffy@cisco.com Mon, 10 Jul 2006 21:25:07 -0700 (PDT) From: Cullen Jennings Date: Mon, 10 Jul 2006 21:25:07 -0700 (PDT) Subject: Re: [Ietf-behave] Question about ICMP scope and how we split it over documents In-Reply-To: <20060708161502.18327.qmail@web33303.mail.mud.yahoo.com> Message-ID: <099F3257-FC48-40C9-94E6-EF5043769B70@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Jul 8, 2006, at 12:15 PM, Pyda Srisuresh wrote: [suresh] Thanks, Cullen. o the questions is about which documents get different parts of the ICMP behavior defined in them. Everyone on the call agreed that the scope was limited to describing the overall behaviors of NATs such that NATs would, as much as possible and still be deployable NATs, not break applications or protocols that used ICMP and define the NAT handling of ICMP such that the NATs did not have non deterministic behavior from the point of view of the applications. Everyone also agreed that the draft-ietf-behave-nat-icmp draft should define the behavior of NAT when handling ICMP requests and also handing ICMP responses that were generated by hosts in response to these ICMP requests - clearly things like ICMP ping is in the scope of the behave-nat-icmp draft. Where everyone did not agree had to do with the question of which document defines the handling of ICMP messages that were generated in response to messages sent by some other protocol type such as UDP or TCP. [suresh] Your comment is whether processing of ICMP error messages is in the scope of ICMP draft or not. Well, we did discuss this specific issue extensively during the draft review with the WG chair. You were also on all the e-mails. The conclusion of the discussion was to make ICMP error hadling text protocol agnostic as in REQ-4 and REQ-5 (stated below,for ease of reference). Actually, I seem to recall that I was one of the WG chairs back then and that I pointed out the same thing back then. But let's get clear about what we are talking about here - do you want to remove the ICMP handling out of the UDP document and move it to the ICMP document? I assure you many people outside behave will think that defining it in two places is a bad idea. What do you want? From fluffy@cisco.com Tue, 11 Jul 2006 05:04:42 -0700 (PDT) From: Cullen Jennings Date: Tue, 11 Jul 2006 05:04:42 -0700 (PDT) Subject: [Ietf-behave] ICMP presentation in meeting today Message-ID: <0ECD4F9F-EDE9-424C-AA31-0219CFE9DF71@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I think the authors of the ICMP document and I are having a hard time coming up with a set of slides for this meeting. This is not an immediate deliverable of the WG and I think it would be best to just cancel the ICMP presentation today. We'll keep things going on list. Cullen From magnus.westerlund@ericsson.com Tue, 11 Jul 2006 06:07:41 -0700 (PDT) From: Magnus Westerlund Date: Tue, 11 Jul 2006 06:07:41 -0700 (PDT) Subject: [Ietf-behave] Cullen Jenings steps down as Chair of Behave Message-ID: <44B3A298.20207@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Effectively immediately Cullen Jennings has stepped down as Chair of the Behave WG. Many thanks for his years of service as chair of this WG. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From dwing@cisco.com Tue, 11 Jul 2006 07:06:41 -0700 (PDT) From: "Dan Wing" Date: Tue, 11 Jul 2006 07:06:41 -0700 (PDT) Subject: [Ietf-behave] minute-taker and jabber scribe Message-ID: <027701c6a4f3$3b79e410$ca73150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I need two volunteers to take minutes, and one volunteer to type into the jabber room. Volunteers before the meeting would be appreciated so we don't waste time volunteering someone. -d From dwing@cisco.com Tue, 11 Jul 2006 07:16:27 -0700 (PDT) From: "Dan Wing" Date: Tue, 11 Jul 2006 07:16:27 -0700 (PDT) Subject: [Ietf-behave] RE: ICMP presentation in meeting today In-Reply-To: <0ECD4F9F-EDE9-424C-AA31-0219CFE9DF71@cisco.com> Message-ID: <028301c6a4f4$990190f0$ca73150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > I think the authors of the ICMP document and I are having a > hard time coming up with a set of slides for this meeting. This is > not an immediate deliverable of the WG and I think it would be > best to just cancel the ICMP presentation today. Ok, thanks for trying. We'll probably use your slot to talk about a 'diagnostics' document that may be useful for P2P (notably for P2P-SIP). > We'll keep things going on list. Alright. -d From rohan.mahy@gmail.com Tue, 11 Jul 2006 07:36:50 -0700 (PDT) From: "Rohan Mahy" Date: Tue, 11 Jul 2006 07:36:50 -0700 (PDT) Subject: Re: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP In-Reply-To: <200607061544.09721.Remi.Denis-Courmont@nokia.com> Message-ID: <953beacc0607110736w6985046fu370780200e05baa9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Rmi, TURN includes odd/even port conventions because there is a large community that wants to be able to communicate with hosts that still use the odd/even convention. We have consensus from the previous meeting to do this. What are the consequences for your UA? - You don't have to allocate your own ports using the old convention - You have the choice to ask or not to ask the TURN server for ports using the convention - You can tell if the peer doesn't need the convention if it has an a=rtcp attribute. What are the consequences for your TURN server? - You need to do a small amount of additional work to allocate ports using the convention when the TURN client asks. This number will be small and will get smaller and smaller over time. - You need to manage your port number space in TURN. thanks, -rohan On 7/6/06, Rmi Denis-Courmont wrote: Hello again, I see that the odd/even allocation "feature" was re-introduced into the TURN draft as it switched to the BEHAVE wg. I understand people want to be interoperable (in this case with very old RTCP implementations), but there are some big problems with the whole odd/even ports thing. First, that does really not fit at all within the BSD socket API, which virtually every body uses nowadays; you have no way to request a odd port (it's either one particular port though it might be in use by another agent, or any available port). The idea of linking the RTCP port to the RTP port is OK when sending multicast (where there is no port allocation from the socket API), but it's quite disturbing when doing unicast, regardless of the NAT traversal issue (and hence even with IPv6). Secondly, introducing support for this into TURN (besides extra complexity) means people will have to use TURN *always* if they are behind a NAT. It is my understanding that we want UAs to limit usage of TURN to when there is really no other options (as determined via ICE). Yet, there is obviously no way to support a odd/even port tuple from one's NAT, meaning the only way to get it to work are UPnP and TURN. If one stick to relaying-less STUN, that does not work anyhow, so why implement it in TURN at all? Ultimately, there is no way to be 100% compatible with old NAT-unfriendly UAs (asymmetric RTP UA being another case of backward compatibility breakage). Besides, RTCP should not be absolutely required for RTP to basically work in most real-life cases. IMHO, the extra complexity of implementing this into TURN implementations, the fact that it incites blind use of TURN regardless of otherwise better NAT traversal solutions, and the lack of simple way to determine when it is actually needed pretty much outweigh the little benefit provided. -- Rmi Denis-Courmont _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Tue, 11 Jul 2006 08:09:00 -0700 (PDT) From: Pyda Srisuresh Date: Tue, 11 Jul 2006 08:09:00 -0700 (PDT) Subject: Re: [Ietf-behave] Question about ICMP scope and how we split it over documents In-Reply-To: <099F3257-FC48-40C9-94E6-EF5043769B70@cisco.com> Message-ID: <20060711150856.60993.qmail@web33302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Cullen Jennings wrote: > > On Jul 8, 2006, at 12:15 PM, Pyda Srisuresh wrote: > > > > > [suresh] Thanks, Cullen. > > > >> o the questions is about which documents get different parts of the > >> ICMP behavior defined in them. Everyone on the call agreed that the > >> scope was limited to describing the overall behaviors of NATs such > >> that NATs would, as much as possible and still be deployable NATs, > >> not break applications or protocols that used ICMP and define the NAT > >> handling of ICMP such that the NATs did not have non deterministic > >> behavior from the point of view of the applications. Everyone also > >> agreed that the draft-ietf-behave-nat-icmp draft should define the > >> behavior of NAT when handling ICMP requests and also handing ICMP > >> responses that were generated by hosts in response to these ICMP > >> requests - clearly things like ICMP ping is in the scope of the > >> behave-nat-icmp draft. Where everyone did not agree had to do with > >> the question of which document defines the handling of ICMP messages > >> that were generated in response to messages sent by some other > >> protocol type such as UDP or TCP. > > > > [suresh] Your comment is whether processing of ICMP error messages > > is in the > > scope of ICMP draft or not. Well, we did discuss this specific issue > > extensively during the draft review with the WG chair. You were > > also on all the > > e-mails. The conclusion of the discussion was to make ICMP error > > hadling text > > protocol agnostic as in REQ-4 and REQ-5 (stated below,for ease of > > reference). > > Actually, I seem to recall that I was one of the WG chairs back then > and that I pointed out the same thing back then. > [suresh] If you did, that is good. Can you you refer me to the e-mail where you did? Assuming you did or you intended to do this, are you saying that you are in agreement that ICMP error handling text in the ICMP draft (as done in REQ-4 and REQ-5) is protocol agnostic? Do you also agree that such a protocol agnostic text concerning ICMP error message handling is within the scope of the ICMP draft? > But let's get clear about what we are talking about here - do you [suresh] Right. That is a good idea. Let me explain what my understandig is and how I gathered this. Your original e-mail said the following - "Where everyone did not agree had to do with the question of which document defines the handling of ICMP messages that were generated in response to messages sent by some other protocol type such as UDP or TCP." By "ICMP messages that were generated in response to messages sent by some other protocol type such as UDP or TCP", I assumed you were refering to ICMP error messages. SO, my understanding is that this thread is about handling of ICMP error messages and whether the handling of ICMP error messages is within the scope of the ICMP draft. REQ-4 and REQ-5 of the ICMP draft address the core of ICMP error handling. Hence, my response as above. Now, what did you mean to talk about? It would help, if you can be specific about the exact requirements that you want to talk about. I was on the same call with you, I read your e-mail. Yet, it is not clear to me what you want to talk about. > want to remove the ICMP handling out of the UDP document and move it > to the ICMP document? I assure you many people outside behave will > think that defining it in two places is a bad idea. What do you want? > [suresh] This thread is not about removing any requirements out of UDP, AFAIK. I certainly am not suggesting that at this time. I suggested removing the overlapping requirements out of the UDP draft during the IESG review of the UDP draft. But, UDP review was complete. A decision was made to keep the requirements within the UDP. Let us move on. Now, are you suggesting the opposite - To remove overlapping requirements from the ICMP, now that UDP is on its way to becoming an RFC? That would be a BAD thing to do. Just because we let go of the ICMP error overlap in UDP, doesnt mean that we remove the ICMP error requirements from the ICMP draft where it actually belongs. Specifically, I believe, this refers to REQ-6 and REQ-8. REQ-6 and REQ-8 are well within the scope of ICMP draft. These requirements are protocol agnostic and applies to all IP protocols. REQ-6 and REQ-8 of the ICMP draft: REQ-6: While processing an ICMP error packet, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP error packet. REQ-8: A NAT device MUST conform to RFC 1812 in IP packet handling. Below are specific instances where a NAT device MUST conform to RFC 1812. a) If DF bit is set on a transit IP packet and the NAT device cannot forward the packet without fragmentation, the NAT device MUST send a "Packet too big" ICMP message (ICMP type 3, Code 4) with a suggested MTU back to the sender and drop the original IP packet. b) A NAT device MUST, by default, generate "Time Exceeded" ICMP error message when it discards a packet due to an expired TTL field, unless explicitly configured otherwise. cheers, suresh From Remi.Denis-Courmont@nokia.com Wed, 12 Jul 2006 02:38:35 -0700 (PDT) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Date: Wed, 12 Jul 2006 02:38:35 -0700 (PDT) Subject: Re: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP In-Reply-To: <200607061544.09721.Remi.Denis-Courmont@nokia.com> Message-ID: <200607121239.27311.Remi.Denis-Courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain Le Tuesday 11 July 2006 17:36, ext Rohan Mahy a crit: > What are the consequences for your TURN server? > - You need to do a small amount of additional work to allocate ports > using the convention when the TURN client asks. This number will be > small and will get smaller and smaller over time. > - You need to manage your port number space in TURN. That's unfortunately not the only consequence. The more worrysome (to me) side effect is that we end up with an incentive for UAs behind even very friendly (e.g. full cone) NATs to use TURN regardless of the availability of connectivity mechanisms that would be less costly to maintain for network operators. Indeed, by *mandating* that TURN servers support this feature, we break the idea that TURN is the last/worst resort for UDP connectivity, by making it somehow "better" than UDP hole punching, in the sense that TURN will provide even/odd port preservation, and hence: 1/ save UAs from the extra burden of implementing RFC 3605. 2/ provide compatibility with RFC 3605-unaware UAs. Sure if people wants to use TURN outside ICE or ICE-like mechanisms, this makes sense, and I'm perfectly fine with this feature. But in the ICE use case, that seems very wrong: you need RFC 3605 with ICE anyway... If it can't be removed, it should be made optional for servers, such as through an error code to explicitly refuse the port alignment options, if only to ensure that TURN remains less interesting than relay-less candidates within ICE, so that relays are less likely to be abused by lazy UAs implementors or what not. -- Rmi Denis-Courmont Assistant Research Engineer From srisuresh@yahoo.com Wed, 12 Jul 2006 06:53:02 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 12 Jul 2006 06:53:02 -0700 (PDT) Subject: [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt Message-ID: <20060712135301.36712.qmail@web33311.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Folks, The authors of draft-srisuresh-behave-p2p-state-03.txt wish to submit the draft as independent submission to the RFC editor and request its publication as an informational RFC. Please review and let us know your comments by no later than 07/26/06. I.e., within 2 weeks from now. Thanks. The draft is available in the archives as follows. http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p-state-03.txt regards, suresh From philip_matthews@magma.ca Wed, 12 Jul 2006 08:20:41 -0700 (PDT) From: Philip Matthews Date: Wed, 12 Jul 2006 08:20:41 -0700 (PDT) Subject: Re: [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <20060712135301.36712.qmail@web33311.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Is this a request for people on the BEHAVE and P2P-SIP mailing lists to review the draft and send you comments? - Philip On 12-Jul-06, at 09:53 , Pyda Srisuresh wrote: Folks, The authors of draft-srisuresh-behave-p2p-state-03.txt wish to submit the draft as independent submission to the RFC editor and request its publication as an informational RFC. Please review and let us know your comments by no later than 07/26/06. I.e., within 2 weeks from now. Thanks. The draft is available in the archives as follows. http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p- state-03.txt regards, suresh _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Wed, 12 Jul 2006 09:34:42 -0700 (PDT) From: Pyda Srisuresh Date: Wed, 12 Jul 2006 09:34:42 -0700 (PDT) Subject: Re: [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: Message-ID: <20060712163441.32107.qmail@web33309.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Right. Thanks. regards, suresh --- Philip Matthews wrote: > Is this a request for people on the BEHAVE and P2P-SIP mailing lists > to review the draft and send you comments? > > - Philip > > > On 12-Jul-06, at 09:53 , Pyda Srisuresh wrote: > > > Folks, > > > > The authors of draft-srisuresh-behave-p2p-state-03.txt wish to > > submit the draft > > as independent submission to the RFC editor and request its > > publication as an > > informational RFC. Please review and let us know your comments by > > no later than > > 07/26/06. I.e., within 2 weeks from now. Thanks. > > > > The draft is available in the archives as follows. > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p- > > state-03.txt > > > > regards, > > suresh > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > From adam@estacado.net Wed, 12 Jul 2006 10:00:33 -0700 (PDT) From: Adam Roach Date: Wed, 12 Jul 2006 10:00:33 -0700 (PDT) Subject: Re: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP In-Reply-To: <200607061544.09721.Remi.Denis-Courmont@nokia.com> Message-ID: <44B52AA8.60506@estacado.net> MIME-Version: 1.0 Content-Type: text/plain Rmi Denis-Courmont wrote: The more worrysome (to me) side effect is that we end up with an incentive for UAs behind even very friendly (e.g. full cone) NATs to use TURN regardless of the availability of connectivity mechanisms that would be less costly to maintain for network operators. Are you honestly arguing for removal of a protocol feature because it is useful? /a From dwing@cisco.com Wed, 12 Jul 2006 11:18:20 -0700 (PDT) From: "Dan Wing" Date: Wed, 12 Jul 2006 11:18:20 -0700 (PDT) Subject: RE: [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <20060712163441.32107.qmail@web33309.mail.mud.yahoo.com> Message-ID: <017601c6a5df$7abb8ec0$2872150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain During the PROTO (*) writeup, we decided that review of this document by BEHAVE and P2P-SIP would be useful, as both groups have subject matter experts in the area covered by this draft. The abstract of draft-srisuresh-behave-p2p-state-03.txt is: This memo documents the various methods known to be in use by the peer-to-peer (P2P) applications for communication in the presence of Network Address Translators (NATs) at the current time. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. (*) PROTO: draft-ietf-proto-wgchair-doc-shepherding-07.txt -d > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > Sent: Wednesday, July 12, 2006 12:35 PM > To: Philip Matthews > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx; p2p-sip@xxxxxxxxxxxxxxx; > dwing@xxxxxxxxx; Dan Kegel > Subject: Re: [Ietf-behave] Request for comments on > draft-srisuresh-behave-p2p-state-03.txt > > Right. Thanks. > > regards, > suresh > > --- Philip Matthews wrote: > > > Is this a request for people on the BEHAVE and P2P-SIP mailing lists > > to review the draft and send you comments? > > > > - Philip > > > > > > On 12-Jul-06, at 09:53 , Pyda Srisuresh wrote: > > > > > Folks, > > > > > > The authors of draft-srisuresh-behave-p2p-state-03.txt wish to > > > submit the draft > > > as independent submission to the RFC editor and request its > > > publication as an > > > informational RFC. Please review and let us know your > comments by > > > no later than > > > 07/26/06. I.e., within 2 weeks from now. Thanks. > > > > > > The draft is available in the archives as follows. > > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p- > > > state-03.txt > > > > > > regards, > > > suresh > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > From aki.niemi@nokia.com Wed, 12 Jul 2006 11:47:15 -0700 (PDT) From: Aki Niemi Date: Wed, 12 Jul 2006 11:47:15 -0700 (PDT) Subject: Re: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP In-Reply-To: <200607061544.09721.Remi.Denis-Courmont@nokia.com> Message-ID: <1152729970.13736.8.camel@macbuster.research.nokia.com> MIME-Version: 1.0 Content-Type: text/plain On ke, 2006-07-12 at 13:00 -0400, ext Adam Roach wrote: > Rmi Denis-Courmont wrote: > > The more worrysome (to me) side effect is that we end up with an incentive > > for UAs behind even very friendly (e.g. full cone) NATs to use TURN > > regardless of the availability of connectivity mechanisms that would be > > less costly to maintain for network operators. > > Are you honestly arguing for removal of a protocol feature because it is > useful? It's a matter of pain vs. benefit. If we were to always add all useful features imaginable, we'd be busy boiling the ocean with every spec we produce. If it's a pain to implement, and provides minimal (and diminishing) returns, let's not put it in. It's as simple as that. -- Aki Niemi Nokia Research Center From adam@estacado.net Wed, 12 Jul 2006 11:58:22 -0700 (PDT) From: Adam Roach Date: Wed, 12 Jul 2006 11:58:22 -0700 (PDT) Subject: Re: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP In-Reply-To: <200607061544.09721.Remi.Denis-Courmont@nokia.com> Message-ID: <44B54647.2090006@estacado.net> MIME-Version: 1.0 Content-Type: text/plain Aki Niemi wrote: It's a matter of pain vs. benefit. If we were to always add all useful features imaginable, we'd be busy boiling the ocean with every spec we produce. The specific argument that Rmi made -- the one to which I responded -- had nothing to do with implementation complexity. His thesis was that the feature under discussion is _so_ useful that it would cause problems -- that somehow failing to cripple the protocol makes it an attractive nuisance. /a From derek@counterpath.com Wed, 12 Jul 2006 12:05:04 -0700 (PDT) From: derek@counterpath.com Date: Wed, 12 Jul 2006 12:05:04 -0700 (PDT) Subject: Re: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP In-Reply-To: <200607061544.09721.Remi.Denis-Courmont@nokia.com> Message-ID: <53076.10.238.10.70.1152731103.webmail@10.238.10.70> MIME-Version: 1.0 Content-Type: text/plain The port pair feature will be required to talk to non-ice supporting 3605 compliant endpoints when endpoint using TURN/ICE is behind a symmetric NAT. I doubt the implementation cost will be onerous, and I think not having it will delay adoption of TURN. --Derek Aki Niemi said: > On ke, 2006-07-12 at 13:00 -0400, ext Adam Roach wrote: > > Rmi Denis-Courmont wrote: > > > The more worrysome (to me) side effect is that we end up with an >> incentive for UAs behind even very friendly (e.g. full cone) NATs to >> use TURN regardless of the availability of connectivity mechanisms >> that would be less costly to maintain for network operators. > > > > Are you honestly arguing for removal of a protocol feature because it is > > useful? > > It's a matter of pain vs. benefit. If we were to always add all useful > features imaginable, we'd be busy boiling the ocean with every spec we > produce. > > If it's a pain to implement, and provides minimal (and diminishing) > returns, let's not put it in. It's as simple as that. > > -- > Aki Niemi > Nokia Research Center > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From Internet-Drafts@ietf.org Wed, 12 Jul 2006 12:50:04 -0700 (PDT) From: Internet-Drafts@ietf.org Date: Wed, 12 Jul 2006 12:50:04 -0700 (PDT) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-rfc3489bis-04.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Simple Traversal Underneath Network Address Translators (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-04.txt Pages : 62 Date : 2006-7-12 Simple Traversal Underneath NATs (STUN) is a lightweight protocol that serves as a tool for application protocols in dealing with NAT traversal. It allows a client to determine the IP address and port allocated to them by a NAT and to keep NAT bindings open. It can also serve as a check for connectivity between a client and a server in the presence of NAT, and for the client to detect failure of the server. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From Remi.Denis-Courmont@nokia.com Thu, 13 Jul 2006 03:27:07 -0700 (PDT) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Date: Thu, 13 Jul 2006 03:27:07 -0700 (PDT) Subject: Re: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP In-Reply-To: <200607061544.09721.Remi.Denis-Courmont@nokia.com> Message-ID: <200607131327.54171.Remi.Denis-Courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain Le Wednesday 12 July 2006 20:00, vous avez crit: > Rmi Denis-Courmont wrote: > > The more worrysome (to me) side effect is that we end up with an > > incentive for UAs behind even very friendly (e.g. full cone) NATs to use > > TURN regardless of the availability of connectivity mechanisms that would > > be less costly to maintain for network operators. > Are you honestly arguing for removal of a protocol feature because it is > useful? Well... No! my original point was that it is useless, painful to implement, and might induce UAs into doing things that I think would be bad. But it was argued that people found it useful; well, I cannot decide for someone else whether a feature is useful to him/her. My point is that this provides an incentive to implement and use the suboptimal solution (TURN alone instead of ICE with TURN as the worst candidate).. Also, how many user agents are there that: - do implement RTCP properly, - do require that the peer send RTCP properly, - do NOT support RFC 3605, - do send symmetric RTP (since asymmetric is fatal) and RTCP, and, - do have a public IPv4 address (otherwise they'll need RFC3605 too)? Probably very very few. I can accept that some people deadly want this feature in TURN anyhow... but I don't want to bloat "my" TURN servers neither do I want to incite UAs implementors into using TURN servers blindly in hope of getting interop with the "very very few" obsolete user agents at stake. As such, I'm not happy that this feature exists, and I'm even less happy that this feature is a *mandatory* requirement for TURN servers. -- Rmi Denis-Courmont Assistant Research Engineer From dwing@cisco.com Thu, 13 Jul 2006 07:46:08 -0700 (PDT) From: "Dan Wing" Date: Thu, 13 Jul 2006 07:46:08 -0700 (PDT) Subject: RE: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP In-Reply-To: <200607131327.54171.Remi.Denis-Courmont@nokia.com> Message-ID: <07c301c6a68b$13c943e0$2872150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Also, how many user agents are there that: > - do implement RTCP properly, > - do require that the peer send RTCP properly, > - do NOT support RFC 3605, > - do send symmetric RTP (since asymmetric is fatal) and RTCP, and, > - do have a public IPv4 address (otherwise they'll need RFC3605 too)? I wanted to throw out a comment on your last point: a UA can be behind a NAT with a SIP-aware ALG, or behind an SBC, in which case it'll have a public IPv4 address and will have adjacent RTP and RTCP ports without RFC3605. I expect that, today, there are a lot of UAs behind SBCs or behind NATs with SIP-aware ALGs. -d From aki.niemi@nokia.com Thu, 13 Jul 2006 08:35:44 -0700 (PDT) From: Aki Niemi Date: Thu, 13 Jul 2006 08:35:44 -0700 (PDT) Subject: RE: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP In-Reply-To: <07c301c6a68b$13c943e0$2872150a@amer.cisco.com> Message-ID: <1152804930.21839.29.camel@macbuster.research.nokia.com> MIME-Version: 1.0 Content-Type: text/plain On to, 2006-07-13 at 10:46 -0400, ext Dan Wing wrote: > > Also, how many user agents are there that: > > - do implement RTCP properly, > > - do require that the peer send RTCP properly, > > - do NOT support RFC 3605, > > - do send symmetric RTP (since asymmetric is fatal) and RTCP, and, > > - do have a public IPv4 address (otherwise they'll need RFC3605 too)? > > I wanted to throw out a comment on your last point: a UA can be > behind a NAT with a SIP-aware ALG, or behind an SBC, in which case it'll > have a public IPv4 address and will have adjacent RTP and RTCP ports > without RFC3605. I expect that, today, there are a lot of UAs > behind SBCs or behind NATs with SIP-aware ALGs. So, what breaks? They can't correctly send RTCP? Is that *really* such a big problem? I'm not seeing RTCP used that much anyhow. An implementor has indicated that the protocol has been added a mandatory to implement feature that makes the implementation a lot more complex without giving a clear benefit. At this point, I think there needs to be more concrete reasons to justify the added complexity than that there might be a scenario that could need this. Like, that something breaks without it. Otherwise, take it out, or make it optional (in which case we won't implement it, BTW). -- Aki Niemi Nokia Research Center From audet@nortel.com Tue, 18 Jul 2006 16:52:48 -0700 (PDT) From: "Francois Audet" Date: Tue, 18 Jul 2006 16:52:48 -0700 (PDT) Subject: [Ietf-behave] draft-ietf-behave-rfc3489bis-04 In-Reply-To: <07c301c6a68b$13c943e0$2872150a@amer.cisco.com> Message-ID: <1ECE0EB50388174790F9694F77522CCF0B8B2167@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Jonathan, There is a glitch in the section numbers for section 12 on STUN Usages. Sections 12.1.1.9-12.1.1.11 should really be 12.1.2-12.1.4. From xavier.marjou@orange-ft.com Thu, 20 Jul 2006 01:28:38 -0700 (PDT) From: "Xavier Marjou" Date: Thu, 20 Jul 2006 01:28:38 -0700 (PDT) Subject: [Ietf-behave] Dedicated draft for RTP keepalive? Message-ID: MIME-Version: 1.0 Content-Type: text/plain Looking at current applications, there are 2 fundamental behaviors that help RTP applications with regards to NAT traversal: "Symmetric RTP" and "Binding keepalives". The first topic is shortly described in a short doc (draft-wing-behave- symmetric-rtprtcp-01). The second topic is currently described in draft-ietf-mmusic-ice-09 (section 7.12), which nicely describes two "binding keepalives" mechanisms: one for communications between ICE agents (STUN-keepalive case) and another for communications between non-ICE agents (RTP-keepalive fallback case). For the latter, I propose to extract it in a separate doc so that non-ICE applications can refer to a very short doc for basic "binding keepalives". What do you think? Xavier From vlada@iptel.org Fri, 21 Jul 2006 02:03:04 -0700 (PDT) From: Vladimir Marek Date: Fri, 21 Jul 2006 02:03:04 -0700 (PDT) Subject: [Ietf-behave] draft-ietf-behave-rfc3489bis-04 - comments Message-ID: <44C0984F.1030709@iptel.org> MIME-Version: 1.0 Content-Type: text/plain Dear Jonathan, I would like to draw your attention to some unclear places or small mistakes. 1) Page 11, chapter 6, first paragraph, sentence "The STUN header contains a STUN message type, transaction ID, and length". I would also add magic cookie into this list. New version could be - "The STUN header contains a STUN message type, magic cookie, transaction ID, and length." 2) Page 13, third paragraph on page, sentence "After the STUN header are zero or more attributes." IMHO it is in conflict with figure 4 on page 28 and also with description of attribute FINGERPRINT ("The FINGERPRINT attribute is present in all STUN message"). Suggested version - "After the STUN header there are one or more attributes." 3) Page 13, fourth line from the end. Typing error - btyes -> bytes 4) Page 25, chapter 9.1.2., first paragraph, last sentence "If the STUN response is a success response, the STUN server adds 0x110 to the Message Type of the request." The success response is described in previous sentence and this sentence should contain error case. Suggestion - "If the STUN response is an error response, the STUN server adds 0x110 to the Message Type of the request." 5) Page 32, error code for Stale Nonce (438). I guess that the error code should be 437 as it is in draft 03 instead of 438. I don't see any reason to skip code 437. 6) Page 33, chapter 11.10., second paragraph, sentence "This attribute MUST always be present in a Binding Response ... ". Maybe it would be good to mention case when the magic cookie is not present in a header (previous version of specification). Suggestion - use same description from third paragraph, in chapter 9.1.2. on page 25. 7) Page 33, chapter 11.10. It's not clear to me when the XORing of port should be performed - before converting port number from host to network order or after this conversion? I would expect that before but it is not evident from that description. Kind regards, Vlada From zhouhong@huawei.com Fri, 21 Jul 2006 02:35:57 -0700 (PDT) From: Stephen Zhou Date: Fri, 21 Jul 2006 02:35:57 -0700 (PDT) Subject: RE: [Ietf-behave] draft-ietf-behave-rfc3489bis-04 - comments In-Reply-To: <44C0984F.1030709@iptel.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Vladimir, > 5) Page 32, error code for Stale Nonce (438). I guess that the error > code should be 437 as it is in draft 03 instead of 438. I don't see any > reason to skip code 437. 437 has been used for TURN-01. BR, Stephen From petithug@acm.org Sat, 22 Jul 2006 06:03:23 -0700 (PDT) From: Marc Petit-Huguenin Date: Sat, 22 Jul 2006 06:03:23 -0700 (PDT) Subject: Re: [Ietf-behave] STUN/TURN unified attribute list In-Reply-To: <44AD395B.6030302@cisco.com> Message-ID: <44C22217.5070407@acm.org> MIME-Version: 1.0 Content-Type: text/plain Jonathan Rosenberg wrote: > We seem to constantly have problems getting the attribute numbering > across TURN, STUN and turn-v6 consistent, non-overlapping and complete. > I have gone through the most recent revisions of each of the drafts > along with the old rfc3489 and enumerated what I think is the complete > set. If folks see any omissions or problems please advise: > > stun-04 0x0001: MAPPED-ADDRESS > HISTORIC 0x0002: RESPONSE-ADDRESS > HISTORIC 0x0003: CHANGE-REQUEST > HISTORIC 0x0004: SOURCE-ADDRESS > HISTORIC 0x0005: CHANGED-ADDRESS > stun-04 0x0006: USERNAME > stun-04 0x0007: PASSWORD > stun-04 0x0008: MESSAGE-INTEGRITY > stun-04 0x0009: ERROR-CODE > stun-04 0x000a: UNKNOWN-ATTRIBUTES > HISTORIC 0x000b: REFLECTED-FROM > turn-01 0x000c: LIFETIME > turn-01 0x0010: BANDWIDTH > turn-01 0x0012: REMOTE-ADDRESS > turn-01 0x0013: DATA > stun-04 0x0014: REALM > stun-04 0x0015: NONCE > turn-01 0x0016: RELAY-ADDRESS > v4/v6-00 0x0017: REQUESTED-ADDRESS-TYPE > turn-01 0x0018: REQUESTED-PORT The text and section 10.6 in turn-01 use REQUESTED-PORT-PROPS. > turn-01 0x0019: REQUESTED-TRANSPORT > stun-04 0x0020: XOR-MAPPED-ADDRESS > turn-01 0x0021: TIMER-VAL > turn-01 0x0022: REQUESTED-IP > stun-04 0x0023: FINGERPRINT > > stun-04 0x8022: SERVER > stun-04 0x8023: ALTERNATE-SERVER > stun-04 0x8024: REFRESH-INTERVAL > > > Thanks, > Jonathan R. -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx From petithug@acm.org Sat, 22 Jul 2006 06:24:13 -0700 (PDT) From: Marc Petit-Huguenin Date: Sat, 22 Jul 2006 06:24:13 -0700 (PDT) Subject: [Ietf-behave] Comments on turn-01 Message-ID: <44C226F9.3050706@acm.org> MIME-Version: 1.0 Content-Type: text/plain Hi, Some comments on draft-ietf-behave-turn-01: - The title should be changed to be aligned with STUN: "Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)" - Section 6, 3rd paragraph: The third example should be "_stun-relay._tls.example.com." - Section 9.1.1.1, 7th paragraph: "...have changed (BANDWIDTH, REQUESTED_TRANSPORT, etc.)." should be "...have changed (BANDWITH, REQUESTED-TRANSPORT, etc...)." - Same section paragraphes 14 and 16: Replace "TURN" by "STUN relay" - Same paragraph, 20th paragraph: "... (See Section 14." should be "... (See Section 14.)" - Section 10: "REQUESTED-PORT" should be "REQUEST-PORT-PROPS" - Section 11, 4th paragraph: Replace "TURN" by "STUN relay" - Section 16.1, 16.2, 16.3, 16.4: Replace all instances of "TURN" by "STUN relay" Thanks. -- Marc Petit-Huguenin Home: marc@xxxxxxxxxxxxxxxxxx Work: marc@xxxxxxx From srisuresh@yahoo.com Thu, 27 Jul 2006 08:36:12 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 27 Jul 2006 08:36:12 -0700 (PDT) Subject: Re: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: Message-ID: <20060727153612.97735.qmail@web33307.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Thanks, Bruce, for your comments. Please see my responses inline. regards, suresh --- Bruce Lowekamp wrote: > A few comments that came to mind while doing a quick read-through of > this document: > > - I would really rather see the more current BEHAVE terminology used > in this draft. Even though it's not yet official in an RFC, I think > it will confuse people to see the older terminology used. > [suresh] We used the RFC 3489 terminology (Symmetric NATs, Cone NATs) because the draft is a capture of existing techniques. We felt, it made sense to use terminology from existing RFCs to describe the current state rather than use newer terms in Behave. I will take your advice and review the draft to see if this can be revised to use the BEHAVE terminology. Thanks. > - It would be nice to see a discussion of what standards are being > developed to try to implement these techniques (e.g. which are > supported by Teredo and ICE). I think the more recent ICE draft is > written to imply a bit broader applicability than the previous one > was. > [suresh] Right, your point is well taken. Even though, the draft does refer both ICE and TEREDO, the coverage can be better. I will add more text discussing the newer standards. The draft doesnt capture the newer ICE well. ICE draft is rapidly changing from UDP only to UDP + TCP and potentially more changes in newer revs. Oh, well.. > - I was surprised to notice that the authors did not cite their own > very good USENIX05 paper as an informative reference. [suresh] Sure, we will do that. Thank you for your comments. regards, suresh > > Bruce > > > On 7/12/06, Dan Wing wrote: > > During the PROTO (*) writeup, we decided that review of this document by > > BEHAVE and P2P-SIP would be useful, as both groups have subject matter > > experts in the area covered by this draft. The abstract of > > draft-srisuresh-behave-p2p-state-03.txt is: > > > > This memo documents the various methods known to be in use by the > > peer-to-peer (P2P) applications for communication in the presence > > of Network Address Translators (NATs) at the current time. This > > memo covers NAT traversal approaches used by both TCP and UDP > > based applications. This memo is not an endorsement of the methods > > described, but merely an attempt to capture them in a document. > > > > (*) PROTO: draft-ietf-proto-wgchair-doc-shepherding-07.txt > > > > -d > > > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > Sent: Wednesday, July 12, 2006 12:35 PM > > > To: Philip Matthews > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx; p2p-sip@xxxxxxxxxxxxxxx; > > > dwing@xxxxxxxxx; Dan Kegel > > > Subject: Re: [Ietf-behave] Request for comments on > > > draft-srisuresh-behave-p2p-state-03.txt > > > > > > Right. Thanks. > > > > > > regards, > > > suresh > > > > > > --- Philip Matthews wrote: > > > > > > > Is this a request for people on the BEHAVE and P2P-SIP mailing lists > > > > to review the draft and send you comments? > > > > > > > > - Philip > > > > > > > > > > > > On 12-Jul-06, at 09:53 , Pyda Srisuresh wrote: > > > > > > > > > Folks, > > > > > > > > > > The authors of draft-srisuresh-behave-p2p-state-03.txt wish to > > > > > submit the draft > > > > > as independent submission to the RFC editor and request its > > > > > publication as an > > > > > informational RFC. Please review and let us know your > > > comments by > > > > > no later than > > > > > 07/26/06. I.e., within 2 weeks from now. Thanks. > > > > > > > > > > The draft is available in the archives as follows. > > > > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p- > > > > > state-03.txt > > > > > > > > > > regards, > > > > > suresh > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ietf-behave mailing list > > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@xxxxxxxxxxxxxxx > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > From lowekamp@cs.wm.edu Wed, 26 Jul 2006 19:08:43 -0700 (PDT) From: "Bruce Lowekamp" Date: Wed, 26 Jul 2006 19:08:43 -0700 (PDT) Subject: Re: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <20060712163441.32107.qmail@web33309.mail.mud.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain A few comments that came to mind while doing a quick read-through of this document: - I would really rather see the more current BEHAVE terminology used in this draft. Even though it's not yet official in an RFC, I think it will confuse people to see the older terminology used. - It would be nice to see a discussion of what standards are being developed to try to implement these techniques (e.g. which are supported by Teredo and ICE). I think the more recent ICE draft is written to imply a bit broader applicability than the previous one was. - I was surprised to notice that the authors did not cite their own very good USENIX05 paper as an informative reference. Bruce On 7/12/06, Dan Wing wrote: During the PROTO (*) writeup, we decided that review of this document by BEHAVE and P2P-SIP would be useful, as both groups have subject matter experts in the area covered by this draft. The abstract of draft-srisuresh-behave-p2p-state-03.txt is: This memo documents the various methods known to be in use by the peer-to-peer (P2P) applications for communication in the presence of Network Address Translators (NATs) at the current time. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. (*) PROTO: draft-ietf-proto-wgchair-doc-shepherding-07.txt -d > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > Sent: Wednesday, July 12, 2006 12:35 PM > To: Philip Matthews > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx; p2p-sip@xxxxxxxxxxxxxxx; > dwing@xxxxxxxxx; Dan Kegel > Subject: Re: [Ietf-behave] Request for comments on > draft-srisuresh-behave-p2p-state-03.txt > > Right. Thanks. > > regards, > suresh > > --- Philip Matthews wrote: > > > Is this a request for people on the BEHAVE and P2P-SIP mailing lists > > to review the draft and send you comments? > > > > - Philip > > > > > > On 12-Jul-06, at 09:53 , Pyda Srisuresh wrote: > > > > > Folks, > > > > > > The authors of draft-srisuresh-behave-p2p-state-03.txt wish to > > > submit the draft > > > as independent submission to the RFC editor and request its > > > publication as an > > > informational RFC. Please review and let us know your > comments by > > > no later than > > > 07/26/06. I.e., within 2 weeks from now. Thanks. > > > > > > The draft is available in the archives as follows. > > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p- > > > state-03.txt > > > > > > regards, > > > suresh > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > _______________________________________________ p2p-sip mailing list p2p-sip@xxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From laine+behave@laine.org Thu, 27 Jul 2006 09:59:25 -0700 (PDT) From: Laine Stump Date: Thu, 27 Jul 2006 09:59:25 -0700 (PDT) Subject: [Ietf-behave] turn-01 and REQUESTED-PORT-PROPS Message-ID: <7.0.1.0.0.20060727124828.01ceebb8@laine.org> MIME-Version: 1.0 Content-Type: text/plain The layout of REQUESTED-PORT-PROPS in turn-01 is very different from REQUESTED-PORT in turn-00. Among other things, there is no longer any place to specify a port when you want to request one (28 of the 32 bits are "reserved", where previously 16 bits were used for the "Port Filter" field). I also notice that REQUESTED-PORT is still referred to in several places (eg in sec 10.8). Was the intent to move the location of this data somewhere else (perhaps start using the unused port field in REQUESTED-IP) and the document was released before editing was finished, or was the removal of the "Port Filter" field when going from REQUESTED-PORT to REQUESTED-PORT-PROPS just an oversight? (Or did I miss something somewhere?) From dwing@cisco.com Thu, 27 Jul 2006 12:18:18 -0700 (PDT) From: "Dan Wing" Date: Thu, 27 Jul 2006 12:18:18 -0700 (PDT) Subject: RE: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <20060727153612.97735.qmail@web33307.mail.mud.yahoo.com> Message-ID: <04b801c6b1b1$6ac12b50$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > > A few comments that came to mind while doing a quick read-through of > > this document: > > > > - I would really rather see the more current BEHAVE terminology used > > in this draft. Even though it's not yet official in an RFC, I think > > it will confuse people to see the older terminology used. > > [suresh] We used the RFC 3489 terminology (Symmetric NATs, > Cone NATs) because the draft is a capture of existing techniques. > We felt, it made sense to use terminology from existing RFCs to > describe the current state rather than use newer terms in Behave. I > will take your advice and review the draft to see if this can be > revised to use the BEHAVE terminology. Thanks. But draft-srisuresh-behave-p2p-state-03.txt's terminology doesn't match RFC3489's definitions. For example, taking just 'port restricted cone', there is a difference: RFC3489: # Port Restricted Cone: A port restricted cone NAT is like a # restricted cone NAT, but the restriction includes port numbers. # Specifically, an external host can send a packet, with source IP # address X and source port P, to the internal host only if the # internal host had previously sent a packet to IP address X and # port P. draft-srisuresh-behave-p2p-state-03.txt: # Port-Restricted Cone NAT # Subsequent to establishing Port Binding at the start of an # outgoing TCP/UDP session, Port-Restricted Cone NAT will # accept incoming traffic to the corresponding public port from # only those external endpoints to which the internal host has # previously sent one or more outgoing packets. I.e., only # those incoming packets that belong to the sessions initiated # by the private host are permitted on the inbound. "only those external endpoints" means IP address, but I expect your intent was to capture both the external endpoint (IP address) and external port. A lot of pain resulted in the consensus text in RFC3489; if you want to use those old terms, I would strongly encourage adopting the definitions from RFC3489 using exactly the same text as in RFC3489 itself. Similarly, if you want to adopt the new terms, it would be best to copy the text verbatim. -d From srisuresh@yahoo.com Thu, 27 Jul 2006 14:07:35 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 27 Jul 2006 14:07:35 -0700 (PDT) Subject: RE: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <04b801c6b1b1$6ac12b50$c2f0200a@amer.cisco.com> Message-ID: <20060727210734.53208.qmail@web33310.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dan Wing wrote: > > > A few comments that came to mind while doing a quick read-through of > > > this document: > > > > > > - I would really rather see the more current BEHAVE terminology used > > > in this draft. Even though it's not yet official in an RFC, I think > > > it will confuse people to see the older terminology used. > > > > [suresh] We used the RFC 3489 terminology (Symmetric NATs, > > Cone NATs) because the draft is a capture of existing techniques. > > We felt, it made sense to use terminology from existing RFCs to > > describe the current state rather than use newer terms in Behave. I > > will take your advice and review the draft to see if this can be > > revised to use the BEHAVE terminology. Thanks. > > But draft-srisuresh-behave-p2p-state-03.txt's terminology doesn't > match RFC3489's definitions. For example, taking just 'port restricted > cone', there is a difference: > > RFC3489: > > # Port Restricted Cone: A port restricted cone NAT is like a > # restricted cone NAT, but the restriction includes port numbers. > # Specifically, an external host can send a packet, with source IP > # address X and source port P, to the internal host only if the > # internal host had previously sent a packet to IP address X and > # port P. > > draft-srisuresh-behave-p2p-state-03.txt: > > # Port-Restricted Cone NAT > # Subsequent to establishing Port Binding at the start of an > # outgoing TCP/UDP session, Port-Restricted Cone NAT will > # accept incoming traffic to the corresponding public port from > # only those external endpoints to which the internal host has > # previously sent one or more outgoing packets. I.e., only > # those incoming packets that belong to the sessions initiated > # by the private host are permitted on the inbound. > > "only those external endpoints" means IP address, but I expect your > intent was to capture both the external endpoint (IP address) and > external port. [suresh] Dan - Early on, in the terminology section, the endpoint is referred as the tuple of (IP adress, Port). This is how the endpoint is referred throughout the documnt, including the figures (all 9 of them). The notation used in the figures to represent the endpoint is :. Endpoint is not referred as just an IP address, anywhere in the document. However, I could make endpoint semantics more explicit be definig this as a term. The same endpoint semantics are used even when defining "Address-Restricted Cone NAT" and "Full Cone NAT". Address-Restricted Cone NAT Subsequent to establishing Port Binding at the start of an outgoing UDP session, Address-Restricted Cone NAT will accept incoming UDP traffic to the corresponding public port from only those external endpoints whose IP address match the address of a node to which the internal host has previously sent one or more outgoing packets. Full Cone NAT Subsequent to establishing Port Binding at the start of an outgoing UDP session, a full cone NAT will accept incoming UDP traffic to the corresponding public port from ANY external endpoint on the public network. Full cone NAT is also sometimes referred as "Promiscuous NAT". > > A lot of pain resulted in the consensus text in RFC3489; if you > want to use those old terms, I would strongly encourage adopting > the definitions from RFC3489 using exactly the same text as in > RFC3489 itself. [suresh] There is ambiguity in RFC 3489 definitions. Hence the reason for disambiguating the terms by using illustration figures and additional text. For example, the p2p-state text describes that "Port-Restricted Cone NATs" are applicable to both TCP and UDP sessions. But, that "Address-Restricted Cone NAT" and "Full COne NAT" are specific to UDP only. > Similarly, if you want to adopt the new terms, > it would be best to copy the text verbatim. [suresh] The p2p-state draft has been around for some time (circa 2004). I believe, the draft text flows well using the terminology it has. To be honest, I am concerned about redoing the draft using BEHAVE terminology. That could be a big surgery and adds dependencies. UDP Behave is about to be an RFC. But, TCP Behave is not there yet. TCP behave terms do differ from the UDP draft. Dan and Bruce - My preference would be to use the terms as is instead of revising the draft with newer terms. I will be happy to make specific text changes where something is not clear. If this is agreeable to you, please suggest the speacific text where you see problem. Thanks. regards, suresh > > -d > From dwing@cisco.com Thu, 27 Jul 2006 14:50:48 -0700 (PDT) From: "Dan Wing" Date: Thu, 27 Jul 2006 14:50:48 -0700 (PDT) Subject: RE: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <20060727210734.53208.qmail@web33310.mail.mud.yahoo.com> Message-ID: <079c01c6b1c6$b86cd920$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > [suresh] Dan - Early on, in the terminology section, the > endpoint is referred as the tuple of (IP adress, Port). This is how > the endpoint is referred throughout the documnt, including the figures > (all 9 of them). The notation used in the figures to represent the > endpoint is :. Endpoint is not referred as just an > IP address, anywhere in the document. However, I could make endpoint > semantics more explicit be definig this as a term. I don't feel the normal definition of 'endpoint' is its IP address and UDP port. Does 'socket' or 'endpoint socket' have the meaning you are ascribing to 'endpoint'? ... > > A lot of pain resulted in the consensus text in RFC3489; if you > > want to use those old terms, I would strongly encourage adopting > > the definitions from RFC3489 using exactly the same text as in > > RFC3489 itself. > > [suresh] There is ambiguity in RFC 3489 definitions. Hence > the reason for disambiguating the terms by using illustration > figures and additional text. For example, the p2p-state text > describes that "Port-Restricted Cone NATs" are applicable to both > TCP and UDP sessions. But, that "Address-Restricted Cone NAT" > and "Full COne NAT" are specific to UDP only. Instead of clarifying a standards-track document (RFC3489) with an informational document, I see more value in just letting the old terms die out and be replaced with the mapping and filtering terms in -behave-nat-udp (sections 4.1 and 5). When RFC3489bis (draft-ietf-behave-rfc3489bis) is published, it will obsolete RFC3489. It seems useful that the only use of the terms will soon be a document marked 'Obsoleted by' so we can adopt the newer and more accurate terms. > > Similarly, if you want to adopt the new terms, > > it would be best to copy the text verbatim. > > [suresh] The p2p-state draft has been around for some time > (circa 2004). I believe, the draft text flows well using > the terminology it has. To be honest, I am concerned about > redoing the draft using BEHAVE terminology. That could be > a big surgery and adds dependencies. I agree it could be a large surgery on the document. I don't understand how it would add a dependency; neither Bruce nor I suggested adding a normative reference. Even if you did, the normative reference would be to behave-nat-udp which is very close to being finished in IESG and will be a standards- track document (so no worries about a downward reference). > UDP Behave is about to > be an RFC. But, TCP Behave is not there yet. TCP behave > terms do differ from the UDP draft. What is the value of TCP's different terms? I mean, does the different terminology help or hurt understanding, consensus, and interoperability? > Dan and Bruce - My preference would be to use the terms as is > instead of revising the draft with newer terms. I will be > happy to make specific text changes where something is not > clear. If this is agreeable to you, please suggest the > speacific text where you see problem. Thanks. The specific text where I see a problem is the use of RFC3489 terminology (cone, port restricted, symmetric) when RFC3489bis is an active WG document and will not include that terminology. That means, upon publication of draft-srisuresh-behave-p2p-state as Informational, it will be the only document that uses these soon-to-be-obsoleted terms. -d From srisuresh@yahoo.com Thu, 27 Jul 2006 16:17:57 -0700 (PDT) From: Pyda Srisuresh Date: Thu, 27 Jul 2006 16:17:57 -0700 (PDT) Subject: RE: [p2p-sip] [Ietf-behave] Request for comments on draft-srisuresh-behave-p2p-state-03.txt In-Reply-To: <079c01c6b1c6$b86cd920$c2f0200a@amer.cisco.com> Message-ID: <20060727231757.10265.qmail@web33315.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Dan Wing wrote: > > > [suresh] Dan - Early on, in the terminology section, the > > endpoint is referred as the tuple of (IP adress, Port). This is how > > the endpoint is referred throughout the documnt, including the figures > > (all 9 of them). The notation used in the figures to represent the > > endpoint is :. Endpoint is not referred as just an > > IP address, anywhere in the document. However, I could make endpoint > > semantics more explicit be definig this as a term. > > I don't feel the normal definition of 'endpoint' is its IP address > and UDP port. Does 'socket' or 'endpoint socket' have the meaning > you are ascribing to 'endpoint'? > [suresh] I donot believe, there is a well-known definition to endpoint. The p2p-state draft refers this as a protocol specific tuple. I will define the term explicitly in Terminology section. > ... > > > A lot of pain resulted in the consensus text in RFC3489; if you > > > want to use those old terms, I would strongly encourage adopting > > > the definitions from RFC3489 using exactly the same text as in > > > RFC3489 itself. > > > > [suresh] There is ambiguity in RFC 3489 definitions. Hence > > the reason for disambiguating the terms by using illustration > > figures and additional text. For example, the p2p-state text > > describes that "Port-Restricted Cone NATs" are applicable to both > > TCP and UDP sessions. But, that "Address-Restricted Cone NAT" > > and "Full COne NAT" are specific to UDP only. > > Instead of clarifying a standards-track document (RFC3489) with > an informational document, I see more value in just letting the > old terms die out and be replaced with the mapping and filtering > terms in -behave-nat-udp (sections 4.1 and 5). When RFC3489bis > (draft-ietf-behave-rfc3489bis) is published, it will obsolete > RFC3489. It seems useful that the only use of the terms will > soon be a document marked 'Obsoleted by' so we can adopt the > newer and more accurate terms. > [suresh] I understand. > > > Similarly, if you want to adopt the new terms, > > > it would be best to copy the text verbatim. > > > > [suresh] The p2p-state draft has been around for some time > > (circa 2004). I believe, the draft text flows well using > > the terminology it has. To be honest, I am concerned about > > redoing the draft using BEHAVE terminology. That could be > > a big surgery and adds dependencies. > > I agree it could be a large surgery on the document. > > I don't understand how it would add a dependency; neither Bruce > nor I suggested adding a normative reference. Even if you > did, the normative reference would be to behave-nat-udp which > is very close to being finished in IESG and will be a standards- > track document (so no worries about a downward reference). > > > UDP Behave is about to > > be an RFC. But, TCP Behave is not there yet. TCP behave > > terms do differ from the UDP draft. > > What is the value of TCP's different terms? I mean, does the > different terminology help or hurt understanding, consensus, > and interoperability? > > > Dan and Bruce - My preference would be to use the terms as is > > instead of revising the draft with newer terms. I will be > > happy to make specific text changes where something is not > > clear. If this is agreeable to you, please suggest the > > speacific text where you see problem. Thanks. > > The specific text where I see a problem is the use of RFC3489 > terminology (cone, port restricted, symmetric) when RFC3489bis > is an active WG document and will not include that terminology. > That means, upon publication of draft-srisuresh-behave-p2p-state > as Informational, it will be the only document that uses these > soon-to-be-obsoleted terms. > [suresh] OK, I will try and revise the text so as not to refer RFC3489 terms. Thanks. regards, suresh > -d > From vlada@iptel.org Mon, 31 Jul 2006 00:09:36 -0700 (PDT) From: Vladimir Marek Date: Mon, 31 Jul 2006 00:09:36 -0700 (PDT) Subject: [Ietf-behave] draft-ietf-behave-rfc3489bis-04 - some questions Message-ID: <44CDACCB.3030201@iptel.org> MIME-Version: 1.0 Content-Type: text/plain Dear Jonathan, I would like to ask you, if you could clarify for me some unclear parts from the draft. 1) Normally when a value is padded to some length the pad is not included into length. I'm not sure how is it in case of UNKNOWN-ATTRIBUTE field. Does the length contain the extra 2B if the number of unknown attributes is an odd number? 2) What is a procedure when you XOR-ing port? Should be port number XOR-ed in host byte order or in network byte order? I would expect that first the port is XOR-ed and then is converted into network byte order. Is that right? 3) Is it IP address converted into network byte order or no? There is no mention about this case and only what could be apply is the rule that all numbers are in network byte order form. Therefor I would expect that both IPv4 and IPv6 should be in network byte order. 4) What about magic cookie, is it in network byte order or not? I would expect that magic cookie is in network byte order representation. Many thanks for your comments! Kind regards, Vladimir Marek From dwing@cisco.com Mon, 31 Jul 2006 13:46:31 -0700 (PDT) From: "Dan Wing" Date: Mon, 31 Jul 2006 13:46:31 -0700 (PDT) Subject: [Ietf-behave] draft minutes Message-ID: <062a01c6b4e2$66c8ebd0$777a150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I placed the draft minutes for BEHAVE at: http://www3.ietf.org/proceedings/06jul/minutes/behave.html Please email me any corrections _before_ the cutoff for corrections (August 28). -d From vlada@iptel.org Wed, 2 Aug 2006 01:13:56 -0700 (PDT) From: Vladimir Marek Date: Wed, 2 Aug 2006 01:13:56 -0700 (PDT) Subject: [Ietf-behave] draft-ietf-behave-rfc3489bis-04 - mistake In-Reply-To: <44CDACCB.3030201@iptel.org> Message-ID: <44D05EE4.1090807@iptel.org> MIME-Version: 1.0 Content-Type: text/plain Dear Jonathan, I found one more little mistake in draft 04: chapter 11.11. on page 34, last sentence in paragraph. The key word USERNAME should be replaced by word SERVER. Kind regards, Vladimir Marek From dwing@cisco.com Wed, 2 Aug 2006 09:19:44 -0700 (PDT) From: "Dan Wing" Date: Wed, 2 Aug 2006 09:19:44 -0700 (PDT) Subject: [Ietf-behave] IP options and NATs Message-ID: <0e2501c6b64f$76a7fc30$ef52150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain While reviewing draft-pashalidis-nsis-gist-legacynats-00.txt, I noticed: > The discussion in this document is based on the > following assumptions. > ... > 6. The legacy NAT does not drop IP packets with a > Router Alert Option (RAO) or an IPv6 extensions > header. Furthermore, the RAO or extension header > is also present in the forwarded packet. If the > NAT does not do this, then there is no way for a > GIST QUERY to traverse the NAT, which is a > prerequisite for the mechanisms described in this > document. I am wondering how today's NATs handle IP options. I asked our engineering teams and found that Cisco's IOS NAT preserves IP options across the NAT, but our PIX and our ASA drop all IP options. Testing will be necessary to determine how various residential style NATs (Linksys, etc.) handle IP options such as RAO. Does anyone know what other NATs do with RAO? -d From dhudson@ubicom.com Wed, 2 Aug 2006 09:27:23 -0700 (PDT) From: "Dave Hudson" Date: Wed, 2 Aug 2006 09:27:23 -0700 (PDT) Subject: RE: [Ietf-behave] IP options and NATs In-Reply-To: <0e2501c6b64f$76a7fc30$ef52150a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I certainly know of quite a number of residential NATs that discard IP options. On the slightly related subject of things being discarded I also know of several that discard DSCP information too. Regards, Dave * -----Original Message----- * From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx * [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wing * Sent: 02 August 2006 17:20 * To: ietf-behave@xxxxxxxxxxxxxxxxxxx * Cc: 'Pashalidis, Andreas' * Subject: [Ietf-behave] IP options and NATs * * While reviewing draft-pashalidis-nsis-gist-legacynats-00.txt, * I noticed: * * > The discussion in this document is based on the * > following assumptions. * > ... * > 6. The legacy NAT does not drop IP packets with a * > Router Alert Option (RAO) or an IPv6 extensions * > header. Furthermore, the RAO or extension header * > is also present in the forwarded packet. If the * > NAT does not do this, then there is no way for a * > GIST QUERY to traverse the NAT, which is a * > prerequisite for the mechanisms described in this * > document. * * I am wondering how today's NATs handle IP options. I asked * our engineering teams and found that Cisco's IOS NAT * preserves IP options across the NAT, but our PIX and our ASA * drop all IP options. Testing will be necessary to determine * how various residential style NATs (Linksys, etc.) handle IP * options such as RAO. * * Does anyone know what other NATs do with RAO? * * -d * _______________________________________________ * Ietf-behave mailing list * Ietf-behave@xxxxxxxxxxxxxxxxxxx * https://list.sipfoundry.org/mailman/listinfo/ietf-behave * * From lars.eggert@netlab.nec.de Wed, 2 Aug 2006 11:23:54 -0700 (PDT) From: Lars Eggert Date: Wed, 2 Aug 2006 11:23:54 -0700 (PDT) Subject: Re: [Ietf-behave] IP options and NATs In-Reply-To: <0e2501c6b64f$76a7fc30$ef52150a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Aug 2, 2006, at 18:19, Dan Wing wrote: I am wondering how today's NATs handle IP options. Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. ACM Computer Communication Review, 35(2), April 2005. http://www.icir.org/mallman/papers/tcp-evo- ccr05.ps It's not about NATs in particular, but just probes a large number of Internet paths, and sure enough, *something* out there drops IP options. Lars -- Lars Eggert NEC Network Laboratories Attachment: smime.p7s --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="p7s00008.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7s00008.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwODAyMTgyMzQ3WjAjBgkqhkiG9w0BCQQxFgQU4HCHU+G4WSIgoocrSP6c XRx+SKkwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAAtrt7MWKWPGhl6gzVI9MHuVRqiJUF9iiUfULGF8xjOJs7bY8m+7Sg2DaoeanXYSkJydROdn aScDCBaIcFaijCNlbaZlwx5aCl/6mJ3rsKNai1uP4xLz2tWmeZ+OcZyrm96Xw7ZbChXTCwFefhaK XxElMgGjP1Utkd173FEj+7+ABzc+X1LYGqtBK77kGb+GDDlzYHRg3uYqy7NuNozGFi9zGeaVww9E 3Yowy41VUIrjDlpE2tc3aDmD/xr7mnjjJqS0FoQggHFhW5uf2bAME0a9W5NGDyDuEpq0FXYFl+sj 14DfkClk35eaYpvwLydRMtqdz+lPMJHzyDk1NJeB5scAAAAAAAA= --Boundary..27398.1163630136.multipart/signed-- From philip_matthews@magma.ca Thu, 3 Aug 2006 12:43:42 -0500 (CDT) (envelope-from philip_matthews@magma.ca) From: Philip Matthews Date: Thu, 3 Aug 2006 12:43:42 -0500 (CDT) (envelope-from philip_matthews@magma.ca) Subject: [Ietf-behave] (no subject) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Folks: I just thought I should let everyone know that there was a brief presentation of some of the key points in the behave-tcp draft at the TCPM session in Montreal on Thursday afternoon. Originally, Saikat was supposed to give this presentation, but he was unable to make it, so I ended up doing it. The presentation covered the following points from the draft: 1) The handling of unsolicited SYNs; 2) The timeout of a connection after 2 hours and 4 minutes; 3) Leaving the exact behavior of the Time-Wait state unspecified. On the first point, the presentation mentioned the various alternatives considered and the decision by BEHAVE to have the NAT send an ICMP Port Unreachable message after a 6 second delay. There was a good discussion on the various alternatives, in particular the idea of using a soft ICMP error code rather than "Port Unreachable". (Unlike the BEHAVE meeting, no one questioned the choice of 6 seconds). In the end the TCPM group said they were happy with the BEHAVE decision. The one other comment received was a request to make the behavior configurable, so that administrators could configure the NAT box to silently drop the SYN instead. There were no comments on points (2) and (3). Those interested can see the slides used in the presentation on the IETF website, and can listen to the audio replay. Minutes of the session are not (yet) available. - Philip From xavier.marjou@orange-ft.com Fri, 4 Aug 2006 03:01:03 -0500 (CDT) (envelope-from xavier.marjou@orange-ft.com) From: "Xavier Marjou" Date: Fri, 4 Aug 2006 03:01:03 -0500 (CDT) (envelope-from xavier.marjou@orange-ft.com) Subject: Re: [Ietf-behave] Dedicated draft for RTP keepalive? Message-ID: MIME-Version: 1.0 Content-Type: text/plain In order to fix ideas, I have posted the following draft: http://www.ietf.org/internet-drafts/draft-marjou-behave-app-rtp-keepalive- 00.txt Xavier -----Original Message----- Object: Dedicated draft for RTP keepalive? Looking at current applications, there are 2 fundamental behaviors that help RTP applications with regards to NAT traversal: "Symmetric RTP" and "Binding keepalives". The first topic is shortly described in a short doc (draft-wing-behave- symmetric-rtprtcp-01). The second topic is currently described in draft-ietf-mmusic-ice-09 (section 7.12), which nicely describes two "binding keepalives" mechanisms: one for communications between ICE agents (STUN-keepalive case) and another for communications between non-ICE agents (RTP-keepalive fallback case). For the latter, I propose to extract it in a separate doc so that non-ICE applications can refer to a very short doc for basic "binding keepalives". What do you think? Xavier From christer.holmberg@ericsson.com Fri, 4 Aug 2006 03:25:42 -0500 (CDT) (envelope-from christer.holmberg@ericsson.com) From: "Christer Holmberg \(JO/LMF\)" Date: Fri, 4 Aug 2006 03:25:42 -0500 (CDT) (envelope-from christer.holmberg@ericsson.com) Subject: Re: [Ietf-behave] Dedicated draft for RTP keepalive? In-Reply-To: Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12CA@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain Hi, A short question. In chapter 4.3 you say: "For media sessions negotiated with SDP, there is a need for the endpoint to use ICE." You can use STUN without using ICE, can't you? Regards, Christer -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Xavier Marjou Sent: 4. elokuuta 2006 10:56 To: ietf-behave@xxxxxxxxxxxxxxxxxxx Cc: mmusic@xxxxxxxx Subject: Re: [Ietf-behave] Dedicated draft for RTP keepalive? In order to fix ideas, I have posted the following draft: http://www.ietf.org/internet-drafts/draft-marjou-behave-app-rtp-keepaliv e- 00.txt Xavier -----Original Message----- Object: Dedicated draft for RTP keepalive? Looking at current applications, there are 2 fundamental behaviors that help RTP applications with regards to NAT traversal: "Symmetric RTP" and "Binding keepalives". The first topic is shortly described in a short doc (draft-wing-behave- symmetric-rtprtcp-01). The second topic is currently described in draft-ietf-mmusic-ice-09 (section 7.12), which nicely describes two "binding keepalives" mechanisms: one for communications between ICE agents (STUN-keepalive case) and another for communications between non-ICE agents (RTP-keepalive fallback case). For the latter, I propose to extract it in a separate doc so that non-ICE applications can refer to a very short doc for basic "binding keepalives". What do you think? Xavier _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From xavier.marjou@orange-ft.com Fri, 4 Aug 2006 04:05:44 -0500 (CDT) (envelope-from xavier.marjou@orange-ft.com) From: "Xavier Marjou" Date: Fri, 4 Aug 2006 04:05:44 -0500 (CDT) (envelope-from xavier.marjou@orange-ft.com) Subject: Re: [Ietf-behave] Dedicated draft for RTP keepalive? Message-ID: MIME-Version: 1.0 Content-Type: text/plain For media sessions negotiated with SDP, I did not want to interfere with ICE, which details how to make use of STUN. Therefore I stated that if STUN is used by the endpoint, then he has to be ICE compliant. However, I agree that STUN could be used without ICE for keepalive. Xavier -----Message d'origine----- De : Christer Holmberg (JO/LMF) [mailto:christer.holmberg@xxxxxxxxxxxx] Envoy : vendredi 4 aot 2006 10:25 : MARJOU Xavier RD-MAPS-LAN; ietf-behave@xxxxxxxxxxxxxxxxxxx Cc : mmusic@xxxxxxxx Objet : RE: [Ietf-behave] Dedicated draft for RTP keepalive? Hi, A short question. In chapter 4.3 you say: "For media sessions negotiated with SDP, there is a need for the endpoint to use ICE." You can use STUN without using ICE, can't you? Regards, Christer From christer.holmberg@ericsson.com Fri, 4 Aug 2006 04:50:10 -0500 (CDT) (envelope-from christer.holmberg@ericsson.com) From: "Christer Holmberg \(JO/LMF\)" Date: Fri, 4 Aug 2006 04:50:10 -0500 (CDT) (envelope-from christer.holmberg@ericsson.com) Subject: Re: [Ietf-behave] Dedicated draft for RTP keepalive? In-Reply-To: Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F12CD@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain Hi, The bis draft of the STUN spec defines a specific STUN keep-alive "usage". So, you don't need ICE in order to use STUN for pure keep-alive purpose. We are also going to define how to use STUN for SIP signalling keep-alive - without any "interference" of ICE. Regards, Christer -----Original Message----- From: Xavier Marjou [mailto:xavier.marjou@xxxxxxxxxxxxx] Sent: 4. elokuuta 2006 12:01 To: Christer Holmberg (JO/LMF) Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] Dedicated draft for RTP keepalive? For media sessions negotiated with SDP, I did not want to interfere with ICE, which details how to make use of STUN. Therefore I stated that if STUN is used by the endpoint, then he has to be ICE compliant. However, I agree that STUN could be used without ICE for keepalive. Xavier -----Message d'origine----- De : Christer Holmberg (JO/LMF) [mailto:christer.holmberg@xxxxxxxxxxxx] Envoy : vendredi 4 aot 2006 10:25 : MARJOU Xavier RD-MAPS-LAN; ietf-behave@xxxxxxxxxxxxxxxxxxx Cc : mmusic@xxxxxxxx Objet : RE: [Ietf-behave] Dedicated draft for RTP keepalive? Hi, A short question. In chapter 4.3 you say: "For media sessions negotiated with SDP, there is a need for the endpoint to use ICE." You can use STUN without using ICE, can't you? Regards, Christer From dwing@cisco.com Wed, 9 Aug 2006 18:59:41 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Wed, 9 Aug 2006 18:59:41 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: [Ietf-behave] IP options and NATs Message-ID: <0c9601c6bc0f$d91485d0$2182200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain An update: I just tried sending UDP packets with IP options set through a Linksys WRT54Gv2 and I could successfully pass packets from inside->outside. I didn't try outside->inside. (Originally I was testing to a system on the Internet, but something was dropping my packets with IP options, as was cited earlier.) -d From dwing@cisco.com Tue, 15 Aug 2006 19:16:39 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Tue, 15 Aug 2006 19:16:39 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] [Sip] Outbound - a new STUN keealive proposal In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F134B@esealmw113.eemea.ericsson.se> Message-ID: <063501c6c0c9$36fdf3d0$0652150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > >> 1. Editorial: Shouldn't the > >> stop-sending-STUN-requests-if-retransmissions-fail text (point > >> 2) be in 3849bis? To me it sounds like generic STUN > >> transaction procedures, which should be defined in the STUN > >> spec. Or, do we consider it specific to the STUN keepalive > >> usage for SIP??? > > > >Propose some text - as much as the advice can be made generic, I > >would want it to be in 3849bis. I suspect it hard to say too much > >more than what is in 3849. > > I need to think a little more about this a little bit more. > > Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, > and when a transaction shall be considered to have failed. But, > there is no text about what happens after that. THAT may be STUN > usage dependent, though, and in some cases it could even be "an > implementation issue"... > > But, I don't see anything SIP specific in saying that STUN > keep-alive re-transmissions shall stop if there is no reply, so > shouldn't that text be in 3849bis - either in the generic > transaction chapter (chapter 7), or in the keep-alive usage chapter > (12.4)? The part of the outbound spec defining the SIP usage of STUN > keep-alive can then of course refer to that text in 3849bis. It would be more appropriate in the keepalive usage section. > My main concern is that we dont specify things which people will > later find out belongs to another spec, and another WG. My concern is that if you stop doing STUN keepalives because you haven't received a response in NNNN retransmissions, your NAT binding will time out soon thereafter. So here is some proposed text for the RFC3489bis keepalive section: If, after retransmitting the STUN Binding Request NNNN times, the STUN client does not receive a STUN Binding Response, the STUN client should assume the STUN server is no longer available. The STUN client SHOULD cease retransmitting the STUN keepalives and inform other applications that the NAT binding is no longer valid (e.g., attempt to re-register if using SIP). -d From christer.holmberg@ericsson.com Wed, 16 Aug 2006 01:55:14 -0500 (CDT) (envelope-from christer.holmberg@ericsson.com) From: "Christer Holmberg \(JO/LMF\)" Date: Wed, 16 Aug 2006 01:55:14 -0500 (CDT) (envelope-from christer.holmberg@ericsson.com) Subject: Re: [Ietf-behave] [Sip] Outbound - a new STUN keealive proposal In-Reply-To: <18997.12.151.41.2.1155687636.squirrel@12.151.41.2> Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F134F@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain Hi Rohan, We could write something like: "If the STUN binding transaction fails, as described in 3489, the SIP UA must/may/could/must not do this-and-that-SIP-procedure". I have nothing against putting SIP specific actions into the outbound draft, but anything that can be considered to be generic to STUN keepalive usage should be in 3489bis. Regards, Christer -----Original Message----- From: Rohan Mahy [mailto:rohan@xxxxxxxxxx] Sent: 16. elokuuta 2006 3:21 To: Dan Wing Cc: Christer Holmberg (JO/LMF); 'Cullen Jennings'; 'SIP'; 'Rohan Mahy'; ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Sip] Outbound - a new STUN keealive proposal Hi, I think this is a slippery slope for 3489bis. I can think of about 3 use cases that would break, or at least would be confusing, with this wording. I would like some time to propose language specific to SIP and STUN on the same port that is appropriate. thanks, -rohan >> >> 1. Editorial: Shouldn't the >> >> stop-sending-STUN-requests-if-retransmissions-fail text (point >> >> 2) be in 3849bis? To me it sounds like generic STUN >> >> transaction procedures, which should be defined in the STUN >> >> spec. Or, do we consider it specific to the STUN keepalive >> >> usage for SIP??? >> > >> >Propose some text - as much as the advice can be made generic, I >> >would want it to be in 3849bis. I suspect it hard to say too much >> >more than what is in 3849. >> >> I need to think a little more about this a little bit more. >> >> Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, >> and when a transaction shall be considered to have failed. But, >> there is no text about what happens after that. THAT may be STUN >> usage dependent, though, and in some cases it could even be "an >> implementation issue"... >> >> But, I don't see anything SIP specific in saying that STUN keep-alive >> re-transmissions shall stop if there is no reply, so shouldn't that >> text be in 3849bis - either in the generic transaction chapter >> (chapter 7), or in the keep-alive usage chapter (12.4)? The part of >> the outbound spec defining the SIP usage of STUN keep-alive can then >> of course refer to that text in 3849bis. > > It would be more appropriate in the keepalive usage section. > >> My main concern is that we dont specify things which people will >> later find out belongs to another spec, and another WG. > > My concern is that if you stop doing STUN keepalives because you > haven't received a response in NNNN retransmissions, your NAT binding > will time out soon thereafter. So here is some proposed text for the > RFC3489bis keepalive section: > > If, after retransmitting the STUN Binding Request NNNN times, > the STUN client does not receive a STUN Binding Response, the > STUN client should assume the STUN server is no longer > available. The STUN client SHOULD cease retransmitting the > STUN keepalives and inform other applications that the NAT > binding is no longer valid (e.g., attempt to re-register if > using SIP). > > -d > From christer.holmberg@ericsson.com Wed, 16 Aug 2006 01:56:15 -0500 (CDT) (envelope-from christer.holmberg@ericsson.com) From: "Christer Holmberg \(JO/LMF\)" Date: Wed, 16 Aug 2006 01:56:15 -0500 (CDT) (envelope-from christer.holmberg@ericsson.com) Subject: Re: [Ietf-behave] [Sip] Outbound - a new STUN keealive proposal In-Reply-To: <063501c6c0c9$36fdf3d0$0652150a@amer.cisco.com> Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1351@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain Hi, >>>> 1. Editorial: Shouldn't the >>>> stop-sending-STUN-requests-if-retransmissions-fail text (point >>>> 2) be in 3849bis? To me it sounds like generic STUN >>>> transaction procedures, which should be defined in the STUN >>>> spec. Or, do we consider it specific to the STUN keepalive >>>> usage for SIP??? >>> >>>Propose some text - as much as the advice can be made generic, I >>>would want it to be in 3849bis. I suspect it hard to say too much >>>more than what is in 3849. >> >>I need to think a little more about this a little bit more. >> >>Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, >>and when a transaction shall be considered to have failed. But, there >>is no text about what happens after that. THAT may be STUN usage >>dependent, though, and in some cases it could even be "an >>implementation issue"... >> >>But, I don't see anything SIP specific in saying that STUN keep-alive >>re-transmissions shall stop if there is no reply, so shouldn't that >>text be in 3849bis - either in the generic transaction chapter >>(chapter 7), or in the keep-alive usage chapter (12.4)? The part of >>the outbound spec defining the SIP usage of STUN keep-alive can then >>of course refer to that text in 3849bis. > >It would be more appropriate in the keepalive usage section. > >>My main concern is that we dont specify things which people will later >>find out belongs to another spec, and another WG. > >My concern is that if you stop doing STUN keepalives because you haven't received a response in NNNN retransmissions, >your NAT binding will time out soon thereafter. So here is some proposed text for the RFC3489bis keepalive section: > > If, after retransmitting the STUN Binding Request NNNN times, > the STUN client does not receive a STUN Binding Response, the > STUN client should assume the STUN server is no longer > available. The STUN client SHOULD cease retransmitting the > STUN keepalives and inform other applications that the NAT > binding is no longer valid (e.g., attempt to re-register if > using SIP). I don't think we need to talk about NNNN times. Can't we simply say "If the STUN client does not receive a response, and the STUN transaction fails, the STUN client should assume....". Then, IF we want to talk about SIP actions taken due to the failure (re-registers etc), THAT belongs to a SIP specific spec I think. Regards, Christer From rohan@ekabal.com Tue, 15 Aug 2006 19:20:44 -0500 (CDT) (envelope-from rohan@figas.ekabal.com) From: Rohan Mahy Date: Tue, 15 Aug 2006 19:20:44 -0500 (CDT) (envelope-from rohan@figas.ekabal.com) Subject: Re: [Ietf-behave] [Sip] Outbound - a new STUN keealive proposal In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F134B@esealmw113.eemea.ericsson.se> Message-ID: <18997.12.151.41.2.1155687636.squirrel@12.151.41.2> MIME-Version: 1.0 Content-Type: text/plain Hi, I think this is a slippery slope for 3489bis. I can think of about 3 use cases that would break, or at least would be confusing, with this wording. I would like some time to propose language specific to SIP and STUN on the same port that is appropriate. thanks, -rohan >> >> 1. Editorial: Shouldn't the >> >> stop-sending-STUN-requests-if-retransmissions-fail text (point >> >> 2) be in 3849bis? To me it sounds like generic STUN >> >> transaction procedures, which should be defined in the STUN >> >> spec. Or, do we consider it specific to the STUN keepalive >> >> usage for SIP??? >> > >> >Propose some text - as much as the advice can be made generic, I >> >would want it to be in 3849bis. I suspect it hard to say too much >> >more than what is in 3849. >> >> I need to think a little more about this a little bit more. >> >> Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, >> and when a transaction shall be considered to have failed. But, >> there is no text about what happens after that. THAT may be STUN >> usage dependent, though, and in some cases it could even be "an >> implementation issue"... >> >> But, I don't see anything SIP specific in saying that STUN >> keep-alive re-transmissions shall stop if there is no reply, so >> shouldn't that text be in 3849bis - either in the generic >> transaction chapter (chapter 7), or in the keep-alive usage chapter >> (12.4)? The part of the outbound spec defining the SIP usage of STUN >> keep-alive can then of course refer to that text in 3849bis. > > It would be more appropriate in the keepalive usage section. > >> My main concern is that we dont specify things which people will >> later find out belongs to another spec, and another WG. > > My concern is that if you stop doing STUN keepalives because you > haven't received a response in NNNN retransmissions, your NAT > binding will time out soon thereafter. So here is some proposed text > for the RFC3489bis keepalive section: > > If, after retransmitting the STUN Binding Request NNNN times, > the STUN client does not receive a STUN Binding Response, the > STUN client should assume the STUN server is no longer > available. The STUN client SHOULD cease retransmitting the > STUN keepalives and inform other applications that the NAT > binding is no longer valid (e.g., attempt to re-register if > using SIP). > > -d > From rohan@ekabal.com Wed, 16 Aug 2006 10:42:38 -0500 (CDT) (envelope-from rohan@ekabal.com) From: Rohan Mahy Date: Wed, 16 Aug 2006 10:42:38 -0500 (CDT) (envelope-from rohan@ekabal.com) Subject: Re: [Ietf-behave] [Sip] Outbound - a new STUN keealive proposal In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1351@esealmw113.eemea.ericsson.se> Message-ID: <5eb344b07237e72d815e46263b744088@ekabal.com> MIME-Version: 1.0 Content-Type: text/plain Christer, it is not that simple. Does the STUN client send retransmissions? What if the STUN transaction failed but other traffic to the same port succeeded before-hand? afterwards? What happens if the STUN transaction fails over an still open TCP connection? What if your TCP connection stalls? thanks, -rohan On Aug 15, 2006, at 23:55, Christer Holmberg ((JO/LMF)) wrote: Hi, 1. Editorial: Shouldn't the stop-sending-STUN-requests-if-retransmissions-fail text (point 2) be in 3849bis? To me it sounds like generic STUN transaction procedures, which should be defined in the STUN spec. Or, do we consider it specific to the STUN keepalive usage for SIP??? Propose some text - as much as the advice can be made generic, I would want it to be in 3849bis. I suspect it hard to say too much more than what is in 3849. I need to think a little more about this a little bit more. Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, and when a transaction shall be considered to have failed. But, there is no text about what happens after that. THAT may be STUN usage dependent, though, and in some cases it could even be "an implementation issue"... But, I don't see anything SIP specific in saying that STUN keep-alive re-transmissions shall stop if there is no reply, so shouldn't that text be in 3849bis - either in the generic transaction chapter (chapter 7), or in the keep-alive usage chapter (12.4)? The part of the outbound spec defining the SIP usage of STUN keep-alive can then of course refer to that text in 3849bis. It would be more appropriate in the keepalive usage section. My main concern is that we dont specify things which people will later find out belongs to another spec, and another WG. My concern is that if you stop doing STUN keepalives because you haven't received a response in NNNN retransmissions, your NAT binding will time out soon thereafter. So here is some proposed text for the RFC3489bis keepalive section: If, after retransmitting the STUN Binding Request NNNN times, the STUN client does not receive a STUN Binding Response, the STUN client should assume the STUN server is no longer available. The STUN client SHOULD cease retransmitting the STUN keepalives and inform other applications that the NAT binding is no longer valid (e.g., attempt to re-register if using SIP). I don't think we need to talk about NNNN times. Can't we simply say "If the STUN client does not receive a response, and the STUN transaction fails, the STUN client should assume....". Then, IF we want to talk about SIP actions taken due to the failure (re-registers etc), THAT belongs to a SIP specific spec I think. Regards, Christer From eric_d_cooper@sympatico.ca Wed, 16 Aug 2006 14:25:45 -0500 (CDT) (envelope-from eric_d_cooper@sympatico.ca) From: "Eric Cooper" Date: Wed, 16 Aug 2006 14:25:45 -0500 (CDT) (envelope-from eric_d_cooper@sympatico.ca) Subject: [Ietf-behave] Time to add mapping/filtering entries Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi All, I've recently been looking into 'Internet Connectivity Establishment' (ICE), which contains some statements indicating that some NAT/FW devices may be overwhelmed if they need to create a bunch of new mapping and/or filtering entries in a short amount of time. Specific to ICE, 'a bunch' is somewhere on the order of 5-25 per ICE endpoint. ICE indicates that endpoints should rate limit packets such that packets which would likely create new mapping and/or filtering entries are spaced 50 ms apart. I wonder if this spacing is really necessary. A quick experiment with Ethereal and my browser seems to indicate that HTTP GET requests to different servers are not spaced 50 ms apart. My questions to the group are: 1) Does anyone have any empirical data regarding the speed at which new mapping/filtering entries can be created on various devices? 2) What is your opinion w.r.t. this 50 ms spacing? Is it necessary for existing devices, and will it continue to be necessary for BEHAVE-NAT-UDP compliant devices? Thanks! Eric Cooper. From christer.holmberg@ericsson.com Thu, 17 Aug 2006 07:15:18 -0500 (CDT) (envelope-from christer.holmberg@ericsson.com) From: "Christer Holmberg \(JO/LMF\)" Date: Thu, 17 Aug 2006 07:15:18 -0500 (CDT) (envelope-from christer.holmberg@ericsson.com) Subject: Re: [Ietf-behave] [Sip] Outbound - a new STUN keealive proposal In-Reply-To: <5eb344b07237e72d815e46263b744088@ekabal.com> Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F136E@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain >Christer, it is not that simple. Does the STUN client send retransmissions? According to 3849bis, it does. >What if the STUN transaction failed but other traffic to the same port succeeded before-hand? afterwards? That is an interesting question. But, I don't tink it's SIP specific, because that "other traffic" could be non-SIP. But, I am not sure we want to specify behavior, saying that one protocol behavior is dependent on another... >What happens if the STUN transaction fails over an still open TCP connection? What if your TCP connection stalls? That is also an interesting question. But, I don't think that is SIP specific either. So, there may be more issues we need to consider. But, if we can agree they belong to 3849bis we can move the discussion to BEHAVE, and it won't affect the work on the outbound spec. But, again, if we want the STUN failure to trigger SIP specific actions (e.g. trigger the sending of a new REGISTER), that should of course be described in the outbound draft. Regards, Christer On Aug 15, 2006, at 23:55, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >>>>> 1. Editorial: Shouldn't the >>>>> stop-sending-STUN-requests-if-retransmissions-fail text (point >>>>> 2) be in 3849bis? To me it sounds like generic STUN >>>>> transaction procedures, which should be defined in the STUN >>>>> spec. Or, do we consider it specific to the STUN keepalive >>>>> usage for SIP??? >>>> >>>> Propose some text - as much as the advice can be made generic, I >>>> would want it to be in 3849bis. I suspect it hard to say too much >>>> more than what is in 3849. >>> >>> I need to think a little more about this a little bit more. >>> >>> Chapter 7.1 of 3849bis does talk about STUN re-transimission timers, >>> and when a transaction shall be considered to have failed. But, >>> there > >>> is no text about what happens after that. THAT may be STUN usage >>> dependent, though, and in some cases it could even be "an >>> implementation issue"... >>> >>> But, I don't see anything SIP specific in saying that STUN >>> keep-alive re-transmissions shall stop if there is no reply, so >>> shouldn't that text be in 3849bis - either in the generic >>> transaction chapter (chapter 7), or in the keep-alive usage chapter >>> (12.4)? The part of the outbound spec defining the SIP usage of STUN >>> keep-alive can then of course refer to that text in 3849bis. >> >> It would be more appropriate in the keepalive usage section. >> >>> My main concern is that we dont specify things which people will >>> later > >>> find out belongs to another spec, and another WG. >> >> My concern is that if you stop doing STUN keepalives because you > haven't received a response in NNNN retransmissions, >> your NAT binding will time out soon thereafter. So here is some > proposed text for the RFC3489bis keepalive section: >> >> If, after retransmitting the STUN Binding Request NNNN times, the >> STUN client does not receive a STUN Binding Response, the STUN >> client should assume the STUN server is no longer available. The >> STUN client SHOULD cease retransmitting the STUN keepalives and >> inform other applications that the NAT binding is no longer valid >> (e.g., attempt to re-register if using SIP). > > I don't think we need to talk about NNNN times. Can't we simply say > "If the STUN client does not receive a response, and the STUN > transaction fails, the STUN client should assume....". > > Then, IF we want to talk about SIP actions taken due to the failure > (re-registers etc), THAT belongs to a SIP specific spec I think. > > Regards, > > Christer From jdrosen@cisco.com Thu, 17 Aug 2006 13:55:54 -0500 (CDT) (envelope-from jdrosen@cisco.com) From: Jonathan Rosenberg Date: Thu, 17 Aug 2006 13:55:54 -0500 (CDT) (envelope-from jdrosen@cisco.com) Subject: [Ietf-behave] STUN issue: CRC vs. SLIP-like encapsulation Message-ID: <44E4BBAF.6000808@cisco.com> MIME-Version: 1.0 Content-Type: text/plain During the last IETF meeting, I discussed the motivations for the FINGERPRINT attribute, which was added in rfc3489bis-04. The basic problem statement is that there are now several usages of STUN which multiplex STUN and some kind of application data (the keepalive usage, which is utilized by sip-outbound, and the connectivity check, used by ICE). STUN-04 discusses how an agent can demux STUN from application data on the same port. The magic cookie provides a simple way that often works, but I was worried about high-rate application protocols with sufficiently randomized data that you would still have collisions - i.e., cases where the magic cookie appears in the data stream in the exact same position. So, the FINGERPRINT as defined in -04 was a SHA-1 hash over the STUN message. If the STUN server gets a packet and the magic cookie is there, it can double check the FINGERPRINT to verify that this is a STUN packet. During the meeting, there was general agreement that something like this would be useful. However, it was suggested that a 32 bit CRC would be sufficiently effective and much simpler, which I agreed. There was also a suggestion at the microphone (I cannot recall who suggested it) for a different solution, which I'll call the "SLIP-style" solution. In this solution, when the client is about to send a data packet on the same IP/port as the STUN is running, it looks to see if the data has the magic cookie in bits 32-63. If it does, it takes the UDP datagram and encapsultes it as an attribute into a STUN message, "Send". This arrives at the STUN server, which decapsulates it, and treats that packet as if it had been sent as non-stun encapsulated. There is already such a Send message in TURN; it would basically be moved into STUN itself. So, the issue is: which mechanism to use - fingerprint or slip-style? I've thought about this a bit, and have come up with the following pros/cons: SLIP-Style ---------- PRO: only add packet overhead when there is a collision, as opposed to every stun message PRO: CPU cost of performing an enapsulation is cheaper than performing a CRC computation CON: may complicate QoS reservation mechanisms, since the packet size for data packets is now less predicable and dependent on the contents of the data CON: might push the size of large UDP packets over the path MTU; i.e., path MTU computations done by the application would be invalid since the effective MTU is reduced by the size of the STUN encapsulation overhead CON: will 'hide' select data packets in a stun enapsulation, totally messing up any on-path tools (things like RTP voice quality measurement devices) that are sniffing for application data packets. Note that this is not actually a problem for RTP since RTP will never conflict with STUN. However, it can happen for SIP if it is compressed with sigcomp. CON: If you accidentially use something like the keepalive usage with a server which doesn't support stun (this is a big thread on the sip list), but correctly discards stun packets, with the slip-like encapsulation, actual data packets will be lost. CON: requires the client to monitor every data packet for the cookie. Thus, the CPU cost is proportional to the data transmit rate. With the fingerprint, the CPU cost of the CRC computation is proportional to the stun data rate. Fingerprint ----------- PRO: Allows easier implementation for stun clients; STUN sender and application can share a socket without talking to each other PRO: predictable packet sizes and data rates (good for QoS reservations) PRO: doesn't impact path MTU computations PRO: CRC computation cost is uniform and predictable - function of the stun rate and not the data rate PRO: doesn't interfere with or touch the application data stream My proposal, as you might guess, is to go with a fingerprint mechanism, and in particular a 32 bit CRC. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From adam@estacado.net Fri, 18 Aug 2006 17:08:43 -0500 (CDT) (envelope-from adam@estacado.net) From: Adam Roach Date: Fri, 18 Aug 2006 17:08:43 -0500 (CDT) (envelope-from adam@estacado.net) Subject: Re: [Ietf-behave] STUN issue: CRC vs. SLIP-like encapsulation In-Reply-To: <44E4BBAF.6000808@cisco.com> Message-ID: <44E63A5F.3060205@estacado.net> MIME-Version: 1.0 Content-Type: text/plain Jonathan Rosenberg wrote: My proposal, as you might guess, is to go with a fingerprint mechanism, and in particular a 32 bit CRC. I think either mechanism works, and will happily go along with either. However, I'd like to reiterate a point that someone else raised at the microphone when we were discussing the issue of SHA-1 versus CRC-32: you probably don't want to use a standard CRC-32 straight up, on the off chance that the multiplexed protocol *also* uses CRC-32, and happens to put it in the same place as one would expect the fingerprint. I believe the suggestion was to take the output of some standard CRC-32 operation and XOR it with a 32-bit value (e.g. 0x5354554e -- "STUN" in ASCII). /a From aeh@db.org Mon, 21 Aug 2006 06:17:43 -0500 (CDT) (envelope-from aeh@db.org) From: "Alfred E. Heggestad" Date: Mon, 21 Aug 2006 06:17:43 -0500 (CDT) (envelope-from aeh@db.org) Subject: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-04 Message-ID: <44E9964D.4000004@db.org> MIME-Version: 1.0 Content-Type: text/plain Hi I have some comments on draft-ietf-behave-rfc3489bis-04 (mainly typos, see below). If an RFC3489 compliant STUN server receives a STUN request with an unknown attribute (i.e. FINGERPRINT), is it supposed to drop it? Minor comments: > Section 6, page 13: > > that they are a multiple of 4 btyes. Such padding is only needed > ^^^^^ typo - should be "4 bytes" > Section 9.1.1, page 25: > > Next, the server MUST check for any mantadory attributes in the > ^^^^^^^^^ typo - should be "mandatory" > Section 11.13, page 34: > > that are being used for keepalives. The REFRESH-INTERVAL provies a > ^^^^^^^ typo - should be "provides" > Section 11.13, page 34: > > represents an interval measured in millseconds. It can be present in > ^^^^^^^^^^^ typo - should be "milliseconds" /alfred From pete.cordell@tech-know-ware.com Mon, 21 Aug 2006 08:39:55 -0500 (CDT) (envelope-from pete.cordell@tech-know-ware.com) From: "Pete Cordell" Date: Mon, 21 Aug 2006 08:39:55 -0500 (CDT) (envelope-from pete.cordell@tech-know-ware.com) Subject: Re: [Ietf-behave] STUN issue: CRC vs. SLIP-like encapsulation In-Reply-To: <44E4BBAF.6000808@cisco.com> Message-ID: <003b01c6c527$429a6950$5000a8c0@RW> MIME-Version: 1.0 Content-Type: text/plain Hi Jonathan, I haven't been following all the details of this, but I wondered whether this secondary check of whether it's a STUN packet could be done based on comparing the length of the overall STUN packet and the sum of the lengths of all the attributes. If by skipping over the lengths of all the attributes you don't arrive at the end of the packet, then it's not a STUN packet. In essence you have a number of 16-bit values (the attribute lengths) that must (notionally) add up to the message length. That may well give you similar entropy to the FINGERPRINT attribute, but doesn't require any additional parameters. Pete. P.S. BTW - Is it time to call it "Session Traversal Underneath NAT"? It doesn't seem so simple anymore! :-) -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= ----- Original Message ----- From: "Jonathan Rosenberg" To: "Behave" Sent: Thursday, August 17, 2006 7:55 PM Subject: [Ietf-behave] STUN issue: CRC vs. SLIP-like encapsulation During the last IETF meeting, I discussed the motivations for the FINGERPRINT attribute, which was added in rfc3489bis-04. The basic problem statement is that there are now several usages of STUN which multiplex STUN and some kind of application data (the keepalive usage, which is utilized by sip-outbound, and the connectivity check, used by ICE). STUN-04 discusses how an agent can demux STUN from application data on the same port. The magic cookie provides a simple way that often works, but I was worried about high-rate application protocols with sufficiently randomized data that you would still have collisions - i.e., cases where the magic cookie appears in the data stream in the exact same position. So, the FINGERPRINT as defined in -04 was a SHA-1 hash over the STUN message. If the STUN server gets a packet and the magic cookie is there, it can double check the FINGERPRINT to verify that this is a STUN packet. During the meeting, there was general agreement that something like this would be useful. However, it was suggested that a 32 bit CRC would be sufficiently effective and much simpler, which I agreed. There was also a suggestion at the microphone (I cannot recall who suggested it) for a different solution, which I'll call the "SLIP-style" solution. In this solution, when the client is about to send a data packet on the same IP/port as the STUN is running, it looks to see if the data has the magic cookie in bits 32-63. If it does, it takes the UDP datagram and encapsultes it as an attribute into a STUN message, "Send". This arrives at the STUN server, which decapsulates it, and treats that packet as if it had been sent as non-stun encapsulated. There is already such a Send message in TURN; it would basically be moved into STUN itself. So, the issue is: which mechanism to use - fingerprint or slip-style? I've thought about this a bit, and have come up with the following pros/cons: SLIP-Style ---------- PRO: only add packet overhead when there is a collision, as opposed to every stun message PRO: CPU cost of performing an enapsulation is cheaper than performing a CRC computation CON: may complicate QoS reservation mechanisms, since the packet size for data packets is now less predicable and dependent on the contents of the data CON: might push the size of large UDP packets over the path MTU; i.e., path MTU computations done by the application would be invalid since the effective MTU is reduced by the size of the STUN encapsulation overhead CON: will 'hide' select data packets in a stun enapsulation, totally messing up any on-path tools (things like RTP voice quality measurement devices) that are sniffing for application data packets. Note that this is not actually a problem for RTP since RTP will never conflict with STUN. However, it can happen for SIP if it is compressed with sigcomp. CON: If you accidentially use something like the keepalive usage with a server which doesn't support stun (this is a big thread on the sip list), but correctly discards stun packets, with the slip-like encapsulation, actual data packets will be lost. CON: requires the client to monitor every data packet for the cookie. Thus, the CPU cost is proportional to the data transmit rate. With the fingerprint, the CPU cost of the CRC computation is proportional to the stun data rate. Fingerprint ----------- PRO: Allows easier implementation for stun clients; STUN sender and application can share a socket without talking to each other PRO: predictable packet sizes and data rates (good for QoS reservations) PRO: doesn't impact path MTU computations PRO: CRC computation cost is uniform and predictable - function of the stun rate and not the data rate PRO: doesn't interfere with or touch the application data stream My proposal, as you might guess, is to go with a fingerprint mechanism, and in particular a 32 bit CRC. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Tue, 22 Aug 2006 19:12:03 -0500 (CDT) (envelope-from fluffy@cisco.com) From: Cullen Jennings Date: Tue, 22 Aug 2006 19:12:03 -0500 (CDT) (envelope-from fluffy@cisco.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: Message-ID: <0CAECBB4-77E5-4B9F-8D0F-3F76D814172E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain My test program that classifies NATs runs a bunch of tests in parallel. If you run the stun packets with no gap, it is clear that many NATs just lose some of the state they should be storing even though they forwarded the packet. When I gap by 10 ms, most NATs seem to work and I don't think I have anything that fails if I am at 20 ms but it is hard to test. There are reports that my test program fails on some NATs with 50ms gaps but I have not been able to replicate this. I have not investigated if you can burst a small number -- such as with HTTP traffic -- and have it work well all the time. All my testing has been with UDP not TCP. If people want to play with this, the software is the open source stuff at vovida.org. On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: Hi All, I've recently been looking into 'Internet Connectivity Establishment' (ICE), which contains some statements indicating that some NAT/FW devices may be overwhelmed if they need to create a bunch of new mapping and/or filtering entries in a short amount of time. Specific to ICE, 'a bunch' is somewhere on the order of 5-25 per ICE endpoint. ICE indicates that endpoints should rate limit packets such that packets which would likely create new mapping and/ or filtering entries are spaced 50 ms apart. I wonder if this spacing is really necessary. A quick experiment with Ethereal and my browser seems to indicate that HTTP GET requests to different servers are not spaced 50 ms apart. My questions to the group are: 1) Does anyone have any empirical data regarding the speed at which new mapping/filtering entries can be created on various devices? 2) What is your opinion w.r.t. this 50 ms spacing? Is it necessary for existing devices, and will it continue to be necessary for BEHAVE-NAT-UDP compliant devices? Thanks! Eric Cooper. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From bstucker@nortel.com Tue, 22 Aug 2006 21:20:21 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) From: "Brian Stucker" Date: Tue, 22 Aug 2006 21:20:21 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: <0CAECBB4-77E5-4B9F-8D0F-3F76D814172E@cisco.com> Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371100D8859@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain It would seem that the NATs are relying on the retransmission regiments of others to handle their overload issues. I wonder if this dropping of packets is also considered to be protection against a DoS attacks? Regards, Brian > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Cullen Jennings > Sent: Tuesday, August 22, 2006 7:12 PM > To: Eric Cooper > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > My test program that classifies NATs runs a bunch of tests in > parallel. If you run the stun packets with no gap, it is > clear that many NATs just lose some of the state they should > be storing even though they forwarded the packet. When I gap > by 10 ms, most NATs seem to work and I don't think I have > anything that fails if I am at 20 ms but it is hard to test. > There are reports that my test program fails on some NATs > with 50ms gaps but I have not been able to replicate this. > > I have not investigated if you can burst a small number -- > such as with HTTP traffic -- and have it work well all the > time. All my testing has been with UDP not TCP. > > If people want to play with this, the software is the open > source stuff at vovida.org. > > > > On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: > > > Hi All, > > > > I've recently been looking into 'Internet Connectivity > Establishment' > > (ICE), which contains some statements indicating that some NAT/FW > > devices may be overwhelmed if they need to create a bunch of new > > mapping and/or filtering entries in a short amount of time. > > > > Specific to ICE, 'a bunch' is somewhere on the order of > 5-25 per ICE > > endpoint. ICE indicates that endpoints should rate limit > packets such > > that packets which would likely create new mapping and/ or > filtering > > entries are spaced 50 ms apart. > > > > I wonder if this spacing is really necessary. A quick > experiment with > > Ethereal and my browser seems to indicate that HTTP GET requests to > > different servers are not spaced 50 ms apart. > > > > My questions to the group are: > > > > 1) Does anyone have any empirical data regarding the speed at which > > new mapping/filtering entries can be created on various devices? > > > > 2) What is your opinion w.r.t. this 50 ms spacing? Is it necessary > > for existing devices, and will it continue to be necessary for > > BEHAVE-NAT-UDP compliant devices? > > > > Thanks! > > > > Eric Cooper. > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From philip_matthews@magma.ca Wed, 23 Aug 2006 14:39:46 -0500 (CDT) (envelope-from philip_matthews@magma.ca) From: Philip Matthews Date: Wed, 23 Aug 2006 14:39:46 -0500 (CDT) (envelope-from philip_matthews@magma.ca) Subject: Re: [Ietf-behave] STUN issue: CRC vs. SLIP-like encapsulation In-Reply-To: <44E4BBAF.6000808@cisco.com> Message-ID: <476BFCDA-86EA-4DC6-B1C7-6F9088DB7AA0@magma.ca> MIME-Version: 1.0 Content-Type: text/plain I would like to point out that there is a third approach that we could take. In this approach, we add a "pre-header" before the start of the real STUN header which allows an implementation to reliably distinguish STUN packets from packets of the other protocol. The format of the "pre-header" depends on the other protocol that we are multiplexing STUN with. For example, if we are multiplexing STUN with SIP, then we might add a four-byte pre-header of "XXXX" before the start of the real STUN header, since a SIP message can never start with these four characters. Though conceptually the pre-header format needs to vary with the other protocol that we want to multiplex STUN with, it seems likely that we could find a "default pre-header" that would work for most other protocols. Here are what I see as the pros and cons of this approach: PRO: Can rapidly detect STUN packets from other packets with 100% reliability. PRO: The packets of the "other" protocol are never modified. CON: When we want to multiplex STUN with another protocol, we may need to define and standardize a new "pre-header" if the default pre-header is not sufficient to distinguish the two protocols. CON: There could conceivably be protocols where there is no pre-header format which fits the bill. (This seems unlikely to occur in practice, since it would seem to imply that almost any garbage packet is a well- formed message in the other protocol). - Philip PS. I believe it was Greg Daley that suggested the SLIP-style approach. On 17-Aug-06, at 14:55 , Jonathan Rosenberg wrote: During the last IETF meeting, I discussed the motivations for the FINGERPRINT attribute, which was added in rfc3489bis-04. The basic problem statement is that there are now several usages of STUN which multiplex STUN and some kind of application data (the keepalive usage, which is utilized by sip-outbound, and the connectivity check, used by ICE). STUN-04 discusses how an agent can demux STUN from application data on the same port. The magic cookie provides a simple way that often works, but I was worried about high-rate application protocols with sufficiently randomized data that you would still have collisions - i.e., cases where the magic cookie appears in the data stream in the exact same position. So, the FINGERPRINT as defined in -04 was a SHA-1 hash over the STUN message. If the STUN server gets a packet and the magic cookie is there, it can double check the FINGERPRINT to verify that this is a STUN packet. During the meeting, there was general agreement that something like this would be useful. However, it was suggested that a 32 bit CRC would be sufficiently effective and much simpler, which I agreed. There was also a suggestion at the microphone (I cannot recall who suggested it) for a different solution, which I'll call the "SLIP-style" solution. In this solution, when the client is about to send a data packet on the same IP/port as the STUN is running, it looks to see if the data has the magic cookie in bits 32-63. If it does, it takes the UDP datagram and encapsultes it as an attribute into a STUN message, "Send". This arrives at the STUN server, which decapsulates it, and treats that packet as if it had been sent as non-stun encapsulated. There is already such a Send message in TURN; it would basically be moved into STUN itself. So, the issue is: which mechanism to use - fingerprint or slip-style? I've thought about this a bit, and have come up with the following pros/cons: SLIP-Style ---------- PRO: only add packet overhead when there is a collision, as opposed to every stun message PRO: CPU cost of performing an enapsulation is cheaper than performing a CRC computation CON: may complicate QoS reservation mechanisms, since the packet size for data packets is now less predicable and dependent on the contents of the data CON: might push the size of large UDP packets over the path MTU; i.e., path MTU computations done by the application would be invalid since the effective MTU is reduced by the size of the STUN encapsulation overhead CON: will 'hide' select data packets in a stun enapsulation, totally messing up any on-path tools (things like RTP voice quality measurement devices) that are sniffing for application data packets. Note that this is not actually a problem for RTP since RTP will never conflict with STUN. However, it can happen for SIP if it is compressed with sigcomp. CON: If you accidentially use something like the keepalive usage with a server which doesn't support stun (this is a big thread on the sip list), but correctly discards stun packets, with the slip-like encapsulation, actual data packets will be lost. CON: requires the client to monitor every data packet for the cookie. Thus, the CPU cost is proportional to the data transmit rate. With the fingerprint, the CPU cost of the CRC computation is proportional to the stun data rate. Fingerprint ----------- PRO: Allows easier implementation for stun clients; STUN sender and application can share a socket without talking to each other PRO: predictable packet sizes and data rates (good for QoS reservations) PRO: doesn't impact path MTU computations PRO: CRC computation cost is uniform and predictable - function of the stun rate and not the data rate PRO: doesn't interfere with or touch the application data stream My proposal, as you might guess, is to go with a fingerprint mechanism, and in particular a 32 bit CRC. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Wed, 23 Aug 2006 19:13:32 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Wed, 23 Aug 2006 19:13:32 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] STUN issue: CRC vs. SLIP-like encapsulation In-Reply-To: <476BFCDA-86EA-4DC6-B1C7-6F9088DB7AA0@magma.ca> Message-ID: <059001c6c712$1bfc34d0$2782200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain As individual contributor: I believe we already have the scheme you're describing. STUN messages all start with the binary digits 0b00 (first two digits are zero). From rfc3489bis: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0| STUN Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transaction ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIP requests start with Method, which is required to be uppercase, and SIP responses start with the string "SIP/2.0", which is also required to be uppercase. Uppercase letters are in the binary range 1000001 ("A", decimal 65) through 1011010 ("Z", decimal 90), which start with the binary sequence 0b10, which is distinguishable from STUN's binary sequence 0b00. Even if an implementation were to send their SIP requests using method names starting with lowercase "a" (1100001) through "z" (1111010), those start with 0b11, which can still be differentiated from SIP packets. -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Philip Matthews > Sent: Wednesday, August 23, 2006 12:39 PM > To: Jonathan Rosenberg > Cc: Behave; Eric Cooper > Subject: Re: [Ietf-behave] STUN issue: CRC vs. SLIP-like encapsulation > > I would like to point out that there is a third approach that we > could take. > > In this approach, we add a "pre-header" before the start of the real > STUN > header which allows an implementation to reliably distinguish STUN > packets > from packets of the other protocol. The format of the "pre-header" > depends > on the other protocol that we are multiplexing STUN with. > > For example, if we are multiplexing STUN with SIP, then we might add > a four-byte pre-header of "XXXX" before the start of the real STUN > header, > since a SIP message can never start with these four characters. > > Though conceptually the pre-header format needs to vary with the other > protocol that we want to multiplex STUN with, it seems likely that > we could find a "default pre-header" that would work for most other > protocols. > > Here are what I see as the pros and cons of this approach: > > PRO: Can rapidly detect STUN packets from other packets with 100% > reliability. > > PRO: The packets of the "other" protocol are never modified. > > CON: When we want to multiplex STUN with another protocol, > we may need to define and standardize a new "pre-header" if the > default pre-header is not sufficient to distinguish the two protocols. > > CON: There could conceivably be protocols where there is no pre-header > format which fits the bill. (This seems unlikely to occur in practice, > since it would seem to imply that almost any garbage packet > is a well- > formed > message in the other protocol). > > > - Philip > > PS. I believe it was Greg Daley that suggested the SLIP-style > approach. > > > On 17-Aug-06, at 14:55 , Jonathan Rosenberg wrote: > > > During the last IETF meeting, I discussed the motivations for the > > FINGERPRINT attribute, which was added in rfc3489bis-04. The basic > > problem statement is that there are now several usages of STUN which > > multiplex STUN and some kind of application data (the > keepalive usage, > > which is utilized by sip-outbound, and the connectivity > check, used by > > ICE). STUN-04 discusses how an agent can demux STUN from application > > data on the same port. The magic cookie provides a simple way that > > often > > works, but I was worried about high-rate application protocols with > > sufficiently randomized data that you would still have collisions - > > i.e., cases where the magic cookie appears in the data stream in the > > exact same position. > > > > So, the FINGERPRINT as defined in -04 was a SHA-1 hash over the STUN > > message. If the STUN server gets a packet and the magic cookie is > > there, > > it can double check the FINGERPRINT to verify that this is a STUN > > packet. > > > > During the meeting, there was general agreement that > something like > > this > > would be useful. However, it was suggested that a 32 bit > CRC would be > > sufficiently effective and much simpler, which I agreed. There was > > also > > a suggestion at the microphone (I cannot recall who suggested it) > > for a > > different solution, which I'll call the "SLIP-style" solution. > > > > In this solution, when the client is about to send a data > packet on > > the > > same IP/port as the STUN is running, it looks to see if the data > > has the > > magic cookie in bits 32-63. If it does, it takes the UDP > datagram and > > encapsultes it as an attribute into a STUN message, "Send". This > > arrives > > at the STUN server, which decapsulates it, and treats that packet > > as if > > it had been sent as non-stun encapsulated. There is already such a > > Send > > message in TURN; it would basically be moved into STUN itself. > > > > So, the issue is: which mechanism to use - fingerprint or > slip-style? > > > > I've thought about this a bit, and have come up with the following > > pros/cons: > > > > SLIP-Style > > ---------- > > > > PRO: only add packet overhead when there is a collision, as > opposed to > > every stun message > > > > PRO: CPU cost of performing an enapsulation is cheaper than > > performing a > > CRC computation > > > > CON: may complicate QoS reservation mechanisms, since the > packet size > > for data packets is now less predicable and dependent on the > > contents of > > the data > > > > CON: might push the size of large UDP packets over the path > MTU; i.e., > > path MTU computations done by the application would be invalid > > since the > > effective MTU is reduced by the size of the STUN encapsulation > > overhead > > > > CON: will 'hide' select data packets in a stun enapsulation, totally > > messing up any on-path tools (things like RTP voice quality > > measurement > > devices) that are sniffing for application data packets. Note that > > this > > is not actually a problem for RTP since RTP will never conflict with > > STUN. However, it can happen for SIP if it is compressed > with sigcomp. > > > > CON: If you accidentially use something like the keepalive usage > > with a > > server which doesn't support stun (this is a big thread on the sip > > list), but correctly discards stun packets, with the slip-like > > encapsulation, actual data packets will be lost. > > > > CON: requires the client to monitor every data packet for > the cookie. > > Thus, the CPU cost is proportional to the data transmit > rate. With the > > fingerprint, the CPU cost of the CRC computation is > proportional to > > the > > stun data rate. > > > > Fingerprint > > ----------- > > > > PRO: Allows easier implementation for stun clients; STUN sender and > > application can share a socket without talking to each other > > > > PRO: predictable packet sizes and data rates (good for QoS > > reservations) > > > > PRO: doesn't impact path MTU computations > > > > PRO: CRC computation cost is uniform and predictable - > function of the > > stun rate and not the data rate > > > > PRO: doesn't interfere with or touch the application data stream > > > > > > > > > > My proposal, as you might guess, is to go with a fingerprint > > mechanism, > > and in particular a 32 bit CRC. > > > > Thanks, > > Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From brian@estacado.net Thu, 24 Aug 2006 13:56:45 -0500 (CDT) (envelope-from brian@estacado.net) From: Brian Hibbard Date: Thu, 24 Aug 2006 13:56:45 -0500 (CDT) (envelope-from brian@estacado.net) Subject: [Ietf-behave] draft-ietf-behave-turn-01 sec 9.2.1 question Message-ID: <44EDF665.2040209@estacado.net> MIME-Version: 1.0 Content-Type: text/plain There is an open issue in behave-turn-01 section 9.2.1: ... [[OPEN ISSUE: Can we eliminate the whole race condition, by requiring the client to close the binding and wait 5 seconds (with no server verification of this requirement) before issuing a new Set Active Destination request? Proposed text follows:]] ... As an implementor, this looks like it would be a welcome simplification to the mechanism of changing Active Destinations. The way I read it, this proposed approach would also allow the server's state machine to be eliminated, and the client's state machine would become trivial. Is there any opposition to making that change to the draft? Are there any other downsides besides the possibility that for a very small time, some packets would be encapsulated that wouldn't otherwise require it? Regards, Brian From Remi.Denis-Courmont@nokia.com Fri, 25 Aug 2006 00:56:24 -0500 (CDT) (envelope-from Remi.Denis-Courmont@nokia.com) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Date: Fri, 25 Aug 2006 00:56:24 -0500 (CDT) (envelope-from Remi.Denis-Courmont@nokia.com) Subject: Re: [Ietf-behave] draft-ietf-behave-turn-01 sec 9.2.1 question In-Reply-To: <44EDF665.2040209@estacado.net> Message-ID: <200608250855.01166.Remi.Denis-Courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain Le Thursday 24 August 2006 21:56, ext Brian Hibbard a crit: > There is an open issue in behave-turn-01 section 9.2.1: > > ... > > [[OPEN ISSUE: Can we eliminate the whole race condition, by > requiring the client to close the binding and wait 5 seconds (with > no server verification of this requirement) before issuing a new Set > Active Destination request? Proposed text follows:]] > > ... > > As an implementor, this looks like it would be a welcome simplification > to the mechanism of changing Active Destinations. The way I read it, > this proposed approach would also allow the server's state machine to be > eliminated, and the client's state machine would become trivial. I pretty much agree here. That would be very welcome. -- Rmi Denis-Courmont Assistant Research Engineer From bstucker@nortel.com Mon, 28 Aug 2006 11:56:03 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) From: "Brian Stucker" Date: Mon, 28 Aug 2006 11:56:03 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: <0CAECBB4-77E5-4B9F-8D0F-3F76D814172E@cisco.com> Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711021C120@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Random thought, Does anyone know if the speed of NATs creating new bindings being limited due to dropping occurs in aggregate, or is it limited only to requests coming in from a single source address? If it's a problem in aggregate (meaning it'll drop new bindings if the overall rate is too high) that might not bode well for large numbers of clients using STUN for connectivity checks behind some NATs. Regards, Brian > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Cullen Jennings > Sent: Tuesday, August 22, 2006 7:12 PM > To: Eric Cooper > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > My test program that classifies NATs runs a bunch of tests in > parallel. If you run the stun packets with no gap, it is > clear that many NATs just lose some of the state they should > be storing even though they forwarded the packet. When I gap > by 10 ms, most NATs seem to work and I don't think I have > anything that fails if I am at 20 ms but it is hard to test. > There are reports that my test program fails on some NATs > with 50ms gaps but I have not been able to replicate this. > > I have not investigated if you can burst a small number -- > such as with HTTP traffic -- and have it work well all the > time. All my testing has been with UDP not TCP. > > If people want to play with this, the software is the open > source stuff at vovida.org. > > > > On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: > > > Hi All, > > > > I've recently been looking into 'Internet Connectivity > Establishment' > > (ICE), which contains some statements indicating that some NAT/FW > > devices may be overwhelmed if they need to create a bunch of new > > mapping and/or filtering entries in a short amount of time. > > > > Specific to ICE, 'a bunch' is somewhere on the order of > 5-25 per ICE > > endpoint. ICE indicates that endpoints should rate limit > packets such > > that packets which would likely create new mapping and/ or > filtering > > entries are spaced 50 ms apart. > > > > I wonder if this spacing is really necessary. A quick > experiment with > > Ethereal and my browser seems to indicate that HTTP GET requests to > > different servers are not spaced 50 ms apart. > > > > My questions to the group are: > > > > 1) Does anyone have any empirical data regarding the speed at which > > new mapping/filtering entries can be created on various devices? > > > > 2) What is your opinion w.r.t. this 50 ms spacing? Is it necessary > > for existing devices, and will it continue to be necessary for > > BEHAVE-NAT-UDP compliant devices? > > > > Thanks! > > > > Eric Cooper. > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From pasi.sarolahti@nokia.com Tue, 29 Aug 2006 21:25:42 -0500 (CDT) (envelope-from Pasi.Sarolahti@nokia.com) From: Pasi Sarolahti Date: Tue, 29 Aug 2006 21:25:42 -0500 (CDT) (envelope-from Pasi.Sarolahti@nokia.com) Subject: [Ietf-behave] STUN retransmission timers Message-ID: <1156904733.3806.20.camel@hed040-213.research.nokia.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit RFC3489bis authors & everyone, I was browsing through draft-ietf-behave-rfc3489bis-04, and section 7.1 on STUN retransmission timers caught my eye, particularly the requirement that "Clients SHOULD retransmit the request starting with an interval of 100ms, doubling every retransmit until the interval reaches 1.6 seconds." -- to me this seems like a way too small value for a retransmission timeout. There are many paths where the round-trip time easily goes over 100ms, such as with many wireless network technologies (for example GPRS/GSM) or satellite links, etc. I think it would be useful to be consistent with values that TCP uses (recommended 1000ms minimum timeout [RFC 2988]), or what SIP uses (default 500ms [RFC 3261]). Thoughts? Regards, - Pasi Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgpqbzGLqp0tL.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpqbzGLqp0tL.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi42IChHTlUv TGludXgpCgppRDhEQlFCRTlQY2RvTmE3TkgxRzJjc1JBbyt2QUo5YW5hVDluMUVKS2FHRmsvYkZl ZFhzSU9DNC9RQ2c0aUpUCjkzc2ZGM1ExeE96SDluNFJXT1ZieVZjPQo9azZhRAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630136.multipart/signed-- From bstucker@nortel.com Wed, 30 Aug 2006 13:50:09 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) From: "Brian Stucker" Date: Wed, 30 Aug 2006 13:50:09 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <1156904733.3806.20.camel@hed040-213.research.nokia.com> Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371102F9B21@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I think there's a bit of a paradox at work here: If you have short retransmission timers, as you point out, the behavior in a wireless network is likely to be poor as many retransmissions will serve no purpose but to clog the access network up with traffic that provides no value. However, if you increase the retransmission timers, other uses of STUN (like ICE) will suffer from increased call setup delay (which is already challenging in many deployment environments). Regards, Brian > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pasi Sarolahti > Sent: Tuesday, August 29, 2006 9:26 PM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] STUN retransmission timers > > RFC3489bis authors & everyone, > > I was browsing through draft-ietf-behave-rfc3489bis-04, and > section 7.1 on STUN retransmission timers caught my eye, > particularly the requirement that "Clients SHOULD retransmit > the request starting with an interval of 100ms, doubling > every retransmit until the interval reaches > 1.6 seconds." -- to me this seems like a way too small value > for a retransmission timeout. There are many paths where the > round-trip time easily goes over 100ms, such as with many > wireless network technologies (for example GPRS/GSM) or > satellite links, etc. > > I think it would be useful to be consistent with values that > TCP uses (recommended 1000ms minimum timeout [RFC 2988]), or > what SIP uses (default 500ms [RFC 3261]). Thoughts? > > Regards, > - Pasi > > From pasi.sarolahti@nokia.com Wed, 30 Aug 2006 15:41:30 -0500 (CDT) (envelope-from Pasi.Sarolahti@nokia.com) From: Pasi Sarolahti Date: Wed, 30 Aug 2006 15:41:30 -0500 (CDT) (envelope-from Pasi.Sarolahti@nokia.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371102F9B21@zrc2hxm2.corp.nortel.com> Message-ID: <1156970481.11011.50.camel@hed040-213.research.nokia.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-08-30 at 13:49 -0500, ext Brian Stucker wrote: > If you have short retransmission timers, as you point out, the behavior > in a wireless network is likely to be poor as many retransmissions will > serve no purpose but to clog the access network up with traffic that > provides no value. > > However, if you increase the retransmission timers, other uses of STUN > (like ICE) will suffer from increased call setup delay (which is already > challenging in many deployment environments). (if there is a packet loss) Yep, I see the point. But taking more principled angle, some working groups make a big deal about not exceeding the initial sending rate and retransmission timeout values considered to be TCP-friendly. Is it ok for some IETF protocols to shortcut these principles and implement their own faster (re)transmission mechanisms over UDP? If yes, ok (but in that case it would be useful to lay out the reasoning somewhere why, and in which cases, it is ok). Ideally a retransmission timer should somehow take the current RTT into account to be even close to appropriate timeout values -- and then one would be one step closer to re-implementing TCP :-). - Pasi Attachment: signature.asc --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="pgpG3XeibwyTp.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpG3XeibwyTp.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi42IChHTlUv TGludXgpCgppRDhEQlFCRTlmZnhvTmE3TkgxRzJjc1JBbjdaQUtEZ2VxOHNNalZXRDhXbmI3Z29Y YTQyU01BK0lBQ2c0ZSswCjdXRWN3UnNMaC8zbHY4RWhWdnY1QkhZPQo9ZUN1eAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630136.multipart/signed-- From dwing@cisco.com Thu, 31 Aug 2006 20:01:09 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Thu, 31 Aug 2006 20:01:09 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <1156904733.3806.20.camel@hed040-213.research.nokia.com> Message-ID: <13bd01c6cd62$165b0230$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > RFC3489bis authors & everyone, As rfc3489bis co-author: Based on your thread and Brian's recent thread ("Time to add mapping/filtering entries"), I thought about rfc3489bis and ICE's interaction with it. ICE makes two significant uses of STUN that are interesting to BEHAVE. The first is the 'classic STUN' usage ("Binding Discovery" in -behave-rfc3489bis) -- learn your public IP address and UDP port. To avoid the problem Cullen described (where NATs seem to 'forget' to create bindings) those binding discovery STUN packets to the STUN server(s) need to be paced. The second interesting ICE usage is its connectivity checks ("Connectivity Check" in -behave-rfc3489bis). ICE's connectivity checks don't need to be paced to be gentle for the same reason, because ICE's connectivity checks don't create new NAT bindings (pedantic readers know that there are some exceptional configurations where ICE's connectivity checks do create a new NAT binding). Rather, ICE's connectivity checks only using existing bindings and change the NAT's filtering (if the NAT does do filtering). I suggest -behave-rfc3489bis should break out the retransmission rules into per-usage recommendations. Of the usages defined in -behave-rfc3489bis, 1. Binding Discovery 2. Connectivity Check 3. NAT Keepalives 4. Short-Term Password here are some thoughts on retransmit timers: 1. Binding Discovery: it doesn't harm interoperability if one STUN client uses 100ms and another STUN client uses 2000ms. It harms call setup time, of course, but presumably the clients were configured with those retransmit timers on purpose -- someone knew the network was fast (100ms) or the network was slow but had very little loss (2000ms). After the first STUN check, the retransmission timer could be adjusted. Note that for ICE, you do a STUN check for your RTP and for your RTCP port separately for each media stream. So if you're doing audio and video you will send 4 STUN packets from 4 different local ports, paced 50ms apart (to avoid the problem Cullen described). If you receive a STUN response for the first one in 20ms you know the RTT and processing time of the STUN server is 20ms. We use that knowledge to our advantage in determining the retransmission timer for the other 3 outstanding STUN transactions. Each of them should come back 20ms after we sent their request. If we don't see the response in 20ms, and we wanted to be aggressive, we could send another request in max(RTT,50ms). 2. Connectivity check: connectivity checks don't occur until you know the peer's IP address and codecs. That provides enough information about the expected bandwidth that ICE can stay below that bandwidth while performing its connectivity checks. 3. NAT Keepavlies: the initial RTT used by TCP SYNs seems reasonable (WinXP seems to wait 2 seconds, for whatever that's worth. RFC2988 seems to recommend a value less than 3 seconds). From there, the RTT of previous successful NAT keepalives can be useful to adjust the retransmit value of subsequent NAT keepalives. 4. Short-Term Password: This is usually the same server as (1), so apply the same rules as (1). -d From lars.eggert@netlab.nec.de Fri, 1 Sep 2006 10:40:37 -0500 (CDT) (envelope-from lars.eggert@netlab.nec.de) From: Lars Eggert Date: Fri, 1 Sep 2006 10:40:37 -0500 (CDT) (envelope-from lars.eggert@netlab.nec.de) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <13bd01c6cd62$165b0230$c3f0200a@amer.cisco.com> Message-ID: <699308B5-77C8-4788-AB8C-41831BAE3431@netlab.nec.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, as an individual contributor, let me echo Pasi's concerns with regards to sending the first retransmission after 100ms. (I do need to read up on the details of the latest STUN version though.) On Sep 1, 2006, at 3:00, Dan Wing wrote: ICE's connectivity checks don't need to be paced to be gentle for the same reason, because ICE's connectivity checks don't create new NAT bindings The potential issue is with causing additional traffic on long, narrow paths, not with causing load on the NAT (but that might be an issue, too). 1. Binding Discovery: it doesn't harm interoperability if one STUN client uses 100ms and another STUN client uses 2000ms. It harms call setup time, of course, but presumably the clients were configured with those retransmit timers on purpose -- someone knew the network was fast (100ms) or the network was slow but had very little loss (2000ms). Right, but the current draft simply says "clients SHOULD retransmit the request starting with an interval of 100ms", irrespective of the path. Maybe it should say something like "clients SHOULD retransmit the request starting with an interval off f(RTT), or Y seconds if the RTT is unknown." TCP uses 3 seconds for Y per RFC1122; see RFC2988 for f(). Lars -- Lars Eggert NEC Network Laboratories Attachment: smime.p7s --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="p7sRALp8WkLVI.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7sRALp8WkLVI.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwOTAx MTU0MDI1WjAjBgkqhkiG9w0BCQQxFgQUFt3ZwAU8Ls/XVonrx2S/YTPtzuYwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBABWybteHKCwxiTGnWnje JwxqzrDtsRlgecndmDGgsZvWr46lbuRNqqnsnTfJ/z3fV/9F7IW7SVp5aO9rP4A9F+DCKeyDpW59 tU7gC1oZLB3sjLH0/ldcXSc6MhgEkR2Vr1eXbV9hfCqTWa65gMS+AG+SIlNX4ZWRYBOWE/xpu64J xUj77T/xEC7QSAY5yvKG/bBByQMG7DW5LhmUooMjLOfVi9qHW8tenXmoX5DvzU7cJdrSyFgpXaqj tPaZIzlTu5PdvUb+53WLt6ndpKSglu1ls1rckFMRsWB2Xm5qU8QBZp5a2Vw2vNASJYC64FuHtJeJ zVEGC0MkxhipbIz97ggAAAAAAAA= --Boundary..27398.1163630136.multipart/signed-- From bstucker@nortel.com Fri, 1 Sep 2006 11:18:48 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) From: "Brian Stucker" Date: Fri, 1 Sep 2006 11:18:48 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <13bd01c6cd62$165b0230$c3f0200a@amer.cisco.com> Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371103C339F@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Dan, I see where you are headed with this, I think it's a good start. With #2, how would bandwidth affect ICE connectivity checks? Are you assuming that bandwidth will guarantee a certain latency budget as well? Regards, Brian > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Thursday, August 31, 2006 8:01 PM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Cc: Stucker, Brian (RICH1:B620); 'Pasi Sarolahti' > Subject: RE: [Ietf-behave] STUN retransmission timers > > > RFC3489bis authors & everyone, > > As rfc3489bis co-author: > > Based on your thread and Brian's recent thread ("Time to add > mapping/filtering entries"), I thought about rfc3489bis and > ICE's interaction with it. > > > ICE makes two significant uses of STUN that are interesting > to BEHAVE. The first is the 'classic STUN' usage ("Binding > Discovery" in > -behave-rfc3489bis) -- learn your public IP address and UDP > port. To avoid the problem Cullen described (where NATs seem > to 'forget' to create > bindings) those binding discovery STUN packets to the STUN > server(s) need to be paced. > > The second interesting ICE usage is its connectivity checks > ("Connectivity Check" in -behave-rfc3489bis). > > ICE's connectivity checks don't need to be paced to be gentle > for the same reason, because ICE's connectivity checks don't > create new NAT bindings (pedantic readers know that there are > some exceptional configurations where ICE's connectivity > checks do create a new NAT binding). Rather, ICE's > connectivity checks only using existing bindings and change > the NAT's filtering (if the NAT does do filtering). > > I suggest -behave-rfc3489bis should break out the > retransmission rules into per-usage recommendations. > > > Of the usages defined in -behave-rfc3489bis, > 1. Binding Discovery > 2. Connectivity Check > 3. NAT Keepalives > 4. Short-Term Password > here are some thoughts on retransmit timers: > > 1. Binding Discovery: it doesn't harm interoperability if one STUN > client uses 100ms and another STUN client uses 2000ms. It harms > call setup time, of course, but presumably the clients were > configured with those retransmit timers on purpose -- someone knew > the network was fast (100ms) or the network was slow but had very > little loss (2000ms). After the first STUN check, the > retransmission timer could be adjusted. Note that for ICE, you do > a STUN check for your RTP and for your RTCP port separately for > each media stream. So if you're doing audio and video you will > send 4 STUN packets from 4 different local ports, paced 50ms apart > (to avoid the problem Cullen described). If you receive a STUN > response for the first one in 20ms you know the RTT and processing > time of the STUN server is 20ms. We use that knowledge to our > advantage in determining the retransmission timer for the other 3 > outstanding STUN transactions. Each of them should come back 20ms > after we sent their request. If we don't see the response in 20ms, > and we wanted to be aggressive, we could send another request in > max(RTT,50ms). > > 2. Connectivity check: connectivity checks don't occur until you know > the peer's IP address and codecs. That provides enough information > about the expected bandwidth that ICE can stay below that bandwidth > while performing its connectivity checks. > > 3. NAT Keepavlies: the initial RTT used by TCP SYNs seems reasonable > (WinXP seems to wait 2 seconds, for whatever that's worth. RFC2988 > seems to recommend a value less than 3 seconds). From there, the > RTT of previous successful NAT keepalives can be useful to adjust > the retransmit value of subsequent NAT keepalives. > > 4. Short-Term Password: This is usually the same server as (1), so > apply the same rules as (1). > > -d > From dwing@cisco.com Fri, 1 Sep 2006 12:13:42 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Fri, 1 Sep 2006 12:13:42 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371103C339F@zrc2hxm2.corp.nortel.com> Message-ID: <039101c6cde9$f43e8590$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Brian, > I see where you are headed with this, I think it's a good start. > > With #2, how would bandwidth affect ICE connectivity checks? Are you > assuming that bandwidth will guarantee a certain latency > budget as well? No, I'm not assuming any relationship between bandwidth and latency. There is the extreme of running VoIP over satellite, and the extreme that we could negotiate G.711 but be on opposite sides of the planet. Rather, I'm saying that if the bandwidth of the negotiated codec is 100kbps, it would be prudent for ICE's connectivity checks to not exceed 100kbps. Networks with strict QoS schedulers may drop packets that exceed the expected bandwidth (PacketCable, most notably; I expect IMS would have similar behavior). -d > > -----Original Message----- > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Thursday, August 31, 2006 8:01 PM > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Cc: Stucker, Brian (RICH1:B620); 'Pasi Sarolahti' > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > RFC3489bis authors & everyone, > > > > As rfc3489bis co-author: > > > > Based on your thread and Brian's recent thread ("Time to add > > mapping/filtering entries"), I thought about rfc3489bis and > > ICE's interaction with it. > > > > > > ICE makes two significant uses of STUN that are interesting > > to BEHAVE. The first is the 'classic STUN' usage ("Binding > > Discovery" in > > -behave-rfc3489bis) -- learn your public IP address and UDP > > port. To avoid the problem Cullen described (where NATs seem > > to 'forget' to create > > bindings) those binding discovery STUN packets to the STUN > > server(s) need to be paced. > > > > The second interesting ICE usage is its connectivity checks > > ("Connectivity Check" in -behave-rfc3489bis). > > > > ICE's connectivity checks don't need to be paced to be gentle > > for the same reason, because ICE's connectivity checks don't > > create new NAT bindings (pedantic readers know that there are > > some exceptional configurations where ICE's connectivity > > checks do create a new NAT binding). Rather, ICE's > > connectivity checks only using existing bindings and change > > the NAT's filtering (if the NAT does do filtering). > > > > I suggest -behave-rfc3489bis should break out the > > retransmission rules into per-usage recommendations. > > > > > > Of the usages defined in -behave-rfc3489bis, > > 1. Binding Discovery > > 2. Connectivity Check > > 3. NAT Keepalives > > 4. Short-Term Password > > here are some thoughts on retransmit timers: > > > > 1. Binding Discovery: it doesn't harm interoperability if one STUN > > client uses 100ms and another STUN client uses 2000ms. It harms > > call setup time, of course, but presumably the clients were > > configured with those retransmit timers on purpose -- > someone knew > > the network was fast (100ms) or the network was slow but had very > > little loss (2000ms). After the first STUN check, the > > retransmission timer could be adjusted. Note that for > ICE, you do > > a STUN check for your RTP and for your RTCP port separately for > > each media stream. So if you're doing audio and video you will > > send 4 STUN packets from 4 different local ports, paced > 50ms apart > > (to avoid the problem Cullen described). If you receive a STUN > > response for the first one in 20ms you know the RTT and > processing > > time of the STUN server is 20ms. We use that knowledge to our > > advantage in determining the retransmission timer for the other 3 > > outstanding STUN transactions. Each of them should come > back 20ms > > after we sent their request. If we don't see the > response in 20ms, > > and we wanted to be aggressive, we could send another request in > > max(RTT,50ms). > > > > 2. Connectivity check: connectivity checks don't occur > until you know > > the peer's IP address and codecs. That provides enough > information > > about the expected bandwidth that ICE can stay below > that bandwidth > > while performing its connectivity checks. > > > > 3. NAT Keepavlies: the initial RTT used by TCP SYNs seems > reasonable > > (WinXP seems to wait 2 seconds, for whatever that's > worth. RFC2988 > > seems to recommend a value less than 3 seconds). From there, the > > RTT of previous successful NAT keepalives can be useful to adjust > > the retransmit value of subsequent NAT keepalives. > > > > 4. Short-Term Password: This is usually the same server as (1), so > > apply the same rules as (1). > > > > -d > > From bstucker@nortel.com Fri, 1 Sep 2006 12:24:50 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) From: "Brian Stucker" Date: Fri, 1 Sep 2006 12:24:50 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <039101c6cde9$f43e8590$c4f0200a@amer.cisco.com> Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371103C34B2@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Ok, makes sense. In terms of wireless, there's a bit of trick that may have to be played as QoS may not be stable yet at the time that an answer to an offer comes back while all of the elements on the signaling path figure out what they want to do with the SDP being exchanged in terms of adjusting the final QoS granted. Also, with mobility networks, there is the possibility that the path that the early packets take is different than ones that the final bearer path will take. So, just because the SDP is good for 100kbps, it does not mean that the packets going between endpoints will get this type of treatment during early stages of the session setup process (right when connectivity checks would be getting performed) or there may be a race condition between the route optimization used and the connectivity checks doing their thing. Regards, Brian > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Friday, September 01, 2006 12:14 PM > To: Stucker, Brian (RICH1:B620); ietf-behave@xxxxxxxxxxxxxxxxxxx > Cc: 'Pasi Sarolahti' > Subject: RE: [Ietf-behave] STUN retransmission timers > > Brian, > > > I see where you are headed with this, I think it's a good start. > > > > With #2, how would bandwidth affect ICE connectivity > checks? Are you > > assuming that bandwidth will guarantee a certain latency budget as > > well? > > No, I'm not assuming any relationship between bandwidth and > latency. There is the extreme of running VoIP over > satellite, and the extreme that we could negotiate G.711 but > be on opposite sides of the planet. > > Rather, I'm saying that if the bandwidth of the negotiated > codec is 100kbps, it would be prudent for ICE's connectivity > checks to not exceed 100kbps. > Networks with strict QoS schedulers may drop packets that > exceed the expected bandwidth (PacketCable, most notably; I > expect IMS would have similar behavior). > > -d > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > Sent: Thursday, August 31, 2006 8:01 PM > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Cc: Stucker, Brian (RICH1:B620); 'Pasi Sarolahti' > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > > RFC3489bis authors & everyone, > > > > > > As rfc3489bis co-author: > > > > > > Based on your thread and Brian's recent thread ("Time to add > > > mapping/filtering entries"), I thought about rfc3489bis and ICE's > > > interaction with it. > > > > > > > > > ICE makes two significant uses of STUN that are interesting to > > > BEHAVE. The first is the 'classic STUN' usage ("Binding > Discovery" > > > in > > > -behave-rfc3489bis) -- learn your public IP address and > UDP port. > > > To avoid the problem Cullen described (where NATs seem to > 'forget' > > > to create > > > bindings) those binding discovery STUN packets to the STUN > > > server(s) need to be paced. > > > > > > The second interesting ICE usage is its connectivity checks > > > ("Connectivity Check" in -behave-rfc3489bis). > > > > > > ICE's connectivity checks don't need to be paced to be gentle for > > > the same reason, because ICE's connectivity checks don't > create new > > > NAT bindings (pedantic readers know that there are some > exceptional > > > configurations where ICE's connectivity checks do create > a new NAT > > > binding). Rather, ICE's connectivity checks only using existing > > > bindings and change the NAT's filtering (if the NAT does do > > > filtering). > > > > > > I suggest -behave-rfc3489bis should break out the retransmission > > > rules into per-usage recommendations. > > > > > > > > > Of the usages defined in -behave-rfc3489bis, > > > 1. Binding Discovery > > > 2. Connectivity Check > > > 3. NAT Keepalives > > > 4. Short-Term Password > > > here are some thoughts on retransmit timers: > > > > > > 1. Binding Discovery: it doesn't harm interoperability > if one STUN > > > client uses 100ms and another STUN client uses 2000ms. > It harms > > > call setup time, of course, but presumably the clients were > > > configured with those retransmit timers on purpose -- > > someone knew > > > the network was fast (100ms) or the network was slow > but had very > > > little loss (2000ms). After the first STUN check, the > > > retransmission timer could be adjusted. Note that for > > ICE, you do > > > a STUN check for your RTP and for your RTCP port separately for > > > each media stream. So if you're doing audio and video you will > > > send 4 STUN packets from 4 different local ports, paced > > 50ms apart > > > (to avoid the problem Cullen described). If you receive a STUN > > > response for the first one in 20ms you know the RTT and > > processing > > > time of the STUN server is 20ms. We use that knowledge to our > > > advantage in determining the retransmission timer for > the other 3 > > > outstanding STUN transactions. Each of them should come > > back 20ms > > > after we sent their request. If we don't see the > > response in 20ms, > > > and we wanted to be aggressive, we could send another > request in > > > max(RTT,50ms). > > > > > > 2. Connectivity check: connectivity checks don't occur > > until you know > > > the peer's IP address and codecs. That provides enough > > information > > > about the expected bandwidth that ICE can stay below > > that bandwidth > > > while performing its connectivity checks. > > > > > > 3. NAT Keepavlies: the initial RTT used by TCP SYNs seems > > reasonable > > > (WinXP seems to wait 2 seconds, for whatever that's > > worth. RFC2988 > > > seems to recommend a value less than 3 seconds). From > there, the > > > RTT of previous successful NAT keepalives can be > useful to adjust > > > the retransmit value of subsequent NAT keepalives. > > > > > > 4. Short-Term Password: This is usually the same server > as (1), so > > > apply the same rules as (1). > > > > > > -d > > > > From dwing@cisco.com Fri, 1 Sep 2006 12:57:21 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Fri, 1 Sep 2006 12:57:21 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371103C34B2@zrc2hxm2.corp.nortel.com> Message-ID: <043301c6cdf0$080e0720$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Ok, makes sense. > > In terms of wireless, there's a bit of trick that may have to be > played as QoS may not be stable yet at the time that an answer to an > offer comes back while all of the elements on the signaling path > figure out what they want to do with the SDP being exchanged in > terms of adjusting the final QoS granted. > > Also, with mobility networks, there is the possibility that the path > that the early packets take is different than ones that the final > bearer path will take. So, just because the SDP is good for > 100kbps, it does not mean that the packets going between endpoints > will get this type of treatment during early stages of the session > setup process (right when connectivity checks would be getting > performed) or there may be a race condition between the route > optimization used and the connectivity checks doing their thing. ICE's connectivity checks don't need to be QoS'd like the forthcoming RTP packets. Packet loss will interfere with ICE, though. Ignoring ICE's connectivity checks, wouldn't the behavior you describe cause problems with real media packets, too, if they are sent before these additional steps are performed? -d > Regards, > Brian > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Friday, September 01, 2006 12:14 PM > > To: Stucker, Brian (RICH1:B620); ietf-behave@xxxxxxxxxxxxxxxxxxx > > Cc: 'Pasi Sarolahti' > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > Brian, > > > > > I see where you are headed with this, I think it's a good start. > > > > > > With #2, how would bandwidth affect ICE connectivity > > checks? Are you > > > assuming that bandwidth will guarantee a certain latency > budget as > > > well? > > > > No, I'm not assuming any relationship between bandwidth and > > latency. There is the extreme of running VoIP over > > satellite, and the extreme that we could negotiate G.711 but > > be on opposite sides of the planet. > > > > Rather, I'm saying that if the bandwidth of the negotiated > > codec is 100kbps, it would be prudent for ICE's connectivity > > checks to not exceed 100kbps. > > Networks with strict QoS schedulers may drop packets that > > exceed the expected bandwidth (PacketCable, most notably; I > > expect IMS would have similar behavior). > > > > -d > > > > > > -----Original Message----- > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > Sent: Thursday, August 31, 2006 8:01 PM > > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Cc: Stucker, Brian (RICH1:B620); 'Pasi Sarolahti' > > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > > > > RFC3489bis authors & everyone, > > > > > > > > As rfc3489bis co-author: > > > > > > > > Based on your thread and Brian's recent thread ("Time to add > > > > mapping/filtering entries"), I thought about rfc3489bis > and ICE's > > > > interaction with it. > > > > > > > > > > > > ICE makes two significant uses of STUN that are interesting to > > > > BEHAVE. The first is the 'classic STUN' usage ("Binding > > Discovery" > > > > in > > > > -behave-rfc3489bis) -- learn your public IP address and > > UDP port. > > > > To avoid the problem Cullen described (where NATs seem to > > 'forget' > > > > to create > > > > bindings) those binding discovery STUN packets to the STUN > > > > server(s) need to be paced. > > > > > > > > The second interesting ICE usage is its connectivity checks > > > > ("Connectivity Check" in -behave-rfc3489bis). > > > > > > > > ICE's connectivity checks don't need to be paced to be > gentle for > > > > the same reason, because ICE's connectivity checks don't > > create new > > > > NAT bindings (pedantic readers know that there are some > > exceptional > > > > configurations where ICE's connectivity checks do create > > a new NAT > > > > binding). Rather, ICE's connectivity checks only using > existing > > > > bindings and change the NAT's filtering (if the NAT does do > > > > filtering). > > > > > > > > I suggest -behave-rfc3489bis should break out the > retransmission > > > > rules into per-usage recommendations. > > > > > > > > > > > > Of the usages defined in -behave-rfc3489bis, > > > > 1. Binding Discovery > > > > 2. Connectivity Check > > > > 3. NAT Keepalives > > > > 4. Short-Term Password > > > > here are some thoughts on retransmit timers: > > > > > > > > 1. Binding Discovery: it doesn't harm interoperability > > if one STUN > > > > client uses 100ms and another STUN client uses 2000ms. > > It harms > > > > call setup time, of course, but presumably the clients were > > > > configured with those retransmit timers on purpose -- > > > someone knew > > > > the network was fast (100ms) or the network was slow > > but had very > > > > little loss (2000ms). After the first STUN check, the > > > > retransmission timer could be adjusted. Note that for > > > ICE, you do > > > > a STUN check for your RTP and for your RTCP port > separately for > > > > each media stream. So if you're doing audio and > video you will > > > > send 4 STUN packets from 4 different local ports, paced > > > 50ms apart > > > > (to avoid the problem Cullen described). If you > receive a STUN > > > > response for the first one in 20ms you know the RTT and > > > processing > > > > time of the STUN server is 20ms. We use that > knowledge to our > > > > advantage in determining the retransmission timer for > > the other 3 > > > > outstanding STUN transactions. Each of them should come > > > back 20ms > > > > after we sent their request. If we don't see the > > > response in 20ms, > > > > and we wanted to be aggressive, we could send another > > request in > > > > max(RTT,50ms). > > > > > > > > 2. Connectivity check: connectivity checks don't occur > > > until you know > > > > the peer's IP address and codecs. That provides enough > > > information > > > > about the expected bandwidth that ICE can stay below > > > that bandwidth > > > > while performing its connectivity checks. > > > > > > > > 3. NAT Keepavlies: the initial RTT used by TCP SYNs seems > > > reasonable > > > > (WinXP seems to wait 2 seconds, for whatever that's > > > worth. RFC2988 > > > > seems to recommend a value less than 3 seconds). From > > there, the > > > > RTT of previous successful NAT keepalives can be > > useful to adjust > > > > the retransmit value of subsequent NAT keepalives. > > > > > > > > 4. Short-Term Password: This is usually the same server > > as (1), so > > > > apply the same rules as (1). > > > > > > > > -d > > > > > > From bstucker@nortel.com Fri, 1 Sep 2006 13:10:26 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) From: "Brian Stucker" Date: Fri, 1 Sep 2006 13:10:26 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <043301c6cdf0$080e0720$c4f0200a@amer.cisco.com> Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371103C353B@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Dan, I'm not of the opinion that ICE connectivity checks need to be QoS'd like RTP packets. However, routing of packets during the early stages of call setup in a wireless environment are likely to encounter vastly different latency budgets as the RTP packets that follow when the call setup has been completed. So, you're not necessarily losing packets. However, if the endpoint is retransmitting too quickly it may mis-identify an endpoint as not being usable because it's confused latency with unreachability. Alternately, you'd could be spamming the network with connectivity checks due to impatience. To answer your second question, yes. It could. However, the problem is not likely to be as severe because in most wireless settings early media is middle-to-end and not end-to-end. The middle typically has more control and awareness of what's going on with the bearer and fewer hops to complete any round-trips necessary. Regards, Brian > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Friday, September 01, 2006 12:57 PM > To: Stucker, Brian (RICH1:B620); ietf-behave@xxxxxxxxxxxxxxxxxxx > Cc: 'Pasi Sarolahti' > Subject: RE: [Ietf-behave] STUN retransmission timers > > > Ok, makes sense. > > > > In terms of wireless, there's a bit of trick that may have to be > > played as QoS may not be stable yet at the time that an > answer to an > > offer comes back while all of the elements on the signaling path > > figure out what they want to do with the SDP being > exchanged in terms > > of adjusting the final QoS granted. > > > > Also, with mobility networks, there is the possibility that > the path > > that the early packets take is different than ones that the final > > bearer path will take. So, just because the SDP is good > for 100kbps, > > it does not mean that the packets going between endpoints will get > > this type of treatment during early stages of the session setup > > process (right when connectivity checks would be getting > > performed) or there may be a race condition between the route > > optimization used and the connectivity checks doing their thing. > > ICE's connectivity checks don't need to be QoS'd like the > forthcoming RTP packets. Packet loss will interfere with ICE, though. > > Ignoring ICE's connectivity checks, wouldn't the behavior you > describe cause problems with real media packets, too, if they > are sent before these additional steps are performed? > > -d > > > > Regards, > > Brian > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > Sent: Friday, September 01, 2006 12:14 PM > > > To: Stucker, Brian (RICH1:B620); ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Cc: 'Pasi Sarolahti' > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > Brian, > > > > > > > I see where you are headed with this, I think it's a good start. > > > > > > > > With #2, how would bandwidth affect ICE connectivity > > > checks? Are you > > > > assuming that bandwidth will guarantee a certain latency > > budget as > > > > well? > > > > > > No, I'm not assuming any relationship between bandwidth > and latency. > > > There is the extreme of running VoIP over satellite, and > the extreme > > > that we could negotiate G.711 but be on opposite sides of the > > > planet. > > > > > > Rather, I'm saying that if the bandwidth of the > negotiated codec is > > > 100kbps, it would be prudent for ICE's connectivity checks to not > > > exceed 100kbps. > > > Networks with strict QoS schedulers may drop packets that > exceed the > > > expected bandwidth (PacketCable, most notably; I expect IMS would > > > have similar behavior). > > > > > > -d > > > > > > > > -----Original Message----- > > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > > Sent: Thursday, August 31, 2006 8:01 PM > > > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > Cc: Stucker, Brian (RICH1:B620); 'Pasi Sarolahti' > > > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > > > > > > RFC3489bis authors & everyone, > > > > > > > > > > As rfc3489bis co-author: > > > > > > > > > > Based on your thread and Brian's recent thread ("Time to add > > > > > mapping/filtering entries"), I thought about rfc3489bis > > and ICE's > > > > > interaction with it. > > > > > > > > > > > > > > > ICE makes two significant uses of STUN that are > interesting to > > > > > BEHAVE. The first is the 'classic STUN' usage ("Binding > > > Discovery" > > > > > in > > > > > -behave-rfc3489bis) -- learn your public IP address and > > > UDP port. > > > > > To avoid the problem Cullen described (where NATs seem to > > > 'forget' > > > > > to create > > > > > bindings) those binding discovery STUN packets to the STUN > > > > > server(s) need to be paced. > > > > > > > > > > The second interesting ICE usage is its connectivity checks > > > > > ("Connectivity Check" in -behave-rfc3489bis). > > > > > > > > > > ICE's connectivity checks don't need to be paced to be > > gentle for > > > > > the same reason, because ICE's connectivity checks don't > > > create new > > > > > NAT bindings (pedantic readers know that there are some > > > exceptional > > > > > configurations where ICE's connectivity checks do create > > > a new NAT > > > > > binding). Rather, ICE's connectivity checks only using > > existing > > > > > bindings and change the NAT's filtering (if the NAT does do > > > > > filtering). > > > > > > > > > > I suggest -behave-rfc3489bis should break out the > > retransmission > > > > > rules into per-usage recommendations. > > > > > > > > > > > > > > > Of the usages defined in -behave-rfc3489bis, > > > > > 1. Binding Discovery > > > > > 2. Connectivity Check > > > > > 3. NAT Keepalives > > > > > 4. Short-Term Password > > > > > here are some thoughts on retransmit timers: > > > > > > > > > > 1. Binding Discovery: it doesn't harm interoperability > > > if one STUN > > > > > client uses 100ms and another STUN client uses 2000ms. > > > It harms > > > > > call setup time, of course, but presumably the clients were > > > > > configured with those retransmit timers on purpose -- > > > > someone knew > > > > > the network was fast (100ms) or the network was slow > > > but had very > > > > > little loss (2000ms). After the first STUN check, the > > > > > retransmission timer could be adjusted. Note that for > > > > ICE, you do > > > > > a STUN check for your RTP and for your RTCP port > > separately for > > > > > each media stream. So if you're doing audio and > > video you will > > > > > send 4 STUN packets from 4 different local ports, paced > > > > 50ms apart > > > > > (to avoid the problem Cullen described). If you > > receive a STUN > > > > > response for the first one in 20ms you know the RTT and > > > > processing > > > > > time of the STUN server is 20ms. We use that > > knowledge to our > > > > > advantage in determining the retransmission timer for > > > the other 3 > > > > > outstanding STUN transactions. Each of them should come > > > > back 20ms > > > > > after we sent their request. If we don't see the > > > > response in 20ms, > > > > > and we wanted to be aggressive, we could send another > > > request in > > > > > max(RTT,50ms). > > > > > > > > > > 2. Connectivity check: connectivity checks don't occur > > > > until you know > > > > > the peer's IP address and codecs. That provides enough > > > > information > > > > > about the expected bandwidth that ICE can stay below > > > > that bandwidth > > > > > while performing its connectivity checks. > > > > > > > > > > 3. NAT Keepavlies: the initial RTT used by TCP SYNs seems > > > > reasonable > > > > > (WinXP seems to wait 2 seconds, for whatever that's > > > > worth. RFC2988 > > > > > seems to recommend a value less than 3 seconds). From > > > there, the > > > > > RTT of previous successful NAT keepalives can be > > > useful to adjust > > > > > the retransmit value of subsequent NAT keepalives. > > > > > > > > > > 4. Short-Term Password: This is usually the same server > > > as (1), so > > > > > apply the same rules as (1). > > > > > > > > > > -d > > > > > > > > > From dwing@cisco.com Fri, 1 Sep 2006 14:43:29 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Fri, 1 Sep 2006 14:43:29 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371103C353B@zrc2hxm2.corp.nortel.com> Message-ID: <066901c6cdfe$e01e30a0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Dan, > > I'm not of the opinion that ICE connectivity checks need to be QoS'd > like RTP packets. However, routing of packets during the > early stages of > call setup in a wireless environment are likely to encounter vastly > different latency budgets as the RTP packets that follow when the call > setup has been completed. Things like policy-based routing and DSCP-aware routing can also cause differences; in fact, they can cause the ICE packets to succeed where the RTP packets will fail. I don't think ICE-10 provides guidance on DSCP marking of its packets, but it probably should: they should receive the same DSCP marking as the RTP packets. > So, you're not necessarily losing packets. > However, if the endpoint is retransmitting too quickly it may > mis-identify an endpoint as not being usable because it's confused > latency with unreachability. The timer value for unreachable isn't directly tied to how quickly you retransmit. You might declare an endpoint unreachable at a fixed 1000ms, but inside of that second you could have transmitted and retransmitted several connectivity checks. > Alternately, you'd could be spamming the > network with connectivity checks due to impatience. If you're going to be sending 100kbps as soon as the call is answered anyway, 100kbps of connectivity checks isn't awful. If you're going to be sending 10kbps as soon as the call is answered, 100kbps of connectivity checks could very well be awful. > To answer your second question, yes. It could. However, the problem is > not likely to be as severe because in most wireless settings > early media is middle-to-end and not end-to-end. The middle > typically has more control and awareness of what's going on > with the bearer and fewer hops to complete any round-trips > necessary. As in draft-stucker-sipping-early-media-coping-01, right? -d > Regards, > Brian > > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Friday, September 01, 2006 12:57 PM > > To: Stucker, Brian (RICH1:B620); ietf-behave@xxxxxxxxxxxxxxxxxxx > > Cc: 'Pasi Sarolahti' > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > Ok, makes sense. > > > > > > In terms of wireless, there's a bit of trick that may have to be > > > played as QoS may not be stable yet at the time that an > > answer to an > > > offer comes back while all of the elements on the signaling path > > > figure out what they want to do with the SDP being > > exchanged in terms > > > of adjusting the final QoS granted. > > > > > > Also, with mobility networks, there is the possibility that > > the path > > > that the early packets take is different than ones that the final > > > bearer path will take. So, just because the SDP is good > > for 100kbps, > > > it does not mean that the packets going between endpoints > will get > > > this type of treatment during early stages of the session setup > > > process (right when connectivity checks would be getting > > > performed) or there may be a race condition between the route > > > optimization used and the connectivity checks doing their thing. > > > > ICE's connectivity checks don't need to be QoS'd like the > > forthcoming RTP packets. Packet loss will interfere with > ICE, though. > > > > Ignoring ICE's connectivity checks, wouldn't the behavior you > > describe cause problems with real media packets, too, if they > > are sent before these additional steps are performed? > > > > -d > > > > > > > Regards, > > > Brian > > > > > > > -----Original Message----- > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > Sent: Friday, September 01, 2006 12:14 PM > > > > To: Stucker, Brian (RICH1:B620); ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Cc: 'Pasi Sarolahti' > > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > > > Brian, > > > > > > > > > I see where you are headed with this, I think it's a > good start. > > > > > > > > > > With #2, how would bandwidth affect ICE connectivity > > > > checks? Are you > > > > > assuming that bandwidth will guarantee a certain latency > > > budget as > > > > > well? > > > > > > > > No, I'm not assuming any relationship between bandwidth > > and latency. > > > > There is the extreme of running VoIP over satellite, and > > the extreme > > > > that we could negotiate G.711 but be on opposite sides of the > > > > planet. > > > > > > > > Rather, I'm saying that if the bandwidth of the > > negotiated codec is > > > > 100kbps, it would be prudent for ICE's connectivity > checks to not > > > > exceed 100kbps. > > > > Networks with strict QoS schedulers may drop packets that > > exceed the > > > > expected bandwidth (PacketCable, most notably; I expect > IMS would > > > > have similar behavior). > > > > > > > > -d > > > > > > > > > > -----Original Message----- > > > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > > > Sent: Thursday, August 31, 2006 8:01 PM > > > > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > Cc: Stucker, Brian (RICH1:B620); 'Pasi Sarolahti' > > > > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > > > > > > > > RFC3489bis authors & everyone, > > > > > > > > > > > > As rfc3489bis co-author: > > > > > > > > > > > > Based on your thread and Brian's recent thread > ("Time to add > > > > > > mapping/filtering entries"), I thought about rfc3489bis > > > and ICE's > > > > > > interaction with it. > > > > > > > > > > > > > > > > > > ICE makes two significant uses of STUN that are > > interesting to > > > > > > BEHAVE. The first is the 'classic STUN' usage ("Binding > > > > Discovery" > > > > > > in > > > > > > -behave-rfc3489bis) -- learn your public IP address and > > > > UDP port. > > > > > > To avoid the problem Cullen described (where NATs seem to > > > > 'forget' > > > > > > to create > > > > > > bindings) those binding discovery STUN packets to the STUN > > > > > > server(s) need to be paced. > > > > > > > > > > > > The second interesting ICE usage is its connectivity checks > > > > > > ("Connectivity Check" in -behave-rfc3489bis). > > > > > > > > > > > > ICE's connectivity checks don't need to be paced to be > > > gentle for > > > > > > the same reason, because ICE's connectivity checks don't > > > > create new > > > > > > NAT bindings (pedantic readers know that there are some > > > > exceptional > > > > > > configurations where ICE's connectivity checks do create > > > > a new NAT > > > > > > binding). Rather, ICE's connectivity checks only using > > > existing > > > > > > bindings and change the NAT's filtering (if the NAT does do > > > > > > filtering). > > > > > > > > > > > > I suggest -behave-rfc3489bis should break out the > > > retransmission > > > > > > rules into per-usage recommendations. > > > > > > > > > > > > > > > > > > Of the usages defined in -behave-rfc3489bis, > > > > > > 1. Binding Discovery > > > > > > 2. Connectivity Check > > > > > > 3. NAT Keepalives > > > > > > 4. Short-Term Password > > > > > > here are some thoughts on retransmit timers: > > > > > > > > > > > > 1. Binding Discovery: it doesn't harm interoperability > > > > if one STUN > > > > > > client uses 100ms and another STUN client uses 2000ms. > > > > It harms > > > > > > call setup time, of course, but presumably the > clients were > > > > > > configured with those retransmit timers on purpose -- > > > > > someone knew > > > > > > the network was fast (100ms) or the network was slow > > > > but had very > > > > > > little loss (2000ms). After the first STUN check, the > > > > > > retransmission timer could be adjusted. Note that for > > > > > ICE, you do > > > > > > a STUN check for your RTP and for your RTCP port > > > separately for > > > > > > each media stream. So if you're doing audio and > > > video you will > > > > > > send 4 STUN packets from 4 different local ports, paced > > > > > 50ms apart > > > > > > (to avoid the problem Cullen described). If you > > > receive a STUN > > > > > > response for the first one in 20ms you know the RTT and > > > > > processing > > > > > > time of the STUN server is 20ms. We use that > > > knowledge to our > > > > > > advantage in determining the retransmission timer for > > > > the other 3 > > > > > > outstanding STUN transactions. Each of them should come > > > > > back 20ms > > > > > > after we sent their request. If we don't see the > > > > > response in 20ms, > > > > > > and we wanted to be aggressive, we could send another > > > > request in > > > > > > max(RTT,50ms). > > > > > > > > > > > > 2. Connectivity check: connectivity checks don't occur > > > > > until you know > > > > > > the peer's IP address and codecs. That provides enough > > > > > information > > > > > > about the expected bandwidth that ICE can stay below > > > > > that bandwidth > > > > > > while performing its connectivity checks. > > > > > > > > > > > > 3. NAT Keepavlies: the initial RTT used by TCP SYNs seems > > > > > reasonable > > > > > > (WinXP seems to wait 2 seconds, for whatever that's > > > > > worth. RFC2988 > > > > > > seems to recommend a value less than 3 seconds). From > > > > there, the > > > > > > RTT of previous successful NAT keepalives can be > > > > useful to adjust > > > > > > the retransmit value of subsequent NAT keepalives. > > > > > > > > > > > > 4. Short-Term Password: This is usually the same server > > > > as (1), so > > > > > > apply the same rules as (1). > > > > > > > > > > > > -d > > > > > > > > > > > > From bstucker@nortel.com Fri, 1 Sep 2006 16:13:30 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) From: "Brian Stucker" Date: Fri, 1 Sep 2006 16:13:30 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <066901c6cdfe$e01e30a0$c4f0200a@amer.cisco.com> Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371103C37F0@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Friday, September 01, 2006 2:43 PM > To: Stucker, Brian (RICH1:B620); ietf-behave@xxxxxxxxxxxxxxxxxxx > Cc: 'Pasi Sarolahti' > Subject: RE: [Ietf-behave] STUN retransmission timers > > > Dan, > > > > I'm not of the opinion that ICE connectivity checks need to > be QoS'd > > like RTP packets. However, routing of packets during the > early stages > > of call setup in a wireless environment are likely to > encounter vastly > > different latency budgets as the RTP packets that follow > when the call > > setup has been completed. > > Things like policy-based routing and DSCP-aware routing can > also cause differences; in fact, they can cause the ICE > packets to succeed where the RTP packets will fail. I don't > think ICE-10 provides guidance on DSCP marking of its > packets, but it probably should: they should receive the > same DSCP marking as the RTP packets. > > > So, you're not necessarily losing packets. > > However, if the endpoint is retransmitting too quickly it may > > mis-identify an endpoint as not being usable because it's confused > > latency with unreachability. > > The timer value for unreachable isn't directly tied to how > quickly you retransmit. You might declare an endpoint > unreachable at a fixed 1000ms, but inside of that second you > could have transmitted and retransmitted several connectivity checks. Hmm.. I thought it was tied to number of retransmissions or time (whichever is satisfied first). I'll have to look for that in -10. > > > Alternately, you'd could be spamming the network with connectivity > > checks due to impatience. > > If you're going to be sending 100kbps as soon as the call is > answered anyway, 100kbps of connectivity checks isn't awful. > If you're going to be sending 10kbps as soon as the call is > answered, 100kbps of connectivity checks could very well be awful. Assuming you're going to get 100kbps. It's a concern that shouldn't be dismissed out of hand. > > > To answer your second question, yes. It could. However, the > problem is > > not likely to be as severe because in most wireless settings early > > media is middle-to-end and not end-to-end. The middle typically has > > more control and awareness of what's going on with the bearer and > > fewer hops to complete any round-trips necessary. > > As in draft-stucker-sipping-early-media-coping-01, right? Yes, I need to put that into the -02 revision. > > -d > > > > Regards, > > Brian > > > > > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > Sent: Friday, September 01, 2006 12:57 PM > > > To: Stucker, Brian (RICH1:B620); ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Cc: 'Pasi Sarolahti' > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > > Ok, makes sense. > > > > > > > > In terms of wireless, there's a bit of trick that may > have to be > > > > played as QoS may not be stable yet at the time that an > > > answer to an > > > > offer comes back while all of the elements on the > signaling path > > > > figure out what they want to do with the SDP being > > > exchanged in terms > > > > of adjusting the final QoS granted. > > > > > > > > Also, with mobility networks, there is the possibility that > > > the path > > > > that the early packets take is different than ones that > the final > > > > bearer path will take. So, just because the SDP is good > > > for 100kbps, > > > > it does not mean that the packets going between endpoints > > will get > > > > this type of treatment during early stages of the session setup > > > > process (right when connectivity checks would be getting > > > > performed) or there may be a race condition between the route > > > > optimization used and the connectivity checks doing their thing. > > > > > > ICE's connectivity checks don't need to be QoS'd like the > > > forthcoming RTP packets. Packet loss will interfere with > > ICE, though. > > > > > > Ignoring ICE's connectivity checks, wouldn't the behavior you > > > describe cause problems with real media packets, too, if they are > > > sent before these additional steps are performed? > > > > > > -d > > > > > > > > > > Regards, > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > > Sent: Friday, September 01, 2006 12:14 PM > > > > > To: Stucker, Brian (RICH1:B620); > ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > Cc: 'Pasi Sarolahti' > > > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > > > > > Brian, > > > > > > > > > > > I see where you are headed with this, I think it's a > > good start. > > > > > > > > > > > > With #2, how would bandwidth affect ICE connectivity > > > > > checks? Are you > > > > > > assuming that bandwidth will guarantee a certain latency > > > > budget as > > > > > > well? > > > > > > > > > > No, I'm not assuming any relationship between bandwidth > > > and latency. > > > > > There is the extreme of running VoIP over satellite, and > > > the extreme > > > > > that we could negotiate G.711 but be on opposite sides of the > > > > > planet. > > > > > > > > > > Rather, I'm saying that if the bandwidth of the > > > negotiated codec is > > > > > 100kbps, it would be prudent for ICE's connectivity > > checks to not > > > > > exceed 100kbps. > > > > > Networks with strict QoS schedulers may drop packets that > > > exceed the > > > > > expected bandwidth (PacketCable, most notably; I expect > > IMS would > > > > > have similar behavior). > > > > > > > > > > -d > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > > > > Sent: Thursday, August 31, 2006 8:01 PM > > > > > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > > Cc: Stucker, Brian (RICH1:B620); 'Pasi Sarolahti' > > > > > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > > > > > > > > > > RFC3489bis authors & everyone, > > > > > > > > > > > > > > As rfc3489bis co-author: > > > > > > > > > > > > > > Based on your thread and Brian's recent thread > > ("Time to add > > > > > > > mapping/filtering entries"), I thought about rfc3489bis > > > > and ICE's > > > > > > > interaction with it. > > > > > > > > > > > > > > > > > > > > > ICE makes two significant uses of STUN that are > > > interesting to > > > > > > > BEHAVE. The first is the 'classic STUN' usage ("Binding > > > > > Discovery" > > > > > > > in > > > > > > > -behave-rfc3489bis) -- learn your public IP address and > > > > > UDP port. > > > > > > > To avoid the problem Cullen described (where NATs seem to > > > > > 'forget' > > > > > > > to create > > > > > > > bindings) those binding discovery STUN packets to the STUN > > > > > > > server(s) need to be paced. > > > > > > > > > > > > > > The second interesting ICE usage is its > connectivity checks > > > > > > > ("Connectivity Check" in -behave-rfc3489bis). > > > > > > > > > > > > > > ICE's connectivity checks don't need to be paced to be > > > > gentle for > > > > > > > the same reason, because ICE's connectivity checks don't > > > > > create new > > > > > > > NAT bindings (pedantic readers know that there are some > > > > > exceptional > > > > > > > configurations where ICE's connectivity checks do create > > > > > a new NAT > > > > > > > binding). Rather, ICE's connectivity checks only using > > > > existing > > > > > > > bindings and change the NAT's filtering (if the > NAT does do > > > > > > > filtering). > > > > > > > > > > > > > > I suggest -behave-rfc3489bis should break out the > > > > retransmission > > > > > > > rules into per-usage recommendations. > > > > > > > > > > > > > > > > > > > > > Of the usages defined in -behave-rfc3489bis, > > > > > > > 1. Binding Discovery > > > > > > > 2. Connectivity Check > > > > > > > 3. NAT Keepalives > > > > > > > 4. Short-Term Password > > > > > > > here are some thoughts on retransmit timers: > > > > > > > > > > > > > > 1. Binding Discovery: it doesn't harm interoperability > > > > > if one STUN > > > > > > > client uses 100ms and another STUN client uses 2000ms. > > > > > It harms > > > > > > > call setup time, of course, but presumably the > > clients were > > > > > > > configured with those retransmit timers on purpose -- > > > > > > someone knew > > > > > > > the network was fast (100ms) or the network was slow > > > > > but had very > > > > > > > little loss (2000ms). After the first STUN check, the > > > > > > > retransmission timer could be adjusted. Note that for > > > > > > ICE, you do > > > > > > > a STUN check for your RTP and for your RTCP port > > > > separately for > > > > > > > each media stream. So if you're doing audio and > > > > video you will > > > > > > > send 4 STUN packets from 4 different local ports, paced > > > > > > 50ms apart > > > > > > > (to avoid the problem Cullen described). If you > > > > receive a STUN > > > > > > > response for the first one in 20ms you know the RTT and > > > > > > processing > > > > > > > time of the STUN server is 20ms. We use that > > > > knowledge to our > > > > > > > advantage in determining the retransmission timer for > > > > > the other 3 > > > > > > > outstanding STUN transactions. Each of them > should come > > > > > > back 20ms > > > > > > > after we sent their request. If we don't see the > > > > > > response in 20ms, > > > > > > > and we wanted to be aggressive, we could send another > > > > > request in > > > > > > > max(RTT,50ms). > > > > > > > > > > > > > > 2. Connectivity check: connectivity checks don't occur > > > > > > until you know > > > > > > > the peer's IP address and codecs. That provides enough > > > > > > information > > > > > > > about the expected bandwidth that ICE can stay below > > > > > > that bandwidth > > > > > > > while performing its connectivity checks. > > > > > > > > > > > > > > 3. NAT Keepavlies: the initial RTT used by TCP SYNs seems > > > > > > reasonable > > > > > > > (WinXP seems to wait 2 seconds, for whatever that's > > > > > > worth. RFC2988 > > > > > > > seems to recommend a value less than 3 seconds). From > > > > > there, the > > > > > > > RTT of previous successful NAT keepalives can be > > > > > useful to adjust > > > > > > > the retransmit value of subsequent NAT keepalives. > > > > > > > > > > > > > > 4. Short-Term Password: This is usually the same server > > > > > as (1), so > > > > > > > apply the same rules as (1). > > > > > > > > > > > > > > -d > > > > > > > > > > > > > > > > From dwing@cisco.com Fri, 1 Sep 2006 16:24:29 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Fri, 1 Sep 2006 16:24:29 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371103C37F0@zrc2hxm2.corp.nortel.com> Message-ID: <071501c6ce0c$fc204320$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > > The timer value for unreachable isn't directly tied to how > > quickly you retransmit. You might declare an endpoint > > unreachable at a fixed 1000ms, but inside of that second you > > could have transmitted and retransmitted several > > connectivity checks. > > Hmm.. I thought it was tied to number of retransmissions or time > (whichever is satisfied first). I'll have to look for that in -10. That is what -10 says. However, this whole thread was about the validity of the 100ms STUN retransmit timer. So I'm trying to tease out what works best from the perspective of success through NATs, and (to a lesser extent) what would work best for ICE. -d > > > Alternately, you'd could be spamming the network with > > > connectivity > > > checks due to impatience. > > > > If you're going to be sending 100kbps as soon as the call is > > answered anyway, 100kbps of connectivity checks isn't awful. > > If you're going to be sending 10kbps as soon as the call is > > answered, 100kbps of connectivity checks could very well be awful. > > Assuming you're going to get 100kbps. It's a concern that shouldn't be > dismissed out of hand. > > > > > > To answer your second question, yes. It could. However, the > > problem is > > > not likely to be as severe because in most wireless > settings early > > > media is middle-to-end and not end-to-end. The middle > typically has > > > more control and awareness of what's going on with the bearer and > > > fewer hops to complete any round-trips necessary. > > > > As in draft-stucker-sipping-early-media-coping-01, right? > > Yes, I need to put that into the -02 revision. > > > > > -d > > > > > > > Regards, > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > Sent: Friday, September 01, 2006 12:57 PM > > > > To: Stucker, Brian (RICH1:B620); ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Cc: 'Pasi Sarolahti' > > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > > > > Ok, makes sense. > > > > > > > > > > In terms of wireless, there's a bit of trick that may > > have to be > > > > > played as QoS may not be stable yet at the time that an > > > > answer to an > > > > > offer comes back while all of the elements on the > > signaling path > > > > > figure out what they want to do with the SDP being > > > > exchanged in terms > > > > > of adjusting the final QoS granted. > > > > > > > > > > Also, with mobility networks, there is the possibility that > > > > the path > > > > > that the early packets take is different than ones that > > the final > > > > > bearer path will take. So, just because the SDP is good > > > > for 100kbps, > > > > > it does not mean that the packets going between endpoints > > > will get > > > > > this type of treatment during early stages of the > session setup > > > > > process (right when connectivity checks would be getting > > > > > performed) or there may be a race condition between the route > > > > > optimization used and the connectivity checks doing > their thing. > > > > > > > > ICE's connectivity checks don't need to be QoS'd like the > > > > forthcoming RTP packets. Packet loss will interfere with > > > ICE, though. > > > > > > > > Ignoring ICE's connectivity checks, wouldn't the behavior you > > > > describe cause problems with real media packets, too, > if they are > > > > sent before these additional steps are performed? > > > > > > > > -d > > > > > > > > > > > > > Regards, > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > > > Sent: Friday, September 01, 2006 12:14 PM > > > > > > To: Stucker, Brian (RICH1:B620); > > ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > Cc: 'Pasi Sarolahti' > > > > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > > > > > > > Brian, > > > > > > > > > > > > > I see where you are headed with this, I think it's a > > > good start. > > > > > > > > > > > > > > With #2, how would bandwidth affect ICE connectivity > > > > > > checks? Are you > > > > > > > assuming that bandwidth will guarantee a certain latency > > > > > budget as > > > > > > > well? > > > > > > > > > > > > No, I'm not assuming any relationship between bandwidth > > > > and latency. > > > > > > There is the extreme of running VoIP over satellite, and > > > > the extreme > > > > > > that we could negotiate G.711 but be on opposite > sides of the > > > > > > planet. > > > > > > > > > > > > Rather, I'm saying that if the bandwidth of the > > > > negotiated codec is > > > > > > 100kbps, it would be prudent for ICE's connectivity > > > checks to not > > > > > > exceed 100kbps. > > > > > > Networks with strict QoS schedulers may drop packets that > > > > exceed the > > > > > > expected bandwidth (PacketCable, most notably; I expect > > > IMS would > > > > > > have similar behavior). > > > > > > > > > > > > -d > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > > > > > > Sent: Thursday, August 31, 2006 8:01 PM > > > > > > > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > > > Cc: Stucker, Brian (RICH1:B620); 'Pasi Sarolahti' > > > > > > > > Subject: RE: [Ietf-behave] STUN retransmission timers > > > > > > > > > > > > > > > > > RFC3489bis authors & everyone, > > > > > > > > > > > > > > > > As rfc3489bis co-author: > > > > > > > > > > > > > > > > Based on your thread and Brian's recent thread > > > ("Time to add > > > > > > > > mapping/filtering entries"), I thought about rfc3489bis > > > > > and ICE's > > > > > > > > interaction with it. > > > > > > > > > > > > > > > > > > > > > > > > ICE makes two significant uses of STUN that are > > > > interesting to > > > > > > > > BEHAVE. The first is the 'classic STUN' usage ("Binding > > > > > > Discovery" > > > > > > > > in > > > > > > > > -behave-rfc3489bis) -- learn your public IP address and > > > > > > UDP port. > > > > > > > > To avoid the problem Cullen described (where > NATs seem to > > > > > > 'forget' > > > > > > > > to create > > > > > > > > bindings) those binding discovery STUN packets > to the STUN > > > > > > > > server(s) need to be paced. > > > > > > > > > > > > > > > > The second interesting ICE usage is its > > connectivity checks > > > > > > > > ("Connectivity Check" in -behave-rfc3489bis). > > > > > > > > > > > > > > > > ICE's connectivity checks don't need to be paced to be > > > > > gentle for > > > > > > > > the same reason, because ICE's connectivity checks don't > > > > > > create new > > > > > > > > NAT bindings (pedantic readers know that there are some > > > > > > exceptional > > > > > > > > configurations where ICE's connectivity checks do create > > > > > > a new NAT > > > > > > > > binding). Rather, ICE's connectivity checks only using > > > > > existing > > > > > > > > bindings and change the NAT's filtering (if the > > NAT does do > > > > > > > > filtering). > > > > > > > > > > > > > > > > I suggest -behave-rfc3489bis should break out the > > > > > retransmission > > > > > > > > rules into per-usage recommendations. > > > > > > > > > > > > > > > > > > > > > > > > Of the usages defined in -behave-rfc3489bis, > > > > > > > > 1. Binding Discovery > > > > > > > > 2. Connectivity Check > > > > > > > > 3. NAT Keepalives > > > > > > > > 4. Short-Term Password > > > > > > > > here are some thoughts on retransmit timers: > > > > > > > > > > > > > > > > 1. Binding Discovery: it doesn't harm interoperability > > > > > > if one STUN > > > > > > > > client uses 100ms and another STUN client > uses 2000ms. > > > > > > It harms > > > > > > > > call setup time, of course, but presumably the > > > clients were > > > > > > > > configured with those retransmit timers on purpose -- > > > > > > > someone knew > > > > > > > > the network was fast (100ms) or the network was slow > > > > > > but had very > > > > > > > > little loss (2000ms). After the first STUN > check, the > > > > > > > > retransmission timer could be adjusted. > Note that for > > > > > > > ICE, you do > > > > > > > > a STUN check for your RTP and for your RTCP port > > > > > separately for > > > > > > > > each media stream. So if you're doing audio and > > > > > video you will > > > > > > > > send 4 STUN packets from 4 different local > ports, paced > > > > > > > 50ms apart > > > > > > > > (to avoid the problem Cullen described). If you > > > > > receive a STUN > > > > > > > > response for the first one in 20ms you know > the RTT and > > > > > > > processing > > > > > > > > time of the STUN server is 20ms. We use that > > > > > knowledge to our > > > > > > > > advantage in determining the retransmission timer for > > > > > > the other 3 > > > > > > > > outstanding STUN transactions. Each of them > > should come > > > > > > > back 20ms > > > > > > > > after we sent their request. If we don't see the > > > > > > > response in 20ms, > > > > > > > > and we wanted to be aggressive, we could send another > > > > > > request in > > > > > > > > max(RTT,50ms). > > > > > > > > > > > > > > > > 2. Connectivity check: connectivity checks don't occur > > > > > > > until you know > > > > > > > > the peer's IP address and codecs. That > provides enough > > > > > > > information > > > > > > > > about the expected bandwidth that ICE can stay below > > > > > > > that bandwidth > > > > > > > > while performing its connectivity checks. > > > > > > > > > > > > > > > > 3. NAT Keepavlies: the initial RTT used by TCP > SYNs seems > > > > > > > reasonable > > > > > > > > (WinXP seems to wait 2 seconds, for whatever that's > > > > > > > worth. RFC2988 > > > > > > > > seems to recommend a value less than 3 > seconds). From > > > > > > there, the > > > > > > > > RTT of previous successful NAT keepalives can be > > > > > > useful to adjust > > > > > > > > the retransmit value of subsequent NAT keepalives. > > > > > > > > > > > > > > > > 4. Short-Term Password: This is usually the same server > > > > > > as (1), so > > > > > > > > apply the same rules as (1). > > > > > > > > > > > > > > > > -d > > > > > > > > > > > > > > > > > > > > From dwing@cisco.com Fri, 1 Sep 2006 17:03:26 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Fri, 1 Sep 2006 17:03:26 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <699308B5-77C8-4788-AB8C-41831BAE3431@netlab.nec.de> Message-ID: <074e01c6ce12$6d575150$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > as an individual contributor, let me echo Pasi's concerns with > regards to sending the first retransmission after 100ms. (I do need > to read up on the details of the latest STUN version though.) > > On Sep 1, 2006, at 3:00, Dan Wing wrote: > > ICE's connectivity checks don't need to be paced to be gentle for > > the same > > reason, because ICE's connectivity checks don't create new NAT > > bindings > > The potential issue is with causing additional traffic on long, > narrow paths, not with causing load on the NAT (but that might be an > issue, too). What do you mean by 'additional'? Any traffic sent is additional compared to sending no traffic at all, and ICE needs to send some packets. > > 1. Binding Discovery: it doesn't harm interoperability if one STUN > > client uses 100ms and another STUN client uses 2000ms. It harms > > call setup time, of course, but presumably the clients were > > configured with those retransmit timers on purpose -- > someone knew > > the network was fast (100ms) or the network was slow but had very > > little loss (2000ms). > > Right, but the current draft simply says "clients SHOULD retransmit > the request starting with an interval of 100ms", irrespective of the > path. Maybe it should say something like "clients SHOULD retransmit > the request starting with an interval off f(RTT), or Y > seconds if the RTT is unknown." TCP uses 3 seconds for Y per > RFC1122; see RFC2988 for f(). Thanks for the pointers. STUN is more similar to DNS than to TCP, and I see that RFC1123 (page 77) recommends an initial minimum RTT of 5 seconds: > (5) When a DNS server or resolver retries a UDP query, > the retry interval SHOULD be constrained by an > exponential backoff algorithm, and SHOULD also have > upper and lower bounds. > > IMPLEMENTATION: A measured RTT and variance (if > available) should be used to calculate an initial > retransmission interval. If this information is not > available, a default of no less than 5 seconds should > be used. Implementations may limit the > retransmission interval, but this limit must exceed > twice the Internet maximum segment lifetime plus > service delay at the name server. -d From lars.eggert@netlab.nec.de Sat, 2 Sep 2006 03:47:36 -0500 (CDT) (envelope-from lars.eggert@netlab.nec.de) From: Lars Eggert Date: Sat, 2 Sep 2006 03:47:36 -0500 (CDT) (envelope-from lars.eggert@netlab.nec.de) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <074e01c6ce12$6d575150$c4f0200a@amer.cisco.com> Message-ID: <5D417809-CE9C-4B13-8092-7F209F781958@netlab.nec.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630136.multipart/signed" --Boundary..27398.1163630136.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, Dan, On Sep 2, 2006, at 0:03, Dan Wing wrote: The potential issue is with causing additional traffic on long, narrow paths, not with causing load on the NAT (but that might be an issue, too). What do you mean by 'additional'? Any traffic sent is additional compared to sending no traffic at all, and ICE needs to send some packets. "Additional" in the sense of sending out the first retransmission before the original transmission has had a chance to reach the destination (on a path with a one-way delay > 100ms). If a host has multiple bindings over a long, narrow path, this may add up. Thanks for the pointers. STUN is more similar to DNS than to TCP, and I see that RFC1123 (page 77) recommends an initial minimum RTT of 5 seconds: (5) When a DNS server or resolver retries a UDP query, the retry interval SHOULD be constrained by an exponential backoff algorithm, and SHOULD also have upper and lower bounds. IMPLEMENTATION: A measured RTT and variance (if available) should be used to calculate an initial retransmission interval. If this information is not available, a default of no less than 5 seconds should be used. Implementations may limit the retransmission interval, but this limit must exceed twice the Internet maximum segment lifetime plus service delay at the name server. Thanks for the pointer. DNS is even more conservative. Lars -- Lars Eggert NEC Network Laboratories Attachment: smime.p7s --Boundary..27398.1163630136.multipart/signed Content-Type: application/octet-stream; name="p7sqgA5KqRbHl.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7sqgA5KqRbHl.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwOTAy MDg0NzI2WjAjBgkqhkiG9w0BCQQxFgQUEzQZYSJ95Zo0z25JaokphIbpVpYwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAKMCzX4NSS9L0/3mROKW Jlg5ZDyZM415+blcL+ywSDqbQPrFIFPUlfPKz8q7WqPNC+Vit94juot4XlJBcgrqm2KPHOf4idvu 3V8Z7gQkmCfqqw0pGlST0OLW7dswedhSmpwARK6TMWGCGZCW7ogUnAasySawQkMOHaBMf1Va/6zA SHNd0/8t8EVmAuSQ8w1PExLUvqGpNvV22cQ9W8Dy5oRs+zVQ9Y7eHyjVkIHitQc9A+hcw9cdokyA xz9ORsNxCkebFgr7U6PGRWnsKT7LIphhhG6vfZ4a45J0t/3rsirIZTZ12+2zZr8Hz4HPQHFrY7oF S2q0PO8digcMliCfA60AAAAAAAA= --Boundary..27398.1163630136.multipart/signed-- From dwing@cisco.com Sat, 2 Sep 2006 11:42:05 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Sat, 2 Sep 2006 11:42:05 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <5D417809-CE9C-4B13-8092-7F209F781958@netlab.nec.de> Message-ID: <0b0c01c6ceae$b381afd0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > "Additional" in the sense of sending out the first retransmission > before the original transmission has had a chance to reach the > destination (on a path with a one-way delay > 100ms). > > If a host has multiple bindings over a long, narrow path, this may > add up. ICE-10 only tests one media line at a time, so it shouldn't add up as quickly as previous versions of ICE. > > Thanks for the pointers. STUN is more similar to DNS than to TCP, > > and I see that RFC1123 (page 77) recommends an initial minimum RTT > > of 5 seconds: > > > >> (5) When a DNS server or resolver retries a UDP query, > >> the retry interval SHOULD be constrained by an > >> exponential backoff algorithm, and SHOULD also have > >> upper and lower bounds. > >> > >> IMPLEMENTATION: A measured RTT and variance (if > >> available) should be used to calculate an initial > >> retransmission interval. If this information is not > >> available, a default of no less than 5 seconds should > >> be used. Implementations may limit the > >> retransmission interval, but this limit must exceed > >> twice the Internet maximum segment lifetime plus > >> service delay at the name server. > > Thanks for the pointer. DNS is even more conservative. I was surprised to see DNS recommended such a high initial RTT, especially that it's higher than TCP's and your DNS server is most typically near you. -d From jdrosen@cisco.com Sat, 2 Sep 2006 20:43:44 -0500 (CDT) (envelope-from jdrosen@cisco.com) From: Jonathan Rosenberg Date: Sat, 2 Sep 2006 20:43:44 -0500 (CDT) (envelope-from jdrosen@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <13bd01c6cd62$165b0230$c3f0200a@amer.cisco.com> Message-ID: <44FA3344.7040200@cisco.com> MIME-Version: 1.0 Content-Type: text/plain I must say I don't really like the idea too much of having to adjust the STUN transaction timers on a usage-by-usage basis. Certainly for SIP we have not advocated different timers for SIP transactions for INVITE vs. SUBSCRIBE, though the two of them both have quite different requirements around latency. I think it makes more sense to try to tune these as a function of RTT. Lars suggested: clients SHOULD retransmit the request starting with an interval off f(RTT), or Y seconds if the RTT is unknown." TCP uses 3 seconds for Y per RFC1122; see RFC2988 for f(). We'll then get into the issue about whether 3s is a reasonable RTT assumption in any network where we're using STUN. I will note that any network with a 3s RTT is going to stink for voip... -Jonathan R. Dan Wing wrote: RFC3489bis authors & everyone, As rfc3489bis co-author: Based on your thread and Brian's recent thread ("Time to add mapping/filtering entries"), I thought about rfc3489bis and ICE's interaction with it. ICE makes two significant uses of STUN that are interesting to BEHAVE. The first is the 'classic STUN' usage ("Binding Discovery" in -behave-rfc3489bis) -- learn your public IP address and UDP port. To avoid the problem Cullen described (where NATs seem to 'forget' to create bindings) those binding discovery STUN packets to the STUN server(s) need to be paced. The second interesting ICE usage is its connectivity checks ("Connectivity Check" in -behave-rfc3489bis). ICE's connectivity checks don't need to be paced to be gentle for the same reason, because ICE's connectivity checks don't create new NAT bindings (pedantic readers know that there are some exceptional configurations where ICE's connectivity checks do create a new NAT binding). Rather, ICE's connectivity checks only using existing bindings and change the NAT's filtering (if the NAT does do filtering). I suggest -behave-rfc3489bis should break out the retransmission rules into per-usage recommendations. Of the usages defined in -behave-rfc3489bis, 1. Binding Discovery 2. Connectivity Check 3. NAT Keepalives 4. Short-Term Password here are some thoughts on retransmit timers: 1. Binding Discovery: it doesn't harm interoperability if one STUN client uses 100ms and another STUN client uses 2000ms. It harms call setup time, of course, but presumably the clients were configured with those retransmit timers on purpose -- someone knew the network was fast (100ms) or the network was slow but had very little loss (2000ms). After the first STUN check, the retransmission timer could be adjusted. Note that for ICE, you do a STUN check for your RTP and for your RTCP port separately for each media stream. So if you're doing audio and video you will send 4 STUN packets from 4 different local ports, paced 50ms apart (to avoid the problem Cullen described). If you receive a STUN response for the first one in 20ms you know the RTT and processing time of the STUN server is 20ms. We use that knowledge to our advantage in determining the retransmission timer for the other 3 outstanding STUN transactions. Each of them should come back 20ms after we sent their request. If we don't see the response in 20ms, and we wanted to be aggressive, we could send another request in max(RTT,50ms). 2. Connectivity check: connectivity checks don't occur until you know the peer's IP address and codecs. That provides enough information about the expected bandwidth that ICE can stay below that bandwidth while performing its connectivity checks. 3. NAT Keepavlies: the initial RTT used by TCP SYNs seems reasonable (WinXP seems to wait 2 seconds, for whatever that's worth. RFC2988 seems to recommend a value less than 3 seconds). From there, the RTT of previous successful NAT keepalives can be useful to adjust the retransmit value of subsequent NAT keepalives. 4. Short-Term Password: This is usually the same server as (1), so apply the same rules as (1). -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From dwing@cisco.com Sun, 3 Sep 2006 00:52:28 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Sun, 3 Sep 2006 00:52:28 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <44FA3344.7040200@cisco.com> Message-ID: <0b3b01c6cf1d$1d755db0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I agree learning the RTT is useful, if you can estimate the RTT to that host: the RTT to the STUN server isn't related to the RTT for connectivity checks. The RTT should only be learned on a per-host basis or perhaps a per-"connection" basis. -d > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxx] > Sent: Saturday, September 02, 2006 6:44 PM > To: Dan Wing > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] STUN retransmission timers > > I must say I don't really like the idea too much of having to > adjust the > STUN transaction timers on a usage-by-usage basis. Certainly > for SIP we > have not advocated different timers for SIP transactions for > INVITE vs. > SUBSCRIBE, though the two of them both have quite different > requirements > around latency. > > I think it makes more sense to try to tune these as a > function of RTT. > Lars suggested: > > > clients SHOULD retransmit the request starting with an > interval off f(RTT), or Y seconds if the RTT is unknown." > TCP uses 3 seconds for Y per RFC1122; see RFC2988 for f(). > > We'll then get into the issue about whether 3s is a reasonable RTT > assumption in any network where we're using STUN. I will note > that any > network with a 3s RTT is going to stink for voip... > > -Jonathan R. > > Dan Wing wrote: > > >>RFC3489bis authors & everyone, > > > > > > As rfc3489bis co-author: > > > > Based on your thread and Brian's recent thread ("Time to add > > mapping/filtering entries"), I thought about rfc3489bis and ICE's > > interaction with it. > > > > > > ICE makes two significant uses of STUN that are interesting > to BEHAVE. The > > first is the 'classic STUN' usage ("Binding Discovery" in > > -behave-rfc3489bis) -- learn your public IP address and UDP > port. To avoid > > the problem Cullen described (where NATs seem to 'forget' to create > > bindings) those binding discovery STUN packets to the STUN > server(s) need to > > be paced. > > > > The second interesting ICE usage is its connectivity checks > ("Connectivity > > Check" in -behave-rfc3489bis). > > > > ICE's connectivity checks don't need to be paced to be > gentle for the same > > reason, because ICE's connectivity checks don't create new > NAT bindings > > (pedantic readers know that there are some exceptional > configurations where > > ICE's connectivity checks do create a new NAT binding). > Rather, ICE's > > connectivity checks only using existing bindings and change > the NAT's > > filtering (if the NAT does do filtering). > > > > I suggest -behave-rfc3489bis should break out the > retransmission rules into > > per-usage recommendations. > > > > > > Of the usages defined in -behave-rfc3489bis, > > 1. Binding Discovery > > 2. Connectivity Check > > 3. NAT Keepalives > > 4. Short-Term Password > > here are some thoughts on retransmit timers: > > > > 1. Binding Discovery: it doesn't harm interoperability if one STUN > > client uses 100ms and another STUN client uses 2000ms. It harms > > call setup time, of course, but presumably the clients were > > configured with those retransmit timers on purpose -- > someone knew > > the network was fast (100ms) or the network was slow but had very > > little loss (2000ms). After the first STUN check, the > > retransmission timer could be adjusted. Note that for > ICE, you do > > a STUN check for your RTP and for your RTCP port separately for > > each media stream. So if you're doing audio and video you will > > send 4 STUN packets from 4 different local ports, paced > 50ms apart > > (to avoid the problem Cullen described). If you receive a STUN > > response for the first one in 20ms you know the RTT and > processing > > time of the STUN server is 20ms. We use that knowledge to our > > advantage in determining the retransmission timer for the other 3 > > outstanding STUN transactions. Each of them should come > back 20ms > > after we sent their request. If we don't see the > response in 20ms, > > and we wanted to be aggressive, we could send another request in > > max(RTT,50ms). > > > > 2. Connectivity check: connectivity checks don't occur > until you know > > the peer's IP address and codecs. That provides enough > information > > about the expected bandwidth that ICE can stay below > that bandwidth > > while performing its connectivity checks. > > > > 3. NAT Keepavlies: the initial RTT used by TCP SYNs seems > reasonable > > (WinXP seems to wait 2 seconds, for whatever that's > worth. RFC2988 > > seems to recommend a value less than 3 seconds). From there, the > > RTT of previous successful NAT keepalives can be useful to adjust > > the retransmit value of subsequent NAT keepalives. > > > > 4. Short-Term Password: This is usually the same server as (1), so > > apply the same rules as (1). > > > > -d > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com From magnus.westerlund@ericsson.com Mon, 4 Sep 2006 03:44:58 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) From: Magnus Westerlund Date: Mon, 4 Sep 2006 03:44:58 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) Subject: [Ietf-behave] AD Evaluation of draft-ietf-behave-multicast-02 Message-ID: <44FBE783.5080107@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, I have done the AD evaluation of this document and do have a few comments. 1. There is a lack of references and explanation of abbreviations. For example none of IGMP version talked about in the introduction has any references. 2. Section 2: "Sending multicast traffic is out of scope because it requires NATting the source IP address of such transmitted multicast traffic." This does not motivate why NATing the source would be a problem and thus should be done so that the receiving entity can actively participate in a session. 3. Section 3.1: "Hosts will periodically send IGMP Report messages to indicate continued interest in receiving the multicast traffic." I think "hosts" in the above sentence should be clarified to mean the NATed hosts. 4. Security consideration. I think it should reference the MAGMA proxy drafts security consideration also. I would appreciate an update to resolve these comments. cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From tomi.kohonen@nokia.com Mon, 4 Sep 2006 06:40:30 -0500 (CDT) (envelope-from tomi.kohonen@nokia.com) From: Date: Mon, 4 Sep 2006 06:40:30 -0500 (CDT) (envelope-from tomi.kohonen@nokia.com) Subject: [Ietf-behave] STUN Server Discovery Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi, There seems to be a new non backwards compatible STUN server discovery process in RFC3489bis (draft-ietf-behave-rfc3489bis-04). I'd hereby like to initiate a discussion on this issue. As I've understood, the RFC3489 specifies the services like this (in 9.1): _stun._tcp.example.com Shared secret service with TLS (*) _stun._udp.example.com Binding query service with UDP ...and RFC3489bis like follows (in 8.1): _stun-pass._tls.example.com Shared secret service with TLS (*) _stun._tcp.example.com Binding query service with TCP (*) _stun._udp.example.com Binding query service with UDP _stun._tls.example.com Binding query service with TLS As can be seen, the shared secret service and binding query service via TCP have conflicting service queries (marked with '*'). If (and when) a client want's to implement support for both RFC3489 and RFC3489bis, this becomes a clear problem. What I'd like to see is that the RFC3489bis would be changed to specify the discovery process in a way which would not conflict with the RFC3489 specification. Backwards compatibility here would be beneficial for both the STUN clients and servers. Second issue regarding the STUN services, is that I'd like to see consistent default ports for all of the (relevant) STUN services (like RFC3489 has). The same kind of a conflict is visible also here: RFC3489: -Shared secret service with TLS: 3478 -Binding query service with UDP: 3478 RFC3489bis: -Shared secret service with TLS: (none) -Binding query service with UDP: 3478 -Binding query service with TCP: 3478 Having default ports (and of course consistent ones) would enable implementation of clients which have only STUN server address configured (i.e. no STUN domain). This would be userful in situations where the (server/network) setup is static, and thus constant DNS SRV queries would be unnecessary. Here the ports would have to be configured, just because there are no default ports. -- Tomi From fluffy@cisco.com Mon, 4 Sep 2006 19:28:41 -0500 (CDT) (envelope-from fluffy@cisco.com) From: Cullen Jennings Date: Mon, 4 Sep 2006 19:28:41 -0500 (CDT) (envelope-from fluffy@cisco.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711021C120@zrc2hxm2.corp.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I looked at some code for a residential NAT and an high end enterprise. I strongly suspect that there was no per source address rate limiting code but instead just limits on when the CPU got too busy in general. I may have gotten this all wrong, staring at a bunch of NAT code that you did not write is a mind numbing process. On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: Random thought, Does anyone know if the speed of NATs creating new bindings being limited due to dropping occurs in aggregate, or is it limited only to requests coming in from a single source address? If it's a problem in aggregate (meaning it'll drop new bindings if the overall rate is too high) that might not bode well for large numbers of clients using STUN for connectivity checks behind some NATs. Regards, Brian -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Cullen Jennings Sent: Tuesday, August 22, 2006 7:12 PM To: Eric Cooper Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] Time to add mapping/filtering entries My test program that classifies NATs runs a bunch of tests in parallel. If you run the stun packets with no gap, it is clear that many NATs just lose some of the state they should be storing even though they forwarded the packet. When I gap by 10 ms, most NATs seem to work and I don't think I have anything that fails if I am at 20 ms but it is hard to test. There are reports that my test program fails on some NATs with 50ms gaps but I have not been able to replicate this. I have not investigated if you can burst a small number -- such as with HTTP traffic -- and have it work well all the time. All my testing has been with UDP not TCP. If people want to play with this, the software is the open source stuff at vovida.org. On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: Hi All, I've recently been looking into 'Internet Connectivity Establishment' (ICE), which contains some statements indicating that some NAT/FW devices may be overwhelmed if they need to create a bunch of new mapping and/or filtering entries in a short amount of time. Specific to ICE, 'a bunch' is somewhere on the order of 5-25 per ICE endpoint. ICE indicates that endpoints should rate limit packets such that packets which would likely create new mapping and/ or filtering entries are spaced 50 ms apart. I wonder if this spacing is really necessary. A quick experiment with Ethereal and my browser seems to indicate that HTTP GET requests to different servers are not spaced 50 ms apart. My questions to the group are: 1) Does anyone have any empirical data regarding the speed at which new mapping/filtering entries can be created on various devices? 2) What is your opinion w.r.t. this 50 ms spacing? Is it necessary for existing devices, and will it continue to be necessary for BEHAVE-NAT-UDP compliant devices? Thanks! Eric Cooper. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Mon, 4 Sep 2006 20:03:41 -0500 (CDT) (envelope-from srisuresh@yahoo.com) From: Pyda Srisuresh Date: Mon, 4 Sep 2006 20:03:41 -0500 (CDT) (envelope-from srisuresh@yahoo.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: Message-ID: <20060905010332.97511.qmail@web33302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain I agree with Cullen's comment below. Binding entry creation is resource constrained at a global level, not ona per-source basis, AFAIK. cheers, suresh --- Cullen Jennings wrote: > > I looked at some code for a residential NAT and an high end > enterprise. I strongly suspect that there was no per source address > rate limiting code but instead just limits on when the CPU got too > busy in general. I may have gotten this all wrong, staring at a bunch > of NAT code that you did not write is a mind numbing process. > > > On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: > > > Random thought, > > > > Does anyone know if the speed of NATs creating new bindings being > > limited due to dropping occurs in aggregate, or is it limited only to > > requests coming in from a single source address? > > > > If it's a problem in aggregate (meaning it'll drop new bindings if the > > overall rate is too high) that might not bode well for large > > numbers of > > clients using STUN for connectivity checks behind some NATs. > > > > Regards, > > Brian > > > >> -----Original Message----- > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > >> Cullen Jennings > >> Sent: Tuesday, August 22, 2006 7:12 PM > >> To: Eric Cooper > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >> Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > >> > >> > >> My test program that classifies NATs runs a bunch of tests in > >> parallel. If you run the stun packets with no gap, it is > >> clear that many NATs just lose some of the state they should > >> be storing even though they forwarded the packet. When I gap > >> by 10 ms, most NATs seem to work and I don't think I have > >> anything that fails if I am at 20 ms but it is hard to test. > >> There are reports that my test program fails on some NATs > >> with 50ms gaps but I have not been able to replicate this. > >> > >> I have not investigated if you can burst a small number -- > >> such as with HTTP traffic -- and have it work well all the > >> time. All my testing has been with UDP not TCP. > >> > >> If people want to play with this, the software is the open > >> source stuff at vovida.org. > >> > >> > >> > >> On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: > >> > >>> Hi All, > >>> > >>> I've recently been looking into 'Internet Connectivity > >> Establishment' > >>> (ICE), which contains some statements indicating that some NAT/FW > >>> devices may be overwhelmed if they need to create a bunch of new > >>> mapping and/or filtering entries in a short amount of time. > >>> > >>> Specific to ICE, 'a bunch' is somewhere on the order of > >> 5-25 per ICE > >>> endpoint. ICE indicates that endpoints should rate limit > >> packets such > >>> that packets which would likely create new mapping and/ or > >> filtering > >>> entries are spaced 50 ms apart. > >>> > >>> I wonder if this spacing is really necessary. A quick > >> experiment with > >>> Ethereal and my browser seems to indicate that HTTP GET requests to > >>> different servers are not spaced 50 ms apart. > >>> > >>> My questions to the group are: > >>> > >>> 1) Does anyone have any empirical data regarding the speed at which > >>> new mapping/filtering entries can be created on various devices? > >>> > >>> 2) What is your opinion w.r.t. this 50 ms spacing? Is it necessary > >>> for existing devices, and will it continue to be necessary for > >>> BEHAVE-NAT-UDP compliant devices? > >>> > >>> Thanks! > >>> > >>> Eric Cooper. > >>> > >>> _______________________________________________ > >>> Ietf-behave mailing list > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >> > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From bstucker@nortel.com Mon, 4 Sep 2006 20:05:52 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) From: "Brian Stucker" Date: Mon, 4 Sep 2006 20:05:52 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: <20060905010332.97511.qmail@web33302.mail.mud.yahoo.com> Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371103C3A52@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Can a recommendation be made somewhere to codify that assumption going forward (ie. so nobody thinks it's safe to assume the latter approach is acceptable)? Regards, Brian > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > Sent: Monday, September 04, 2006 8:04 PM > To: Cullen Jennings; Stucker, Brian (RICH1:B620) > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > I agree with Cullen's comment below. Binding entry creation > is resource constrained at a global level, not ona per-source > basis, AFAIK. > > cheers, > suresh > > --- Cullen Jennings wrote: > > > > > I looked at some code for a residential NAT and an high end > > enterprise. I strongly suspect that there was no per source address > > rate limiting code but instead just limits on when the CPU got too > > busy in general. I may have gotten this all wrong, staring > at a bunch > > of NAT code that you did not write is a mind numbing process. > > > > > > On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: > > > > > Random thought, > > > > > > Does anyone know if the speed of NATs creating new bindings being > > > limited due to dropping occurs in aggregate, or is it > limited only > > > to requests coming in from a single source address? > > > > > > If it's a problem in aggregate (meaning it'll drop new > bindings if > > > the overall rate is too high) that might not bode well for large > > > numbers of clients using STUN for connectivity checks behind some > > > NATs. > > > > > > Regards, > > > Brian > > > > > >> -----Original Message----- > > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > >> Cullen Jennings > > >> Sent: Tuesday, August 22, 2006 7:12 PM > > >> To: Eric Cooper > > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > >> Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > >> > > >> > > >> My test program that classifies NATs runs a bunch of tests in > > >> parallel. If you run the stun packets with no gap, it is clear > > >> that many NATs just lose some of the state they should > be storing > > >> even though they forwarded the packet. When I gap by 10 > ms, most > > >> NATs seem to work and I don't think I have anything that > fails if I > > >> am at 20 ms but it is hard to test. > > >> There are reports that my test program fails on some > NATs with 50ms > > >> gaps but I have not been able to replicate this. > > >> > > >> I have not investigated if you can burst a small number > -- such as > > >> with HTTP traffic -- and have it work well all the time. All my > > >> testing has been with UDP not TCP. > > >> > > >> If people want to play with this, the software is the > open source > > >> stuff at vovida.org. > > >> > > >> > > >> > > >> On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: > > >> > > >>> Hi All, > > >>> > > >>> I've recently been looking into 'Internet Connectivity > > >> Establishment' > > >>> (ICE), which contains some statements indicating that > some NAT/FW > > >>> devices may be overwhelmed if they need to create a > bunch of new > > >>> mapping and/or filtering entries in a short amount of time. > > >>> > > >>> Specific to ICE, 'a bunch' is somewhere on the order of > > >> 5-25 per ICE > > >>> endpoint. ICE indicates that endpoints should rate limit > > >> packets such > > >>> that packets which would likely create new mapping and/ or > > >> filtering > > >>> entries are spaced 50 ms apart. > > >>> > > >>> I wonder if this spacing is really necessary. A quick > > >> experiment with > > >>> Ethereal and my browser seems to indicate that HTTP GET > requests > > >>> to different servers are not spaced 50 ms apart. > > >>> > > >>> My questions to the group are: > > >>> > > >>> 1) Does anyone have any empirical data regarding the speed at > > >>> which new mapping/filtering entries can be created on > various devices? > > >>> > > >>> 2) What is your opinion w.r.t. this 50 ms spacing? Is it > > >>> necessary for existing devices, and will it continue to be > > >>> necessary for BEHAVE-NAT-UDP compliant devices? > > >>> > > >>> Thanks! > > >>> > > >>> Eric Cooper. > > >>> > > >>> _______________________________________________ > > >>> Ietf-behave mailing list > > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > >> _______________________________________________ > > >> Ietf-behave mailing list > > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > >> > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > From ssenthil@cisco.com Mon, 4 Sep 2006 20:13:08 -0500 (CDT) (envelope-from ssenthil@cisco.com) From: "Senthil Sivakumar \(ssenthil\)" Date: Mon, 4 Sep 2006 20:13:08 -0500 (CDT) (envelope-from ssenthil@cisco.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB02398DE8@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Do you mean it is not acceptable to have per-source rate limiting? If so, why? Cisco IOS NAT supports various types of rate-limiting including per-source. One of the main reasons to have to support per-source rate limiting was because of virus affected end stations that could potentially fill up the NAT table and eventually causing it to crash.. Senthil > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Brian Stucker > Sent: Monday, September 04, 2006 9:06 PM > To: Pyda Srisuresh; Cullen Jennings (fluffy) > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > Can a recommendation be made somewhere to codify that > assumption going forward (ie. so nobody thinks it's safe to > assume the latter approach is acceptable)? > > Regards, > Brian > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > Sent: Monday, September 04, 2006 8:04 PM > > To: Cullen Jennings; Stucker, Brian (RICH1:B620) > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > > I agree with Cullen's comment below. Binding entry creation is > > resource constrained at a global level, not ona per-source basis, > > AFAIK. > > > > cheers, > > suresh > > > > --- Cullen Jennings wrote: > > > > > > > > I looked at some code for a residential NAT and an high end > > > enterprise. I strongly suspect that there was no per > source address > > > rate limiting code but instead just limits on when the > CPU got too > > > busy in general. I may have gotten this all wrong, staring > > at a bunch > > > of NAT code that you did not write is a mind numbing process. > > > > > > > > > On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: > > > > > > > Random thought, > > > > > > > > Does anyone know if the speed of NATs creating new > bindings being > > > > limited due to dropping occurs in aggregate, or is it > > limited only > > > > to requests coming in from a single source address? > > > > > > > > If it's a problem in aggregate (meaning it'll drop new > > bindings if > > > > the overall rate is too high) that might not bode well > for large > > > > numbers of clients using STUN for connectivity checks > behind some > > > > NATs. > > > > > > > > Regards, > > > > Brian > > > > > > > >> -----Original Message----- > > > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > > >> Cullen Jennings > > > >> Sent: Tuesday, August 22, 2006 7:12 PM > > > >> To: Eric Cooper > > > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > >> Subject: Re: [Ietf-behave] Time to add > mapping/filtering entries > > > >> > > > >> > > > >> My test program that classifies NATs runs a bunch of tests in > > > >> parallel. If you run the stun packets with no gap, it > is clear > > > >> that many NATs just lose some of the state they should > > be storing > > > >> even though they forwarded the packet. When I gap by 10 > > ms, most > > > >> NATs seem to work and I don't think I have anything that > > fails if I > > > >> am at 20 ms but it is hard to test. > > > >> There are reports that my test program fails on some > > NATs with 50ms > > > >> gaps but I have not been able to replicate this. > > > >> > > > >> I have not investigated if you can burst a small number > > -- such as > > > >> with HTTP traffic -- and have it work well all the > time. All my > > > >> testing has been with UDP not TCP. > > > >> > > > >> If people want to play with this, the software is the > > open source > > > >> stuff at vovida.org. > > > >> > > > >> > > > >> > > > >> On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: > > > >> > > > >>> Hi All, > > > >>> > > > >>> I've recently been looking into 'Internet Connectivity > > > >> Establishment' > > > >>> (ICE), which contains some statements indicating that > > some NAT/FW > > > >>> devices may be overwhelmed if they need to create a > > bunch of new > > > >>> mapping and/or filtering entries in a short amount of time. > > > >>> > > > >>> Specific to ICE, 'a bunch' is somewhere on the order of > > > >> 5-25 per ICE > > > >>> endpoint. ICE indicates that endpoints should rate limit > > > >> packets such > > > >>> that packets which would likely create new mapping and/ or > > > >> filtering > > > >>> entries are spaced 50 ms apart. > > > >>> > > > >>> I wonder if this spacing is really necessary. A quick > > > >> experiment with > > > >>> Ethereal and my browser seems to indicate that HTTP GET > > requests > > > >>> to different servers are not spaced 50 ms apart. > > > >>> > > > >>> My questions to the group are: > > > >>> > > > >>> 1) Does anyone have any empirical data regarding the speed at > > > >>> which new mapping/filtering entries can be created on > > various devices? > > > >>> > > > >>> 2) What is your opinion w.r.t. this 50 ms spacing? Is it > > > >>> necessary for existing devices, and will it continue to be > > > >>> necessary for BEHAVE-NAT-UDP compliant devices? > > > >>> > > > >>> Thanks! > > > >>> > > > >>> Eric Cooper. > > > >>> > > > >>> _______________________________________________ > > > >>> Ietf-behave mailing list > > > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > >> _______________________________________________ > > > >> Ietf-behave mailing list > > > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > >> > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From bstucker@nortel.com Mon, 4 Sep 2006 20:38:07 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) From: "Brian Stucker" Date: Mon, 4 Sep 2006 20:38:07 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB02398DE8@xmb-sjc-236.amer.cisco.com> Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371103C3A59@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain The recommendation does not imply a binary decision, just that it has impacts on the behavior of protocols designed explicitly to help manage NAT interactions (ie. STUN) over short periods of time. I'm assuming a happy medium can be reached as has been brokered on other NAT related behaviors. If someone's pounding you with STUN packets every 5ms for 6 minutes, their packets deserve to be sent to /dev/null. If someone happens to hit you with 3 o 4 STUN packets every 20ms for 100ms, that's probably not an attack. My point, is that volumetric controls on rate limiting absent context are going to run the risk of breaking benign applications. Unless some parameters on what's acceptible are agreed upon it will be impossible to verify that the protocol works beyond ancedotal evidence. The only way I see to improve upon this would be to documenting the assumptions that are made about the behavior of a given NAT with respect to dropping messages, and to put that assumption/recommendation somewhere that a NAT designer will see it that couldn't give a hoot about STUN. Regards, Brian > -----Original Message----- > From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@xxxxxxxxx] > Sent: Monday, September 04, 2006 8:13 PM > To: Stucker, Brian (RICH1:B620); Pyda Srisuresh; Cullen > Jennings (fluffy) > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > > Do you mean it is not acceptable to have per-source rate > limiting? If so, why? Cisco IOS NAT supports various types of > rate-limiting including per-source. One of the main reasons > to have to support per-source rate limiting was because of > virus affected end stations that could potentially fill up > the NAT table and eventually causing it to crash.. > > Senthil > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Brian > > Stucker > > Sent: Monday, September 04, 2006 9:06 PM > > To: Pyda Srisuresh; Cullen Jennings (fluffy) > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > > Can a recommendation be made somewhere to codify that > assumption going > > forward (ie. so nobody thinks it's safe to assume the > latter approach > > is acceptable)? > > > > Regards, > > Brian > > > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > Sent: Monday, September 04, 2006 8:04 PM > > > To: Cullen Jennings; Stucker, Brian (RICH1:B620) > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > > > > I agree with Cullen's comment below. Binding entry creation is > > > resource constrained at a global level, not ona per-source basis, > > > AFAIK. > > > > > > cheers, > > > suresh > > > > > > --- Cullen Jennings wrote: > > > > > > > > > > > I looked at some code for a residential NAT and an high end > > > > enterprise. I strongly suspect that there was no per > > source address > > > > rate limiting code but instead just limits on when the > > CPU got too > > > > busy in general. I may have gotten this all wrong, staring > > > at a bunch > > > > of NAT code that you did not write is a mind numbing process. > > > > > > > > > > > > On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: > > > > > > > > > Random thought, > > > > > > > > > > Does anyone know if the speed of NATs creating new > > bindings being > > > > > limited due to dropping occurs in aggregate, or is it > > > limited only > > > > > to requests coming in from a single source address? > > > > > > > > > > If it's a problem in aggregate (meaning it'll drop new > > > bindings if > > > > > the overall rate is too high) that might not bode well > > for large > > > > > numbers of clients using STUN for connectivity checks > > behind some > > > > > NATs. > > > > > > > > > > Regards, > > > > > Brian > > > > > > > > > >> -----Original Message----- > > > > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > Behalf Of > > > > >> Cullen Jennings > > > > >> Sent: Tuesday, August 22, 2006 7:12 PM > > > > >> To: Eric Cooper > > > > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > >> Subject: Re: [Ietf-behave] Time to add > > mapping/filtering entries > > > > >> > > > > >> > > > > >> My test program that classifies NATs runs a bunch of > tests in > > > > >> parallel. If you run the stun packets with no gap, it > > is clear > > > > >> that many NATs just lose some of the state they should > > > be storing > > > > >> even though they forwarded the packet. When I gap by 10 > > > ms, most > > > > >> NATs seem to work and I don't think I have anything that > > > fails if I > > > > >> am at 20 ms but it is hard to test. > > > > >> There are reports that my test program fails on some > > > NATs with 50ms > > > > >> gaps but I have not been able to replicate this. > > > > >> > > > > >> I have not investigated if you can burst a small number > > > -- such as > > > > >> with HTTP traffic -- and have it work well all the > > time. All my > > > > >> testing has been with UDP not TCP. > > > > >> > > > > >> If people want to play with this, the software is the > > > open source > > > > >> stuff at vovida.org. > > > > >> > > > > >> > > > > >> > > > > >> On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: > > > > >> > > > > >>> Hi All, > > > > >>> > > > > >>> I've recently been looking into 'Internet Connectivity > > > > >> Establishment' > > > > >>> (ICE), which contains some statements indicating that > > > some NAT/FW > > > > >>> devices may be overwhelmed if they need to create a > > > bunch of new > > > > >>> mapping and/or filtering entries in a short amount of time. > > > > >>> > > > > >>> Specific to ICE, 'a bunch' is somewhere on the order of > > > > >> 5-25 per ICE > > > > >>> endpoint. ICE indicates that endpoints should rate limit > > > > >> packets such > > > > >>> that packets which would likely create new mapping and/ or > > > > >> filtering > > > > >>> entries are spaced 50 ms apart. > > > > >>> > > > > >>> I wonder if this spacing is really necessary. A quick > > > > >> experiment with > > > > >>> Ethereal and my browser seems to indicate that HTTP GET > > > requests > > > > >>> to different servers are not spaced 50 ms apart. > > > > >>> > > > > >>> My questions to the group are: > > > > >>> > > > > >>> 1) Does anyone have any empirical data regarding > the speed at > > > > >>> which new mapping/filtering entries can be created on > > > various devices? > > > > >>> > > > > >>> 2) What is your opinion w.r.t. this 50 ms spacing? Is it > > > > >>> necessary for existing devices, and will it continue to be > > > > >>> necessary for BEHAVE-NAT-UDP compliant devices? > > > > >>> > > > > >>> Thanks! > > > > >>> > > > > >>> Eric Cooper. > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Ietf-behave mailing list > > > > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > >> _______________________________________________ > > > > >> Ietf-behave mailing list > > > > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > >> > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > From ssenthil@cisco.com Tue, 5 Sep 2006 08:56:23 -0500 (CDT) (envelope-from ssenthil@cisco.com) From: "Senthil Sivakumar \(ssenthil\)" Date: Tue, 5 Sep 2006 08:56:23 -0500 (CDT) (envelope-from ssenthil@cisco.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB02398E77@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Brian Stucker [mailto:bstucker@xxxxxxxxxx] > Sent: Monday, September 04, 2006 9:38 PM > To: Senthil Sivakumar (ssenthil); Pyda Srisuresh; Cullen > Jennings (fluffy) > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > > The recommendation does not imply a binary decision, just > that it has impacts on the behavior of protocols designed > explicitly to help manage NAT interactions (ie. STUN) over > short periods of time. > > I'm assuming a happy medium can be reached as has been > brokered on other NAT related behaviors. > > If someone's pounding you with STUN packets every 5ms for 6 > minutes, their packets deserve to be sent to /dev/null. If > someone happens to hit you with 3 o 4 STUN packets every 20ms > for 100ms, that's probably not an attack. > > My point, is that volumetric controls on rate limiting absent > context are going to run the risk of breaking benign > applications. Unless some parameters on what's acceptible are > agreed upon it will be impossible to verify that the protocol > works beyond ancedotal evidence. It is true that volumetric controls can be bad, but it is upto the admin to determine what is the acceptable level in his/her network. Also, different applications have different characteristics and a NAT controlling it by some hard coded means isn't a great solution. However, if this is a configurable option for the admin to specify the rules for rate limiting, then it provides enough tools and controls for the admin. I think we could make a generic requirement statement that "NATs should not do any rate limiting unless explicitly configured to do so." Thanks Senthil > > The only way I see to improve upon this would be to > documenting the assumptions that are made about the behavior > of a given NAT with respect to dropping messages, and to put > that assumption/recommendation somewhere that a NAT designer > will see it that couldn't give a hoot about STUN. > > Regards, > Brian > > > -----Original Message----- > > From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@xxxxxxxxx] > > Sent: Monday, September 04, 2006 8:13 PM > > To: Stucker, Brian (RICH1:B620); Pyda Srisuresh; Cullen Jennings > > (fluffy) > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > > > > Do you mean it is not acceptable to have per-source rate > limiting? If > > so, why? Cisco IOS NAT supports various types of rate-limiting > > including per-source. One of the main reasons to have to support > > per-source rate limiting was because of virus affected end stations > > that could potentially fill up the NAT table and eventually > causing it > > to crash.. > > > > Senthil > > > > > -----Original Message----- > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > Behalf Of Brian > > > Stucker > > > Sent: Monday, September 04, 2006 9:06 PM > > > To: Pyda Srisuresh; Cullen Jennings (fluffy) > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > > > > Can a recommendation be made somewhere to codify that > > assumption going > > > forward (ie. so nobody thinks it's safe to assume the > > latter approach > > > is acceptable)? > > > > > > Regards, > > > Brian > > > > > > > -----Original Message----- > > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > > Sent: Monday, September 04, 2006 8:04 PM > > > > To: Cullen Jennings; Stucker, Brian (RICH1:B620) > > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > > > > > > I agree with Cullen's comment below. Binding entry creation is > > > > resource constrained at a global level, not ona > per-source basis, > > > > AFAIK. > > > > > > > > cheers, > > > > suresh > > > > > > > > --- Cullen Jennings wrote: > > > > > > > > > > > > > > I looked at some code for a residential NAT and an high end > > > > > enterprise. I strongly suspect that there was no per > > > source address > > > > > rate limiting code but instead just limits on when the > > > CPU got too > > > > > busy in general. I may have gotten this all wrong, staring > > > > at a bunch > > > > > of NAT code that you did not write is a mind numbing process. > > > > > > > > > > > > > > > On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: > > > > > > > > > > > Random thought, > > > > > > > > > > > > Does anyone know if the speed of NATs creating new > > > bindings being > > > > > > limited due to dropping occurs in aggregate, or is it > > > > limited only > > > > > > to requests coming in from a single source address? > > > > > > > > > > > > If it's a problem in aggregate (meaning it'll drop new > > > > bindings if > > > > > > the overall rate is too high) that might not bode well > > > for large > > > > > > numbers of clients using STUN for connectivity checks > > > behind some > > > > > > NATs. > > > > > > > > > > > > Regards, > > > > > > Brian > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > > Behalf Of > > > > > >> Cullen Jennings > > > > > >> Sent: Tuesday, August 22, 2006 7:12 PM > > > > > >> To: Eric Cooper > > > > > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > >> Subject: Re: [Ietf-behave] Time to add > > > mapping/filtering entries > > > > > >> > > > > > >> > > > > > >> My test program that classifies NATs runs a bunch of > > tests in > > > > > >> parallel. If you run the stun packets with no gap, it > > > is clear > > > > > >> that many NATs just lose some of the state they should > > > > be storing > > > > > >> even though they forwarded the packet. When I gap by 10 > > > > ms, most > > > > > >> NATs seem to work and I don't think I have anything that > > > > fails if I > > > > > >> am at 20 ms but it is hard to test. > > > > > >> There are reports that my test program fails on some > > > > NATs with 50ms > > > > > >> gaps but I have not been able to replicate this. > > > > > >> > > > > > >> I have not investigated if you can burst a small number > > > > -- such as > > > > > >> with HTTP traffic -- and have it work well all the > > > time. All my > > > > > >> testing has been with UDP not TCP. > > > > > >> > > > > > >> If people want to play with this, the software is the > > > > open source > > > > > >> stuff at vovida.org. > > > > > >> > > > > > >> > > > > > >> > > > > > >> On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: > > > > > >> > > > > > >>> Hi All, > > > > > >>> > > > > > >>> I've recently been looking into 'Internet Connectivity > > > > > >> Establishment' > > > > > >>> (ICE), which contains some statements indicating that > > > > some NAT/FW > > > > > >>> devices may be overwhelmed if they need to create a > > > > bunch of new > > > > > >>> mapping and/or filtering entries in a short > amount of time. > > > > > >>> > > > > > >>> Specific to ICE, 'a bunch' is somewhere on the order of > > > > > >> 5-25 per ICE > > > > > >>> endpoint. ICE indicates that endpoints should rate limit > > > > > >> packets such > > > > > >>> that packets which would likely create new mapping and/ or > > > > > >> filtering > > > > > >>> entries are spaced 50 ms apart. > > > > > >>> > > > > > >>> I wonder if this spacing is really necessary. A quick > > > > > >> experiment with > > > > > >>> Ethereal and my browser seems to indicate that HTTP GET > > > > requests > > > > > >>> to different servers are not spaced 50 ms apart. > > > > > >>> > > > > > >>> My questions to the group are: > > > > > >>> > > > > > >>> 1) Does anyone have any empirical data regarding > > the speed at > > > > > >>> which new mapping/filtering entries can be created on > > > > various devices? > > > > > >>> > > > > > >>> 2) What is your opinion w.r.t. this 50 ms spacing? Is it > > > > > >>> necessary for existing devices, and will it > continue to be > > > > > >>> necessary for BEHAVE-NAT-UDP compliant devices? > > > > > >>> > > > > > >>> Thanks! > > > > > >>> > > > > > >>> Eric Cooper. > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> Ietf-behave mailing list > > > > > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > >> _______________________________________________ > > > > > >> Ietf-behave mailing list > > > > > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > >> > > > > > _______________________________________________ > > > > > Ietf-behave mailing list > > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > From kbiswas@cisco.com Tue, 5 Sep 2006 15:48:38 -0500 (CDT) (envelope-from kbiswas@cisco.com) From: "Kaushik Biswas \(kbiswas\)" Date: Tue, 5 Sep 2006 15:48:38 -0500 (CDT) (envelope-from kbiswas@cisco.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries Message-ID: <378E78E5F361564BB066432F6415764B0247AFA2@xmb-sjc-228.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > I think we could make a generic requirement statement that > "NATs should not do any rate limiting unless explicitly > configured to do so." This might be difficult for vendors to adhere to, since rate limiting might get done not only for virus-protection (which are mostly config driven like per-host rate-limiting,etc) but also might happen due to each vendor's internal memory-management schemes amongst others. If someone is pounding you with STUN packets every 5ms for 6 minutes, that might be okay on a particular vendor (say vendor A) as that's how their memory-management scheme might be, but might not be ok with another vendor (say vendor B). And actually vendor A might be quoting that in their performance-results and telling why they are better over vendor B. Now one shouldn't be putting in some statement which makes vendor B not complaint just because its CPU/memory-management scheme may not be fast enough. IMO, it is good to highlight this issue, as was found in Cullen's tests that certain NATs can handle traffic-rate better than others, but we should stop short of a recommendation in this regard. Thanks, Kaushik > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Senthil Sivakumar (ssenthil) > Sent: Tuesday, September 05, 2006 6:56 AM > To: Brian Stucker; Pyda Srisuresh; Cullen Jennings (fluffy) > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > > > -----Original Message----- > > From: Brian Stucker [mailto:bstucker@xxxxxxxxxx] > > Sent: Monday, September 04, 2006 9:38 PM > > To: Senthil Sivakumar (ssenthil); Pyda Srisuresh; Cullen Jennings > > (fluffy) > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > > > > The recommendation does not imply a binary decision, just > that it has > > impacts on the behavior of protocols designed explicitly to help > > manage NAT interactions (ie. STUN) over short periods of time. > > > > I'm assuming a happy medium can be reached as has been brokered on > > other NAT related behaviors. > > > > If someone's pounding you with STUN packets every 5ms for 6 > minutes, > > their packets deserve to be sent to /dev/null. If someone > happens to > > hit you with 3 o 4 STUN packets every 20ms for 100ms, > that's probably > > not an attack. > > > > My point, is that volumetric controls on rate limiting > absent context > > are going to run the risk of breaking benign applications. > Unless some > > parameters on what's acceptible are agreed upon it will be > impossible > > to verify that the protocol works beyond ancedotal evidence. > > It is true that volumetric controls can be bad, but it is > upto the admin to determine what is the acceptable level in > his/her network. Also, different applications have different > characteristics and a NAT controlling it by some hard coded > means isn't a great solution. However, if this is a > configurable option for the admin to specify the rules for > rate limiting, then it provides enough tools and controls for > the admin. > I think we could make a generic requirement statement that > "NATs should not do any rate limiting unless explicitly > configured to do so." > > Thanks > Senthil > > > > > The only way I see to improve upon this would be to documenting the > > assumptions that are made about the behavior of a given NAT with > > respect to dropping messages, and to put that > > assumption/recommendation somewhere that a NAT designer will see it > > that couldn't give a hoot about STUN. > > > > Regards, > > Brian > > > > > -----Original Message----- > > > From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@xxxxxxxxx] > > > Sent: Monday, September 04, 2006 8:13 PM > > > To: Stucker, Brian (RICH1:B620); Pyda Srisuresh; Cullen Jennings > > > (fluffy) > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > > > > > > Do you mean it is not acceptable to have per-source rate > > limiting? If > > > so, why? Cisco IOS NAT supports various types of rate-limiting > > > including per-source. One of the main reasons to have to support > > > per-source rate limiting was because of virus affected > end stations > > > that could potentially fill up the NAT table and eventually > > causing it > > > to crash.. > > > > > > Senthil > > > > > > > -----Original Message----- > > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > > Behalf Of Brian > > > > Stucker > > > > Sent: Monday, September 04, 2006 9:06 PM > > > > To: Pyda Srisuresh; Cullen Jennings (fluffy) > > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > > > > > > Can a recommendation be made somewhere to codify that > > > assumption going > > > > forward (ie. so nobody thinks it's safe to assume the > > > latter approach > > > > is acceptable)? > > > > > > > > Regards, > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > > > > Sent: Monday, September 04, 2006 8:04 PM > > > > > To: Cullen Jennings; Stucker, Brian (RICH1:B620) > > > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > Subject: Re: [Ietf-behave] Time to add > mapping/filtering entries > > > > > > > > > > I agree with Cullen's comment below. Binding entry > creation is > > > > > resource constrained at a global level, not ona > > per-source basis, > > > > > AFAIK. > > > > > > > > > > cheers, > > > > > suresh > > > > > > > > > > --- Cullen Jennings wrote: > > > > > > > > > > > > > > > > > I looked at some code for a residential NAT and an high end > > > > > > enterprise. I strongly suspect that there was no per > > > > source address > > > > > > rate limiting code but instead just limits on when the > > > > CPU got too > > > > > > busy in general. I may have gotten this all wrong, staring > > > > > at a bunch > > > > > > of NAT code that you did not write is a mind > numbing process. > > > > > > > > > > > > > > > > > > On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: > > > > > > > > > > > > > Random thought, > > > > > > > > > > > > > > Does anyone know if the speed of NATs creating new > > > > bindings being > > > > > > > limited due to dropping occurs in aggregate, or is it > > > > > limited only > > > > > > > to requests coming in from a single source address? > > > > > > > > > > > > > > If it's a problem in aggregate (meaning it'll drop new > > > > > bindings if > > > > > > > the overall rate is too high) that might not bode well > > > > for large > > > > > > > numbers of clients using STUN for connectivity checks > > > > behind some > > > > > > > NATs. > > > > > > > > > > > > > > Regards, > > > > > > > Brian > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > > > > > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > > > Behalf Of > > > > > > >> Cullen Jennings > > > > > > >> Sent: Tuesday, August 22, 2006 7:12 PM > > > > > > >> To: Eric Cooper > > > > > > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > >> Subject: Re: [Ietf-behave] Time to add > > > > mapping/filtering entries > > > > > > >> > > > > > > >> > > > > > > >> My test program that classifies NATs runs a bunch of > > > tests in > > > > > > >> parallel. If you run the stun packets with no gap, it > > > > is clear > > > > > > >> that many NATs just lose some of the state they should > > > > > be storing > > > > > > >> even though they forwarded the packet. When I gap by 10 > > > > > ms, most > > > > > > >> NATs seem to work and I don't think I have anything that > > > > > fails if I > > > > > > >> am at 20 ms but it is hard to test. > > > > > > >> There are reports that my test program fails on some > > > > > NATs with 50ms > > > > > > >> gaps but I have not been able to replicate this. > > > > > > >> > > > > > > >> I have not investigated if you can burst a small number > > > > > -- such as > > > > > > >> with HTTP traffic -- and have it work well all the > > > > time. All my > > > > > > >> testing has been with UDP not TCP. > > > > > > >> > > > > > > >> If people want to play with this, the software is the > > > > > open source > > > > > > >> stuff at vovida.org. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: > > > > > > >> > > > > > > >>> Hi All, > > > > > > >>> > > > > > > >>> I've recently been looking into 'Internet Connectivity > > > > > > >> Establishment' > > > > > > >>> (ICE), which contains some statements indicating that > > > > > some NAT/FW > > > > > > >>> devices may be overwhelmed if they need to create a > > > > > bunch of new > > > > > > >>> mapping and/or filtering entries in a short > > amount of time. > > > > > > >>> > > > > > > >>> Specific to ICE, 'a bunch' is somewhere on the order of > > > > > > >> 5-25 per ICE > > > > > > >>> endpoint. ICE indicates that endpoints should > rate limit > > > > > > >> packets such > > > > > > >>> that packets which would likely create new > mapping and/ or > > > > > > >> filtering > > > > > > >>> entries are spaced 50 ms apart. > > > > > > >>> > > > > > > >>> I wonder if this spacing is really necessary. A quick > > > > > > >> experiment with > > > > > > >>> Ethereal and my browser seems to indicate that HTTP GET > > > > > requests > > > > > > >>> to different servers are not spaced 50 ms apart. > > > > > > >>> > > > > > > >>> My questions to the group are: > > > > > > >>> > > > > > > >>> 1) Does anyone have any empirical data regarding > > > the speed at > > > > > > >>> which new mapping/filtering entries can be created on > > > > > various devices? > > > > > > >>> > > > > > > >>> 2) What is your opinion w.r.t. this 50 ms > spacing? Is it > > > > > > >>> necessary for existing devices, and will it > > continue to be > > > > > > >>> necessary for BEHAVE-NAT-UDP compliant devices? > > > > > > >>> > > > > > > >>> Thanks! > > > > > > >>> > > > > > > >>> Eric Cooper. > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> Ietf-behave mailing list > > > > > > >>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > >>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > >> _______________________________________________ > > > > > > >> Ietf-behave mailing list > > > > > > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > >> > > > > > > _______________________________________________ > > > > > > Ietf-behave mailing list > > > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From dbarrett@quinthar.com Tue, 5 Sep 2006 17:18:30 -0500 (CDT) (envelope-from dbarrett@quinthar.com) From: "David Barrett" Date: Tue, 5 Sep 2006 17:18:30 -0500 (CDT) (envelope-from dbarrett@quinthar.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: <378E78E5F361564BB066432F6415764B0247AFA2@xmb-sjc-228.amer.cisco.com> Message-ID: <200609052218.k85MIQSR082223@lambda.sipfoundry.org> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Kaushik Biswas (kbiswas) > > > I think we could make a generic requirement statement that > > "NATs should not do any rate limiting unless explicitly > > configured to do so." > > ... > > Now one shouldn't be putting in some statement which makes vendor B not > complaint just because its CPU/memory-management scheme may not be fast > enough. IMO, it is good to highlight this issue, as was found in > Cullen's tests that certain NATs can handle traffic-rate better than > others, but we should stop short of a recommendation in this regard. (Been silent for a bit but speaking up as I'm working with precisely this issue right now) I agree we shouldn't make a device non-compliant due to having insufficient resources to handle a particular volume of NAT bindings (CPU, memory, etc). But I agree with Senthil that we should recommend against NATs rate-limiting new bindings that they could otherwise handle, unless explicitly configured to do so. (Incidentally, I'd count virus software and other automated reconfigurations as "explicitly configured" for the sake of this argument.) -david From kbiswas@cisco.com Tue, 5 Sep 2006 17:57:38 -0500 (CDT) (envelope-from kbiswas@cisco.com) From: "Kaushik Biswas \(kbiswas\)" Date: Tue, 5 Sep 2006 17:57:38 -0500 (CDT) (envelope-from kbiswas@cisco.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries Message-ID: <378E78E5F361564BB066432F6415764B0247B0B9@xmb-sjc-228.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Agreed, one can recommend that rate-limit on per-user,etc shouldn't be done by default and only by config, but my concern is more to do with traffic-rate. Since from the initial discussion, looks like that was a concern - that is if the traffic-rate or delay is such and such, then certain NATs were ok and certain were not. This is where putting a recommendation may not be right. Thanks, Kaushik > -----Original Message----- > From: David Barrett [mailto:dbarrett@xxxxxxxxxxxx] > Sent: Tuesday, September 05, 2006 3:18 PM > To: Kaushik Biswas (kbiswas); Senthil Sivakumar (ssenthil); > 'Brian Stucker'; 'Pyda Srisuresh'; Cullen Jennings (fluffy) > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > > > -----Original Message----- > > From: Kaushik Biswas (kbiswas) > > > > > I think we could make a generic requirement statement that "NATs > > > should not do any rate limiting unless explicitly > configured to do > > > so." > > > > ... > > > > Now one shouldn't be putting in some statement which makes vendor B > > not complaint just because its CPU/memory-management scheme > may not be > > fast enough. IMO, it is good to highlight this issue, as > was found in > > Cullen's tests that certain NATs can handle traffic-rate > better than > > others, but we should stop short of a recommendation in this regard. > > (Been silent for a bit but speaking up as I'm working with > precisely this issue right now) > > I agree we shouldn't make a device non-compliant due to > having insufficient resources to handle a particular volume > of NAT bindings (CPU, memory, etc). > But I agree with Senthil that we should recommend against > NATs rate-limiting new bindings that they could otherwise > handle, unless explicitly configured to do so. > > (Incidentally, I'd count virus software and other automated > reconfigurations as "explicitly configured" for the sake of > this argument.) > > -david > From fluffy@cisco.com Tue, 5 Sep 2006 18:09:20 -0500 (CDT) (envelope-from fluffy@cisco.com) From: Cullen Jennings Date: Tue, 5 Sep 2006 18:09:20 -0500 (CDT) (envelope-from fluffy@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <13bd01c6cd62$165b0230$c3f0200a@amer.cisco.com> Message-ID: <397CCDC9-1658-4632-87B3-E0CD01927380@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Just as a comment watching this thread ... I will note that the PWE work allows an unlimited amount of bandwidth, has no backoff, is not TCP rate friendly, can be expected over all sorts of IP networks but most importantly for the discussion here ... did not seem to have issues with this in IETF LC and was approved by IESG. For the most part, it does not seem like there are practical ways for a client to estimate it's RTT without doing something more or less like STUN. So we could say that it should be configurable and that the default should be some value. Back of the envelope looks like ICE won't work if we set the default to 3 seconds. I seem to recall that we spent a long time on this argument when we did the STUN RFC. If we were going to redo that conversation, I would want us to have some good logic on why this was a problem worth solving. It may be that we need to scope where STUN is used to be places where this STUN induced portion of the congestion problem would be a drop in the bucket compared to the RTP over UDP problem. Cullen (with my individual hat on) On Sep 2, 2006, at 6:43 PM, Jonathan Rosenberg wrote: I must say I don't really like the idea too much of having to adjust the STUN transaction timers on a usage-by-usage basis. Certainly for SIP we have not advocated different timers for SIP transactions for INVITE vs. SUBSCRIBE, though the two of them both have quite different requirements around latency. I think it makes more sense to try to tune these as a function of RTT. Lars suggested: clients SHOULD retransmit the request starting with an interval off f(RTT), or Y seconds if the RTT is unknown." TCP uses 3 seconds for Y per RFC1122; see RFC2988 for f(). We'll then get into the issue about whether 3s is a reasonable RTT assumption in any network where we're using STUN. I will note that any network with a 3s RTT is going to stink for voip... -Jonathan R. Dan Wing wrote: RFC3489bis authors & everyone, As rfc3489bis co-author: Based on your thread and Brian's recent thread ("Time to add mapping/filtering entries"), I thought about rfc3489bis and ICE's interaction with it. ICE makes two significant uses of STUN that are interesting to BEHAVE. The first is the 'classic STUN' usage ("Binding Discovery" in -behave-rfc3489bis) -- learn your public IP address and UDP port. To avoid the problem Cullen described (where NATs seem to 'forget' to create bindings) those binding discovery STUN packets to the STUN server (s) need to be paced. The second interesting ICE usage is its connectivity checks ("Connectivity Check" in -behave-rfc3489bis). ICE's connectivity checks don't need to be paced to be gentle for the same reason, because ICE's connectivity checks don't create new NAT bindings (pedantic readers know that there are some exceptional configurations where ICE's connectivity checks do create a new NAT binding). Rather, ICE's connectivity checks only using existing bindings and change the NAT's filtering (if the NAT does do filtering). I suggest -behave-rfc3489bis should break out the retransmission rules into per-usage recommendations. Of the usages defined in -behave-rfc3489bis, 1. Binding Discovery 2. Connectivity Check 3. NAT Keepalives 4. Short-Term Password here are some thoughts on retransmit timers: 1. Binding Discovery: it doesn't harm interoperability if one STUN client uses 100ms and another STUN client uses 2000ms. It harms call setup time, of course, but presumably the clients were configured with those retransmit timers on purpose -- someone knew the network was fast (100ms) or the network was slow but had very little loss (2000ms). After the first STUN check, the retransmission timer could be adjusted. Note that for ICE, you do a STUN check for your RTP and for your RTCP port separately for each media stream. So if you're doing audio and video you will send 4 STUN packets from 4 different local ports, paced 50ms apart (to avoid the problem Cullen described). If you receive a STUN response for the first one in 20ms you know the RTT and processing time of the STUN server is 20ms. We use that knowledge to our advantage in determining the retransmission timer for the other 3 outstanding STUN transactions. Each of them should come back 20ms after we sent their request. If we don't see the response in 20ms, and we wanted to be aggressive, we could send another request in max(RTT,50ms). 2. Connectivity check: connectivity checks don't occur until you know the peer's IP address and codecs. That provides enough information about the expected bandwidth that ICE can stay below that bandwidth while performing its connectivity checks. 3. NAT Keepavlies: the initial RTT used by TCP SYNs seems reasonable (WinXP seems to wait 2 seconds, for whatever that's worth. RFC2988 seems to recommend a value less than 3 seconds). From there, the RTT of previous successful NAT keepalives can be useful to adjust the retransmit value of subsequent NAT keepalives. 4. Short-Term Password: This is usually the same server as (1), so apply the same rules as (1). -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Tue, 5 Sep 2006 18:32:52 -0500 (CDT) (envelope-from fluffy@cisco.com) From: Cullen Jennings Date: Tue, 5 Sep 2006 18:32:52 -0500 (CDT) (envelope-from fluffy@cisco.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB02398E77@xmb-sjc-236.amer.cisco.com> Message-ID: <1D63FE97-E3FB-498F-A8AA-2784A0AF9ADD@cisco.com> MIME-Version: 1.0 Content-Type: text/plain What folks are saying on this thread makes sense to me. I think that rate limiting is definitely falling into the firewall behavior type space. We tried to keep this out of scope for behave because it is such a large set of problems to try and tackle. On Sep 5, 2006, at 6:56 AM, Senthil Sivakumar ((ssenthil)) wrote: -----Original Message----- From: Brian Stucker [mailto:bstucker@xxxxxxxxxx] Sent: Monday, September 04, 2006 9:38 PM To: Senthil Sivakumar (ssenthil); Pyda Srisuresh; Cullen Jennings (fluffy) Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] Time to add mapping/filtering entries The recommendation does not imply a binary decision, just that it has impacts on the behavior of protocols designed explicitly to help manage NAT interactions (ie. STUN) over short periods of time. I'm assuming a happy medium can be reached as has been brokered on other NAT related behaviors. If someone's pounding you with STUN packets every 5ms for 6 minutes, their packets deserve to be sent to /dev/null. If someone happens to hit you with 3 o 4 STUN packets every 20ms for 100ms, that's probably not an attack. My point, is that volumetric controls on rate limiting absent context are going to run the risk of breaking benign applications. Unless some parameters on what's acceptible are agreed upon it will be impossible to verify that the protocol works beyond ancedotal evidence. It is true that volumetric controls can be bad, but it is upto the admin to determine what is the acceptable level in his/her network. Also, different applications have different characteristics and a NAT controlling it by some hard coded means isn't a great solution. However, if this is a configurable option for the admin to specify the rules for rate limiting, then it provides enough tools and controls for the admin. I think we could make a generic requirement statement that "NATs should not do any rate limiting unless explicitly configured to do so." Thanks Senthil The only way I see to improve upon this would be to documenting the assumptions that are made about the behavior of a given NAT with respect to dropping messages, and to put that assumption/recommendation somewhere that a NAT designer will see it that couldn't give a hoot about STUN. Regards, Brian -----Original Message----- From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@xxxxxxxxx] Sent: Monday, September 04, 2006 8:13 PM To: Stucker, Brian (RICH1:B620); Pyda Srisuresh; Cullen Jennings (fluffy) Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] Time to add mapping/filtering entries Do you mean it is not acceptable to have per-source rate limiting? If so, why? Cisco IOS NAT supports various types of rate-limiting including per-source. One of the main reasons to have to support per-source rate limiting was because of virus affected end stations that could potentially fill up the NAT table and eventually causing it to crash.. Senthil -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Brian Stucker Sent: Monday, September 04, 2006 9:06 PM To: Pyda Srisuresh; Cullen Jennings (fluffy) Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] Time to add mapping/filtering entries Can a recommendation be made somewhere to codify that assumption going forward (ie. so nobody thinks it's safe to assume the latter approach is acceptable)? Regards, Brian -----Original Message----- From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] Sent: Monday, September 04, 2006 8:04 PM To: Cullen Jennings; Stucker, Brian (RICH1:B620) Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] Time to add mapping/filtering entries I agree with Cullen's comment below. Binding entry creation is resource constrained at a global level, not ona per-source basis, AFAIK. cheers, suresh --- Cullen Jennings wrote: I looked at some code for a residential NAT and an high end enterprise. I strongly suspect that there was no per source address rate limiting code but instead just limits on when the CPU got too busy in general. I may have gotten this all wrong, staring at a bunch of NAT code that you did not write is a mind numbing process. On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: Random thought, Does anyone know if the speed of NATs creating new bindings being limited due to dropping occurs in aggregate, or is it limited only to requests coming in from a single source address? If it's a problem in aggregate (meaning it'll drop new bindings if the overall rate is too high) that might not bode well for large numbers of clients using STUN for connectivity checks behind some NATs. Regards, Brian -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Cullen Jennings Sent: Tuesday, August 22, 2006 7:12 PM To: Eric Cooper Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] Time to add mapping/filtering entries My test program that classifies NATs runs a bunch of tests in parallel. If you run the stun packets with no gap, it is clear that many NATs just lose some of the state they should be storing even though they forwarded the packet. When I gap by 10 ms, most NATs seem to work and I don't think I have anything that fails if I am at 20 ms but it is hard to test. There are reports that my test program fails on some NATs with 50ms gaps but I have not been able to replicate this. I have not investigated if you can burst a small number -- such as with HTTP traffic -- and have it work well all the time. All my testing has been with UDP not TCP. If people want to play with this, the software is the open source stuff at vovida.org. On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: Hi All, I've recently been looking into 'Internet Connectivity Establishment' (ICE), which contains some statements indicating that some NAT/FW devices may be overwhelmed if they need to create a bunch of new mapping and/or filtering entries in a short amount of time. Specific to ICE, 'a bunch' is somewhere on the order of 5-25 per ICE endpoint. ICE indicates that endpoints should rate limit packets such that packets which would likely create new mapping and/ or filtering entries are spaced 50 ms apart. I wonder if this spacing is really necessary. A quick experiment with Ethereal and my browser seems to indicate that HTTP GET requests to different servers are not spaced 50 ms apart. My questions to the group are: 1) Does anyone have any empirical data regarding the speed at which new mapping/filtering entries can be created on various devices? 2) What is your opinion w.r.t. this 50 ms spacing? Is it necessary for existing devices, and will it continue to be necessary for BEHAVE-NAT-UDP compliant devices? Thanks! Eric Cooper. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From bstucker@nortel.com Wed, 6 Sep 2006 00:44:19 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) From: "Brian Stucker" Date: Wed, 6 Sep 2006 00:44:19 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: <1D63FE97-E3FB-498F-A8AA-2784A0AF9ADD@cisco.com> Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711046442F@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain So, In relation to rate limiting behavior of a NAT, do we need to say: A. Nothing. B. Mention possible problems, but give no recommendations to NAT desigers/administrators about what to do about it. C. Mention possible problems, and give recommended guidelines for dealing with it (simple formulas or minimal expected behavior). To me, A is not a real option because this thread has generated enough interest that it's obviously worth debating, so it's probably worth mentioning (also, nobody has claimed that a potential problem does not exist). It's been argued below that it can be left up to configuration which may be true in many contexts. However, configuration variables need a default value. STUN should work with any out-of-the-box NAT that is BEHAVE compliant. This means that although configuration could be used it should not be required to make STUN work. Finally, not all NATs are designed to allow administrators the opportunity to tweak every possible variable into the NAT's behavior. Therefore, configuration may not be possible (and we still want a reasonable degree of certainty that STUN will work properly if the NAT is BEHAVE compliant). So, in the interest of leaving the guesswork out of the process, but not tying the hands of the administrator, I'd vote for C. Regards, Brian > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Tuesday, September 05, 2006 6:33 PM > To: Senthil Sivakumar ((ssenthil)) > Cc: Stucker, Brian (RICH1:B620); Pyda Srisuresh; > ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > What folks are saying on this thread makes sense to me. I > think that rate limiting is definitely falling into the > firewall behavior type space. We tried to keep this out of > scope for behave because it is such a large set of problems > to try and tackle. > > > On Sep 5, 2006, at 6:56 AM, Senthil Sivakumar ((ssenthil)) wrote: > > > > > > >> -----Original Message----- > >> From: Brian Stucker [mailto:bstucker@xxxxxxxxxx] > >> Sent: Monday, September 04, 2006 9:38 PM > >> To: Senthil Sivakumar (ssenthil); Pyda Srisuresh; Cullen Jennings > >> (fluffy) > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >> Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > >> > >> The recommendation does not imply a binary decision, just > that it has > >> impacts on the behavior of protocols designed explicitly to help > >> manage NAT interactions (ie. STUN) over short periods of time. > >> > >> I'm assuming a happy medium can be reached as has been brokered on > >> other NAT related behaviors. > >> > >> If someone's pounding you with STUN packets every 5ms for > 6 minutes, > >> their packets deserve to be sent to /dev/null. If someone > happens to > >> hit you with 3 o 4 STUN packets every 20ms for 100ms, > that's probably > >> not an attack. > >> > >> My point, is that volumetric controls on rate limiting > absent context > >> are going to run the risk of breaking benign applications. Unless > >> some parameters on what's acceptible are agreed upon it will be > >> impossible to verify that the protocol works beyond ancedotal > >> evidence. > > > > It is true that volumetric controls can be bad, but it is upto the > > admin to determine what is the acceptable level in his/her network. > > Also, different applications have different characteristics > and a NAT > > controlling it by some hard coded means isn't a great solution. > > However, > > if this is a configurable option for the admin to specify the rules > > for rate limiting, then it provides enough tools and > controls for the > > admin. > > I think we could make a generic requirement statement that "NATs > > should not do any rate limiting unless explicitly configured to do > > so." > > > > Thanks > > Senthil > > > >> > >> The only way I see to improve upon this would be to > >> documenting the assumptions that are made about the behavior > >> of a given NAT with respect to dropping messages, and to put > >> that assumption/recommendation somewhere that a NAT designer > >> will see it that couldn't give a hoot about STUN. > >> > >> Regards, > >> Brian > >> > >>> -----Original Message----- > >>> From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@xxxxxxxxx] > >>> Sent: Monday, September 04, 2006 8:13 PM > >>> To: Stucker, Brian (RICH1:B620); Pyda Srisuresh; Cullen Jennings > >>> (fluffy) > >>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > >>> > >>> Do you mean it is not acceptable to have per-source rate > >> limiting? If > >>> so, why? Cisco IOS NAT supports various types of rate-limiting > >>> including per-source. One of the main reasons to have to support > >>> per-source rate limiting was because of virus affected > end stations > >>> that could potentially fill up the NAT table and eventually > >> causing it > >>> to crash.. > >>> > >>> Senthil > >>> > >>>> -----Original Message----- > >>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > >> Behalf Of Brian > >>>> Stucker > >>>> Sent: Monday, September 04, 2006 9:06 PM > >>>> To: Pyda Srisuresh; Cullen Jennings (fluffy) > >>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>> Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > >>>> > >>>> Can a recommendation be made somewhere to codify that > >>> assumption going > >>>> forward (ie. so nobody thinks it's safe to assume the > >>> latter approach > >>>> is acceptable)? > >>>> > >>>> Regards, > >>>> Brian > >>>> > >>>>> -----Original Message----- > >>>>> From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > >>>>> Sent: Monday, September 04, 2006 8:04 PM > >>>>> To: Cullen Jennings; Stucker, Brian (RICH1:B620) > >>>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>> Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > >>>>> > >>>>> I agree with Cullen's comment below. Binding entry creation is > >>>>> resource constrained at a global level, not ona > >> per-source basis, > >>>>> AFAIK. > >>>>> > >>>>> cheers, > >>>>> suresh > >>>>> > >>>>> --- Cullen Jennings wrote: > >>>>> > >>>>>> > >>>>>> I looked at some code for a residential NAT and an high end > >>>>>> enterprise. I strongly suspect that there was no per > >>>> source address > >>>>>> rate limiting code but instead just limits on when the > >>>> CPU got too > >>>>>> busy in general. I may have gotten this all wrong, staring > >>>>> at a bunch > >>>>>> of NAT code that you did not write is a mind numbing process. > >>>>>> > >>>>>> > >>>>>> On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: > >>>>>> > >>>>>>> Random thought, > >>>>>>> > >>>>>>> Does anyone know if the speed of NATs creating new > >>>> bindings being > >>>>>>> limited due to dropping occurs in aggregate, or is it > >>>>> limited only > >>>>>>> to requests coming in from a single source address? > >>>>>>> > >>>>>>> If it's a problem in aggregate (meaning it'll drop new > >>>>> bindings if > >>>>>>> the overall rate is too high) that might not bode well > >>>> for large > >>>>>>> numbers of clients using STUN for connectivity checks > >>>> behind some > >>>>>>> NATs. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Brian > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>>>>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > >>> Behalf Of > >>>>>>>> Cullen Jennings > >>>>>>>> Sent: Tuesday, August 22, 2006 7:12 PM > >>>>>>>> To: Eric Cooper > >>>>>>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>>>> Subject: Re: [Ietf-behave] Time to add > >>>> mapping/filtering entries > >>>>>>>> > >>>>>>>> > >>>>>>>> My test program that classifies NATs runs a bunch of > >>> tests in > >>>>>>>> parallel. If you run the stun packets with no gap, it > >>>> is clear > >>>>>>>> that many NATs just lose some of the state they should > >>>>> be storing > >>>>>>>> even though they forwarded the packet. When I gap by 10 > >>>>> ms, most > >>>>>>>> NATs seem to work and I don't think I have anything that > >>>>> fails if I > >>>>>>>> am at 20 ms but it is hard to test. > >>>>>>>> There are reports that my test program fails on some > >>>>> NATs with 50ms > >>>>>>>> gaps but I have not been able to replicate this. > >>>>>>>> > >>>>>>>> I have not investigated if you can burst a small number > >>>>> -- such as > >>>>>>>> with HTTP traffic -- and have it work well all the > >>>> time. All my > >>>>>>>> testing has been with UDP not TCP. > >>>>>>>> > >>>>>>>> If people want to play with this, the software is the > >>>>> open source > >>>>>>>> stuff at vovida.org. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: > >>>>>>>> > >>>>>>>>> Hi All, > >>>>>>>>> > >>>>>>>>> I've recently been looking into 'Internet Connectivity > >>>>>>>> Establishment' > >>>>>>>>> (ICE), which contains some statements indicating that > >>>>> some NAT/FW > >>>>>>>>> devices may be overwhelmed if they need to create a > >>>>> bunch of new > >>>>>>>>> mapping and/or filtering entries in a short > >> amount of time. > >>>>>>>>> > >>>>>>>>> Specific to ICE, 'a bunch' is somewhere on the order of > >>>>>>>> 5-25 per ICE > >>>>>>>>> endpoint. ICE indicates that endpoints should rate limit > >>>>>>>> packets such > >>>>>>>>> that packets which would likely create new mapping and/ or > >>>>>>>> filtering > >>>>>>>>> entries are spaced 50 ms apart. > >>>>>>>>> > >>>>>>>>> I wonder if this spacing is really necessary. A quick > >>>>>>>> experiment with > >>>>>>>>> Ethereal and my browser seems to indicate that HTTP GET > >>>>> requests > >>>>>>>>> to different servers are not spaced 50 ms apart. > >>>>>>>>> > >>>>>>>>> My questions to the group are: > >>>>>>>>> > >>>>>>>>> 1) Does anyone have any empirical data regarding > >>> the speed at > >>>>>>>>> which new mapping/filtering entries can be created on > >>>>> various devices? > >>>>>>>>> > >>>>>>>>> 2) What is your opinion w.r.t. this 50 ms spacing? Is it > >>>>>>>>> necessary for existing devices, and will it > >> continue to be > >>>>>>>>> necessary for BEHAVE-NAT-UDP compliant devices? > >>>>>>>>> > >>>>>>>>> Thanks! > >>>>>>>>> > >>>>>>>>> Eric Cooper. > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Ietf-behave mailing list > >>>>>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>>>>>> _______________________________________________ > >>>>>>>> Ietf-behave mailing list > >>>>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>>>>>> > >>>>>> _______________________________________________ > >>>>>> Ietf-behave mailing list > >>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Ietf-behave mailing list > >>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>> > >>> > >> > From tomi.kohonen@nokia.com Wed, 6 Sep 2006 00:51:39 -0500 (CDT) (envelope-from tomi.kohonen@nokia.com) From: Date: Wed, 6 Sep 2006 00:51:39 -0500 (CDT) (envelope-from tomi.kohonen@nokia.com) Subject: Re: [Ietf-behave] STUN Server Discovery In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi, Since nobody seems to have anything to say to these issues, I'll now add my solution proposals for these problems here. Hopefully this will trigger some discussion. 1) DNS SRV Query: Since the RFC3489 had a different interpretation of the protocol part in "_stun._tcp.example.com" (meaning TLS, instead of TCP), I suggest that RFC3489bis would specify a new service, namely "stun-bind". This service would solely be the STUN binding query service as specified in RFC3489(bis). Now, if a client supports both the new and old specification versions, it can first try the new service names "stun-pass" and "stun-bind". If these do not give results, the client can try the old ones. RFC3489: _stun._tcp.example.com Shared secret service with TLS _stun._udp.example.com Binding query service with UDP RFC3489bis: _stun-pass._tls.example.com Shared secret service with TLS _stun-bind._udp.example.com Binding query service with UDP _stun-bind._tcp.example.com Binding query service with TCP _stun-bind._tls.example.com Binding query service with TLS 2) Default STUN ports: For the default port assignment, I'd say that the RFC3489 ports should be preserved. If we need new default ports, those should not conflict with the old ones. So, the default ports could be like this: RFC3489: -Shared secret service with TLS: 3478 -Binding query service with UDP: 3478 RFC3489bis: -Binding query service with TCP: ? Kind regards, Tomi Kohonen >-----Original Message----- >From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] >Sent: 04 September, 2006 14:40 >To: ietf-behave@xxxxxxxxxxxxxxxxxxx >Subject: [Ietf-behave] STUN Server Discovery > > >Hi, > >There seems to be a new non backwards compatible STUN server >discovery process in RFC3489bis >(draft-ietf-behave-rfc3489bis-04). I'd hereby like to initiate >a discussion on this issue. > >As I've understood, the RFC3489 specifies the services like this (in >9.1): >_stun._tcp.example.com Shared secret service with TLS (*) >_stun._udp.example.com Binding query service with UDP > >...and RFC3489bis like follows (in 8.1): >_stun-pass._tls.example.com Shared secret service with TLS (*) >_stun._tcp.example.com Binding query service with TCP (*) >_stun._udp.example.com Binding query service with UDP >_stun._tls.example.com Binding query service with TLS > >As can be seen, the shared secret service and binding query >service via TCP have conflicting service queries (marked with '*'). >If (and when) a client want's to implement support for both >RFC3489 and RFC3489bis, this becomes a clear problem. > >What I'd like to see is that the RFC3489bis would be changed >to specify the discovery process in a way which would not >conflict with the RFC3489 specification. Backwards >compatibility here would be beneficial for both the STUN >clients and servers. > >Second issue regarding the STUN services, is that I'd like to >see consistent default ports for all of the (relevant) STUN >services (like >RFC3489 has). The same kind of a conflict is visible also here: > >RFC3489: >-Shared secret service with TLS: 3478 >-Binding query service with UDP: 3478 > >RFC3489bis: >-Shared secret service with TLS: (none) >-Binding query service with UDP: 3478 >-Binding query service with TCP: 3478 > >Having default ports (and of course consistent ones) would >enable implementation of clients which have only STUN server >address configured (i.e. no STUN domain). This would be >userful in situations where the >(server/network) setup is static, and thus constant DNS SRV >queries would be unnecessary. Here the ports would have to be >configured, just because there are no default ports. > >-- >Tomi > > >_______________________________________________ >Ietf-behave mailing list >Ietf-behave@xxxxxxxxxxxxxxxxxxx >https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From dbarrett@quinthar.com Wed, 6 Sep 2006 01:07:16 -0500 (CDT) (envelope-from dbarrett@quinthar.com) From: "David Barrett" Date: Wed, 6 Sep 2006 01:07:16 -0500 (CDT) (envelope-from dbarrett@quinthar.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711046442F@zrc2hxm2.corp.nortel.com> Message-ID: <200609060607.k8667CVF012217@lambda.sipfoundry.org> MIME-Version: 1.0 Content-Type: text/plain I concur. Option C seems best. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave- > bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Brian Stucker > Sent: Tuesday, September 05, 2006 10:44 PM > To: Cullen Jennings; Senthil Sivakumar ((ssenthil)) > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > So, > > In relation to rate limiting behavior of a NAT, do we need to say: > > A. Nothing. > B. Mention possible problems, but give no recommendations to NAT > desigers/administrators about what to do about it. > C. Mention possible problems, and give recommended guidelines for > dealing with it (simple formulas or minimal expected behavior). > > To me, A is not a real option because this thread has generated enough > interest that it's obviously worth debating, so it's probably worth > mentioning (also, nobody has claimed that a potential problem does not > exist). > > It's been argued below that it can be left up to configuration which may > be true in many contexts. However, configuration variables need a > default value. STUN should work with any out-of-the-box NAT that is > BEHAVE compliant. This means that although configuration could be used > it should not be required to make STUN work. > > Finally, not all NATs are designed to allow administrators the > opportunity to tweak every possible variable into the NAT's behavior. > Therefore, configuration may not be possible (and we still want a > reasonable degree of certainty that STUN will work properly if the NAT > is BEHAVE compliant). > > So, in the interest of leaving the guesswork out of the process, but not > tying the hands of the administrator, I'd vote for C. > > Regards, > Brian > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > > Sent: Tuesday, September 05, 2006 6:33 PM > > To: Senthil Sivakumar ((ssenthil)) > > Cc: Stucker, Brian (RICH1:B620); Pyda Srisuresh; > > ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > > > > What folks are saying on this thread makes sense to me. I > > think that rate limiting is definitely falling into the > > firewall behavior type space. We tried to keep this out of > > scope for behave because it is such a large set of problems > > to try and tackle. > > > > > > On Sep 5, 2006, at 6:56 AM, Senthil Sivakumar ((ssenthil)) wrote: > > > > > > > > > > >> -----Original Message----- > > >> From: Brian Stucker [mailto:bstucker@xxxxxxxxxx] > > >> Sent: Monday, September 04, 2006 9:38 PM > > >> To: Senthil Sivakumar (ssenthil); Pyda Srisuresh; Cullen Jennings > > >> (fluffy) > > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > >> Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > > >> > > >> The recommendation does not imply a binary decision, just > > that it has > > >> impacts on the behavior of protocols designed explicitly to help > > >> manage NAT interactions (ie. STUN) over short periods of time. > > >> > > >> I'm assuming a happy medium can be reached as has been brokered on > > >> other NAT related behaviors. > > >> > > >> If someone's pounding you with STUN packets every 5ms for > > 6 minutes, > > >> their packets deserve to be sent to /dev/null. If someone > > happens to > > >> hit you with 3 o 4 STUN packets every 20ms for 100ms, > > that's probably > > >> not an attack. > > >> > > >> My point, is that volumetric controls on rate limiting > > absent context > > >> are going to run the risk of breaking benign applications. Unless > > >> some parameters on what's acceptible are agreed upon it will be > > >> impossible to verify that the protocol works beyond ancedotal > > >> evidence. > > > > > > It is true that volumetric controls can be bad, but it is upto the > > > admin to determine what is the acceptable level in his/her network. > > > Also, different applications have different characteristics > > and a NAT > > > controlling it by some hard coded means isn't a great solution. > > > However, > > > if this is a configurable option for the admin to specify the rules > > > for rate limiting, then it provides enough tools and > > controls for the > > > admin. > > > I think we could make a generic requirement statement that "NATs > > > should not do any rate limiting unless explicitly configured to do > > > so." > > > > > > Thanks > > > Senthil > > > > > >> > > >> The only way I see to improve upon this would be to > > >> documenting the assumptions that are made about the behavior > > >> of a given NAT with respect to dropping messages, and to put > > >> that assumption/recommendation somewhere that a NAT designer > > >> will see it that couldn't give a hoot about STUN. > > >> > > >> Regards, > > >> Brian > > >> > > >>> -----Original Message----- > > >>> From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@xxxxxxxxx] > > >>> Sent: Monday, September 04, 2006 8:13 PM > > >>> To: Stucker, Brian (RICH1:B620); Pyda Srisuresh; Cullen Jennings > > >>> (fluffy) > > >>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > >>> Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > > >>> > > >>> Do you mean it is not acceptable to have per-source rate > > >> limiting? If > > >>> so, why? Cisco IOS NAT supports various types of rate-limiting > > >>> including per-source. One of the main reasons to have to support > > >>> per-source rate limiting was because of virus affected > > end stations > > >>> that could potentially fill up the NAT table and eventually > > >> causing it > > >>> to crash.. > > >>> > > >>> Senthil > > >>> > > >>>> -----Original Message----- > > >>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > >>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > > >> Behalf Of Brian > > >>>> Stucker > > >>>> Sent: Monday, September 04, 2006 9:06 PM > > >>>> To: Pyda Srisuresh; Cullen Jennings (fluffy) > > >>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > >>>> Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > >>>> > > >>>> Can a recommendation be made somewhere to codify that > > >>> assumption going > > >>>> forward (ie. so nobody thinks it's safe to assume the > > >>> latter approach > > >>>> is acceptable)? > > >>>> > > >>>> Regards, > > >>>> Brian > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > > >>>>> Sent: Monday, September 04, 2006 8:04 PM > > >>>>> To: Cullen Jennings; Stucker, Brian (RICH1:B620) > > >>>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > >>>>> Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > >>>>> > > >>>>> I agree with Cullen's comment below. Binding entry creation is > > >>>>> resource constrained at a global level, not ona > > >> per-source basis, > > >>>>> AFAIK. > > >>>>> > > >>>>> cheers, > > >>>>> suresh > > >>>>> > > >>>>> --- Cullen Jennings wrote: > > >>>>> > > >>>>>> > > >>>>>> I looked at some code for a residential NAT and an high end > > >>>>>> enterprise. I strongly suspect that there was no per > > >>>> source address > > >>>>>> rate limiting code but instead just limits on when the > > >>>> CPU got too > > >>>>>> busy in general. I may have gotten this all wrong, staring > > >>>>> at a bunch > > >>>>>> of NAT code that you did not write is a mind numbing process. > > >>>>>> > > >>>>>> > > >>>>>> On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: > > >>>>>> > > >>>>>>> Random thought, > > >>>>>>> > > >>>>>>> Does anyone know if the speed of NATs creating new > > >>>> bindings being > > >>>>>>> limited due to dropping occurs in aggregate, or is it > > >>>>> limited only > > >>>>>>> to requests coming in from a single source address? > > >>>>>>> > > >>>>>>> If it's a problem in aggregate (meaning it'll drop new > > >>>>> bindings if > > >>>>>>> the overall rate is too high) that might not bode well > > >>>> for large > > >>>>>>> numbers of clients using STUN for connectivity checks > > >>>> behind some > > >>>>>>> NATs. > > >>>>>>> > > >>>>>>> Regards, > > >>>>>>> Brian > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > >>>>>>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > > >>> Behalf Of > > >>>>>>>> Cullen Jennings > > >>>>>>>> Sent: Tuesday, August 22, 2006 7:12 PM > > >>>>>>>> To: Eric Cooper > > >>>>>>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > > >>>>>>>> Subject: Re: [Ietf-behave] Time to add > > >>>> mapping/filtering entries > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> My test program that classifies NATs runs a bunch of > > >>> tests in > > >>>>>>>> parallel. If you run the stun packets with no gap, it > > >>>> is clear > > >>>>>>>> that many NATs just lose some of the state they should > > >>>>> be storing > > >>>>>>>> even though they forwarded the packet. When I gap by 10 > > >>>>> ms, most > > >>>>>>>> NATs seem to work and I don't think I have anything that > > >>>>> fails if I > > >>>>>>>> am at 20 ms but it is hard to test. > > >>>>>>>> There are reports that my test program fails on some > > >>>>> NATs with 50ms > > >>>>>>>> gaps but I have not been able to replicate this. > > >>>>>>>> > > >>>>>>>> I have not investigated if you can burst a small number > > >>>>> -- such as > > >>>>>>>> with HTTP traffic -- and have it work well all the > > >>>> time. All my > > >>>>>>>> testing has been with UDP not TCP. > > >>>>>>>> > > >>>>>>>> If people want to play with this, the software is the > > >>>>> open source > > >>>>>>>> stuff at vovida.org. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: > > >>>>>>>> > > >>>>>>>>> Hi All, > > >>>>>>>>> > > >>>>>>>>> I've recently been looking into 'Internet Connectivity > > >>>>>>>> Establishment' > > >>>>>>>>> (ICE), which contains some statements indicating that > > >>>>> some NAT/FW > > >>>>>>>>> devices may be overwhelmed if they need to create a > > >>>>> bunch of new > > >>>>>>>>> mapping and/or filtering entries in a short > > >> amount of time. > > >>>>>>>>> > > >>>>>>>>> Specific to ICE, 'a bunch' is somewhere on the order of > > >>>>>>>> 5-25 per ICE > > >>>>>>>>> endpoint. ICE indicates that endpoints should rate limit > > >>>>>>>> packets such > > >>>>>>>>> that packets which would likely create new mapping and/ or > > >>>>>>>> filtering > > >>>>>>>>> entries are spaced 50 ms apart. > > >>>>>>>>> > > >>>>>>>>> I wonder if this spacing is really necessary. A quick > > >>>>>>>> experiment with > > >>>>>>>>> Ethereal and my browser seems to indicate that HTTP GET > > >>>>> requests > > >>>>>>>>> to different servers are not spaced 50 ms apart. > > >>>>>>>>> > > >>>>>>>>> My questions to the group are: > > >>>>>>>>> > > >>>>>>>>> 1) Does anyone have any empirical data regarding > > >>> the speed at > > >>>>>>>>> which new mapping/filtering entries can be created on > > >>>>> various devices? > > >>>>>>>>> > > >>>>>>>>> 2) What is your opinion w.r.t. this 50 ms spacing? Is it > > >>>>>>>>> necessary for existing devices, and will it > > >> continue to be > > >>>>>>>>> necessary for BEHAVE-NAT-UDP compliant devices? > > >>>>>>>>> > > >>>>>>>>> Thanks! > > >>>>>>>>> > > >>>>>>>>> Eric Cooper. > > >>>>>>>>> > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> Ietf-behave mailing list > > >>>>>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > >>>>>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > >>>>>>>> _______________________________________________ > > >>>>>>>> Ietf-behave mailing list > > >>>>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > >>>>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > >>>>>>>> > > >>>>>> _______________________________________________ > > >>>>>> Ietf-behave mailing list > > >>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > >>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > >>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Ietf-behave mailing list > > >>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > > >>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > >>>> > > >>> > > >> > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From lars.eggert@netlab.nec.de Wed, 6 Sep 2006 03:56:48 -0500 (CDT) (envelope-from lars.eggert@netlab.nec.de) From: Lars Eggert Date: Wed, 6 Sep 2006 03:56:48 -0500 (CDT) (envelope-from lars.eggert@netlab.nec.de) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <13bd01c6cd62$165b0230$c3f0200a@amer.cisco.com> Message-ID: <756131CC-807A-484F-BB7C-EDCC15714D66@netlab.nec.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630137.multipart/signed" --Boundary..27398.1163630137.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sep 6, 2006, at 1:09, Cullen Jennings wrote: I will note that the PWE work allows an unlimited amount of bandwidth, has no backoff, is not TCP rate friendly, can be expected over all sorts of IP networks but most importantly for the discussion here ... did not seem to have issues with this in IETF LC and was approved by IESG. Actually, these issues were discussed and PWE3 will work on a common congestion control mechanism for their pseudowires, such that they can be used over best-effort networks. The current drafts say that people SHOULD really only run them over provisioned paths for that reason. Also, the deployment cases for pseudowires are different than for STUN/ICE, which I'd expect to run over much more diverse paths. In any event, I'm confident that we can come up with a retransmission scheme that will support ICE and not be too aggressive. One idea is that a sender can detect when it has sent a spurious retransmission, because it will receive some sort of acknowledgment from the receiver for message it has already retransmitted. In such a case, it could back off the retransmission timer a bit. This would allow STUN to start with a short timer that would lengthen when used over long- delay paths. Lars -- Lars Eggert NEC Network Laboratories Attachment: smime.p7s --Boundary..27398.1163630137.multipart/signed Content-Type: application/octet-stream; name="p7sHEc7xqHoNQ.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p7sHEc7xqHoNQ.p7s" Content-Description: "Description: S/MIME cryptographic signature" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwOTA2 MDg1NjM4WjAjBgkqhkiG9w0BCQQxFgQUwhxccmj/IGcYAACf8RhmYHWIjYkwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAHca7sgnojTRdyx8s6ih IUn1kcDOrry+ERBe1l/E2PA8B2PrfjSKuBSpyQbauZ1+n5uatwno3VRl46h0Rk/r0+v+N7BQTK+w +7CMZkZzaSg7NVQhGeTSi0ynFtAul2eyzTTNPOJ1M/osYd/DJY5tTniCmz6SV12IqYQjelmy6xEU V1u+d/t5KuUACXKMvLpfpLthmtV6fuKEnqE9iKTEKp4JBAn+6/YOT7eGElctH5mSzMF40wv2WUxC TbjqO27+gFxzzgXbELk1EAOs3G+7D3IasuapjtXIb+F6Xy9mRFkR4JZlCw0JE2CQKHgAxXsLsiWE KgMhT06Sa+JHlS8gIiIAAAAAAAA= --Boundary..27398.1163630137.multipart/signed-- From fluffy@cisco.com Wed, 6 Sep 2006 11:27:41 -0500 (CDT) (envelope-from fluffy@cisco.com) From: Cullen Jennings Date: Wed, 6 Sep 2006 11:27:41 -0500 (CDT) (envelope-from fluffy@cisco.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: <54dkuc$9pok17@sj-inbound-b.cisco.com> Message-ID: <2F4BD0F2-3D77-46C4-B580-AA87364A92DB@cisco.com> MIME-Version: 1.0 Content-Type: text/plain We tried on some of this long ago and it was a complete failure to get people to agree on anything remotely resembling minimum performance criteria for NATs. Everyone agreed it would be nice if we could agree on something but every time someone put a number on the table people had many reasons why that number could not possibly work for them. On Sep 5, 2006, at 11:07 PM, David Barrett wrote: I concur. Option C seems best. -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave- bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Brian Stucker Sent: Tuesday, September 05, 2006 10:44 PM To: Cullen Jennings; Senthil Sivakumar ((ssenthil)) Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] Time to add mapping/filtering entries So, In relation to rate limiting behavior of a NAT, do we need to say: A. Nothing. B. Mention possible problems, but give no recommendations to NAT desigers/administrators about what to do about it. C. Mention possible problems, and give recommended guidelines for dealing with it (simple formulas or minimal expected behavior). To me, A is not a real option because this thread has generated enough interest that it's obviously worth debating, so it's probably worth mentioning (also, nobody has claimed that a potential problem does not exist). It's been argued below that it can be left up to configuration which may be true in many contexts. However, configuration variables need a default value. STUN should work with any out-of-the-box NAT that is BEHAVE compliant. This means that although configuration could be used it should not be required to make STUN work. Finally, not all NATs are designed to allow administrators the opportunity to tweak every possible variable into the NAT's behavior. Therefore, configuration may not be possible (and we still want a reasonable degree of certainty that STUN will work properly if the NAT is BEHAVE compliant). So, in the interest of leaving the guesswork out of the process, but not tying the hands of the administrator, I'd vote for C. Regards, Brian -----Original Message----- From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] Sent: Tuesday, September 05, 2006 6:33 PM To: Senthil Sivakumar ((ssenthil)) Cc: Stucker, Brian (RICH1:B620); Pyda Srisuresh; ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] Time to add mapping/filtering entries What folks are saying on this thread makes sense to me. I think that rate limiting is definitely falling into the firewall behavior type space. We tried to keep this out of scope for behave because it is such a large set of problems to try and tackle. On Sep 5, 2006, at 6:56 AM, Senthil Sivakumar ((ssenthil)) wrote: -----Original Message----- From: Brian Stucker [mailto:bstucker@xxxxxxxxxx] Sent: Monday, September 04, 2006 9:38 PM To: Senthil Sivakumar (ssenthil); Pyda Srisuresh; Cullen Jennings (fluffy) Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] Time to add mapping/filtering entries The recommendation does not imply a binary decision, just that it has impacts on the behavior of protocols designed explicitly to help manage NAT interactions (ie. STUN) over short periods of time. I'm assuming a happy medium can be reached as has been brokered on other NAT related behaviors. If someone's pounding you with STUN packets every 5ms for 6 minutes, their packets deserve to be sent to /dev/null. If someone happens to hit you with 3 o 4 STUN packets every 20ms for 100ms, that's probably not an attack. My point, is that volumetric controls on rate limiting absent context are going to run the risk of breaking benign applications. Unless some parameters on what's acceptible are agreed upon it will be impossible to verify that the protocol works beyond ancedotal evidence. It is true that volumetric controls can be bad, but it is upto the admin to determine what is the acceptable level in his/her network. Also, different applications have different characteristics and a NAT controlling it by some hard coded means isn't a great solution. However, if this is a configurable option for the admin to specify the rules for rate limiting, then it provides enough tools and controls for the admin. I think we could make a generic requirement statement that "NATs should not do any rate limiting unless explicitly configured to do so." Thanks Senthil The only way I see to improve upon this would be to documenting the assumptions that are made about the behavior of a given NAT with respect to dropping messages, and to put that assumption/recommendation somewhere that a NAT designer will see it that couldn't give a hoot about STUN. Regards, Brian -----Original Message----- From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@xxxxxxxxx] Sent: Monday, September 04, 2006 8:13 PM To: Stucker, Brian (RICH1:B620); Pyda Srisuresh; Cullen Jennings (fluffy) Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] Time to add mapping/filtering entries Do you mean it is not acceptable to have per-source rate limiting? If so, why? Cisco IOS NAT supports various types of rate-limiting including per-source. One of the main reasons to have to support per-source rate limiting was because of virus affected end stations that could potentially fill up the NAT table and eventually causing it to crash.. Senthil -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Brian Stucker Sent: Monday, September 04, 2006 9:06 PM To: Pyda Srisuresh; Cullen Jennings (fluffy) Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] Time to add mapping/filtering entries Can a recommendation be made somewhere to codify that assumption going forward (ie. so nobody thinks it's safe to assume the latter approach is acceptable)? Regards, Brian -----Original Message----- From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] Sent: Monday, September 04, 2006 8:04 PM To: Cullen Jennings; Stucker, Brian (RICH1:B620) Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] Time to add mapping/filtering entries I agree with Cullen's comment below. Binding entry creation is resource constrained at a global level, not ona per-source basis, AFAIK. cheers, suresh --- Cullen Jennings wrote: I looked at some code for a residential NAT and an high end enterprise. I strongly suspect that there was no per source address rate limiting code but instead just limits on when the CPU got too busy in general. I may have gotten this all wrong, staring at a bunch of NAT code that you did not write is a mind numbing process. On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: Random thought, Does anyone know if the speed of NATs creating new bindings being limited due to dropping occurs in aggregate, or is it limited only to requests coming in from a single source address? If it's a problem in aggregate (meaning it'll drop new bindings if the overall rate is too high) that might not bode well for large numbers of clients using STUN for connectivity checks behind some NATs. Regards, Brian -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Cullen Jennings Sent: Tuesday, August 22, 2006 7:12 PM To: Eric Cooper Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] Time to add mapping/filtering entries My test program that classifies NATs runs a bunch of tests in parallel. If you run the stun packets with no gap, it is clear that many NATs just lose some of the state they should be storing even though they forwarded the packet. When I gap by 10 ms, most NATs seem to work and I don't think I have anything that fails if I am at 20 ms but it is hard to test. There are reports that my test program fails on some NATs with 50ms gaps but I have not been able to replicate this. I have not investigated if you can burst a small number -- such as with HTTP traffic -- and have it work well all the time. All my testing has been with UDP not TCP. If people want to play with this, the software is the open source stuff at vovida.org. On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: Hi All, I've recently been looking into 'Internet Connectivity Establishment' (ICE), which contains some statements indicating that some NAT/FW devices may be overwhelmed if they need to create a bunch of new mapping and/or filtering entries in a short amount of time. Specific to ICE, 'a bunch' is somewhere on the order of 5-25 per ICE endpoint. ICE indicates that endpoints should rate limit packets such that packets which would likely create new mapping and/ or filtering entries are spaced 50 ms apart. I wonder if this spacing is really necessary. A quick experiment with Ethereal and my browser seems to indicate that HTTP GET requests to different servers are not spaced 50 ms apart. My questions to the group are: 1) Does anyone have any empirical data regarding the speed at which new mapping/filtering entries can be created on various devices? 2) What is your opinion w.r.t. this 50 ms spacing? Is it necessary for existing devices, and will it continue to be necessary for BEHAVE-NAT-UDP compliant devices? Thanks! Eric Cooper. _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dbarrett@quinthar.com Wed, 6 Sep 2006 14:47:00 -0500 (CDT) (envelope-from dbarrett@quinthar.com) From: "David Barrett" Date: Wed, 6 Sep 2006 14:47:00 -0500 (CDT) (envelope-from dbarrett@quinthar.com) Subject: Re: [Ietf-behave] Time to add mapping/filtering entries In-Reply-To: <2F4BD0F2-3D77-46C4-B580-AA87364A92DB@cisco.com> Message-ID: <200609061947.k86Jkux9051771@lambda.sipfoundry.org> MIME-Version: 1.0 Content-Type: text/plain I agree with you there. I'm merely suggestion we recommend NAT's be configured by default to not explicitly filter NAT mappings based on criteria other than resource constraints. Whether your device supports 1 or 1M NAT bindings per second doesn't matter. Rather, we recommend that number should be as high as you can conceivably make it by default, with rate-limited NAT binding being an optional (non-default) feature. -david > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > Sent: Wednesday, September 06, 2006 9:27 AM > To: David Barrett > Cc: 'Brian Stucker'; 'Senthil Sivakumar ((ssenthil))'; ietf- > behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > > > We tried on some of this long ago and it was a complete failure to > get people to agree on anything remotely resembling minimum > performance criteria for NATs. Everyone agreed it would be nice if we > could agree on something but every time someone put a number on the > table people had many reasons why that number could not possibly work > for them. > > > On Sep 5, 2006, at 11:07 PM, David Barrett wrote: > > > I concur. Option C seems best. > > > >> -----Original Message----- > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave- > >> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Brian Stucker > >> Sent: Tuesday, September 05, 2006 10:44 PM > >> To: Cullen Jennings; Senthil Sivakumar ((ssenthil)) > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >> Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > >> > >> So, > >> > >> In relation to rate limiting behavior of a NAT, do we need to say: > >> > >> A. Nothing. > >> B. Mention possible problems, but give no recommendations to NAT > >> desigers/administrators about what to do about it. > >> C. Mention possible problems, and give recommended guidelines for > >> dealing with it (simple formulas or minimal expected behavior). > >> > >> To me, A is not a real option because this thread has generated > >> enough > >> interest that it's obviously worth debating, so it's probably worth > >> mentioning (also, nobody has claimed that a potential problem does > >> not > >> exist). > >> > >> It's been argued below that it can be left up to configuration > >> which may > >> be true in many contexts. However, configuration variables need a > >> default value. STUN should work with any out-of-the-box NAT that is > >> BEHAVE compliant. This means that although configuration could be > >> used > >> it should not be required to make STUN work. > >> > >> Finally, not all NATs are designed to allow administrators the > >> opportunity to tweak every possible variable into the NAT's behavior. > >> Therefore, configuration may not be possible (and we still want a > >> reasonable degree of certainty that STUN will work properly if the > >> NAT > >> is BEHAVE compliant). > >> > >> So, in the interest of leaving the guesswork out of the process, > >> but not > >> tying the hands of the administrator, I'd vote for C. > >> > >> Regards, > >> Brian > >> > >>> -----Original Message----- > >>> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > >>> Sent: Tuesday, September 05, 2006 6:33 PM > >>> To: Senthil Sivakumar ((ssenthil)) > >>> Cc: Stucker, Brian (RICH1:B620); Pyda Srisuresh; > >>> ietf-behave@xxxxxxxxxxxxxxxxxxx > >>> Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > >>> > >>> > >>> What folks are saying on this thread makes sense to me. I > >>> think that rate limiting is definitely falling into the > >>> firewall behavior type space. We tried to keep this out of > >>> scope for behave because it is such a large set of problems > >>> to try and tackle. > >>> > >>> > >>> On Sep 5, 2006, at 6:56 AM, Senthil Sivakumar ((ssenthil)) wrote: > >>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Brian Stucker [mailto:bstucker@xxxxxxxxxx] > >>>>> Sent: Monday, September 04, 2006 9:38 PM > >>>>> To: Senthil Sivakumar (ssenthil); Pyda Srisuresh; Cullen Jennings > >>>>> (fluffy) > >>>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>> Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > >>>>> > >>>>> The recommendation does not imply a binary decision, just > >>> that it has > >>>>> impacts on the behavior of protocols designed explicitly to help > >>>>> manage NAT interactions (ie. STUN) over short periods of time. > >>>>> > >>>>> I'm assuming a happy medium can be reached as has been brokered on > >>>>> other NAT related behaviors. > >>>>> > >>>>> If someone's pounding you with STUN packets every 5ms for > >>> 6 minutes, > >>>>> their packets deserve to be sent to /dev/null. If someone > >>> happens to > >>>>> hit you with 3 o 4 STUN packets every 20ms for 100ms, > >>> that's probably > >>>>> not an attack. > >>>>> > >>>>> My point, is that volumetric controls on rate limiting > >>> absent context > >>>>> are going to run the risk of breaking benign applications. Unless > >>>>> some parameters on what's acceptible are agreed upon it will be > >>>>> impossible to verify that the protocol works beyond ancedotal > >>>>> evidence. > >>>> > >>>> It is true that volumetric controls can be bad, but it is upto the > >>>> admin to determine what is the acceptable level in his/her network. > >>>> Also, different applications have different characteristics > >>> and a NAT > >>>> controlling it by some hard coded means isn't a great solution. > >>>> However, > >>>> if this is a configurable option for the admin to specify the rules > >>>> for rate limiting, then it provides enough tools and > >>> controls for the > >>>> admin. > >>>> I think we could make a generic requirement statement that "NATs > >>>> should not do any rate limiting unless explicitly configured to do > >>>> so." > >>>> > >>>> Thanks > >>>> Senthil > >>>> > >>>>> > >>>>> The only way I see to improve upon this would be to > >>>>> documenting the assumptions that are made about the behavior > >>>>> of a given NAT with respect to dropping messages, and to put > >>>>> that assumption/recommendation somewhere that a NAT designer > >>>>> will see it that couldn't give a hoot about STUN. > >>>>> > >>>>> Regards, > >>>>> Brian > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@xxxxxxxxx] > >>>>>> Sent: Monday, September 04, 2006 8:13 PM > >>>>>> To: Stucker, Brian (RICH1:B620); Pyda Srisuresh; Cullen Jennings > >>>>>> (fluffy) > >>>>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>> Subject: RE: [Ietf-behave] Time to add mapping/filtering entries > >>>>>> > >>>>>> Do you mean it is not acceptable to have per-source rate > >>>>> limiting? If > >>>>>> so, why? Cisco IOS NAT supports various types of rate-limiting > >>>>>> including per-source. One of the main reasons to have to support > >>>>>> per-source rate limiting was because of virus affected > >>> end stations > >>>>>> that could potentially fill up the NAT table and eventually > >>>>> causing it > >>>>>> to crash.. > >>>>>> > >>>>>> Senthil > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>>>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > >>>>> Behalf Of Brian > >>>>>>> Stucker > >>>>>>> Sent: Monday, September 04, 2006 9:06 PM > >>>>>>> To: Pyda Srisuresh; Cullen Jennings (fluffy) > >>>>>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>>> Subject: Re: [Ietf-behave] Time to add mapping/filtering entries > >>>>>>> > >>>>>>> Can a recommendation be made somewhere to codify that > >>>>>> assumption going > >>>>>>> forward (ie. so nobody thinks it's safe to assume the > >>>>>> latter approach > >>>>>>> is acceptable)? > >>>>>>> > >>>>>>> Regards, > >>>>>>> Brian > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] > >>>>>>>> Sent: Monday, September 04, 2006 8:04 PM > >>>>>>>> To: Cullen Jennings; Stucker, Brian (RICH1:B620) > >>>>>>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>>>> Subject: Re: [Ietf-behave] Time to add mapping/filtering > >>>>>>>> entries > >>>>>>>> > >>>>>>>> I agree with Cullen's comment below. Binding entry creation is > >>>>>>>> resource constrained at a global level, not ona > >>>>> per-source basis, > >>>>>>>> AFAIK. > >>>>>>>> > >>>>>>>> cheers, > >>>>>>>> suresh > >>>>>>>> > >>>>>>>> --- Cullen Jennings wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> I looked at some code for a residential NAT and an high end > >>>>>>>>> enterprise. I strongly suspect that there was no per > >>>>>>> source address > >>>>>>>>> rate limiting code but instead just limits on when the > >>>>>>> CPU got too > >>>>>>>>> busy in general. I may have gotten this all wrong, staring > >>>>>>>> at a bunch > >>>>>>>>> of NAT code that you did not write is a mind numbing process. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote: > >>>>>>>>> > >>>>>>>>>> Random thought, > >>>>>>>>>> > >>>>>>>>>> Does anyone know if the speed of NATs creating new > >>>>>>> bindings being > >>>>>>>>>> limited due to dropping occurs in aggregate, or is it > >>>>>>>> limited only > >>>>>>>>>> to requests coming in from a single source address? > >>>>>>>>>> > >>>>>>>>>> If it's a problem in aggregate (meaning it'll drop new > >>>>>>>> bindings if > >>>>>>>>>> the overall rate is too high) that might not bode well > >>>>>>> for large > >>>>>>>>>> numbers of clients using STUN for connectivity checks > >>>>>>> behind some > >>>>>>>>>> NATs. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> Brian > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > >>>>>>>>>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On > >>>>>> Behalf Of > >>>>>>>>>>> Cullen Jennings > >>>>>>>>>>> Sent: Tuesday, August 22, 2006 7:12 PM > >>>>>>>>>>> To: Eric Cooper > >>>>>>>>>>> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>>>>>>> Subject: Re: [Ietf-behave] Time to add > >>>>>>> mapping/filtering entries > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> My test program that classifies NATs runs a bunch of > >>>>>> tests in > >>>>>>>>>>> parallel. If you run the stun packets with no gap, it > >>>>>>> is clear > >>>>>>>>>>> that many NATs just lose some of the state they should > >>>>>>>> be storing > >>>>>>>>>>> even though they forwarded the packet. When I gap by 10 > >>>>>>>> ms, most > >>>>>>>>>>> NATs seem to work and I don't think I have anything that > >>>>>>>> fails if I > >>>>>>>>>>> am at 20 ms but it is hard to test. > >>>>>>>>>>> There are reports that my test program fails on some > >>>>>>>> NATs with 50ms > >>>>>>>>>>> gaps but I have not been able to replicate this. > >>>>>>>>>>> > >>>>>>>>>>> I have not investigated if you can burst a small number > >>>>>>>> -- such as > >>>>>>>>>>> with HTTP traffic -- and have it work well all the > >>>>>>> time. All my > >>>>>>>>>>> testing has been with UDP not TCP. > >>>>>>>>>>> > >>>>>>>>>>> If people want to play with this, the software is the > >>>>>>>> open source > >>>>>>>>>>> stuff at vovida.org. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi All, > >>>>>>>>>>>> > >>>>>>>>>>>> I've recently been looking into 'Internet Connectivity > >>>>>>>>>>> Establishment' > >>>>>>>>>>>> (ICE), which contains some statements indicating that > >>>>>>>> some NAT/FW > >>>>>>>>>>>> devices may be overwhelmed if they need to create a > >>>>>>>> bunch of new > >>>>>>>>>>>> mapping and/or filtering entries in a short > >>>>> amount of time. > >>>>>>>>>>>> > >>>>>>>>>>>> Specific to ICE, 'a bunch' is somewhere on the order of > >>>>>>>>>>> 5-25 per ICE > >>>>>>>>>>>> endpoint. ICE indicates that endpoints should rate limit > >>>>>>>>>>> packets such > >>>>>>>>>>>> that packets which would likely create new mapping and/ or > >>>>>>>>>>> filtering > >>>>>>>>>>>> entries are spaced 50 ms apart. > >>>>>>>>>>>> > >>>>>>>>>>>> I wonder if this spacing is really necessary. A quick > >>>>>>>>>>> experiment with > >>>>>>>>>>>> Ethereal and my browser seems to indicate that HTTP GET > >>>>>>>> requests > >>>>>>>>>>>> to different servers are not spaced 50 ms apart. > >>>>>>>>>>>> > >>>>>>>>>>>> My questions to the group are: > >>>>>>>>>>>> > >>>>>>>>>>>> 1) Does anyone have any empirical data regarding > >>>>>> the speed at > >>>>>>>>>>>> which new mapping/filtering entries can be created on > >>>>>>>> various devices? > >>>>>>>>>>>> > >>>>>>>>>>>> 2) What is your opinion w.r.t. this 50 ms spacing? Is it > >>>>>>>>>>>> necessary for existing devices, and will it > >>>>> continue to be > >>>>>>>>>>>> necessary for BEHAVE-NAT-UDP compliant devices? > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks! > >>>>>>>>>>>> > >>>>>>>>>>>> Eric Cooper. > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> Ietf-behave mailing list > >>>>>>>>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>>>>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Ietf-behave mailing list > >>>>>>>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>>>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Ietf-behave mailing list > >>>>>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ietf-behave mailing list > >>>>>>> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >>>>>>> https://list.sipfoundry.org/mailman/listinfo/ietf-behave > >>>>>>> > >>>>>> > >>>>> > >>> > >> > >> _______________________________________________ > >> Ietf-behave mailing list > >> Ietf-behave@xxxxxxxxxxxxxxxxxxx > >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave From jdrosen@cisco.com Thu, 7 Sep 2006 10:35:18 -0500 (CDT) (envelope-from jdrosen@cisco.com) From: Jonathan Rosenberg Date: Thu, 7 Sep 2006 10:35:18 -0500 (CDT) (envelope-from jdrosen@cisco.com) Subject: Re: [Ietf-behave] STUN Server Discovery In-Reply-To: Message-ID: <45003C2A.6010000@cisco.com> MIME-Version: 1.0 Content-Type: text/plain inline. tomi.kohonen@xxxxxxxxx wrote: Hi, There seems to be a new non backwards compatible STUN server discovery process in RFC3489bis (draft-ietf-behave-rfc3489bis-04). I'd hereby like to initiate a discussion on this issue. As I've understood, the RFC3489 specifies the services like this (in 9.1): _stun._tcp.example.com Shared secret service with TLS (*) _stun._udp.example.com Binding query service with UDP ...and RFC3489bis like follows (in 8.1): _stun-pass._tls.example.com Shared secret service with TLS (*) _stun._tcp.example.com Binding query service with TCP (*) _stun._udp.example.com Binding query service with UDP _stun._tls.example.com Binding query service with TLS As can be seen, the shared secret service and binding query service via TCP have conflicting service queries (marked with '*'). If (and when) a client want's to implement support for both RFC3489 and RFC3489bis, this becomes a clear problem. In theory perhaps. The reality is, AFAIK, the shared secret service with TLS has not been used or deployed to any degree. Thus, I do not believe it is important to retain backwards compatibility with that discovery procedure. Furthermore, since binding query service with TCP was never defined in RFC3489, there isn't a backwards compatibility issue at all. An older client would never try it. A new client trying to contact an old server would find that the service is unavailable (no records for it), which is exactly the right thing since it is in fact unavailable - this is an old server that doesn't support the feature anyway. The most important thing for backwards compatibility is binding discovery for UDP, which is backwards compatible. Another point, if you are going to build a stun client now, you would build an rfc3489bis one. I see no point in doing both. What I'd like to see is that the RFC3489bis would be changed to specify the discovery process in a way which would not conflict with the RFC3489 specification. Backwards compatibility here would be beneficial for both the STUN clients and servers. Second issue regarding the STUN services, is that I'd like to see consistent default ports for all of the (relevant) STUN services (like RFC3489 has). The same kind of a conflict is visible also here: RFC3489: -Shared secret service with TLS: 3478 -Binding query service with UDP: 3478 RFC3489bis: -Shared secret service with TLS: (none) -Binding query service with UDP: 3478 -Binding query service with TCP: 3478 Having default ports (and of course consistent ones) would enable implementation of clients which have only STUN server address configured (i.e. no STUN domain). This would be userful in situations where the (server/network) setup is static, and thus constant DNS SRV queries would be unnecessary. Here the ports would have to be configured, just because there are no default ports. Again, the principle difference here is shared secrets with TLS. I still assert that backwards compatibility for this is not important. There is a separate question on whether or not 3489bis should have a default port for TLS (for any application usage). This port will necessarily be different than 3478. I don't have a very strong feeling on this and would be OK with asking IANA for a port. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From Kai.Vehmanen@nokia.com Fri, 8 Sep 2006 03:34:10 -0500 (CDT) (envelope-from Kai.Vehmanen@nokia.com) From: Date: Fri, 8 Sep 2006 03:34:10 -0500 (CDT) (envelope-from Kai.Vehmanen@nokia.com) Subject: Re: [Ietf-behave] STUN Server Discovery In-Reply-To: <45003C2A.6010000@cisco.com> Message-ID: <719D5CCC2F6E3644B0A9F5C9B1D00088020C31FD@esebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain Hello, On 07 September, 2006 Jonathan Rosenberg wrote: >In theory perhaps. The reality is, AFAIK, the shared secret >service with TLS has not been used or deployed to any degree. >Thus, I do not believe it is important to retain backwards >compatibility with that discovery procedure. I disagree with this one. There are definitely implementations out there, so a good reason is needed for breaking compatibility for these clients. >Furthermore, since binding query service with TCP was never >defined in RFC3489, there isn't a backwards compatibility >issue at all. An older client would never try it. A new client An older client would do a DNS query for "_stun._tcp", which has different semantics in RFC3489 and RFC3489bis. Thus it's a mess if you are upgrading a server from RFC3489 to RFC3489bis. Of course the shared-secret procedure would not work anymore, but the old clients will be able to handle this (as per original 3489). AFAIK there are also no deployments for RFC3489bis which utilize "_stun._tcp" yet, so fixing the bis draft should not be a problem to anyone, and avoids the break with respect to 3489. Of course, it seems difficult to come up with an elegant fix to this ("_stun-bis._tcp" perhaps), but I still think this is a real problem. -- first.surname@xxxxxxxxx (Kai Vehmanen) Networking Technologies Laboratory, Nokia Research Center From pete.cordell@tech-know-ware.com Fri, 8 Sep 2006 03:53:26 -0500 (CDT) (envelope-from pete.cordell@tech-know-ware.com) From: "Pete Cordell" Date: Fri, 8 Sep 2006 03:53:26 -0500 (CDT) (envelope-from pete.cordell@tech-know-ware.com) Subject: Re: [Ietf-behave] STUN Server Discovery In-Reply-To: <719D5CCC2F6E3644B0A9F5C9B1D00088020C31FD@esebe104.NOE.Nokia.com> Message-ID: <005d01c6d324$39e54d10$5000a8c0@RW> MIME-Version: 1.0 Content-Type: text/plain ----- Original Message From: AFAIK there are also no deployments for RFC3489bis which utilize "_stun._tcp" yet, so fixing the bis draft should not be a problem to anyone, and avoids the break with respect to 3489. Of course, it seems difficult to come up with an elegant fix to this ("_stun-bis._tcp" perhaps), but I still think this is a real problem. Entering style police mode... If such an approach is thought to be necessary, something like "_stun2._tcp" would be better, otherwise we might end up with "_stun-bis-bis-bis-bis._tcp"! Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= From tomi.kohonen@nokia.com Mon, 11 Sep 2006 08:25:34 -0500 (CDT) (envelope-from tomi.kohonen@nokia.com) From: Date: Mon, 11 Sep 2006 08:25:34 -0500 (CDT) (envelope-from tomi.kohonen@nokia.com) Subject: Re: [Ietf-behave] STUN Server Discovery In-Reply-To: <719D5CCC2F6E3644B0A9F5C9B1D00088020C31FD@esebe104.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi, >>In theory perhaps. The reality is, AFAIK, the shared secret service >>with TLS has not been used or deployed to any degree. >>Thus, I do not believe it is important to retain backwards >>compatibility with that discovery procedure. > >I disagree with this one. There are definitely implementations >out there, so a good reason is needed for breaking >compatibility for these clients. I still believe we should make sure that there is no conflicts here between RFC3489 and RFC3489bis. If we in any way can make the new RFC3489bis not to conflict here, we should do it. Is there reason why this is not possible? I'd say that adding a new DNS SRV record for the STUN binding request service might be the way to go here. I would not name this with a protocol version (like "stun-bis") but rather the protocol name like "stun-bind", like I wrote earlier. This is consistent with the shared secret service "stun-pass" as seems to be chosen as the naming convention in RFC3489bis. >AFAIK there are also no deployments for RFC3489bis which >utilize "_stun._tcp" yet, so fixing the bis draft should not >be a problem to anyone, and avoids the break with respect to >3489. Of course, it seems difficult to come up with an elegant >fix to this ("_stun-bis._tcp" perhaps), but I still think this >is a real problem. Yes, when we have to choose between 1) conflicting with an existing RFC (3489) or 2) changing an Internet Draft (RFC3489bis), I don't think we should even concider #1 if we really have to. >Another point, if you are going to build a stun client now, you would >build an rfc3489bis one. I see no point in doing both. I don't see how implementing a draft would solve this. Drafts tend to change rapidly, and when they do, we suddenly have a much bigger mess :) Keep in mind that there is also equipment which can not be updated as easily as a PC client. If one must support the current implementations out there (implementing just RFC3489), we don't have much choice. Implementing the new RFC3489bis now will not solve this until the servers are updated too. >There is a separate question on whether or not 3489bis should have a default port >for TLS (for any application usage). This port will necessarily be different than >3478. I don't have a very strong feeling on this and would be OK with asking IANA >for a port. Ok, please do that :) -- Tomi Kohonen From dwing@cisco.com Mon, 11 Sep 2006 20:46:18 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Mon, 11 Sep 2006 20:46:18 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] AD Evaluation of draft-ietf-behave-multicast-02 In-Reply-To: <44FBE783.5080107@ericsson.com> Message-ID: <0e8901c6d60d$37ab9b30$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@xxxxxxxxxxxx] > Sent: Monday, September 04, 2006 1:45 AM > To: Dan Wing; Behave WG > Subject: AD Evaluation of draft-ietf-behave-multicast-02 > > Hi, > > I have done the AD evaluation of this document and do have a > few comments. > > 1. There is a lack of references and explanation of > abbreviations. For example none of IGMP version talked about > in the introduction has any references. The new version now normatively references IGMPv2 and v3, and non-normatively referencing IGMPv1 (which is declared out of scope because it isn't widely deployed). > 2. Section 2: > "Sending multicast traffic is out of scope because it requires NATting > the source IP address of such transmitted multicast traffic." > > This does not motivate why NATing the source would be a > problem and thus should be done so that the receiving entity > can actively participate in a session. You're right, and there is no good reason to reduce the scope and eliminate that functionality. I removed that sentence from the updated version. I did not see any other impact to expanding the scope in that manner. > 3. Section 3.1: > "Hosts will periodically send IGMP Report messages to indicate > continued interest in receiving the multicast traffic." > > I think "hosts" in the above sentence should be clarified to mean the > NATed hosts. Done. > 4. Security consideration. > I think it should reference the MAGMA proxy drafts security > consideration also. Done. > I would appreciate an update to resolve these comments. The new version is at: http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-multicast -03.txt Differences from -02 are at: http://tinyurl.com/hmyq5 I will wait a day for BEHAVE comment and then post it as an Internet Draft. Thanks for your review! -d From magnus.westerlund@ericsson.com Tue, 12 Sep 2006 06:46:45 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) From: Magnus Westerlund Date: Tue, 12 Sep 2006 06:46:45 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) Subject: Re: [Ietf-behave] AD Evaluation of draft-ietf-behave-multicast-02 In-Reply-To: <0e8901c6d60d$37ab9b30$c4f0200a@amer.cisco.com> Message-ID: <45069E18.2030803@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Dan Wing skrev: 2. Section 2: "Sending multicast traffic is out of scope because it requires NATting the source IP address of such transmitted multicast traffic." This does not motivate why NATing the source would be a problem and thus should be done so that the receiving entity can actively participate in a session. You're right, and there is no good reason to reduce the scope and eliminate that functionality. I removed that sentence from the updated version. I did not see any other impact to expanding the scope in that manner. The only issue I have with this change is that there are no requirements on how a NAT should handle outbound traffic to multicast traffic and that binding state. I think there will be need for something that clarifies that. If I understand things correctly, the NAT needs to translate each transmitting host to a unique external IP and port compared to any other host on the internal side. And then maintain that binding for as long as the host is continuing to transmit IGMP traffic to the NAT. But I am no expert on multicast so please consult with more knowledge people. As I see this this is fundamental change that we probably need to do a new short WG last call after implementing. If people are not agreeing with supporting sending of traffic to multicast groups please speak up now. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From dwing@cisco.com Tue, 12 Sep 2006 19:37:16 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Tue, 12 Sep 2006 19:37:16 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: [Ietf-behave] bi-directional multicast traffic [was RE: AD Evaluation of draft-ietf-behave-multicast-02] In-Reply-To: <45069E18.2030803@ericsson.com> Message-ID: <08e101c6d6cc$b2511ad0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@xxxxxxxxxxxx] > Sent: Tuesday, September 12, 2006 4:47 AM > To: Dan Wing > Cc: Behave WG > Subject: Re: AD Evaluation of draft-ietf-behave-multicast-02 > > Dan Wing skrev: > > > >> 2. Section 2: > >> "Sending multicast traffic is out of scope because it > >> requires NATting the source IP address of such > >> transmitted multicast traffic." > >> > >> This does not motivate why NATing the source would be a > >> problem and thus should be done so that the receiving entity > >> can actively participate in a session. > > > > You're right, and there is no good reason to reduce the scope > > and eliminate that functionality. I removed that sentence from > > the updated version. I did not see any other impact to expanding > > the scope in that manner. > > > > The only issue I have with this change is that there are no > requirements on how a NAT should handle outbound traffic to > multicast traffic and that binding state. The NAT need only do nothing odd if the destination address is a multicast address (the Class Formerly Known as Class D). I can add such a statement to the document. > I think there will be need for something that > clarifies that. If I understand things correctly, the NAT needs to > translate each transmitting host to a unique external IP and port > compared to any other host on the internal side. Right; that is normal operation and is covered by -behave-nat-udp. > And then maintain that binding for as long as the host is > continuing to transmit IGMP traffic to the NAT. I was thinking doing the normal 2 minute timeout, as described in -behave-nat-udp, would be sufficient. There could be two unrelated multicast applications running on one host -- one receiving multicast traffic and another one that sends multicast traffic. Similarly, if you have nested NATs (doing NAPT), like this: host1-+ | host2-+--NAT1---NAT2---------Internet | host3-+ NAT2 will only see NAT1. Host1 might be receiving multicast traffic and host2 might send to a multicast address, but now NAT2 will keep host2's outgoing binding open unnecessarily. Over time, one persistant multicast listener and occasional multicast senders, all behind NAT1, would consume all of NAT2's bindings. > But I am no expert on multicast so please consult > with more knowledge people. > > As I see this this is fundamental change that we probably > need to do a new short WG last call after implementing. Agreed. > If people are not agreeing with supporting sending of > traffic to multicast groups please speak up now. -d > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From magnus.westerlund@ericsson.com Wed, 13 Sep 2006 02:41:42 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) From: Magnus Westerlund Date: Wed, 13 Sep 2006 02:41:42 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) Subject: Re: [Ietf-behave] bi-directional multicast traffic [was RE: AD Evaluation of draft-ietf-behave-multicast-02] In-Reply-To: <08e101c6d6cc$b2511ad0$c4f0200a@amer.cisco.com> Message-ID: <4507B630.4040302@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Dan Wing skrev: And then maintain that binding for as long as the host is continuing to transmit IGMP traffic to the NAT. I was thinking doing the normal 2 minute timeout, as described in -behave-nat-udp, would be sufficient. There could be two unrelated multicast applications running on one host -- one receiving multicast traffic and another one that sends multicast traffic. Similarly, if you have nested NATs (doing NAPT), like this: host1-+ | host2-+--NAT1---NAT2---------Internet | host3-+ NAT2 will only see NAT1. Host1 might be receiving multicast traffic and host2 might send to a multicast address, but now NAT2 will keep host2's outgoing binding open unnecessarily. Over time, one persistant multicast listener and occasional multicast senders, all behind NAT1, would consume all of NAT2's bindings. Okay, I see the problem. However I don't think a two minute timeout will cut it. The reason is that an ASM session with RTP and RTCP a pure listener may transmit less than one RTCP packet every 2 minutes, for example 50 kbps of RR and 8000 participants will result in that. The example is a large multicast group but not extremely large. The issue this result in is that each time a host's binding times out it will change source address tuple. This may trigger collision detection in other session members, see Section 8.2 in RFC 3550. Can't we recommend that a NAT keeps the binding for at least 1 hour if it receives IGMP traffic. To protect against an attack/exhaustion of resource the NAT may close down bindings starting with the longest inactive down to them being treated equally to normal UDP ones. That way I think we will have good performance and only inconsistent behavior in the case of resource exhaustion. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From dwing@cisco.com Wed, 13 Sep 2006 22:23:38 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Wed, 13 Sep 2006 22:23:38 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] bi-directional multicast traffic [was RE: AD Evaluation of draft-ietf-behave-multicast-02] In-Reply-To: <4507B630.4040302@ericsson.com> Message-ID: <038b01c6d7ad$24a73610$a4d9520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain ... > Okay, I see the problem. However I don't think a two minute > timeout will cut it. The reason is that an ASM session with RTP > and RTCP a pure listener may transmit less than one RTCP packet > every 2 minutes, for example 50 kbps of RR and 8000 participants > will result in that. The example is a large multicast group but > not extremely large. The issue this result in is that each time a > host's binding times out it will change source address tuple. This > may trigger collision detection in other session members, see > Section 8.2 in RFC 3550. > > Can't we recommend that a NAT keeps the binding for at least 1 hour > if it receives IGMP traffic. To protect against an > attack/exhaustion of resource the NAT may close down bindings > starting with the longest inactive down to them being treated > equally to normal UDP ones. That way I think we will have good > performance and only inconsistent behavior in the case of resource > exhaustion. Thanks for bringing that to my attention. You're right, a two minute timeout won't work. RFC3550's suggestion that a new SSRC chosen if the source transport address changes isn't tenable with a NAPT that times out sessions -- an RTP application would need to change its SSRC any time two minutes had elapsed between RTP or RTCP transmissions or do a STUN check hoping to discover the mapping had not timed out. Either solution is pretty gross. I rewrote section 3 to accomodate your suggestion and placed the new version, dated September 13th, at: http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-multicast -03.txt http://tinyurl.com/gsllh (the second URL merely redirects to the first) -d From magnus.westerlund@ericsson.com Thu, 14 Sep 2006 02:45:25 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) From: Magnus Westerlund Date: Thu, 14 Sep 2006 02:45:25 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) Subject: Re: [Ietf-behave] bi-directional multicast traffic [was RE: AD Evaluation of draft-ietf-behave-multicast-02] In-Reply-To: <038b01c6d7ad$24a73610$a4d9520a@amer.cisco.com> Message-ID: <4509088D.2010106@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi Dan, I have looked at the text you wrote. A couple of comments: If a NAPT followed the requirements of [I-D.ietf-behave-nat-udp] (and timed out a UDP session after 2 minutes of inactivity) and the multicast group is sufficiently large (approximately 8000 members with a normal 50kbps audio RTP stream), the elapsed time between a NAPTed host sending its RTCP Receiver Reports would exceed 2 minutes, causing an unnecessary RTP collision detection to be performed by other session members. That calculation was done for 50 kbps of RTCP receiver bandwidth, i.e. B=RR:50000 in SDP. For the session you specify in text with the normal 5% (3.75% of session bandwidth to receivers) rules would result in deterministic intervals beyond 2 minutes for session of around 300 participants or more. This requires the NAPT not assign a new UDP source port for that raffic. Misspelled "traffic" at the end of the session. Otherwise it looks good. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From dwing@cisco.com Thu, 14 Sep 2006 19:00:40 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Thu, 14 Sep 2006 19:00:40 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] bi-directional multicast traffic [was RE: AD Evaluation of draft-ietf-behave-multicast-02] In-Reply-To: <4509088D.2010106@ericsson.com> Message-ID: <015c01c6d859$f4256c20$6382200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > I have looked at the text you wrote. A couple of comments: > > If a > NAPT followed the requirements of [I-D.ietf-behave-nat-udp] (and > timed out a UDP session after 2 minutes of inactivity) and the > multicast group is sufficiently large (approximately 8000 members > with a normal 50kbps audio RTP stream), the elapsed time between a > NAPTed host sending its RTCP Receiver Reports would > exceed 2 minutes, > causing an unnecessary RTP collision detection to be performed by > other session members. > > That calculation was done for 50 kbps of RTCP receiver > bandwidth, i.e. B=RR:50000 in SDP. For the session you specify in > text with the normal 5% (3.75% of session bandwidth to receivers) > rules would result in deterministic intervals beyond 2 minutes > for session of around 300 participants or more. Thanks. Adjusted my text from "8000 members" to "300 members". > This requires the NAPT not assign a new UDP source port for that > raffic. > > Misspelled "traffic" at the end of the session. Fixed. -d From magnus.westerlund@ericsson.com Fri, 15 Sep 2006 02:31:32 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) From: Magnus Westerlund Date: Fri, 15 Sep 2006 02:31:32 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) Subject: Re: [Ietf-behave] bi-directional multicast traffic [was RE: AD Evaluation of draft-ietf-behave-multicast-02] In-Reply-To: <015c01c6d859$f4256c20$6382200a@amer.cisco.com> Message-ID: <450A56CA.3000306@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Thanks, Then I am satisfied with the update. Unless someone has any objection I will go to IETF last call as soon as the updated version is available. /Magnus Dan Wing skrev: I have looked at the text you wrote. A couple of comments: If a NAPT followed the requirements of [I-D.ietf-behave-nat-udp] (and timed out a UDP session after 2 minutes of inactivity) and the multicast group is sufficiently large (approximately 8000 members with a normal 50kbps audio RTP stream), the elapsed time between a NAPTed host sending its RTCP Receiver Reports would exceed 2 minutes, causing an unnecessary RTP collision detection to be performed by other session members. That calculation was done for 50 kbps of RTCP receiver bandwidth, i.e. B=RR:50000 in SDP. For the session you specify in text with the normal 5% (3.75% of session bandwidth to receivers) rules would result in deterministic intervals beyond 2 minutes for session of around 300 participants or more. Thanks. Adjusted my text from "8000 members" to "300 members". This requires the NAPT not assign a new UDP source port for that raffic. Misspelled "traffic" at the end of the session. Fixed. -d -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From Internet-Drafts@ietf.org Fri, 15 Sep 2006 14:50:16 -0500 (CDT) (envelope-from ietf@ietf.org) From: Internet-Drafts@ietf.org Date: Fri, 15 Sep 2006 14:50:16 -0500 (CDT) (envelope-from ietf@ietf.org) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-multicast-03.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Multicast Requirements for a Network Address Port Translator (NAPT) Author(s) : D. Wing Filename : draft-ietf-behave-multicast-03.txt Pages : 8 Date : 2006-9-15 This document places requirements on a Network Address Translator (NAT) and Network Address and Port Translator (NAPT) that supports IP multicast by implementing an Internet Group Management Protocol (IGMP) proxy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-multicast-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-multicast-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From iesg-secretary@ietf.org Mon, 18 Sep 2006 09:36:09 -0500 (CDT) (envelope-from ietf@ietf.org) From: The IESG Date: Mon, 18 Sep 2006 09:36:09 -0500 (CDT) (envelope-from ietf@ietf.org) Subject: [Ietf-behave] Last Call: 'Multicast Requirements for a Network Address Port Translator (NAPT)' to BCP (draft-ietf-behave-multicast) Message-ID: MIME-Version: 1.0 Content-Type: text/plain The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG to consider the following document: - 'Multicast Requirements for a Network Address Port Translator (NAPT) ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2006-10-02. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-03.txt From audet@nortel.com Mon, 18 Sep 2006 11:02:02 -0500 (CDT) (envelope-from AUDET@nortel.com) From: "Francois Audet" Date: Mon, 18 Sep 2006 11:02:02 -0500 (CDT) (envelope-from AUDET@nortel.com) Subject: Re: [Ietf-behave] Last Call: 'Multicast Requirements for a Network Address Port Translator (NAPT)' to BCP (draft-ietf-behave-multicast) In-Reply-To: Message-ID: <1ECE0EB50388174790F9694F77522CCF0D233E9D@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Looks good to me. Minor comment on first sentence of section 3.1 which states that "Multicast traffic arrives only outside-to-inside." It would be useful to explain briefly why this assumption is made (i.e., multicast orininating behind a NAT is not in-scope? or not possible?). > -----Original Message----- > From: The IESG [mailto:iesg-secretary@xxxxxxxx] > Sent: Monday, September 18, 2006 7:36 AM > To: IETF-Announce > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Last Call: 'Multicast Requirements for a Network > Address Port Translator (NAPT)' to BCP (draft-ietf-behave-multicast) > > The IESG has received a request from the Behavior Engineering > for Hindrance Avoidance WG to consider the following document: > > - 'Multicast Requirements for a Network Address Port > Translator (NAPT) ' > as a BCP > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send any > comments to the iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists > by 2006-10-02. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-03.txt > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf-announce > From dwing@cisco.com Mon, 18 Sep 2006 11:27:04 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Mon, 18 Sep 2006 11:27:04 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] Last Call: 'Multicast Requirements for a Network Address Port Translator (NAPT)' to BCP (draft-ietf-behave-multicast) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0D233E9D@zrc2hxm0.corp.nortel.com> Message-ID: <0d4501c6db3f$404368e0$6382200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Looks good to me. > > Minor comment on first sentence of section 3.1 which states that > "Multicast traffic arrives only outside-to-inside." > > It would be useful to explain briefly why this assumption is > made (i.e., > > multicast orininating behind a NAT is not in-scope? or not possible?). To do that you're doing what is now called "Any-source multicast" (ASM), the 'classic' multicast in RFC1112. It isn't widely deployed, especially on the Internet, for a bunch of good reasons, not the least of which anyone broadcasting into the multicast session has to Do The Right Thing. The cooperative Internet faded from the world about 15 years ago. I declared RFC1112-style multicast as out-of-scope for this reason. Let me know if it should be declared in-scope. I can add some text if that seems helpful. How does this feel: > > 3.1. NAPT Inbound Refresh Behavior > > Multicast traffic arrives only outside-to-inside. > > Discussion: inside-to-outside multicast traffic > requires Any Source Multicast (ASM) [RFC1112], > which is not widely deployed on the Internet and > is also considered out of scope for this document. > > Thus, a NAPT needs to also meet REQ-6a of NAT UDP > requirements [I-D.ietf-behave-nat-udp] ... > > -d From magnus.westerlund@ericsson.com Tue, 19 Sep 2006 03:32:54 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) From: Magnus Westerlund Date: Tue, 19 Sep 2006 03:32:54 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) Subject: Re: [Ietf-behave] Last Call: 'Multicast Requirements for a Network Address Port Translator (NAPT)' to BCP (draft-ietf-behave-multicast) In-Reply-To: <0d4501c6db3f$404368e0$6382200a@amer.cisco.com> Message-ID: <450FAB2E.6050104@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Dan Wing skrev: Looks good to me. Minor comment on first sentence of section 3.1 which states that "Multicast traffic arrives only outside-to-inside." It would be useful to explain briefly why this assumption is made (i.e., multicast orininating behind a NAT is not in-scope? or not possible?). To do that you're doing what is now called "Any-source multicast" (ASM), the 'classic' multicast in RFC1112. It isn't widely deployed, especially on the Internet, for a bunch of good reasons, not the least of which anyone broadcasting into the multicast session has to Do The Right Thing. The cooperative Internet faded from the world about 15 years ago. I declared RFC1112-style multicast as out-of-scope for this reason. Let me know if it should be declared in-scope. I can add some text if that seems helpful. How does this feel: Dan, I thought ASM would work as the document currently is specified. The IGMP proxy document does specify behavior for supporting senders (section 3.3 of RFC 4605) and with the correct translation the packets sent will have a good source address. So please clarify what you think will not work with ASM? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From rdenis@simphalempin.com Mon, 18 Sep 2006 13:35:16 -0500 (CDT) (envelope-from rdenis@simphalempin.com) From: =?windows-1252?q?R=E9mi_Denis-Courmont?= Date: Mon, 18 Sep 2006 13:35:16 -0500 (CDT) (envelope-from rdenis@simphalempin.com) Subject: Re: [Ietf-behave] Properly detecting netfilter NATs In-Reply-To: <20060916022102.GA1808@litech.org> Message-ID: <200609182134.54606@auguste.remlab.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630137.multipart/signed" --Boundary..27398.1163630137.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Le samedi 16 septembre 2006 11:50, Rmi Denis-Courmont a crit : > > Unless there's a better way to detect netfilter NATs or work around > > them in the client, I can put together a patch. > AFAICT, symmetric-to-symmetric NAT traversal is plain impossible > without triangle routing. If I may clarify: I mean there, I believe, no way to get, say two users behind two distinct OpenBSD packet filter (which I read was purposedly symmetric - not checked on my own). Can I know which precise 2.4 kernel version you were using? I'm pretty sure I started development of miredo with a 2.4-kernel-based NAT myself a few years back, so I suspect a change in the course of the 2.4 tree. I can't think of anyway to two miredo instances behind two NATs such as yours to communicate to each others. Unless timing is extremely fortunate, whenever one side tries to send a packet to the other it is bound to cause a "mis-binding", whereby the NAT would create a binding toward itself as I described in http://list.sipfoundry.org/archive/ietf-behave/msg00950.html . So yeah, you seem to have uncovered a bothersome if not serious regression with the removal of the cone NAT probes. If anyone has more input, it's welcome, but I am pretty much convinced NATs of such kind are hopeless with regards to peer-to-peer (let alone TURN, that is). -- Rmi Denis-Courmont http://www.remlab.net/ Attachment: pgpE1H0u9djeD.pgp --Boundary..27398.1163630137.multipart/signed Content-Type: application/octet-stream; name="pgpE1H0u9djeD.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpE1H0u9djeD.pgp" Content-Description: "Description: PGP signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC41IChHTlUv TGludXgpCgppRDhEQlFCRkR1Yk93K3h0dnQxdEVyMFJBbmhlQUtEM0NDUFI1VUFqaHZmQzNCUEJl TVRoY1VYYlJ3Q2ZWblhiCjVTY0pncnhJQWRuVmpncGtTUlFLTXdFPQo9UzRZQwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630137.multipart/signed-- From lutchann-miredo@litech.org Mon, 18 Sep 2006 19:35:50 -0500 (CDT) (envelope-from lutchann@puck.litech.org) From: Nathan Lutchansky Date: Mon, 18 Sep 2006 19:35:50 -0500 (CDT) (envelope-from lutchann@puck.litech.org) Subject: Re: [Ietf-behave] [miredo-devel] Re: Properly detecting netfilter NATs In-Reply-To: <20060916022102.GA1808@litech.org> Message-ID: <20060919003542.GA8888@litech.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630137.multipart/signed" --Boundary..27398.1163630137.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, Sep 18, 2006 at 09:34:50PM +0300, R?mi Denis-Courmont wrote: > Le samedi 16 septembre 2006 11:50, R?mi Denis-Courmont a ?crit : > > > Unless there's a better way to detect netfilter NATs or work around > > > them in the client, I can put together a patch. > > > AFAICT, symmetric-to-symmetric NAT traversal is plain impossible > > without triangle routing. > > If I may clarify: I mean there, I believe, no way to get, say two users > behind two distinct OpenBSD packet filter (which I read was purposedly > symmetric - not checked on my own). > > Can I know which precise 2.4 kernel version you were using? It's a 2.4.29 kernel from OpenWRT. > I'm pretty > sure I started development of miredo with a 2.4-kernel-based NAT myself > a few years back, so I suspect a change in the course of the 2.4 tree. After more experimentation I found that dropping UDP packets on unused NAT ports as described in your older message actually did sometimes work at first, but it would always revert to the symmetric mode after a few minutes. So I can imagine light/test usage may not have revealed this limitation to the workaround. > you seem to have uncovered a bothersome if not serious > regression with the removal of the cone NAT probes. > > If anyone has more input, it's welcome, but I am pretty much convinced > NATs of such kind are hopeless with regards to peer-to-peer (let alone > TURN, that is). Right, and considering that most of the NATs I've used myself in hotels, wireless hotspots, conference centers, etc, tend to be Linux, BSD, IOS, or some "secure" corporate-type NAT, I worry that Teredo doesn't have much of a future unless some other higher-overhead operating mode can be added to permit third-party relaying between two Teredo nodes behind symmetric NATs. -Nathan Attachment: pgpnI9Ec5Qd09.pgp --Boundary..27398.1163630137.multipart/signed Content-Type: application/octet-stream; name="pgpnI9Ec5Qd09.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpnI9Ec5Qd09.pgp" Content-Description: "Description: PGP signature" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjEgKEdO VS9MaW51eCkKCmlEOERCUUZGRHp0ZVR2aURrVzhtaHljUkFuNUhBSjlXa05Vb1FvOUNIRDUzU1Vy aUFvZDRpTlY3VndDZUxGRU0KR29JTFhyQjJMR3RTeDBrL3JYS0M4azg9Cj01eUVoCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQo= --Boundary..27398.1163630137.multipart/signed-- From gael.breard@orange-ft.com Wed, 20 Sep 2006 08:06:42 -0500 (CDT) (envelope-from gael.breard@orange-ft.com) From: "BREARD Gael RD-MAPS-ISS" Date: Wed, 20 Sep 2006 08:06:42 -0500 (CDT) (envelope-from gael.breard@orange-ft.com) Subject: [Ietf-behave] Re : turn-01 and REQUESTED-PORT-PROPS Message-ID: MIME-Version: 1.0 Content-Type: text/plain >The layout of REQUESTED-PORT-PROPS in turn-01 is very different from >REQUESTED-PORT in turn-00. Among other things, there is no longer any place to >specify a port when you want to request one (28 of the 32 bits are "reserved", >where previously 16 bits were used for the "Port Filter" field). I also notice >that REQUESTED-PORT is still referred to in several places (eg in sec 10.8). >Was the intent to move the location of this data somewhere else (perhaps start >using the unused port field in REQUESTED-IP) and the document was released >before editing was finished, or was the removal of the "Port Filter" field >when going from REQUESTED-PORT to REQUESTED-PORT-PROPS just an oversight? (Or >did I miss something somewhere?) Just have the same problem. No response for that ? I would agree to use the unused port field of REQUESTED-IP (and so rename it REQUESTED-ADDRESS). And why do not use reserved 8 bits of this attribute for coding requested transport, port alignment and allocation behavior ? One bit should then be added to code if specific IP is requested. (if not : address field could be removed) So it would give for example (field order...) : REQUESTED-ADDRESS : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|C|B| A | E | Family | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A : for requested port alignment (idem turn-01) 00 no specific port alignment 01 odd port number 10 even port number 11 even port number; reserve next higher port B & C : for requested port allocation behavior. (idem B turn-01) B: 0 no specific port requested 1 specific port requested (port field used only with this property) C: 1 door requested 1 door not requested C&&B = forbidden D: for requested IP 0 no specific IP requested ( => address field absent) 1 specific IP requested ( => address field present / family field used only with this property) E: for requested transport 000: UDP 001: TCP Bad (?) : only 3 bits for transport (could take some bits in family field ?) Gal From laine+behave@laine.org Fri, 22 Sep 2006 08:48:09 -0500 (CDT) (envelope-from laine+behave@laine.org) From: Laine Stump Date: Fri, 22 Sep 2006 08:48:09 -0500 (CDT) (envelope-from laine+behave@laine.org) Subject: Re: [Ietf-behave] Re : turn-01 and REQUESTED-PORT-PROPS In-Reply-To: Message-ID: <7.0.1.0.0.20060922093408.01d1e9b0@laine.org> MIME-Version: 1.0 Content-Type: text/plain At 09:06 AM 9/20/2006, BREARD Gael RD-MAPS-ISS wrote: >The layout of REQUESTED-PORT-PROPS in turn-01 is very different from REQUESTED-PORT in turn-00. Among other things, there is no longer any place to specify a port when you want to request one (28 of the 32 bits are "reserved", where previously 16 bits were used for the "Port Filter" field). I also notice that REQUESTED-PORT is still referred to in several places (eg in sec 10.8). Was the intent to move the location of this data somewhere else (perhaps start using the unused port field in REQUESTED-IP) and the document was released before editing was finished, or was the removal of the "Port Filter" field when going from REQUESTED-PORT to REQUESTED-PORT-PROPS just an oversight? (Or did I miss something somewhere?) Just have the same problem. No response for that ? No, there was never a response. For awhile I thought maybe I was the only one actually implementing code based on this spec ;-) After reading the minutes of the last wg meeting, it seems like this part will change again soon anyway. In light of that, and lacking any response, I've just left our implementation using the old REQUESTED-PORT format (from turn-00) for now (which works, since I didn't put in the ill-fated "door" stuff), and will update it when the next draft is available. I would agree to use the unused port field of REQUESTED-IP (and so rename it REQUESTED-ADDRESS). And why do not use reserved 8 bits of this attribute for coding requested transport, port alignment and allocation behavior ? One bit should then be added to code if specific IP is requested. (if not : address field could be removed) So it would give for example (field order...) : REQUESTED-ADDRESS : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|C|B| A | E | Family | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A : for requested port alignment (idem turn-01) 00 no specific port alignment 01 odd port number 10 even port number 11 even port number; reserve next higher port B & C : for requested port allocation behavior. (idem B turn-01) B: 0 no specific port requested 1 specific port requested (port field used only with this property) C: 1 door requested 1 door not requested C&&B = forbidden D: for requested IP 0 no specific IP requested ( => address field absent) 1 specific IP requested ( => address field present / family field used only with this property) E: for requested transport 000: UDP 001: TCP Bad (?) : only 3 bits for transport (could take some bits in family field ?) Gal _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From aeh@db.org Tue, 3 Oct 2006 09:32:32 -0500 (CDT) (envelope-from aeh@db.org) From: "Alfred E. Heggestad" Date: Tue, 3 Oct 2006 09:32:32 -0500 (CDT) (envelope-from aeh@db.org) Subject: [Ietf-behave] Compatibility between RFC3489 and draft-ietf-behave-rfc3489bis-04 Message-ID: <45227448.80500@db.org> MIME-Version: 1.0 Content-Type: text/plain Hi Is rfc3489bis-04 intended to be backwards compatible with RFC3489? i.e. should it be possible to use a RFC3489 compliant STUN-client with a bis-04 compliant STUN server, or vice versa? My findings so far, when implementing a STUN library as specified in rfc3489bis-04, is that there are some issues. However they might be implementation-specific. * rfc3489bis-04 compliant STUN client against RFC3489-compliant STUN server: The STUN request contains the new FINGERPRINT attribute, but this attribute is not supported by the STUN server (Vovida.org 0.96), hence the response is dropped. * RFC3489-compliant STUN client against rfc3489bit-04 compliant STUN server: The STUN request is sent from the client (X-lite) and the STUN server returns a response with MAPPED-ADDRESS attribute. But since the response does not contain attributes SOURCE-ADDRESS and CHANGED-ADDRESS, the STUN client is not able to use the response. If these two specs are intended to be compliant, are there any special ways of getting this to work? many thanks in advance. /alfred From dwing@cisco.com Tue, 3 Oct 2006 10:44:24 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Tue, 3 Oct 2006 10:44:24 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] Compatibility between RFC3489 anddraft-ietf-behave-rfc3489bis-04 In-Reply-To: <45227448.80500@db.org> Message-ID: <10c501c6e702$c782d970$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Is rfc3489bis-04 intended to be backwards compatible with RFC3489? > I.E. should it be possible to use a RFC3489 compliant STUN-client > with a bis-04 compliant STUN server, or vice versa? > > My findings so far, when implementing a STUN library as specified in > rfc3489bis-04, is that there are some issues. However they might be > implementation-specific. > > > * rfc3489bis-04 compliant STUN client against > RFC3489-compliant STUN server: > > The STUN request contains the new FINGERPRINT attribute, but this > attribute is not supported by the STUN server (Vovida.org 0.96), > hence the response is dropped. That shouldn't be a problem for the RFC3489bis-compliant STUN client. The primary purpose of this attribute is to provide an additional distinguisher for STUN/non-STUN packets. That is, there isn't any reason for an RFC3489bis-compliant STUN server to validate or check for that attribute. Similarly, it won't see the XOR-MAPPED-ADDRESS, either, because a RFC3489 STUN server won't return it. Thus, if the RFC3489bis client wants to interoperate with a RFC3489 STUN server, it needs to understand the responses sent by a RFC3489 server. > * RFC3489-compliant STUN client against rfc3489bit-04 > compliant STUN server: > > The STUN request is sent from the client (X-lite) and the STUN > server returns a response with MAPPED-ADDRESS attribute. But > since the response does not contain attributes SOURCE-ADDRESS and > CHANGED-ADDRESS, the STUN client is not able to use the response. You probably noticed that in RFC3489 the transaction ID is 128 bits but in RFC3489bis the same bits in the STUN packet are the fixed magic cookie (32 bits) and a 96 bit transaction ID. Your RFC3489bis-compliant STUN server can determine if the incoming STUN request was sent by a RFC3489-compliant STUN client or an RFC3489-bis-compliant STUN server by examining the 32 bit value. If it's 0x2112A442 (the value of the magic cookie in RFC3489bis), the STUN request is from a RFC3489bis client; if it's some other value, the STUN request is from a RFC3489 client. -d > > If these two specs are intended to be compliant, are there any special > ways of getting this to work? > > many thanks in advance. > > > /alfred > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From aeh@db.org Tue, 3 Oct 2006 18:32:09 -0500 (CDT) (envelope-from aeh@db.org) From: "Alfred E. Heggestad" Date: Tue, 3 Oct 2006 18:32:09 -0500 (CDT) (envelope-from aeh@db.org) Subject: Re: [Ietf-behave] Compatibility between RFC3489 anddraft-ietf-behave-rfc3489bis-04 In-Reply-To: <10c501c6e702$c782d970$c5f0200a@amer.cisco.com> Message-ID: <4522F31F.1050500@db.org> MIME-Version: 1.0 Content-Type: text/plain Dan Wing wrote: * rfc3489bis-04 compliant STUN client against RFC3489-compliant STUN server: The STUN request contains the new FINGERPRINT attribute, but this attribute is not supported by the STUN server (Vovida.org 0.96), hence the response is dropped. That shouldn't be a problem for the RFC3489bis-compliant STUN client. The primary purpose of this attribute is to provide an additional distinguisher for STUN/non-STUN packets. That is, there isn't any reason for an RFC3489bis-compliant STUN server to validate or check for that attribute. Similarly, it won't see the XOR-MAPPED-ADDRESS, either, because a RFC3489 STUN server won't return it. Thus, if the RFC3489bis client wants to interoperate with a RFC3489 STUN server, it needs to understand the responses sent by a RFC3489 server. many thanks for your answer. ok I understand that the new FINGERPRINT attribute to distinguish between STUN and non-STUN packets. prior to sending a STUN request, the STUN client cannot know which version of the spec the STUN server supports. so it can e.g. try to send a bis-04 compliant STUN request include the FINGERPRINT attrib and if it times out, then try to send a STUN request ala RFC3489.. * RFC3489-compliant STUN client against rfc3489bit-04 compliant STUN server: The STUN request is sent from the client (X-lite) and the STUN server returns a response with MAPPED-ADDRESS attribute. But since the response does not contain attributes SOURCE-ADDRESS and CHANGED-ADDRESS, the STUN client is not able to use the response. You probably noticed that in RFC3489 the transaction ID is 128 bits but in RFC3489bis the same bits in the STUN packet are the fixed magic cookie (32 bits) and a 96 bit transaction ID. Your RFC3489bis-compliant STUN server can determine if the incoming STUN request was sent by a RFC3489-compliant STUN client or an RFC3489-bis-compliant STUN server by examining the 32 bit value. If it's 0x2112A442 (the value of the magic cookie in RFC3489bis), the STUN request is from a RFC3489bis client; if it's some other value, the STUN request is from a RFC3489 client. yes you are right. I have updated my STUN server now to support both flavours. although there is a (tiny) chance that the first 4 bytes of the TID generated by a RFC3489-client actually contains 0x2112a442. but I guess, if the a STUN request fails for this reason the client will just retry until it works.. thanks again for your help. /alfred From fluffy@cisco.com Tue, 3 Oct 2006 22:14:31 -0500 (CDT) (envelope-from fluffy@cisco.com) From: Cullen Jennings Date: Tue, 3 Oct 2006 22:14:31 -0500 (CDT) (envelope-from fluffy@cisco.com) Subject: Re: [Ietf-behave] STUN Server Discovery In-Reply-To: <719D5CCC2F6E3644B0A9F5C9B1D00088020C31FD@esebe104.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Sep 8, 2006, at 1:34 AM, wrote: On 07 September, 2006 Jonathan Rosenberg wrote: In theory perhaps. The reality is, AFAIK, the shared secret service with TLS has not been used or deployed to any degree. Thus, I do not believe it is important to retain backwards compatibility with that discovery procedure. I disagree with this one. There are definitely implementations out there, Can you point me at a deployed one - I've been looking for some flows I can capture to show as an example. Thanks. From fluffy@cisco.com Tue, 3 Oct 2006 22:21:51 -0500 (CDT) (envelope-from fluffy@cisco.com) From: Cullen Jennings Date: Tue, 3 Oct 2006 22:21:51 -0500 (CDT) (envelope-from fluffy@cisco.com) Subject: Re: [Ietf-behave] Re : turn-01 and REQUESTED-PORT-PROPS In-Reply-To: Message-ID: <564CF334-F188-4A5F-80A9-0E9AD55DCA6D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain On Sep 20, 2006, at 6:06 AM, BREARD Gael RD-MAPS-ISS wrote: B: 0 no specific port requested 1 specific port requested (port field used only with this property) C: 1 door requested 1 door not requested C&&B = forbidden As a slight tweak to what you are suggesting, I would rather see the protocol design enforce the C&&B forbidden by encoding this more like 00 no specific port requested and no door 01 no specific port requested and no door 10 specific port requested and no door requested 11 no specific port requested and door requested From fluffy@cisco.com Tue, 3 Oct 2006 22:23:51 -0500 (CDT) (envelope-from fluffy@cisco.com) From: Cullen Jennings Date: Tue, 3 Oct 2006 22:23:51 -0500 (CDT) (envelope-from fluffy@cisco.com) Subject: Re: [Ietf-behave] Re : turn-01 and REQUESTED-PORT-PROPS In-Reply-To: Message-ID: <08B02293-596C-4AA1-9500-FFF2637CE43D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Oh, on a side note, I should mention I really have not figured out if I think the doors are needed or not. On Sep 20, 2006, at 6:06 AM, BREARD Gael RD-MAPS-ISS wrote: The layout of REQUESTED-PORT-PROPS in turn-01 is very different from REQUESTED-PORT in turn-00. Among other things, there is no longer any place to specify a port when you want to request one (28 of the 32 bits are "reserved", where previously 16 bits were used for the "Port Filter" field). I also notice that REQUESTED- PORT is still referred to in several places (eg in sec 10.8). Was the intent to move the location of this data somewhere else (perhaps start using the unused port field in REQUESTED-IP) and the document was released before editing was finished, or was the removal of the "Port Filter" field when going from REQUESTED-PORT to REQUESTED-PORT-PROPS just an oversight? (Or did I miss something somewhere?) Just have the same problem. No response for that ? I would agree to use the unused port field of REQUESTED-IP (and so rename it REQUESTED-ADDRESS). And why do not use reserved 8 bits of this attribute for coding requested transport, port alignment and allocation behavior ? One bit should then be added to code if specific IP is requested. (if not : address field could be removed) So it would give for example (field order...) : REQUESTED-ADDRESS : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ |D|C|B| A | E | Family | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ | Address (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ A : for requested port alignment (idem turn-01) 00 no specific port alignment 01 odd port number 10 even port number 11 even port number; reserve next higher port B & C : for requested port allocation behavior. (idem B turn-01) B: 0 no specific port requested 1 specific port requested (port field used only with this property) C: 1 door requested 1 door not requested C&&B = forbidden D: for requested IP 0 no specific IP requested ( => address field absent) 1 specific IP requested ( => address field present / family field used only with this property) E: for requested transport 000: UDP 001: TCP Bad (?) : only 3 bits for transport (could take some bits in family field ?) Gal _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Tue, 3 Oct 2006 22:48:30 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Tue, 3 Oct 2006 22:48:30 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] Re : turn-01 and REQUESTED-PORT-PROPS In-Reply-To: <08B02293-596C-4AA1-9500-FFF2637CE43D@cisco.com> Message-ID: <0af101c6e767$ef408ab0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain The introduction of "doors" in turn-01 did not achieve WG consensus at the Montreal meeting. This was reflected in the minutes, http://www3.ietf.org/proceedings/06jul/minutes/behave.html, which concluded with: "Will remove the Door from next version of the draft." The authors of turn have not yet to honored the working group with a new version of the document reflecting that consensus. -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Cullen Jennings > Sent: Tuesday, October 03, 2006 8:24 PM > To: BREARD Gael RD-MAPS-ISS > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] Re : turn-01 and REQUESTED-PORT-PROPS > > > Oh, on a side note, I should mention I really have not > figured out if > I think the doors are needed or not. > > > On Sep 20, 2006, at 6:06 AM, BREARD Gael RD-MAPS-ISS wrote: > > > > >> The layout of REQUESTED-PORT-PROPS in turn-01 is very different > >> from REQUESTED-PORT in turn-00. Among other things, there is no > >> longer any place to specify a port when you want to request one > >> (28 of the 32 bits are "reserved", where previously 16 bits were > >> used for the "Port Filter" field). I also notice that REQUESTED- > >> PORT is still referred to in several places (eg in sec 10.8). Was > >> the intent to move the location of this data somewhere else > >> (perhaps start using the unused port field in REQUESTED-IP) and > >> the document was released before editing was finished, or was the > >> removal of the "Port Filter" field when going from REQUESTED-PORT > >> to REQUESTED-PORT-PROPS just an oversight? (Or did I miss > >> something somewhere?) > > > > > > Just have the same problem. No response for that ? > > > > I would agree to use the unused port field of REQUESTED-IP (and so > > rename it REQUESTED-ADDRESS). > > And why do not use reserved 8 bits of this attribute for coding > > requested transport, port alignment and allocation behavior ? > > One bit should then be added to code if specific IP is requested. > > (if not : address field could be removed) > > > > So it would give for example (field order...) : > > > > REQUESTED-ADDRESS : > > > > 0 1 2 > 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 > > 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+-+ > > |D|C|B| A | E | Family | > > Port | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+-+ > > | Address (variable) > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+-+ > > > > A : for requested port alignment (idem turn-01) > > > > 00 no specific port alignment > > 01 odd port number > > 10 even port number > > 11 even port number; reserve next higher port > > > > B & C : for requested port allocation behavior. (idem B turn-01) > > > > B: > > 0 no specific port requested > > 1 specific port requested (port field > used only with this > > property) > > C: > > 1 door requested > > 1 door not requested > > > > C&&B = forbidden > > > > D: for requested IP > > 0 no specific IP requested ( => address field absent) > > 1 specific IP requested ( => address field present / family > > field used only with this property) > > > > E: for requested transport > > 000: UDP > > 001: TCP > > > > > > Bad (?) : only 3 bits for transport (could take some bits > in family > > field ?) > > > > > > Gal > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From fluffy@cisco.com Wed, 4 Oct 2006 00:27:11 -0500 (CDT) (envelope-from fluffy@cisco.com) From: Cullen Jennings Date: Wed, 4 Oct 2006 00:27:11 -0500 (CDT) (envelope-from fluffy@cisco.com) Subject: Re: [Ietf-behave] Re : turn-01 and REQUESTED-PORT-PROPS In-Reply-To: <0af101c6e767$ef408ab0$c5f0200a@amer.cisco.com> Message-ID: <6B1DCBF2-95A4-4732-B864-91DDE6259E49@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Ah, excellent - thanks for memory jog :-) On Oct 3, 2006, at 8:48 PM, Dan Wing wrote: The introduction of "doors" in turn-01 did not achieve WG consensus at the Montreal meeting. This was reflected in the minutes, http://www3.ietf.org/proceedings/06jul/minutes/behave.html, which concluded with: "Will remove the Door from next version of the draft." The authors of turn have not yet to honored the working group with a new version of the document reflecting that consensus. -d -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Cullen Jennings Sent: Tuesday, October 03, 2006 8:24 PM To: BREARD Gael RD-MAPS-ISS Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: Re: [Ietf-behave] Re : turn-01 and REQUESTED-PORT-PROPS Oh, on a side note, I should mention I really have not figured out if I think the doors are needed or not. On Sep 20, 2006, at 6:06 AM, BREARD Gael RD-MAPS-ISS wrote: The layout of REQUESTED-PORT-PROPS in turn-01 is very different from REQUESTED-PORT in turn-00. Among other things, there is no longer any place to specify a port when you want to request one (28 of the 32 bits are "reserved", where previously 16 bits were used for the "Port Filter" field). I also notice that REQUESTED- PORT is still referred to in several places (eg in sec 10.8). Was the intent to move the location of this data somewhere else (perhaps start using the unused port field in REQUESTED-IP) and the document was released before editing was finished, or was the removal of the "Port Filter" field when going from REQUESTED-PORT to REQUESTED-PORT-PROPS just an oversight? (Or did I miss something somewhere?) Just have the same problem. No response for that ? I would agree to use the unused port field of REQUESTED-IP (and so rename it REQUESTED-ADDRESS). And why do not use reserved 8 bits of this attribute for coding requested transport, port alignment and allocation behavior ? One bit should then be added to code if specific IP is requested. (if not : address field could be removed) So it would give for example (field order...) : REQUESTED-ADDRESS : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ |D|C|B| A | E | Family | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ | Address (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ A : for requested port alignment (idem turn-01) 00 no specific port alignment 01 odd port number 10 even port number 11 even port number; reserve next higher port B & C : for requested port allocation behavior. (idem B turn-01) B: 0 no specific port requested 1 specific port requested (port field used only with this property) C: 1 door requested 1 door not requested C&&B = forbidden D: for requested IP 0 no specific IP requested ( => address field absent) 1 specific IP requested ( => address field present / family field used only with this property) E: for requested transport 000: UDP 001: TCP Bad (?) : only 3 bits for transport (could take some bits in family field ?) Gal _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From magnus.westerlund@ericsson.com Wed, 4 Oct 2006 04:26:46 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) From: Magnus Westerlund Date: Wed, 4 Oct 2006 04:26:46 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) Subject: [Ietf-behave] RTCP SSRC collision and draft-ietf-behave-nat-multicast Message-ID: <45237DF2.1060600@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, During the IETF last call for "Multicast Requirements for a Network Address Port Translator (NAPT)" (draft-ietf-behave-multicast-03) some issues have come up. They all evolve about the binding that a NAT needs to create when a host on the inside of the NAT sends traffic either to the multicast group or to a feedback receiver in SSM (such as in draft-ietf-avt-rtcpssm). One issue that exist here is in relation to RTP and its collision detection mechanism. draft-ietf-behave-nat-udp does specify that outgoing UDP NAT binding shall be kept alive for at least 2 minutes. However for a certain amount of participants and a given RTCP bit-rate the RTCP reporting interval will become longer than the minimum binding lifetime. In those cases there is the risk that each message sent will have a different source IP address and UDP port tuple. That can trigger the RTP collision detection mechanism as described in section 8.2 of RFC 3550. To avoid these issue in most cases when transmitting to ASM multicast groups we propose that NAT will keep bindings for 1 hour. To clarify that means no change to the bindings going to unicast addresses, only packets that has a multicast group as destination address. The collision issue may now occur for sessions that has average RTCP reporting interval that is longer than 40 minutes instead of 80 seconds. We understand that this will not resolve the issue for sessions that would like to run in this configuration. For SSM sessions it would be best if the feedback receiver and media receivers primarily looks at the CNAME for determining SSRC collision and not network addresses. This seems necessary anyway for the media receivers in simple feedback mode as all RTCP packets will seem to come from the distribution source, thus address checking is useless. Collisions can only be found by checking the CNAME. In fact I think this is something that is required to be clarified in draft-ietf-avt-rtcpssm or otherwise all receivers will constantly detect collisions with there own RTCP packets. In the RTCP SSM summary mode the situation is somewhat different. For the feedback target, the address would be useful for determining that RTCP packet arrives from different sources. However in the presence of NATs this becomes a source of error. I wrote primarily look at CNAME in the previous paragraph. The reason for this is the remaining issue of loop detection. If one completely skips using the source address one will can't determine if some packets constantly comes back from another address and actually should be blocked for that reason. Here I don't have any brilliant ideas on how to resolve this issue. Please comment on the proposal Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From philip_matthews@magma.ca Wed, 4 Oct 2006 05:49:22 -0500 (CDT) (envelope-from philip_matthews@magma.ca) From: Philip Matthews Date: Wed, 4 Oct 2006 05:49:22 -0500 (CDT) (envelope-from philip_matthews@magma.ca) Subject: Re: [Ietf-behave] Compatibility between RFC3489 anddraft-ietf-behave-rfc3489bis-04 In-Reply-To: <10c501c6e702$c782d970$c5f0200a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain I think it is important to recognize that some aspects of rfc3489bis are still under discussion and may change significantly. For example, the FINGERPRINT attribute was introduced in the -04 version and was the subject of much discussion at the last meeting. If you are interested, you can read the minutes of the last BEHAVE meeting in the Proceedings portion of the IETF website. - Philip On 3-Oct-06, at 19:32 , Alfred E. Heggestad wrote: Dan Wing wrote: * rfc3489bis-04 compliant STUN client against RFC3489-compliant STUN server: The STUN request contains the new FINGERPRINT attribute, but this attribute is not supported by the STUN server (Vovida.org 0.96), hence the response is dropped. That shouldn't be a problem for the RFC3489bis-compliant STUN client. The primary purpose of this attribute is to provide an additional distinguisher for STUN/non-STUN packets. That is, there isn't any reason for an RFC3489bis-compliant STUN server to validate or check for that attribute. Similarly, it won't see the XOR-MAPPED-ADDRESS, either, because a RFC3489 STUN server won't return it. Thus, if the RFC3489bis client wants to interoperate with a RFC3489 STUN server, it needs to understand the responses sent by a RFC3489 server. many thanks for your answer. ok I understand that the new FINGERPRINT attribute to distinguish between STUN and non-STUN packets. prior to sending a STUN request, the STUN client cannot know which version of the spec the STUN server supports. so it can e.g. try to send a bis-04 compliant STUN request include the FINGERPRINT attrib and if it times out, then try to send a STUN request ala RFC3489.. * RFC3489-compliant STUN client against rfc3489bit-04 compliant STUN server: The STUN request is sent from the client (X-lite) and the STUN server returns a response with MAPPED-ADDRESS attribute. But since the response does not contain attributes SOURCE-ADDRESS and CHANGED-ADDRESS, the STUN client is not able to use the response. You probably noticed that in RFC3489 the transaction ID is 128 bits but in RFC3489bis the same bits in the STUN packet are the fixed magic cookie (32 bits) and a 96 bit transaction ID. Your RFC3489bis-compliant STUN server can determine if the incoming STUN request was sent by a RFC3489- compliant STUN client or an RFC3489-bis-compliant STUN server by examining the 32 bit value. If it's 0x2112A442 (the value of the magic cookie in RFC3489bis), the STUN request is from a RFC3489bis client; if it's some other value, the STUN request is from a RFC3489 client. yes you are right. I have updated my STUN server now to support both flavours. although there is a (tiny) chance that the first 4 bytes of the TID generated by a RFC3489-client actually contains 0x2112a442. but I guess, if the a STUN request fails for this reason the client will just retry until it works.. thanks again for your help. /alfred _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From magnus.westerlund@ericsson.com Wed, 4 Oct 2006 09:21:27 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) From: Magnus Westerlund Date: Wed, 4 Oct 2006 09:21:27 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) Subject: Re: [Ietf-behave] [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast In-Reply-To: <45237DF2.1060600@ericsson.com> Message-ID: <4523C35F.1070906@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Mark Baugher skrev: Magnus, I am unclear why we need to address this topic at all. I don't understand why we need to support a napt for multicast. I'd like to understand this basic requirement. Mark The task of the BEHAVE WG is to try to move to a world where NAPTs behave in a more deterministic behavior. In that scenario multicast can't be excluded, especially today when we start seeing more and more deployment (at least on local scale) of multicast. For example to support IPTV. This is a chartered and milestoned work of the BEHAVE WG. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From dwing@cisco.com Wed, 4 Oct 2006 12:08:17 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Wed, 4 Oct 2006 12:08:17 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: [Ietf-behave] p2p-state as new milestone? Message-ID: <0e9901c6e7d7$a9338a70$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain The authors of draft-srisuresh-behave-p2p-state have asked us to adopt the document to become a working group document. We don't currently have a milestone for such a work item, so a new milestone (and date) would need to be created. To adopt the document I would like some discussion on the list around this document's applicability to the WG. We will also need at least two WG volunteers for ongoing technical review as the document progresses. http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p-state-04.txt -d From tomi.kohonen@nokia.com Thu, 5 Oct 2006 03:00:59 -0500 (CDT) (envelope-from tomi.kohonen@nokia.com) From: Date: Thu, 5 Oct 2006 03:00:59 -0500 (CDT) (envelope-from tomi.kohonen@nokia.com) Subject: Re: [Ietf-behave] Compatibility between RFC3489 anddraft-ietf-behave-rfc3489bis-04 In-Reply-To: <45227448.80500@db.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi, There are some non backwards compatible issues in rfc3489bis-04 in the STUN service discovery. You can see these by looking at the Behave WG mailing list archive - the mail subject is "STUN Server Discovery". IMHO, these compatibility issues have not yet been solved. I hope these are taken thoroughly care of in the next draft version. -- Tomi Kohonen Nokia Corporation >-----Original Message----- >From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of >ext Alfred E. Heggestad >Sent: 03 October, 2006 17:32 >To: ietf-behave@xxxxxxxxxxxxxxxxxxx >Subject: [Ietf-behave] Compatibility between RFC3489 >anddraft-ietf-behave-rfc3489bis-04 > >Hi > >Is rfc3489bis-04 intended to be backwards compatible with >RFC3489? i.e. should it be possible to use a RFC3489 compliant >STUN-client with a bis-04 compliant STUN server, or vice versa? > >My findings so far, when implementing a STUN library as >specified in rfc3489bis-04, is that there are some issues. >However they might be implementation-specific. > > >* rfc3489bis-04 compliant STUN client against >RFC3489-compliant STUN server: > > The STUN request contains the new FINGERPRINT attribute, but this > attribute is not supported by the STUN server (Vovida.org 0.96), > hence the response is dropped. > > > >* RFC3489-compliant STUN client against rfc3489bit-04 >compliant STUN server: > > The STUN request is sent from the client (X-lite) and the >STUN server > returns a response with MAPPED-ADDRESS attribute. But since >the response > does not contain attributes SOURCE-ADDRESS and >CHANGED-ADDRESS, the STUN > client is not able to use the response. > > >If these two specs are intended to be compliant, are there any >special ways of getting this to work? > >many thanks in advance. > > >/alfred > From magnus.westerlund@ericsson.com Thu, 5 Oct 2006 03:37:42 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) From: Magnus Westerlund Date: Thu, 5 Oct 2006 03:37:42 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) Subject: Re: [Ietf-behave] [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast In-Reply-To: <45237DF2.1060600@ericsson.com> Message-ID: <4524C44B.7080603@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Mark Baugher skrev: Magnus, On Oct 4, 2006, at 7:21 AM, Magnus Westerlund wrote: Mark Baugher skrev: Magnus, I am unclear why we need to address this topic at all. I don't understand why we need to support a napt for multicast. I'd like to understand this basic requirement. Mark The task of the BEHAVE WG is to try to move to a world where NAPTs behave in a more deterministic behavior. In that scenario multicast can't be excluded, especially today when we start seeing more and more deployment (at least on local scale) of multicast. For example to support IPTV. This is a chartered and milestoned work of the BEHAVE WG. Maybe it's obvious, but there is no re-writing of the destination address to a unicast or multicast administratively-scoped address. The rewriting occurs only on the source address of an outgoing multicast packet. This was not immediately obvious to me. Exactly, the issue is that for a RTCP receiver outside of the NAT the source address tuple of any RTCP packet received may change due to bindings timing out between each transmission from the NATed sender. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From Internet-Drafts@ietf.org Thu, 5 Oct 2006 14:50:15 -0500 (CDT) (envelope-from ietf@ietf.org) From: Internet-Drafts@ietf.org Date: Thu, 5 Oct 2006 14:50:15 -0500 (CDT) (envelope-from ietf@ietf.org) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-nat-icmp-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for ICMP protocol Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-nat-icmp-01.txt Pages : 21 Date : 2006-10-5 This document identifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the ICMP protocol. The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-nat-icmp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-nat-icmp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From mbaugher@cisco.com Wed, 4 Oct 2006 09:04:09 -0500 (CDT) (envelope-from mbaugher@cisco.com) From: Mark Baugher Date: Wed, 4 Oct 2006 09:04:09 -0500 (CDT) (envelope-from mbaugher@cisco.com) Subject: Re: [Ietf-behave] [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast In-Reply-To: <45237DF2.1060600@ericsson.com> Message-ID: <8DCE45FE-207A-4583-B98D-497FCDCA4B67@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Magnus, I am unclear why we need to address this topic at all. I don't understand why we need to support a napt for multicast. I'd like to understand this basic requirement. Mark On Oct 4, 2006, at 2:25 AM, Magnus Westerlund wrote: Hi, During the IETF last call for "Multicast Requirements for a Network Address Port Translator (NAPT)" (draft-ietf-behave-multicast-03) some issues have come up. They all evolve about the binding that a NAT needs to create when a host on the inside of the NAT sends traffic either to the multicast group or to a feedback receiver in SSM (such as in draft-ietf-avt-rtcpssm). One issue that exist here is in relation to RTP and its collision detection mechanism. draft-ietf-behave-nat-udp does specify that outgoing UDP NAT binding shall be kept alive for at least 2 minutes. However for a certain amount of participants and a given RTCP bit-rate the RTCP reporting interval will become longer than the minimum binding lifetime. In those cases there is the risk that each message sent will have a different source IP address and UDP port tuple. That can trigger the RTP collision detection mechanism as described in section 8.2 of RFC 3550. To avoid these issue in most cases when transmitting to ASM multicast groups we propose that NAT will keep bindings for 1 hour. To clarify that means no change to the bindings going to unicast addresses, only packets that has a multicast group as destination address. The collision issue may now occur for sessions that has average RTCP reporting interval that is longer than 40 minutes instead of 80 seconds. We understand that this will not resolve the issue for sessions that would like to run in this configuration. For SSM sessions it would be best if the feedback receiver and media receivers primarily looks at the CNAME for determining SSRC collision and not network addresses. This seems necessary anyway for the media receivers in simple feedback mode as all RTCP packets will seem to come from the distribution source, thus address checking is useless. Collisions can only be found by checking the CNAME. In fact I think this is something that is required to be clarified in draft-ietf-avt-rtcpssm or otherwise all receivers will constantly detect collisions with there own RTCP packets. In the RTCP SSM summary mode the situation is somewhat different. For the feedback target, the address would be useful for determining that RTCP packet arrives from different sources. However in the presence of NATs this becomes a source of error. I wrote primarily look at CNAME in the previous paragraph. The reason for this is the remaining issue of loop detection. If one completely skips using the source address one will can't determine if some packets constantly comes back from another address and actually should be blocked for that reason. Here I don't have any brilliant ideas on how to resolve this issue. Please comment on the proposal Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx _______________________________________________ Audio/Video Transport Working Group avt@xxxxxxxx https://www1.ietf.org/mailman/listinfo/avt From mbaugher@cisco.com Wed, 4 Oct 2006 16:57:26 -0500 (CDT) (envelope-from mbaugher@cisco.com) From: Mark Baugher Date: Wed, 4 Oct 2006 16:57:26 -0500 (CDT) (envelope-from mbaugher@cisco.com) Subject: Re: [Ietf-behave] [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast In-Reply-To: <45237DF2.1060600@ericsson.com> Message-ID: <55D8F002-2057-4FAD-A498-62365D9F0FF9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Magnus, On Oct 4, 2006, at 7:21 AM, Magnus Westerlund wrote: Mark Baugher skrev: Magnus, I am unclear why we need to address this topic at all. I don't understand why we need to support a napt for multicast. I'd like to understand this basic requirement. Mark The task of the BEHAVE WG is to try to move to a world where NAPTs behave in a more deterministic behavior. In that scenario multicast can't be excluded, especially today when we start seeing more and more deployment (at least on local scale) of multicast. For example to support IPTV. This is a chartered and milestoned work of the BEHAVE WG. Maybe it's obvious, but there is no re-writing of the destination address to a unicast or multicast administratively-scoped address. The rewriting occurs only on the source address of an outgoing multicast packet. This was not immediately obvious to me. Mark Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From casner@acm.org Thu, 5 Oct 2006 13:14:05 -0500 (CDT) (envelope-from casner@acm.org) From: Stephen Casner Date: Thu, 5 Oct 2006 13:14:05 -0500 (CDT) (envelope-from casner@acm.org) Subject: Re: [Ietf-behave] [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast In-Reply-To: <45237DF2.1060600@ericsson.com> Message-ID: <20061005110309.O50730@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: text/plain Magnus, > During the IETF last call for "Multicast Requirements for a Network > Address Port Translator (NAPT)" (draft-ietf-behave-multicast-03) some > issues have come up. They all evolve about the binding that a NAT needs > to create when a host on the inside of the NAT sends traffic either to > the multicast group or to a feedback receiver in SSM (such as in > draft-ietf-avt-rtcpssm). One issue that exist here is in relation to RTP > and its collision detection mechanism. > > draft-ietf-behave-nat-udp does specify that outgoing UDP NAT binding > shall be kept alive for at least 2 minutes. However for a certain amount > of participants and a given RTCP bit-rate the RTCP reporting interval > will become longer than the minimum binding lifetime. In those cases > there is the risk that each message sent will have a different source IP > address and UDP port tuple. That can trigger the RTP collision detection > mechanism as described in section 8.2 of RFC 3550. One of the changes from RFC 1889 to RFC 3550 was the following: o In Section 8.2, the requirement that a new SSRC identifier MUST be chosen whenever the source transport address is changed has been relaxed to say that a new SSRC identifier MAY be chosen. Correspondingly, it was clarified that an implementation MAY choose to keep packets from the new source address rather than the existing source address when an SSRC collision occurs between two other participants, and SHOULD do so for applications such as telephony in which some sources such as mobile entities may change addresses during the course of an RTP session. Thus, it seems that the "MAY" clauses allow the address change to be tolerated without any additional mechanism. It is an open question whether existing receiver implementations will behave this way. > To avoid these issue in most cases when transmitting to ASM multicast > groups we propose that NAT will keep bindings for 1 hour. To clarify > that means no change to the bindings going to unicast addresses, only > packets that has a multicast group as destination address. The collision > issue may now occur for sessions that has average RTCP reporting > interval that is longer than 40 minutes instead of 80 seconds. We > understand that this will not resolve the issue for sessions that would > like to run in this configuration. Adding that requirement seems reasonable and useful to me. Since the number of ASM multicast sessions is likely to be small, that should not cause significant resource conflicts for the NAPT. > For SSM sessions it would be best if the feedback receiver and media > receivers primarily looks at the CNAME for determining SSRC collision > and not network addresses. This seems necessary anyway for the media > receivers in simple feedback mode as all RTCP packets will seem to come > from the distribution source, thus address checking is useless. > Collisions can only be found by checking the CNAME. In fact I think this > is something that is required to be clarified in draft-ietf-avt-rtcpssm > or otherwise all receivers will constantly detect collisions with there > own RTCP packets. Regarding the last sentence, a participant would not receive its own SSRC with two different addresses, but you are right that it might consider the receipt of its own reflected RTCP packets as a collision. It is worth a note in draft-ietf-avt-rtcpssm. > In the RTCP SSM summary mode the situation is somewhat different. For > the feedback target, the address would be useful for determining that > RTCP packet arrives from different sources. However in the presence of > NATs this becomes a source of error. I wrote primarily look at CNAME in > the previous paragraph. The reason for this is the remaining issue of > loop detection. If one completely skips using the source address one > will can't determine if some packets constantly comes back from another > address and actually should be blocked for that reason. Here I don't > have any brilliant ideas on how to resolve this issue. I don't have any suggestions either, other than eliminate NAT. :-) -- Steve From srisuresh@yahoo.com Thu, 5 Oct 2006 17:35:59 -0500 (CDT) (envelope-from srisuresh@yahoo.com) From: Pyda Srisuresh Date: Thu, 5 Oct 2006 17:35:59 -0500 (CDT) (envelope-from srisuresh@yahoo.com) Subject: Re: [Ietf-behave] I-D ACTION:draft-ietf-behave-nat-icmp-01.txt In-Reply-To: Message-ID: <20061005223550.71142.qmail@web33309.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Gentlefolks, Below is a summary of updates that went into the new rev of ICMP draft. I folded in all comments I received on the previous rev into this rev. Some of the comments were on the list and some I received in private. Please review and post any comments you might have to the list. Thanks. 1. REQ-1 & REQ-2: Added justification text for these requirements. 2. REQ-3: Redid the text to be transport agnostic. Also added a requirement on traversing past IP options in the embedded packet. 3. REQ-4 & REQ-5: Drew two additional figures to explain inbound and outbound ICMP error messages. Reworded the requirements text to be easier read. Removed text that refered to IP & ICMP checksum updates, as all NATs are assumed to do this already (per RFC 3022). 4. REQ-7: Added a new requirement to support ICMP hairpinning. 5. Miscellaneous text changes. regards, suresh --- Internet-Drafts@xxxxxxxx wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance > Working Group of the IETF. > > Title : NAT Behavioral Requirements for ICMP protocol > Author(s) : P. Srisuresh, et al. > Filename : draft-ietf-behave-nat-icmp-01.txt > Pages : 21 > Date : 2006-10-5 > > This document identifies the behavioral properties required of the > Network Address Translator (NAT) devices in conjunction with the > ICMP protocol. The objective of this memo is to make NAT devices > more predictable and compatible with diverse application protocols > that traverse the devices. Companion documents provide behavioral > recommendations specific to TCP, UDP and other protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-behave-nat-icmp-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@xxxxxxxxx > In the body type: > "FILE /internet-drafts/draft-ietf-behave-nat-icmp-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From Kai.Vehmanen@nokia.com Fri, 6 Oct 2006 03:30:31 -0500 (CDT) (envelope-from Kai.Vehmanen@nokia.com) From: Date: Fri, 6 Oct 2006 03:30:31 -0500 (CDT) (envelope-from Kai.Vehmanen@nokia.com) Subject: Re: [Ietf-behave] STUN Server Discovery In-Reply-To: Message-ID: <719D5CCC2F6E3644B0A9F5C9B1D000880224A726@esebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain Hello, On 04 October 2006, Cullen Jennings wrote: >> I disagree with this one. There are definitely implementations out >> there, >Can you point me at a deployed one - I've been looking for >some flows I can capture to show as an example. uhm, that's more difficult to answer. ;) There are definitely implementations. One is for example part of the the Sofia-SIP open-source SIP stack. And there have been other implementations at testing events. But I do not know of any widescale deployments (anyone else on the list?).... Still, the problem remains. As there are clients implemented according to RFC3489 - including the shared-secret discovery part, upgrades to the servers should not break these clients. Specifically, these clients will make SRV queries for "_stun._tcp", and it would be harmful to reuse this service name for something else in the bis draft. -- first.surname@xxxxxxxxx (Kai Vehmanen) Networking Technologies Laboratory, Nokia Research Center From rohan.mahy@gmail.com Fri, 6 Oct 2006 15:23:02 -0500 (CDT) (envelope-from rohan.mahy@gmail.com) From: "Rohan Mahy" Date: Fri, 6 Oct 2006 15:23:02 -0500 (CDT) (envelope-from rohan.mahy@gmail.com) Subject: [Ietf-behave] updated version of TURN Message-ID: <953beacc0610061322l5defe155l7ff4f023364cb81d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Hi Folks, TURN expired due to an error on my part submitting -01. Also many folks who hadn't read the minutes from Montreal were asking questions about the door concept. I just submitted an update (an -02) which is just a stopgap. It removes the door concept and has a handful of other fixes, but does not incoroporate all the changes we agreed to make to the document. I am still planning to submit an -03 before San Diego. If anyone wants to see the draft before it appears, it is available here: http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-turn-02.html http://scm.sipfoundry.org/rep/ietf-drafts/behave/draft-ietf-behave-turn-02.txt thanks, -rohan From lowekamp@sipeerior.com Mon, 9 Oct 2006 12:56:49 -0500 (CDT) (envelope-from lowekamp@gmail.com) From: "Bruce Lowekamp" Date: Mon, 9 Oct 2006 12:56:49 -0500 (CDT) (envelope-from lowekamp@gmail.com) Subject: [Ietf-behave] review of rfc3489bis-04 Message-ID: <20d2bdfb0610091056iba0cf7bx9ecc431a2e7a777a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Review of draft-ietf-behave-rfc3489bis-04 Bruce B. Lowekamp College of William and Mary and SIPeerior Technologies, Inc. I waited to write this review until we completed implementing this STUN draft inside the reSIProcate stack. A number of these comments stem from the design of that implementation, which does initial classification and parsing at the stack layer and then passes the message up for further processing at the dialog/application level when necessary. I've grouped comments into two sections: protocol issues, where I think the current specification should be changed in some way, and document clarifications, where I think the draft has a mistake that doesn't reflect the intention of the protocol. I also made some notes on a few more general clarity and grammar issues that I am forwarding to Jonathan separately. Having worked with a previous implementation guided only by the original 3489 and also worked with this version, 3489bis is significantly cleaner and easier to read, understand, and implement. Tiffany Broadbent did a lot of the implementation and many of these comments stem from questions she brought up while developing. Protocol issues: There are several issues that are motivated by the combination of supporting new usages as extensions and trying to integrate our implementation into an entire SIP stack. - It would be much easier to implement a stack-level for STUN if specific bits indicated whether a message is a request, response, error response, or indication. In several spots the draft refers to response and error response types as 0x100 and 0x110 higher, which I assume is intended to indicate bits to be set, but I don't think it technically reads that way. However, no way of determining whether a type is an indication is mentioned in the draft. Providing for future message types to be identified without recompiling the code with a new list of types for a new usage would be very helpful. - There are a number of issues if future usages are defined that are not idempotent. For example, Section 6 allows bit-wise identical requests to use the same transaction ID. I assume this is intended to simplify periodic keepalives for low-power devices, however I don't think that assuming re-using transaction IDs is safe for future usages is a good idea. I suggest revising the two sentences (or one if changed) in that paragraph that allow TID reuse to indicate that TIDs cannot be reused except for retransmissions of the same request unless allowed by the particular usage. - In a similar vein, there is currently no specification for how long a server must remember a previous TID to ensure that a retransmission or duplication is not processed twice. Also, there is no longer any specification of what a client should do if it receives a duplicate response. Seems like in both cases there should be a suggestion to remember the previous TID for 9500ms to avoid processing the same transaction multiple times. - Why is DTLS not mentioned? - I would like to see an overall transaction timer. Multiplying the 9500ms request timeout by a set of shared secret, nonce, ALTERNATE-SERVER, and SRV cycles, the worst-case time for a single transaction is quite bad. A misconfigured set of servers could set up an ALTERNATE-SERVER loop. - Are NONCEs intended to be used to challenge each individual request/response or as a per-session value? Section 8.3.2 says that NONCE values should be cached and reused on subsequent request/response. 8.3.1, item 2 says: "The message would not contain the NONCE attribute," and at the end of the list the next paragraph says that the NONCE is included only if the request is a retry as a consequence of an error response. I think item 2 of 8.3.1 should say "The message MUST NOT contain the REALM attribute," regardless of the NONCE issue. My impression previously has been that the intention of the NONCE is to default to a per-session value unless the server wants to authenticate more often, but 8.3.1 doesn't seem to support that. - I don't see an error code for unknown message type. Perhaps 405? (generating these properly also requires being able to identify whether the unknown type is a request or an indication) - 8.3.2 436 response: this would be the wrong error code for an expired short-term, but should the client get another shared-secret if the username was acquired through a shared-secret request? - 8.3.2 500 response: several? - We had a discussion at the last IETF of whether to retain the current fingerprint, switch to a CRC, use a keyed CRC, or drop it. I believe the consensus was to switch to a keyed CRC, but after implementing this draft, I would favor making the fingerprint optional. IMHO, the application multiplexing stun and application data is in the best position to identify whether it is needed, and in the vast majority of cases, it isn't needed. Even with our generic implementation, it would be trivial for us to add an option to include or not include FINGERPRINT when we're multiplexing over a single socket, and none of our current applications would require it. - 11.6: for our implementation, it was useful to use 408 and 484 to deliver errors from the stack to the application layer. Since STUN isn't designed to be proxied, it may not make sense to include them here, but it does make the implementation easier to use them. - 11.9 why not just pad out the extra field? - in section 12, there is an explicit assumption that binding requests will always require integrity, but keepalives won't. I don't think I agree with this in all cases. If using STUN for binding inside a TLS connection, I don't think integrity is required. In the keepalive case, I also don't think I agree that re-establishing a session is necessarily a trivial cost in time or in lost behavior. First, a lot of work has been done with sip-outbound to stage this sort of reconnection. Secondly, since STUN will be applied to other protocols beside SIP, I think this distinction assumes characteristics of the application protocol that are not known in advance. I would prefer SHOULD-level strength here, and some discussion of how to choose when to require message integrity and when not to. - 12.3.1: should a changed binding be interpreted as a clue to reduce the refresh interval? (I assume the answer is yes, and mostly think it should be explicitly suggested by the text) - 12.3.2: assuming that keepalives are used for a fixed server also extends from assuming SIP is the application protocol. This assumption should probably be weakened/removed. - 12.4.1/12.4.7: one says shared-secrets are specific to SRV Priority, the other to domain name Document clarifications: section 6: as mentioned on the mailing list, the header includes the magic cookie and the body has at least one attribute in the current spec. section 6, 3rd par: stun can also run over TLS/TCP, right? end of 7.1 and 7.2: I think these are supposed to say the same thing about trying multiple SRV results, but it's a bit confusing since they're worded completely differently. I prefer the 7.1 version. end of 8.2: should refer to a section 8.3.2 first par: what if there is a MESSAGE-INTEGRITY in the response but not request 8.3.2 starting after the second paragraph: Every paragraph has a sentence or two, worded slightly differently, about using a NONCE if returned. Can this be grouped into a single paragraph before the long list? Also, toward the end of the section, there is the paragraph that refers to caching NONCEs. This paragraph should be moved here along with the global NONCE rules. 8.3.2 starting after the second paragraph: After each code, put the parenthesized reason phrases from 11.6. It's too hard to read with just the codes. 8.3.2 third par: remind that the long-term password is pre-provisioned here - 8.3.2 300 response: should the same s-t credentials be used? depends on domain or on srv response? - 8.3.2 500 paragraph: Unknown response codes should start a new paragraph, 3XX should be included. - 8.3.2 paragraph after 500: I think this should say that the unknown optional attributes should be ignored, not a response containing unknown optional attributes. - 8.3.2 last two paragraphs: why are these two paragraphs here? Seems like they should be later on in the sections describing handling the attributes. - 8.3.1 and 8.4: UDP can be pipelined, as well. - 9.1 the one sentence before 9.1.1 seems to apply only to 9.1.1 - 9.1.1 1st par: can do stun binding over tls too, as well - 9.1.1: there are two different paragraphs that refer to generating a 432 if the USERNAME is not present. - 9.1.1: can there be one paragraph describing the possibility of attaching a NONCE to almost every error response? - 9.1.2: exclusive-or of the source IP address and port from the request -> exclusive-or of the source transport address and magic cookie. - 9.1.2: before the FINGERPRINT paragraph, there should be a paragraph that if the request contained MESSAGE-INTEGRITY, the response must have MESSAGE-INTEGRITY generated to match 8.3.2 - 9.1.2: FINGERPRINT paragraph : indication->response - 9.1.2 last sentence: requests defined -> usages defined - end of 9.2: depends on the message type -> depends on the usage. for consistency with earlier client discussion. - 10 end of 1st par: requests and responses -> messages and indications - 11 Figure 4: I think MESSAGE-INTEGRITY should be C for Response and Error Response based on 8.3.2 requiring it if the request used it. - 11.1: should probably say IP addr is in network byte order - 11.3: used as the HMAC *key* in the - 11.4: why "generally"? - 11.4 last sentence: shared secret->password to include both short and long term? - 12.2.1/12.2.7: 12.2.1 "assumed" that the rendezvous gives the shared secret, 12.2.7 says it MUST - 12.2.2 last sentence: actual communications -> application data traffic. - 12.4.1 is 9 minutes a MUST? - 12.4.9: the very end refers to REFLECTED-FROM. I know this is a historical leftover, but I can't figure out what the sentence is trying to say. - 14.1: since this draft allows for and refers to extensions, including stun-relay explicitly, I think it's better to say something like STUN is intended to provide the functionality necessary to describe how to connect two endpoints regardless of the location of type of NATs in the topology. From Internet-Drafts@ietf.org Mon, 9 Oct 2006 14:50:16 -0500 (CDT) (envelope-from ietf@ietf.org) From: Internet-Drafts@ietf.org Date: Mon, 9 Oct 2006 14:50:16 -0500 (CDT) (envelope-from ietf@ietf.org) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-turn-02.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-turn-02.txt Pages : 49 Date : 2006-10-9 This specification defines a usage of the Simple Traversal of UDP Through NAT (STUN) Protocol for asking the STUN server to relay packets towards a client. This usage is useful for elements behind NATs whose mapping behavior is address and port dependent. The extension purposefully restricts the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the STUN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-turn-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-turn-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From dwing@cisco.com Tue, 10 Oct 2006 13:08:53 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Tue, 10 Oct 2006 13:08:53 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: [Ietf-behave] BEHAVE presentations Message-ID: <085b01c6ec97$132e0e00$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain If you'd like a time slot in BEHAVE, please unicast me the I-D and the amount of time you want. -d From srisuresh@yahoo.com Tue, 10 Oct 2006 13:24:55 -0500 (CDT) (envelope-from srisuresh@yahoo.com) From: Pyda Srisuresh Date: Tue, 10 Oct 2006 13:24:55 -0500 (CDT) (envelope-from srisuresh@yahoo.com) Subject: Re: [Ietf-behave] p2p-state as new milestone? In-Reply-To: <0e9901c6e7d7$a9338a70$c5f0200a@amer.cisco.com> Message-ID: <20061010182445.22357.qmail@web33303.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Dan, Let me clarify on the applicability of the p2p-state draft to the WG. The document provides the current state of NAT traversal techniques in use by P2P applications. As such, this provides a background for the recommendations in draft-ford-behave-app-04.txt, which is currently a candidate for the "protocol design techniques for using the existing set of NAT traversal approaches" milestone. For this reason, I requested for the p2p-state draft to be advanced as informational RFC. My read of the charer for this WG is that it is focussed on requirements and BCP documents. So, initialy (a few months ago), I requested Magnus to review this as independent submission, to which he readily agreed. The doucment was sent for review on both behve and p2psip lists. The current rev of the draft folds in all the comments received during that review. Later, Magnus clarified that he believed that the draft indeed is within the WG charter and as such should be progressed as WG document. Hence my request to consider this as WG draft. I understand, you are aware of the events preceding the request. But, I am sending this note for the benefit of the WG at large. Thanks. regards, suresh --- Dan Wing wrote: > The authors of draft-srisuresh-behave-p2p-state have asked us to adopt the > document to become a working group document. We don't currently have a > milestone for such a work item, so a new milestone (and date) would need to > be created. > > To adopt the document I would like some discussion on the list around this > document's applicability to the WG. We will also need at least two WG > volunteers for ongoing technical review as the document progresses. > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p-state-04.txt > > -d > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From spencer@mcsr-labs.org Tue, 10 Oct 2006 14:52:22 -0500 (CDT) (envelope-from spencer@mcsr-labs.org) From: "Spencer Dawkins" Date: Tue, 10 Oct 2006 14:52:22 -0500 (CDT) (envelope-from spencer@mcsr-labs.org) Subject: Re: [Ietf-behave] p2p-state as new milestone? In-Reply-To: <20061010182445.22357.qmail@web33303.mail.mud.yahoo.com> Message-ID: <227101c6eca5$36b74fe0$0300a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain Speaking only for myself... Dan, Let me clarify on the applicability of the p2p-state draft to the WG. The document provides the current state of NAT traversal techniques in use by P2P applications. As such, this provides a background for the recommendations in draft-ford-behave-app-04.txt, which is currently a candidate for the "protocol design techniques for using the existing set of NAT traversal approaches" milestone. For this reason, I requested for the p2p-state draft to be advanced as informational RFC. My read of the charer for this WG is that it is focussed on requirements and BCP documents. So, initialy (a few months ago), I requested Magnus to review this as independent submission, to which he readily agreed. The doucment was sent for review on both behve and p2psip lists. The current rev of the draft folds in all the comments received during that review. Later, Magnus clarified that he believed that the draft indeed is within the WG charter and as such should be progressed as WG document. Hence my request to consider this as WG draft. I understand, you are aware of the events preceding the request. But, I am sending this note for the benefit of the WG at large. At the P2PSIP ad hoc in Montreal, my understanding was that the proposed P2PSIP charter points to BEHAVE for NAT traversal issues, so my conclusion from that understanding is that the draft is more likely to get community review in BEHAVE than outside BEHAVE, and the topic is closer to BEHAVE's scope than any other obvious working group. Thanks, Spencer From Internet-Drafts@ietf.org Wed, 11 Oct 2006 14:50:16 -0500 (CDT) (envelope-from ietf@ietf.org) From: Internet-Drafts@ietf.org Date: Wed, 11 Oct 2006 14:50:16 -0500 (CDT) (envelope-from ietf@ietf.org) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-nat-udp-08.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for Unicast UDP Author(s) : F. Audet, C. Jennings Filename : draft-ietf-behave-nat-udp-08.txt Pages : 29 Date : 2006-10-11 This document defines basic terminology for describing different types of NAT behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or on-line gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-nat-udp-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-nat-udp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From zhouhong@huawei.com Thu, 12 Oct 2006 01:30:48 -0500 (CDT) (envelope-from zhouhong@huawei.com) From: Stephen Zhou Date: Thu, 12 Oct 2006 01:30:48 -0500 (CDT) (envelope-from zhouhong@huawei.com) Subject: Re: [Ietf-behave] I-D ACTION:draft-ietf-behave-nat-udp-08.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi Francois, Has this draft been change to Standard Track category? But It is a BCP in the WG charter. Thanks! BR, Stephen -----Original Message----- From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Internet-Drafts@xxxxxxxx Sent: Thursday, October 12, 2006 3:50 AM To: i-d-announce@xxxxxxxx Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-nat-udp-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for Unicast UDP Author(s) : F. Audet, C. Jennings Filename : draft-ietf-behave-nat-udp-08.txt Pages : 29 Date : 2006-10-11 This document defines basic terminology for describing different types of NAT behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or on-line gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-nat-udp-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-nat-udp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From dwing@cisco.com Thu, 12 Oct 2006 12:25:17 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Thu, 12 Oct 2006 12:25:17 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: [Ietf-behave] Application milestone Message-ID: <1e9701c6ee23$5c8c4340$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain The authors of draft-ford-behave-app-04.txt have proposed the WG to adopt that document to meet an existing BEHAVE milestone: Dec 2006 Submit a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches to IESG Please review draft-ford-behave-app-04.txt and comment to the list on its suitability for that milestone -- if more sections are needed, we need to combine it with other work, or its suitability as-is. I hope to have one of the authors present the document at San Diego meeting. -d From dwing@cisco.com Thu, 12 Oct 2006 15:29:06 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Thu, 12 Oct 2006 15:29:06 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] I-D ACTION:draft-ietf-behave-nat-udp-08.txt In-Reply-To: Message-ID: <23bf01c6ee3d$0a8b39b0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain It is BCP, and the approval notification as a BCP just went out a few moments ago, http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg03026.html I expect Francois upgraded his XML2RFC to 1.31, which adds an "Intended Status:" header. Thanks for noticing the error. It will get fixed prior to publication as an RFC. -d > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Stephen Zhou > Sent: Wednesday, October 11, 2006 11:25 PM > To: audet@xxxxxxxxxx > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] I-D ACTION:draft-ietf-behave-nat-udp-08.txt > > Hi Francois, > Has this draft been change to Standard Track category? > But It is a BCP in the WG charter. > Thanks! > > BR, > Stephen > > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Internet-Drafts@xxxxxxxx > Sent: Thursday, October 12, 2006 3:50 AM > To: i-d-announce@xxxxxxxx > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-nat-udp-08.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. > > Title : NAT Behavioral Requirements for Unicast UDP > Author(s) : F. Audet, C. Jennings > Filename : draft-ietf-behave-nat-udp-08.txt > Pages : 29 > Date : 2006-10-11 > > This document defines basic terminology for describing different > types of NAT behavior when handling Unicast UDP and also defines a > set of requirements that would allow many applications, such as > multimedia communications or on-line gaming, to work consistently. > Developing NATs that meet this set of requirements will greatly > increase the likelihood that these applications will function > properly. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-08.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@xxxxxxxx with the word unsubscribe in > the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-behave-nat-udp-08.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@xxxxxxxxx > In the body type: > "FILE /internet-drafts/draft-ietf-behave-nat-udp-08.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From guillaume.fortaine@wanadoo.fr Thu, 12 Oct 2006 16:44:25 -0500 (CDT) (envelope-from guillaume.fortaine@wanadoo.fr) From: William DUCK Date: Thu, 12 Oct 2006 16:44:25 -0500 (CDT) (envelope-from guillaume.fortaine@wanadoo.fr) Subject: [Ietf-behave] TURN/STUN/ICE Open Source Message-ID: <200610122344.10997.guillaume.fortaine@wanadoo.fr> MIME-Version: 1.0 Content-Type: text/plain Hello, I would want to know if one day an open source implementation of ICE will be available . http://www.voip-info.org/wiki-STUN http://sourceforge.net/projects/stun/ http://tools.ietf.org/wg/behave/draft-ietf-behave-rfc3489bis/draft-ietf-behave-rfc3489bis-04.txt http://www.voip-info.org/wiki/view/TURN http://tools.ietf.org/wg/behave/draft-ietf-behave-turn/draft-ietf-behave-turn-02.txt http://www.voip-info.org/wiki/view/ICE http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-ice/draft-ietf-mmusic-ice-11.txt Best Regards, Will From spencer@mcsr-labs.org Thu, 12 Oct 2006 22:34:52 -0500 (CDT) (envelope-from spencer@mcsr-labs.org) From: "Spencer Dawkins" Date: Thu, 12 Oct 2006 22:34:52 -0500 (CDT) (envelope-from spencer@mcsr-labs.org) Subject: Re: [Ietf-behave] p2p-state as new milestone? In-Reply-To: <0e9901c6e7d7$a9338a70$c5f0200a@amer.cisco.com> Message-ID: <2bc601c6ee78$326fed00$0300a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Dan, The authors of draft-srisuresh-behave-p2p-state have asked us to adopt the document to become a working group document. We don't currently have a milestone for such a work item, so a new milestone (and date) would need to be created. To adopt the document I would like some discussion on the list around this document's applicability to the WG. We will also need at least two WG volunteers for ongoing technical review as the document progresses. http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p-state-04.txt I should have also noted that I would be willing to serve as one of the technical reviewers. Sorry for omitting this from my previous posting. (Oh, am I supposed to read e-mail past the first paragraph?) Thanks, Spencer From ssenthil@cisco.com Fri, 13 Oct 2006 09:42:52 -0500 (CDT) (envelope-from ssenthil@cisco.com) From: "Senthil Sivakumar \(ssenthil\)" Date: Fri, 13 Oct 2006 09:42:52 -0500 (CDT) (envelope-from ssenthil@cisco.com) Subject: Re: [Ietf-behave] Application milestone Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0271A65F@xmb-sjc-236.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Dan Wing (dwing) > Sent: Thursday, October 12, 2006 1:25 PM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Cc: 'Dan Kegel' > Subject: [Ietf-behave] Application milestone > > The authors of draft-ford-behave-app-04.txt have proposed the > WG to adopt that document to meet an existing BEHAVE milestone: > > Dec 2006 Submit a BCP that discusses protocol > design techniques for using the existing > set of NAT traversal approaches to IESG > > > Please review draft-ford-behave-app-04.txt and comment to the > list on its suitability for that milestone -- if more > sections are needed, we need to combine it with other work, > or its suitability as-is. I support adopting the draft as a WG document. I would be willing to review the draft as it progresses. Senthil > > I hope to have one of the authors present the document at San > Diego meeting. > > -d > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From jdrosen@cisco.com Fri, 13 Oct 2006 15:20:54 -0500 (CDT) (envelope-from jdrosen@cisco.com) From: Jonathan Rosenberg Date: Fri, 13 Oct 2006 15:20:54 -0500 (CDT) (envelope-from jdrosen@cisco.com) Subject: Re: [Ietf-behave] STUN Server Discovery In-Reply-To: <719D5CCC2F6E3644B0A9F5C9B1D000880224A726@esebe104.NOE.Nokia.com> Message-ID: <452FF51A.6040704@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Kai.Vehmanen@xxxxxxxxx wrote: Hello, On 04 October 2006, Cullen Jennings wrote: I disagree with this one. There are definitely implementations out there, Can you point me at a deployed one - I've been looking for some flows I can capture to show as an example. uhm, that's more difficult to answer. ;) There are definitely implementations. One is for example part of the the Sofia-SIP open-source SIP stack. And there have been other implementations at testing events. But I do not know of any widescale deployments (anyone else on the list?).... My concern is that whats in RFC 3489 is a mistake. A big one. It conflates the transport protocol with the usage. Those are totally separated in RFC3489bis. I am loathe to retain this mistake in 3489bis to maintain backwards compatibility with implementations that are not in active deployment. IETF does not guarantee backwards compatibility across revisions of specs. When we went from RFC2543 to RFC3261 is was MOSTLY backwards compatible. We did remove some features and change some things. For example, we removed the absolute date format for registrations and focused on relative times, due to interop problems found in time synchronization. This did break interoperability in the sense that there were *implementations* of the absolute date format, but no real deployments that were truly impacted by this. The result is that this has been a non-event. Still, the problem remains. As there are clients implemented according to RFC3489 - including the shared-secret discovery part, upgrades to the servers should not break these clients. Specifically, these clients will make SRV queries for "_stun._tcp", and it would be harmful to reuse this service name for something else in the bis draft. In order to allow STUN to be extensible to other usages and still have a story on DNS discovery, we need to be able to have DNS queries of the form: _usage._transport.domainname if we retain backwards compatibility this pattern is broken. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Fri, 13 Oct 2006 15:32:22 -0500 (CDT) (envelope-from jdrosen@cisco.com) From: Jonathan Rosenberg Date: Fri, 13 Oct 2006 15:32:22 -0500 (CDT) (envelope-from jdrosen@cisco.com) Subject: Re: [Ietf-behave] Compatibility between RFC3489 anddraft-ietf-behave-rfc3489bis-04 In-Reply-To: <10c501c6e702$c782d970$c5f0200a@amer.cisco.com> Message-ID: <452FF7C9.9000304@cisco.com> MIME-Version: 1.0 Content-Type: text/plain inline. Alfred E. Heggestad wrote: Dan Wing wrote: * rfc3489bis-04 compliant STUN client against RFC3489-compliant STUN server: The STUN request contains the new FINGERPRINT attribute, but this attribute is not supported by the STUN server (Vovida.org 0.96), hence the response is dropped. That shouldn't be a problem for the RFC3489bis-compliant STUN client. The primary purpose of this attribute is to provide an additional distinguisher for STUN/non-STUN packets. That is, there isn't any reason for an RFC3489bis-compliant STUN server to validate or check for that attribute. Similarly, it won't see the XOR-MAPPED-ADDRESS, either, because a RFC3489 STUN server won't return it. Thus, if the RFC3489bis client wants to interoperate with a RFC3489 STUN server, it needs to understand the responses sent by a RFC3489 server. many thanks for your answer. ok I understand that the new FINGERPRINT attribute to distinguish between STUN and non-STUN packets. prior to sending a STUN request, the STUN client cannot know which version of the spec the STUN server supports. so it can e.g. try to send a bis-04 compliant STUN request include the FINGERPRINT attrib and if it times out, then try to send a STUN request ala RFC3489.. Actually I have a better idea. I can change the value of FINGERPRINT to be in the range of optional attributes. This way, it will be ignored by an older RFC3489 implementation. Since muxing is not an issue in the classic rfc3489 stun usage, its fine. yes you are right. I have updated my STUN server now to support both flavours. although there is a (tiny) chance that the first 4 bytes of the TID generated by a RFC3489-client actually contains 0x2112a442. but I guess, if the a STUN request fails for this reason the client will just retry until it works.. It will be really, really rare. Given a packet loss of 10%, its actually more likely that all of teh requests in a transaction are lost than it is you'll run into this overlap. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From dbarrett@quinthar.com Sat, 14 Oct 2006 01:42:24 -0500 (CDT) (envelope-from dbarrett@quinthar.com) From: "David Barrett" Date: Sat, 14 Oct 2006 01:42:24 -0500 (CDT) (envelope-from dbarrett@quinthar.com) Subject: [Ietf-behave] GoogleWifi NAT Message-ID: <031101c6ef5b$e1420320$4600a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain I’m working on a p2p layer and testing on a variety of networks, and it appears that the Google WiFi network in Union Square (San Francisco) uses a NAT with unusual properties.  It’s a pretty normal symmetric NAT (address/port-dependent mapping and filtering), except it lets each UDP port only receive from precisely one remote host.   To give an example: 1)       Open a UDP socket on port A 2)       Send from A to remote host B 3)       B receives the packet and responds 4)       A receives B’s response just fine 5)       Send from A to remote host C 6)       C receives the packet and responds 7)      A never receives C’s response   That’s right, A can apparently send to any number of remote hosts, but can only receive from the first one it sends to.  Each remote host is assigned a different mapping (ie, if you send to two different STUN servers, each server sees a different port for A), but only the first server contacted can actually reply back along the route it sees.   I don’t recall the BEHAVE spec mentioning anything about this behavior, though speaking as a p2p developer, it’s pretty awful.  Has anyone else seen anything like this?   -david     From saikat@cs.cornell.edu Sat, 14 Oct 2006 01:53:54 -0500 (CDT) (envelope-from saikat@cs.cornell.edu) From: Saikat Guha Date: Sat, 14 Oct 2006 01:53:54 -0500 (CDT) (envelope-from saikat@cs.cornell.edu) Subject: Re: [Ietf-behave] GoogleWifi NAT In-Reply-To: <031101c6ef5b$e1420320$4600a8c0@Quinthar> Message-ID: <1160808814.3762.80.camel@sioux.systems.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630137.multipart/signed" --Boundary..27398.1163630137.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2006-10-13 at 23:42 -0700, David Barrett wrote: > To give an example: > 1) Open a UDP socket on port A > 2) Send from A to remote host B > 3) B receives the packet and responds > 4) A receives B’s response just fine > 5) Send from A to remote host C > 6) C receives the packet and responds > 7) A never receives C’s response I would call it either an unintentional bug, or an intentional (and brain-dead) firewall policy. > I don’t recall the BEHAVE spec mentioning anything about this > behavior, though speaking as a p2p developer, it’s pretty awful. Granted, it is a pain for P2P developers, I am not convinced this falls within the scope of BEHAVE (which explicitly excludes firewall behavior). Perhaps try to reach someone at Google (maybe via NANOG) to figure out whether this is intentional or accidental? -- Saikat Attachment: signature.asc --Boundary..27398.1163630137.multipart/signed Content-Type: application/octet-stream; name="pgpMNP2aVaPlk.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpMNP2aVaPlk.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC41IChHTlUv TGludXgpCgppRDhEQlFCRk1JbHVuRmx0cWk2OTEvb1JBbDd0QUo5bFZTeW9CbkVvWENNMisvb09K enJRcE9xaWZ3Q2ZmVnFNClp3UnM3UE9Dd3pyMVNBOVh0elBqZnJVPQo9bFVLOAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630137.multipart/signed-- From saikat@cs.cornell.edu Sat, 14 Oct 2006 01:56:13 -0500 (CDT) (envelope-from saikat@cs.cornell.edu) From: Saikat Guha Date: Sat, 14 Oct 2006 01:56:13 -0500 (CDT) (envelope-from saikat@cs.cornell.edu) Subject: Re: [Ietf-behave] Application milestone In-Reply-To: <1e9701c6ee23$5c8c4340$c5f0200a@amer.cisco.com> Message-ID: <1160808950.3762.83.camel@sioux.systems.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630137.multipart/signed" --Boundary..27398.1163630137.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2006-10-12 at 10:25 -0700, Dan Wing wrote: > The authors of draft-ford-behave-app-04.txt have proposed the WG to adopt > that document to meet an existing BEHAVE milestone: I am willing to support and review this document. Are there other contenders for the same milestone? I recall someone proposing the ICE document (more or less) as the behave-app document? -- Saikat Attachment: signature.asc --Boundary..27398.1163630137.multipart/signed Content-Type: application/octet-stream; name="pgpGpoBFcOkyh.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpGpoBFcOkyh.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC41IChHTlUv TGludXgpCgppRDhEQlFCRk1JbjJuRmx0cWk2OTEvb1JBcU5rQUp3SkoweHBGN3RnQTJxM2s4MGlx Sk93ak1ZSzd3Q2VKa0VhCjBYc1k2bysrbmZESUw0b0JVUTFGM1ZRPQo9Yk05YgotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630137.multipart/signed-- From kbiswas@cisco.com Sat, 14 Oct 2006 14:57:20 -0500 (CDT) (envelope-from kbiswas@cisco.com) From: "Kaushik Biswas \(kbiswas\)" Date: Sat, 14 Oct 2006 14:57:20 -0500 (CDT) (envelope-from kbiswas@cisco.com) Subject: Re: [Ietf-behave] p2p-state as new milestone? Message-ID: <378E78E5F361564BB066432F6415764B027DA9C9@xmb-sjc-228.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I am fine with adapting this as a WG document and would be willing to review the same as it progress. Thanks, Kaushik > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Pyda Srisuresh > Sent: Tuesday, October 10, 2006 11:25 AM > To: Dan Wing (dwing); ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] p2p-state as new milestone? > > Dan, > > Let me clarify on the applicability of the p2p-state draft to > the WG. The document provides the current state of NAT > traversal techniques in use by P2P applications. As such, > this provides a background for the recommendations in > draft-ford-behave-app-04.txt, which is currently a candidate > for the "protocol design techniques for using the existing > set of NAT traversal approaches" > milestone. For this reason, I requested for the p2p-state > draft to be advanced as informational RFC. > > My read of the charer for this WG is that it is focussed on > requirements and BCP documents. So, initialy (a few months > ago), I requested Magnus to review this as independent > submission, to which he readily agreed. The doucment was sent > for review on both behve and p2psip lists. The current rev of > the draft folds in all the comments received during that > review. Later, Magnus clarified that he believed that the > draft indeed is within the WG charter and as such should be > progressed as WG document. Hence my request to consider this > as WG draft. I understand, you are aware of the events > preceding the request. But, I am sending this note for the > benefit of the WG at large. > > Thanks. > > regards, > suresh > > --- Dan Wing wrote: > > > The authors of draft-srisuresh-behave-p2p-state have asked > us to adopt > > the document to become a working group document. We don't > currently > > have a milestone for such a work item, so a new milestone > (and date) > > would need to be created. > > > > To adopt the document I would like some discussion on the > list around > > this document's applicability to the WG. We will also need > at least > > two WG volunteers for ongoing technical review as the > document progresses. > > > > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p-state-0 > > 4.txt > > > > -d > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From aeh@db.org Sun, 15 Oct 2006 06:23:38 -0500 (CDT) (envelope-from aeh@db.org) From: "Alfred E. Heggestad" Date: Sun, 15 Oct 2006 06:23:38 -0500 (CDT) (envelope-from aeh@db.org) Subject: Re: [Ietf-behave] Compatibility between RFC3489 anddraft-ietf-behave-rfc3489bis-04 In-Reply-To: <10c501c6e702$c782d970$c5f0200a@amer.cisco.com> Message-ID: <45321A62.6060805@db.org> MIME-Version: 1.0 Content-Type: text/plain inline. Jonathan Rosenberg wrote: inline. Alfred E. Heggestad wrote: Dan Wing wrote: * rfc3489bis-04 compliant STUN client against RFC3489-compliant STUN server: The STUN request contains the new FINGERPRINT attribute, but this attribute is not supported by the STUN server (Vovida.org 0.96), hence the response is dropped. That shouldn't be a problem for the RFC3489bis-compliant STUN client. The primary purpose of this attribute is to provide an additional distinguisher for STUN/non-STUN packets. That is, there isn't any reason for an RFC3489bis-compliant STUN server to validate or check for that attribute. Similarly, it won't see the XOR-MAPPED-ADDRESS, either, because a RFC3489 STUN server won't return it. Thus, if the RFC3489bis client wants to interoperate with a RFC3489 STUN server, it needs to understand the responses sent by a RFC3489 server. many thanks for your answer. ok I understand that the new FINGERPRINT attribute to distinguish between STUN and non-STUN packets. prior to sending a STUN request, the STUN client cannot know which version of the spec the STUN server supports. so it can e.g. try to send a bis-04 compliant STUN request include the FINGERPRINT attrib and if it times out, then try to send a STUN request ala RFC3489.. Actually I have a better idea. I can change the value of FINGERPRINT to be in the range of optional attributes. This way, it will be ignored by an older RFC3489 implementation. Since muxing is not an issue in the classic rfc3489 stun usage, its fine. yes, that makes sense. the FINGERPRINT (or CRC32) attribute could be optional, but RECOMMENDED for checking the validity of a STUN message. the STUN server will always include this attribute for responses to rfc3489bis clients. yes you are right. I have updated my STUN server now to support both flavours. although there is a (tiny) chance that the first 4 bytes of the TID generated by a RFC3489-client actually contains 0x2112a442. but I guess, if the a STUN request fails for this reason the client will just retry until it works.. It will be really, really rare. Given a packet loss of 10%, its actually more likely that all of teh requests in a transaction are lost than it is you'll run into this overlap. ok fair enough.. /alfred Thanks, Jonathan R. From aeh@db.org Sun, 15 Oct 2006 11:14:25 -0500 (CDT) (envelope-from aeh@db.org) From: "Alfred E. Heggestad" Date: Sun, 15 Oct 2006 11:14:25 -0500 (CDT) (envelope-from aeh@db.org) Subject: [Ietf-behave] turn02 REQUESTED-TRANSPORT Message-ID: <45325E87.4060007@db.org> MIME-Version: 1.0 Content-Type: text/plain hi I have a questions about Section 10.7 in draft-ietf-behave-turn-02.txt: > 10.7 REQUESTED-TRANSPORT > > This attribute is used by the client to request a specific transport > protocol for the allocated transport address. It is a 32 bit > unsigned integer. Its values are: > > > 0x0000 0000: UDP > 0x0000 0001: TCP > > If an Allocate request is sent over TCP and requests a UDP > allocation, or an Allocate request is sent over TLS over TCP and > requests a UDP or TCP allocation, the server will relay data between > the two transports. > > Extensions to the relay usage can define additional transport > protocols. [[TODO: Add IANA registry]] Instead of defining two new values for UDP/TCP transport can we reuse e.g. the values defined in netinet/in.h: ... IPPROTO_TCP = 6, /* Transmission Control Protocol. */ IPPROTO_UDP = 17, /* User Datagram Protocol. */ ... this way implementors can avoid yet another mapping between STUN-specific values (e.g. Address Families) and host-specific values.. (POSIX) ;) /alfred From audet@nortel.com Sun, 15 Oct 2006 13:57:09 -0500 (CDT) (envelope-from AUDET@nortel.com) From: "Francois Audet" Date: Sun, 15 Oct 2006 13:57:09 -0500 (CDT) (envelope-from AUDET@nortel.com) Subject: Re: [Ietf-behave] GoogleWifi NAT In-Reply-To: <1160808814.3762.80.camel@sioux.systems.cs.cornell.edu> Message-ID: <1ECE0EB50388174790F9694F77522CCF0D8A9125@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain Just when we tought we've seen all possible bad NAT tricks.... > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Saikat Guha > Sent: Friday, October 13, 2006 11:54 PM > To: David Barrett > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] GoogleWifi NAT > > On Fri, 2006-10-13 at 23:42 -0700, David Barrett wrote: > > To give an example: > > 1) Open a UDP socket on port A > > 2) Send from A to remote host B > > 3) B receives the packet and responds > > 4) A receives B's response just fine > > 5) Send from A to remote host C > > 6) C receives the packet and responds > > 7) A never receives C's response > > I would call it either an unintentional bug, or an intentional (and > brain-dead) firewall policy. > > > I don't recall the BEHAVE spec mentioning anything about this > > behavior, though speaking as a p2p developer, it's pretty awful. > > Granted, it is a pain for P2P developers, I am not convinced > this falls within the scope of BEHAVE (which explicitly > excludes firewall behavior). Perhaps try to reach someone at > Google (maybe via NANOG) to figure out whether this is > intentional or accidental? > > -- > Saikat > From audet@nortel.com Sun, 15 Oct 2006 15:06:08 -0500 (CDT) (envelope-from AUDET@nortel.com) From: "Francois Audet" Date: Sun, 15 Oct 2006 15:06:08 -0500 (CDT) (envelope-from AUDET@nortel.com) Subject: Re: [Ietf-behave] p2p-state as new milestone? In-Reply-To: <2bc601c6ee78$326fed00$0300a8c0@china.huawei.com> Message-ID: <1ECE0EB50388174790F9694F77522CCF0D8A913A@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain It looks like the authors have significantly improved the draft from version -03 to align with the other documents of the BEHAVE working group, in particular with draft-ietf-behave-nat-udp. I do believe that the document (which should probably be INFORMATIONAL) has good information useful for the other documents in the BEHAVE working group. One minor note: the references need to be updated. For example, rev draft-ietf-behave-nat-udp to -08. I am willing to review as well. > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Spencer Dawkins > Sent: Thursday, October 12, 2006 8:32 PM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] p2p-state as new milestone? > > Hi, Dan, > > > > The authors of draft-srisuresh-behave-p2p-state have asked > us to adopt > > the document to become a working group document. We don't > currently > > have a milestone for such a work item, so a new milestone > (and date) > > would need to be created. > > > > To adopt the document I would like some discussion on the > list around > > this document's applicability to the WG. We will also need > at least > > two WG volunteers for ongoing technical review as the > document progresses. > > > > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p-state-0 > > 4.txt > > I should have also noted that I would be willing to serve as > one of the technical reviewers. Sorry for omitting this from > my previous posting. > > (Oh, am I supposed to read e-mail past the first paragraph?) > > Thanks, > > Spencer > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From lars.eggert@netlab.nec.de Sun, 15 Oct 2006 19:15:12 -0500 (CDT) (envelope-from lars.eggert@netlab.nec.de) From: Lars Eggert Date: Sun, 15 Oct 2006 19:15:12 -0500 (CDT) (envelope-from lars.eggert@netlab.nec.de) Subject: Re: [Ietf-behave] turn02 REQUESTED-TRANSPORT In-Reply-To: <45325E87.4060007@db.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Oct 16, 2006, at 1:15, Alfred E. Heggestad wrote: Instead of defining two new values for UDP/TCP transport can we reuse e.g. the values defined in netinet/in.h: These are taken from the IANA registry for protocol numbers (http:// www.iana.org/assignments/protocol-numbers), and I agree that using those numbers would be better than creating a new registry. Lars -- Lars Eggert NEC Network Laboratories From derek@counterpath.com Sun, 15 Oct 2006 22:38:13 -0500 (CDT) (envelope-from derek@counterpath.com) From: derek@counterpath.com Date: Sun, 15 Oct 2006 22:38:13 -0500 (CDT) (envelope-from derek@counterpath.com) Subject: [Ietf-behave] draft-macdonald-behave-nat-behavior-discovery-00 Message-ID: <47399.10.238.10.70.1160969882.webmail@10.238.10.70> MIME-Version: 1.0 Content-Type: text/plain Bruce and I submitted the NAT discovery draft discussed last IETF. Until in shows up in the repository you can find it at: https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdonald-behave-nat-behavior-discovery-00.txt and https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdonald-behave-nat-behavior-discovery-00.html -Derek From Remi.Denis-Courmont@nokia.com Mon, 16 Oct 2006 01:06:17 -0500 (CDT) (envelope-from Remi.Denis-Courmont@nokia.com) From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Date: Mon, 16 Oct 2006 01:06:17 -0500 (CDT) (envelope-from Remi.Denis-Courmont@nokia.com) Subject: Re: [Ietf-behave] GoogleWifi NAT In-Reply-To: <031101c6ef5b$e1420320$4600a8c0@Quinthar> Message-ID: <200610160907.27282.Remi.Denis-Courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain Le Saturday 14 October 2006 09:42, ext David Barrett a crit: > That's right, A can apparently send to any number of remote hosts, but can > only receive from the first one it sends to. Each remote host is assigned > a different mapping (ie, if you send to two different STUN servers, each > server sees a different port for A), but only the first server contacted > can actually reply back along the route it sees. I've seen worst NATs yet. Whenever it sees a UDP packet with a new internal IP/port tuple, slirp will record the destination IP/port tuple of that packet, and then NAT it. Then, whenever it receives a packet coming from the same internal IP/port tuple, it rewrites not only the source IP/port, but also the destination IP/port the same as with the first packet. As such, not only can you only reach one external host, but you will send it packets that were not intended to it... FYI, while slirp is very old, you can at least still find it in real use in the QEMU emulator networking code. I think it might make sense to document this limitation of some NATs (that they can only reach one destination). It might actually have some consequence as to how to handle TURN redirect message for instance: with such a NAT, you'd better open a new UDP socket and get a different internal source port if you switch TURN server. -- Rmi Denis-Courmont Assistant Research Engineer From bstucker@nortel.com Mon, 16 Oct 2006 10:17:21 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) From: "Brian Stucker" Date: Mon, 16 Oct 2006 10:17:21 -0500 (CDT) (envelope-from BSTUCKER@nortel.com) Subject: Re: [Ietf-behave] p2p-state as new milestone? In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0D8A913A@zrc2hxm0.corp.nortel.com> Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA8C@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain I would be willing to review the document, so there's your two. Regards, Brian > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Audet, Francois (SC100:3055) > Sent: Sunday, October 15, 2006 2:52 PM > To: Spencer Dawkins; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Ietf-behave] p2p-state as new milestone? > > It looks like the authors have significantly improved the > draft from version -03 to align with the other documents of > the BEHAVE working group, in particular with > draft-ietf-behave-nat-udp. > > I do believe that the document (which should probably be > INFORMATIONAL) has good information useful for the other > documents in the BEHAVE working group. > > One minor note: the references need to be updated. For > example, rev draft-ietf-behave-nat-udp to -08. > > I am willing to review as well. > > > > -----Original Message----- > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf > Of Spencer > > Dawkins > > Sent: Thursday, October 12, 2006 8:32 PM > > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [Ietf-behave] p2p-state as new milestone? > > > > Hi, Dan, > > > > > > > The authors of draft-srisuresh-behave-p2p-state have asked > > us to adopt > > > the document to become a working group document. We don't > > currently > > > have a milestone for such a work item, so a new milestone > > (and date) > > > would need to be created. > > > > > > To adopt the document I would like some discussion on the > > list around > > > this document's applicability to the WG. We will also need > > at least > > > two WG volunteers for ongoing technical review as the > > document progresses. > > > > > > > > > http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p-state-0 > > > 4.txt > > > > I should have also noted that I would be willing to serve as one of > > the technical reviewers. Sorry for omitting this from my previous > > posting. > > > > (Oh, am I supposed to read e-mail past the first paragraph?) > > > > Thanks, > > > > Spencer > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From lowekamp@sipeerior.com Mon, 16 Oct 2006 10:27:13 -0500 (CDT) (envelope-from lowekamp@gmail.com) From: "Bruce Lowekamp" Date: Mon, 16 Oct 2006 10:27:13 -0500 (CDT) (envelope-from lowekamp@gmail.com) Subject: Re: [Ietf-behave] p2p-state as new milestone? In-Reply-To: Message-ID: <20d2bdfb0610160827j6d6a124bu86ad720a1f394ccf@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain I think this document fits in with the charter's statement that the group will examine approaches that are already in use today and probably makes sense as an informational rfc. I support it for that purpose and am willing to serve as a reviewer. Bruce On 10/4/06, Dan Wing wrote: The authors of draft-srisuresh-behave-p2p-state have asked us to adopt the document to become a working group document. We don't currently have a milestone for such a work item, so a new milestone (and date) would need to be created. To adopt the document I would like some discussion on the list around this document's applicability to the WG. We will also need at least two WG volunteers for ongoing technical review as the document progresses. http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p-state-04.txt -d _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From srisuresh@yahoo.com Mon, 16 Oct 2006 10:37:30 -0500 (CDT) (envelope-from srisuresh@yahoo.com) From: Pyda Srisuresh Date: Mon, 16 Oct 2006 10:37:30 -0500 (CDT) (envelope-from srisuresh@yahoo.com) Subject: [Ietf-behave] Fw: P2P Communications across NAT Message-ID: <20061016153720.64142.qmail@web33302.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Forwarding an e-mail from Henry to the list, as this doesnt seem to have made to the list for some reason. regards, suresh ----- Forwarded Message ---- From: Henry Sinnreich To: ietf-behave@xxxxxxxxxxxxxxxxxxx Cc: Pyda Srisuresh Sent: Sunday, October 15, 2006 5:01:59 PM Subject: P2P Communications across NAT I would like to suggest that other related work is well suited for the BEHAVE WG charter, specifically the I-D of interest is State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) http://www.ietf.org/internet-drafts/draft-srisuresh-behave-p2p-state-04. txt Given the emerging work on P2P SIP, this I-D seems very timely and in scope for the BEHAVE WG. What do you all think? Thanks, Henry From dwing@cisco.com Mon, 16 Oct 2006 14:03:29 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Mon, 16 Oct 2006 14:03:29 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] p2p-state as new milestone? In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43715DFA8C@zrc2hxm2.corp.nortel.com> Message-ID: <073a01c6f155$be39a1c0$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Thanks, everyone. We will adopt p2p-state as a new milestone, and last call it pretty shortly. -d From jdrosen@cisco.com Mon, 16 Oct 2006 15:16:41 -0500 (CDT) (envelope-from jdrosen@cisco.com) From: Jonathan Rosenberg Date: Mon, 16 Oct 2006 15:16:41 -0500 (CDT) (envelope-from jdrosen@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <13bd01c6cd62$165b0230$c3f0200a@amer.cisco.com> Message-ID: <4533E89B.2020406@cisco.com> MIME-Version: 1.0 Content-Type: text/plain So, I went back and am re-reading various threads in RFC 3489bis as I work on the update, and this is a big one, and one that we did NOT resolve. The question again is whether or not to change the 100ms initial retransmit interval for STUN. Dan had proposed to make the algorithms/defaults different for each usage. I had proposed it should not be different per usage, but that the hard part is in the choosing of the initial value. Cullen proposed that we shouldn't muck with what we did in rfc3489 without really good reason, and Lars is (I think) advocating something better than what is in 3489bis today. To be clear, the big issue is that with ICE, the stun connectivity checks will almost always be to a host that is 'new' and for which a cached RTT estimate doesn't exist. Consequently, the checks will almost always use the default RTT. This is somewhat different than classic stun to a stun server (or the sip outbound usage) where you can do an RTT estimate. I do think, as others do, that the 3s retransmit timer for TCP is entirely too long for ICE for an initial RTT estimate. The metric to use here is that this directly impacts call setup. If you want ICE to have a chance to pick the optimal path even if it saw a packet loss, you need to wait this initial retransmit interval at least as an additional call setup time. I'd argue its probably a few times this to really give it a chance. If we use say 4x, thats 12s which is way too long for call setup. A more reasonable number is like 500ms-1000ms, and dividing by 4, well that gets us right back to around 125 to 250ms as the initial RTT estimate. So, I would be OK with a change which keeps the current number at 100ms, allows it to be configurable and gives guidance on doing so for wireless clients, and then uses a cached RTT if there is one, along with the standard TCP formulas for backoff. Thoughts? -Jonathan R. Lars Eggert wrote: On Sep 6, 2006, at 1:09, Cullen Jennings wrote: I will note that the PWE work allows an unlimited amount of bandwidth, has no backoff, is not TCP rate friendly, can be expected over all sorts of IP networks but most importantly for the discussion here ... did not seem to have issues with this in IETF LC and was approved by IESG. Actually, these issues were discussed and PWE3 will work on a common congestion control mechanism for their pseudowires, such that they can be used over best-effort networks. The current drafts say that people SHOULD really only run them over provisioned paths for that reason. Also, the deployment cases for pseudowires are different than for STUN/ICE, which I'd expect to run over much more diverse paths. In any event, I'm confident that we can come up with a retransmission scheme that will support ICE and not be too aggressive. One idea is that a sender can detect when it has sent a spurious retransmission, because it will receive some sort of acknowledgment from the receiver for message it has already retransmitted. In such a case, it could back off the retransmission timer a bit. This would allow STUN to start with a short timer that would lengthen when used over long- delay paths. Lars ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From dwing@cisco.com Mon, 16 Oct 2006 16:38:19 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Mon, 16 Oct 2006 16:38:19 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <4533E89B.2020406@cisco.com> Message-ID: <0c2f01c6f16b$5fde80d0$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain ... > So, I would be OK with a change which keeps the current > number at 100ms, allows it to be configurable and gives > guidance on doing so for wireless clients, Such guidance is helpful for the wireless client itself but its peer (which may be on a wired network) doesn't know the characteristics of that wireless technology (whatever those characteristics might be -- slow? lossy?). > and then uses > a cached RTT if there is one, along with the standard TCP > formulas for backoff. > > Thoughts? That should work. I expect you'll only allow an RTT to be cached for ~5 minutes, or until the connection is torn down, whichever occurs first? -d From jdrosen@cisco.com Mon, 16 Oct 2006 17:15:57 -0500 (CDT) (envelope-from jdrosen@cisco.com) From: Jonathan Rosenberg Date: Mon, 16 Oct 2006 17:15:57 -0500 (CDT) (envelope-from jdrosen@cisco.com) Subject: Re: [Ietf-behave] STUN retransmission timers In-Reply-To: <0c2f01c6f16b$5fde80d0$c3f0200a@amer.cisco.com> Message-ID: <4534048E.6070809@cisco.com> MIME-Version: 1.0 Content-Type: text/plain inline. Dan Wing wrote: ... So, I would be OK with a change which keeps the current number at 100ms, allows it to be configurable and gives guidance on doing so for wireless clients, Such guidance is helpful for the wireless client itself but its peer (which may be on a wired network) doesn't know the characteristics of that wireless technology (whatever those characteristics might be -- slow? lossy?). Since its a two-way handshake it may not really matter. The server side doesn't have to maintain a timer at all in fact. That said, Bruce has suggested in his comments that we are encountering requests that are not idempotent, such as TURN Allocate, and this means we DO need to have timers at the server for detecting idempotent requests, to resend the same response. So, there are two responses to that. Firstly, I actually need to think more about whether TURN really is or isn't idempotent. A redone Allocate request will probably just extend the existing binding lifetime rather than creating a new one, which is exactly what you want. If it turns out its not idempotent, then we could just impost a large server timer that holds onto the resposne to resend, say 20s. I'm hoping that TURN is idempotent however. Back soon on that one... and then uses a cached RTT if there is one, along with the standard TCP formulas for backoff. Thoughts? That should work. I expect you'll only allow an RTT to be cached for ~5 minutes, or until the connection is torn down, whichever occurs first? Hmm, not sure. Are there established norms for this? For sip-outbound you'll keep the cache fresh for a long time. However for binding discovery unless you make calls every 5min you'll lose the cached RTT to your default server. It would be nice if you could cache it much longer. I just don't know how long it is reasonable to assume its accurate. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From dwing@cisco.com Tue, 17 Oct 2006 19:25:19 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Tue, 17 Oct 2006 19:25:19 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: [Ietf-behave] NAT control stun usage Message-ID: <205501c6f24b$dd9ada60$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain If there is agenda time and interest, Jonathan or I will present this draft in San Diego. -d > -----Original Message----- > From: Internet-Drafts@xxxxxxxx [mailto:Internet-Drafts@xxxxxxxx] > Sent: Tuesday, October 17, 2006 12:50 PM > To: i-d-announce@xxxxxxxx > Subject: I-D ACTION:draft-wing-behave-nat-control-stun-usage-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Controlling NAT Bindings using STUN > Author(s) : D. Wing, J. Rosenberg > Filename : draft-wing-behave-nat-control-stun-usage-00.txt > Pages : 17 > Date : 2006-10-17 > > Simple Traversal Underneath NAT (STUN) is a mechanism for > traversing NATs. STUN requests are transmitted through a NAT to > external STUN servers. While this works very well, its two > primary drawbacks are the inability to modify the properties of a > NAT binding and the need to query a public STUN server for every > NAT binding. These drawbacks require frequent messages which > present a load on servers (like SIP servers and STUN servers) and > are bad for low speed access networks, such as cellular. This > document proposes that the STUN server be embedded in the NAT > itself, and describes how these STUN servers can be readily > discovered and utilized to reduce queries to public STUN servers > and to reduce NAT keepalive traffic. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wing-behave-nat-cont > rol-stun-usage-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@xxxxxxxx with the word unsubscribe in > the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-wing-behave-nat-control-stun-usage-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@xxxxxxxxx > In the body type: > "FILE > /internet-drafts/draft-wing-behave-nat-control-stun-usage-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > <<< Message/External-body; name="ATT06908.dat": Unrecognized >>> <<< Message/External-body; name="draft-wing-behave-nat-control-stun-usage-00.txt": Unrecognized >>> _______________________________________________ I-D-Announce mailing list I-D-Announce@xxxxxxxx https://www1.ietf.org/mailman/listinfo/i-d-announce From Internet-Drafts@ietf.org Wed, 18 Oct 2006 14:50:16 -0500 (CDT) (envelope-from ietf@ietf.org) From: Internet-Drafts@ietf.org Date: Wed, 18 Oct 2006 14:50:16 -0500 (CDT) (envelope-from ietf@ietf.org) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-p2p-state-00.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-p2p-state-00.txt Pages : 32 Date : 2006-10-18 This memo documents the various methods known to be in use by peer-to-peer (P2P) applications for communication in the presence of Network Address Translators (NATs) at the current time. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-p2p-state-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-p2p-state-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From srisuresh@yahoo.com Thu, 19 Oct 2006 08:42:06 -0500 (CDT) (envelope-from srisuresh@yahoo.com) From: Pyda Srisuresh Date: Thu, 19 Oct 2006 08:42:06 -0500 (CDT) (envelope-from srisuresh@yahoo.com) Subject: Re: [Ietf-behave] I-D ACTION:draft-ietf-behave-p2p-state-00.txt In-Reply-To: Message-ID: <20061019134156.70096.qmail@web33304.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain Much thanks to Spencer, Kaushik, Henry, Francois, Bruce and Brian for expressing their support to adapt the p2p-state draft as WG document. It is now a WG document and ready to progress as an informational RFC. The document fixes the rev levels of the references. Thanks, Francois, for pointing this out. regards, suresh --- Internet-Drafts@xxxxxxxx wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance > Working Group of the IETF. > > Title : State of Peer-to-Peer(P2P) Communication Across > Network Address > Translators(NATs) > Author(s) : P. Srisuresh, et al. > Filename : draft-ietf-behave-p2p-state-00.txt > Pages : 32 > Date : 2006-10-18 > > This memo documents the various methods known to be in use by > peer-to-peer (P2P) applications for communication in the presence > of Network Address Translators (NATs) at the current time. This > memo covers NAT traversal approaches used by both TCP and UDP > based applications. This memo is not an endorsement of the methods > described, but merely an attempt to capture them in a document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-behave-p2p-state-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@xxxxxxxxx > In the body type: > "FILE /internet-drafts/draft-ietf-behave-p2p-state-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From sunilkumar_j@spanservices.com Mon, 23 Oct 2006 07:54:05 -0500 (CDT) (envelope-from sunilkumar_j@spanservices.com) From: "SUNIL J. KUMAR" Date: Mon, 23 Oct 2006 07:54:05 -0500 (CDT) (envelope-from sunilkumar_j@spanservices.com) Subject: [Ietf-behave] SIP over TLS via NAT/Firewall Message-ID: <8DA47B9A5400DE40ADB30B051C215CCE02C05942@mail.spanservices.com> MIME-Version: 1.0 Content-Type: text/plain Hi, Would like to know about SIP negotiations on TLS. It is the fact that TLS strictly provides hop-by-hop security in a SIP Network and even encryption is also on hop-by-hop basis. It'll be great if someone let me know if there is a SIP ALG coexisting with NAT/Firewall on the edge of an enterprise network and there is a SIP Server on the public network. If suppose an UA sends a SIP request message on TLS, can it be incepted by NAT/Firewall on the edge or it'll bypass NAT/Firewall and directly go to the SIP Server on the public network? Private Network | Public Network | UA-----------------> NAT/Firewal l/SIP-ALG------------------------------------> SIP Server tls | tls | Regards, Sunil From Remi.Denis-Courmont@nokia.com Mon, 23 Oct 2006 08:05:38 -0500 (CDT) (envelope-from Remi.Denis-Courmont@nokia.com) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Date: Mon, 23 Oct 2006 08:05:38 -0500 (CDT) (envelope-from Remi.Denis-Courmont@nokia.com) Subject: Re: [Ietf-behave] SIP over TLS via NAT/Firewall In-Reply-To: <8DA47B9A5400DE40ADB30B051C215CCE02C05942@mail.spanservices.com> Message-ID: <200610231606.56127.Remi.Denis-Courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain Le Monday 23 October 2006 15:55, ext SUNIL J. KUMAR a crit: > It'll be great if someone let me know if there is a SIP ALG coexisting with > NAT/Firewall on the edge of an enterprise network and there is a SIP Server > on the public network. If suppose an UA sends a SIP request message on TLS, > can it be incepted by NAT/Firewall on the edge or it'll bypass NAT/Firewall > and directly go to the SIP Server on the public network? Obviously, the NAT won't be able to decipher the traffic, so it won't be able to act as SIP/SDP ALG. As for the firewall, it won't do connection tracking, so it won't be able to allow media to flow. And anyway, I doubt a NAT or a firewall would be willing to decipher and recipher SIP traffic even if it could. That being said, quite many SIP ALG out there are quite broken, so you might be better off with preventing these from seeing your SIP signaling. -- Rmi Denis-Courmont Assistant Research Engineer From dwing@cisco.com Mon, 23 Oct 2006 08:07:09 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Mon, 23 Oct 2006 08:07:09 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] SIP over TLS via NAT/Firewall In-Reply-To: <8DA47B9A5400DE40ADB30B051C215CCE02C05942@mail.spanservices.com> Message-ID: <06cc01c6f6a4$1d5cfaa0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Hi, > > Would like to know about SIP negotiations on TLS. It is the > fact that TLS strictly provides hop-by-hop security in a SIP > Network and even encryption is also on hop-by-hop basis. > > It'll be great if someone let me know if there is a SIP ALG > coexisting with NAT/Firewall on the edge of an enterprise > network and there is a SIP Server on the public network. If > suppose an UA sends a SIP request message on TLS, can it be > incepted by NAT/Firewall on the edge No, a TLS-encrypted message cannot be intercepted by a NAT or firewall device. If a NAT or firewall could examine the plaintext contents of a TLS-encrypted message, TLS wouldn't have much value! -d > or it'll bypass > NAT/Firewall and directly go to the SIP Server on the public > network? > > > Private Network | > Public Network > > | > > UA-----------------> NAT/Firewal > l/SIP-ALG------------------------------------> SIP Server > > tls | > tls > > | > > > > Regards, > > Sunil > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From jdrosen@cisco.com Mon, 23 Oct 2006 14:47:42 -0500 (CDT) (envelope-from jdrosen@cisco.com) From: Jonathan Rosenberg Date: Mon, 23 Oct 2006 14:47:42 -0500 (CDT) (envelope-from jdrosen@cisco.com) Subject: Re: [Ietf-behave] review of rfc3489bis-04 In-Reply-To: <20d2bdfb0610091056iba0cf7bx9ecc431a2e7a777a@mail.gmail.com> Message-ID: <453D1C51.2030407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Bruce, Thanks for the thoughtful and outstanding comments. Responses inline: Bruce Lowekamp wrote: Review of draft-ietf-behave-rfc3489bis-04 Bruce B. Lowekamp College of William and Mary and SIPeerior Technologies, Inc. I waited to write this review until we completed implementing this STUN draft inside the reSIProcate stack. A number of these comments stem from the design of that implementation, which does initial classification and parsing at the stack layer and then passes the message up for further processing at the dialog/application level when necessary. I've grouped comments into two sections: protocol issues, where I think the current specification should be changed in some way, and document clarifications, where I think the draft has a mistake that doesn't reflect the intention of the protocol. I also made some notes on a few more general clarity and grammar issues that I am forwarding to Jonathan separately. Having worked with a previous implementation guided only by the original 3489 and also worked with this version, 3489bis is significantly cleaner and easier to read, understand, and implement. Tiffany Broadbent did a lot of the implementation and many of these comments stem from questions she brought up while developing. Thanks for you and Tiffany for the comments. Responses below. Protocol issues: There are several issues that are motivated by the combination of supporting new usages as extensions and trying to integrate our implementation into an entire SIP stack. - It would be much easier to implement a stack-level for STUN if specific bits indicated whether a message is a request, response, error response, or indication. In several spots the draft refers to response and error response types as 0x100 and 0x110 higher, which I assume is intended to indicate bits to be set, but I don't think it technically reads that way. However, no way of determining whether a type is an indication is mentioned in the draft. Providing for future message types to be identified without recompiling the code with a new list of types for a new usage would be very helpful. I think this is a good idea, almost a necessity based on the layering that is now introduced. You are correct that currently nothing indicates that a message is an indication, and it should. Unfortunately the currently allocated values for the TURN indications (which is the only place they are being used) doesn't allow an easy way to identify them. However I think we are better off changing the turn message values to fix this. I have now made this explicit by using two bits from the message type header field to indicate the "class" of the message (request, success response, error response, indication), and the remaining 12 bits are the method. This formalizes the message type structure which has been there till now. Unfortunately this will require a change in the message type values for the indications in TURN, but I think its worth it. - There are a number of issues if future usages are defined that are not idempotent. For example, Section 6 allows bit-wise identical requests to use the same transaction ID. I assume this is intended to simplify periodic keepalives for low-power devices, however I don't think that assuming re-using transaction IDs is safe for future usages is a good idea. I suggest revising the two sentences (or one if changed) in that paragraph that allow TID reuse to indicate that TIDs cannot be reused except for retransmissions of the same request unless allowed by the particular usage. It wasn't meant to imply that you can reuse a TID for future transactions. I'll reword. - In a similar vein, there is currently no specification for how long a server must remember a previous TID to ensure that a retransmission or duplication is not processed twice. Also, there is no longer any specification of what a client should do if it receives a duplicate response. Seems like in both cases there should be a suggestion to remember the previous TID for 9500ms to avoid processing the same transaction multiple times. This is an excellent point. I've added text around client and server handling of retransmits. THe text on the server side normatively requires retransmitting the response, but allows this to be done either by storing the response or recomputing, the latter being possible only for certain methods (namely the Binding Request). This is important to allow for stateless processing in a basic server. - Why is DTLS not mentioned? Why would it be mentioned? STUN does not currently run on DTLS. If you'd like to write a spec, go ahead :) - I would like to see an overall transaction timer. Multiplying the 9500ms request timeout by a set of shared secret, nonce, ALTERNATE-SERVER, and SRV cycles, the worst-case time for a single transaction is quite bad. A misconfigured set of servers could set up an ALTERNATE-SERVER loop. I don't see a need for an additional timer. Certainly we have not done this for SIP itself. If the application wants to abort at some point, it can do so on its own. We don't need normative language around this. - Are NONCEs intended to be used to challenge each individual request/response or as a per-session value? Per-session. That is, they are cached and reused in subsequent requests to the same IP/port. Section 8.3.2 says that NONCE values should be cached and reused on subsequent request/response. 8.3.1, item 2 says: "The message would not contain the NONCE attribute," and at the end of the list the next paragraph says that the NONCE is included only if the request is a retry as a consequence of an error response. I think item 2 of 8.3.1 should say "The message MUST NOT contain the REALM attribute," regardless of the NONCE issue. Yeah, item two is a bug. It should say REALM, as you indicate. My impression previously has been that the intention of the NONCE is to default to a per-session value unless the server wants to authenticate more often, but 8.3.1 doesn't seem to support that. - I don't see an error code for unknown message type. Perhaps 405? (generating these properly also requires being able to identify whether the unknown type is a request or an indication) Per above we can now do this. I am somewhat conflicted on whether we need to. The original STUN didn't include this sicne there just wasn't the level of flexibility and extensibility to merit it. Even now, its not clear. We're tying extensibility more to usages than methods. I'm inclined to omit it, and add text that says to reject with a 400 if the method is unknown. If I added a code for unknown methods, you'd need to add a "supported"-like mechanism as SIP has for that code to be useful, and furthermore only under the assumption that there is remedy (i.e., another method to try). - 8.3.2 436 response: this would be the wrong error code for an expired short-term, but should the client get another shared-secret if the username was acquired through a shared-secret request? Good question. I think so, to handle cases where the problem IS in fact expiry but the server has forgotten that it even expired the username. I'll need to add words on not retrying infinitely in the case of repeated 436. - 8.3.2 500 response: several? Is amazingly hard to be concrete and useful here. If STUN overload turns into a real problem we'll need a proper mechanism for this. For now this is an OK placeholder I think. - We had a discussion at the last IETF of whether to retain the current fingerprint, switch to a CRC, use a keyed CRC, or drop it. I believe the consensus was to switch to a keyed CRC, but after implementing this draft, I would favor making the fingerprint optional. IMHO, the application multiplexing stun and application data is in the best position to identify whether it is needed, and in the vast majority of cases, it isn't needed. Even with our generic implementation, it would be trivial for us to add an option to include or not include FINGERPRINT when we're multiplexing over a single socket, and none of our current applications would require it. THere seems to be some consensus around that. I've made it optional and turned it into a CRC with xoring. - 11.6: for our implementation, it was useful to use 408 and 484 to deliver errors from the stack to the application layer. Since STUN isn't designed to be proxied, it may not make sense to include them here, but it does make the implementation easier to use them. I assume you are referring to SIP response codes here? Regarding timeouts (408), I see no need to introduce them here. Your own implementation can do that as a matter of design choice. We don't need to say anything about it. Regarding 484 (address incomplete) - I dont see the relevance. - 11.9 why not just pad out the extra field? 1/2 dozen one hand, 6 on the other. - in section 12, there is an explicit assumption that binding requests will always require integrity, but keepalives won't. I don't think I agree with this in all cases. If using STUN for binding inside a TLS connection, I don't think integrity is required. Fair enough; I dont think the spec says you have to use it though. So I'm not sure what you are asking me to change with the binding usage. In the keepalive case, I also don't think I agree that re-establishing a session is necessarily a trivial cost in time or in lost behavior. Well, triviality is relative. Relative to the costs of authenticated each keepalive, I think its trivial :) First, a lot of work has been done with sip-outbound to stage this sort of reconnection. Right... nothing here is contradicting that. Secondly, since STUN will be applied to other protocols beside SIP, I think this distinction assumes characteristics of the application protocol that are not known in advance. I would prefer SHOULD-level strength here, and some discussion of how to choose when to require message integrity and when not to. I will soften it a bit. However, for the case of sip-outbound I am quite opposed to authentication. Practically speaking, it is unfathomably expensive. I would rather remove the feature which has the UA re-register if it sees a change in IP. - 12.3.1: should a changed binding be interpreted as a clue to reduce the refresh interval? (I assume the answer is yes, and mostly think it should be explicitly suggested by the text) Hmm. I think that could be dangerous. An attacker could force you into rapid refreshes. What would the trigger be for you to increase the time again? - 12.3.2: assuming that keepalives are used for a fixed server also extends from assuming SIP is the application protocol. This assumption should probably be weakened/removed. What do you mean by "fixed"? There is an assumption about keeping bindings alive for a long lived associated for receipt of incoming communications. That assumption is stated in 12.3.1. - 12.4.1/12.4.7: one says shared-secrets are specific to SRV Priority, the other to domain name This is a bug, thanks. It can't hurt to be conservative and use it on all SRV records. I'll fix 12.4.1. Document clarifications: section 6: as mentioned on the mailing list, the header includes the magic cookie and the body has at least one attribute in the current spec. Fixed (though its now zero or more with fingerprint being optional) section 6, 3rd par: stun can also run over TLS/TCP, right? fixed. end of 7.1 and 7.2: I think these are supposed to say the same thing about trying multiple SRV results, but it's a bit confusing since they're worded completely differently. I prefer the 7.1 version. ok, i made them consistent using the 7.1 version end of 8.2: should refer to a section I'm not sure what you are referring to. 8.3.2 first par: what if there is a MESSAGE-INTEGRITY in the response but not request good catch - weird case. Ignore MESSAGE-INTEGRITY and continue. I've noted that. 8.3.2 starting after the second paragraph: Every paragraph has a sentence or two, worded slightly differently, about using a NONCE if returned. Can this be grouped into a single paragraph before the long list? Also, toward the end of the section, there is the paragraph that refers to caching NONCEs. This paragraph should be moved here along with the global NONCE rules. Actually towards the end it repeats the simple rule that can be distilled - a retry contains the nonce from the error response. I've consolidated as you suggest. 8.3.2 starting after the second paragraph: After each code, put the parenthesized reason phrases from 11.6. It's too hard to read with just the codes. fixed. 8.3.2 third par: remind that the long-term password is pre-provisioned here added - 8.3.2 300 response: should the same s-t credentials be used? depends on domain or on srv response? may as well always do it. If you guess wrong you'll be re-challenged anyway. Typically alternate-server is across a cluster so they would work. - 8.3.2 500 paragraph: Unknown response codes should start a new paragraph, 3XX should be included. fixed. - 8.3.2 paragraph after 500: I think this should say that the unknown optional attributes should be ignored, not a response containing unknown optional attributes. oops - big bug there. fixed. - 8.3.2 last two paragraphs: why are these two paragraphs here? Seems like they should be later on in the sections describing handling the attributes. removed - 8.3.1 and 8.4: UDP can be pipelined, as well. fixed - 9.1 the one sentence before 9.1.1 seems to apply only to 9.1.1 removed - 9.1.1 1st par: can do stun binding over tls too, as well fixed; though if I were being pedantic I'd point out that PORTS are only defined for UDP and TCP. TCP/TLS is not a separate transport protocol. - 9.1.1: there are two different paragraphs that refer to generating a 432 if the USERNAME is not present. removed second occurence - 9.1.1: can there be one paragraph describing the possibility of attaching a NONCE to almost every error response? moved around. Also added response names like the client processing. - 9.1.2: exclusive-or of the source IP address and port from the request -> exclusive-or of the source transport address and magic cookie. Another big oops. - 9.1.2: before the FINGERPRINT paragraph, there should be a paragraph that if the request contained MESSAGE-INTEGRITY, the response must have MESSAGE-INTEGRITY generated to match 8.3.2 good catch - fixed. - 9.1.2: FINGERPRINT paragraph : indication->response fixed - 9.1.2 last sentence: requests defined -> usages defined actually I think "methods" is better - end of 9.2: depends on the message type -> depends on the usage. for consistency with earlier client discussion. changed to method also - 10 end of 1st par: requests and responses -> messages and indications actually 'all message types' is correct here - 11 Figure 4: I think MESSAGE-INTEGRITY should be C for Response and Error Response based on 8.3.2 requiring it if the request used it. ok - 11.1: should probably say IP addr is in network byte order pl - 11.3: used as the HMAC *key* in the fixed - 11.4: why "generally"? FINGERPRINT. I clarified. - 11.4 last sentence: shared secret->password to include both short and long term? I think its OK as written. - 12.2.1/12.2.7: 12.2.1 "assumed" that the rendezvous gives the shared secret, 12.2.7 says it MUST - 12.2.2 last sentence: actual communications -> application data traffic. This has all been removed since connectivity checks are entirely in ICE now. - 12.4.1 is 9 minutes a MUST? Yes. THe normative requirement is spelled out in the server processing section. - 12.4.9: the very end refers to REFLECTED-FROM. I know this is a historical leftover, but I can't figure out what the sentence is trying to say. Its all historic. I removed the whole bit about using clientIP. - 14.1: since this draft allows for and refers to extensions, including stun-relay explicitly, I think it's better to say something like STUN is intended to provide the functionality necessary to describe how to connect two endpoints regardless of the location of type of NATs in the topology. Wow! Talk about a thorough read - I thought I was the only one that would ever read this section. Fixed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From sunilkumar_j@spanservices.com Tue, 24 Oct 2006 09:34:08 -0500 (CDT) (envelope-from sunilkumar_j@spanservices.com) From: "SUNIL J. KUMAR" Date: Tue, 24 Oct 2006 09:34:08 -0500 (CDT) (envelope-from sunilkumar_j@spanservices.com) Subject: Re: [Ietf-behave] SIP over TLS via NAT/Firewall In-Reply-To: <06cc01c6f6a4$1d5cfaa0$c5f0200a@amer.cisco.com> Message-ID: <8DA47B9A5400DE40ADB30B051C215CCE02C05951@mail.spanservices.com> MIME-Version: 1.0 Content-Type: text/plain Thanks a lot. Its a very valid comment. That means, if at all we have to intercept any SIP Message on the NAT/Firewall/SIP-ALG which was sent over TLS, there MUST be a proxy server coexisting with the SIP-ALG/NAT so that it'll become a SIP Entity and can be on the path of any SIP Message in-coming to or outgoing from the trusted network. if one can suggest what should be minimal proxy functionality? I am sure that just Stateless Proxy won't suffice. Please comments. Best Regards, Sunil ________________________________ From: Dan Wing [mailto:dwing@xxxxxxxxx] Sent: Mon 10/23/2006 6:36 PM To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > Hi, > > Would like to know about SIP negotiations on TLS. It is the > fact that TLS strictly provides hop-by-hop security in a SIP > Network and even encryption is also on hop-by-hop basis. > > It'll be great if someone let me know if there is a SIP ALG > coexisting with NAT/Firewall on the edge of an enterprise > network and there is a SIP Server on the public network. If > suppose an UA sends a SIP request message on TLS, can it be > incepted by NAT/Firewall on the edge No, a TLS-encrypted message cannot be intercepted by a NAT or firewall device. If a NAT or firewall could examine the plaintext contents of a TLS-encrypted message, TLS wouldn't have much value! -d > or it'll bypass > NAT/Firewall and directly go to the SIP Server on the public > network? > > > Private Network | > Public Network > > | > > UA-----------------> NAT/Firewal > l/SIP-ALG------------------------------------> SIP Server > > tls | > tls > > | > > > > Regards, > > Sunil > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Tue, 24 Oct 2006 11:21:39 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Tue, 24 Oct 2006 11:21:39 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] SIP over TLS via NAT/Firewall In-Reply-To: <8DA47B9A5400DE40ADB30B051C215CCE02C05951@mail.spanservices.com> Message-ID: <0f5301c6f788$75865a70$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain > Thanks a lot. Its a very valid comment. That means, if at all > we have to intercept any SIP Message on the > NAT/Firewall/SIP-ALG which was sent over TLS, there MUST be a > proxy server coexisting with the SIP-ALG/NAT so that it'll > become a SIP Entity and can be on the path of any SIP Message > in-coming to or outgoing from the trusted network. Why do you believe this is a requirement? There are several disadvantages to such an approach, and few -- if any -- advantages. -d > if one can > suggest what should be minimal proxy functionality? I am sure > that just Stateless Proxy won't suffice. Please comments. > > Best Regards, > Sunil > > ________________________________ > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Mon 10/23/2006 6:36 PM > To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > > > > Hi, > > > > Would like to know about SIP negotiations on TLS. It is the > > fact that TLS strictly provides hop-by-hop security in a SIP > > Network and even encryption is also on hop-by-hop basis. > > > > It'll be great if someone let me know if there is a SIP ALG > > coexisting with NAT/Firewall on the edge of an enterprise > > network and there is a SIP Server on the public network. If > > suppose an UA sends a SIP request message on TLS, can it be > > incepted by NAT/Firewall on the edge > > No, a TLS-encrypted message cannot be intercepted by a NAT or firewall > device. If a NAT or firewall could examine the plaintext > contents of a > TLS-encrypted message, TLS wouldn't have much value! > > -d > > > or it'll bypass > > NAT/Firewall and directly go to the SIP Server on the public > > network? > > > > > > Private Network | > > Public Network > > > > | > > > > UA-----------------> NAT/Firewal > > l/SIP-ALG------------------------------------> SIP Server > > > > tls | > > tls > > > > | > > > > > > > > Regards, > > > > Sunil > > > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From sunilkumar_j@spanservices.com Tue, 24 Oct 2006 12:59:45 -0500 (CDT) (envelope-from sunilkumar_j@spanservices.com) From: "SUNIL J. KUMAR" Date: Tue, 24 Oct 2006 12:59:45 -0500 (CDT) (envelope-from sunilkumar_j@spanservices.com) Subject: Re: [Ietf-behave] SIP over TLS via NAT/Firewall In-Reply-To: <0f5301c6f788$75865a70$c5f0200a@amer.cisco.com> Message-ID: <8DA47B9A5400DE40ADB30B051C215CCE02C05953@mail.spanservices.com> MIME-Version: 1.0 Content-Type: text/plain Hi Dan, Since we are planning to provide more security at SIP ALG level from number of possible attacks like evesdropping, session hijacking, DOS Attacks, sessions tear down, impersonnating a server, Registration hijacking etc and SIP RFC 3261 suggests that TLS can be a good way to provide security. But this security we want to have at SIP-ALG/NAT level itself. An idea on this solution would be of great help. Thanks, Sunil ________________________________ From: Dan Wing [mailto:dwing@xxxxxxxxx] Sent: Tue 10/24/2006 9:51 PM To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > Thanks a lot. Its a very valid comment. That means, if at all > we have to intercept any SIP Message on the > NAT/Firewall/SIP-ALG which was sent over TLS, there MUST be a > proxy server coexisting with the SIP-ALG/NAT so that it'll > become a SIP Entity and can be on the path of any SIP Message > in-coming to or outgoing from the trusted network. Why do you believe this is a requirement? There are several disadvantages to such an approach, and few -- if any -- advantages. -d > if one can > suggest what should be minimal proxy functionality? I am sure > that just Stateless Proxy won't suffice. Please comments. > > Best Regards, > Sunil > > ________________________________ > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Mon 10/23/2006 6:36 PM > To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > > > > Hi, > > > > Would like to know about SIP negotiations on TLS. It is the > > fact that TLS strictly provides hop-by-hop security in a SIP > > Network and even encryption is also on hop-by-hop basis. > > > > It'll be great if someone let me know if there is a SIP ALG > > coexisting with NAT/Firewall on the edge of an enterprise > > network and there is a SIP Server on the public network. If > > suppose an UA sends a SIP request message on TLS, can it be > > incepted by NAT/Firewall on the edge > > No, a TLS-encrypted message cannot be intercepted by a NAT or firewall > device. If a NAT or firewall could examine the plaintext > contents of a > TLS-encrypted message, TLS wouldn't have much value! > > -d > > > or it'll bypass > > NAT/Firewall and directly go to the SIP Server on the public > > network? > > > > > > Private Network | > > Public Network > > > > | > > > > UA-----------------> NAT/Firewal > > l/SIP-ALG------------------------------------> SIP Server > > > > tls | > > tls > > > > | > > > > > > > > Regards, > > > > Sunil > > > > > > > > > > > > _______________________________________________ > > Ietf-behave mailing list > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From dwing@cisco.com Tue, 24 Oct 2006 13:18:39 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Tue, 24 Oct 2006 13:18:39 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] SIP over TLS via NAT/Firewall In-Reply-To: <8DA47B9A5400DE40ADB30B051C215CCE02C05953@mail.spanservices.com> Message-ID: <143001c6f798$ce876ff0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Check out draft-camarillo-sipping-sbc-funcs-04.txt which is what I think you're asking about? -d > -----Original Message----- > From: SUNIL J. KUMAR [mailto:sunilkumar_j@xxxxxxxxxxxxxxxx] > Sent: Tuesday, October 24, 2006 11:01 AM > To: Dan Wing; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > Hi Dan, > > Since we are planning to provide more security at SIP ALG > level from number of possible attacks like evesdropping, > session hijacking, DOS Attacks, sessions tear down, > impersonnating a server, Registration hijacking etc and SIP > RFC 3261 suggests that TLS can be a good way to provide > security. But this security we want to have at SIP-ALG/NAT > level itself. An idea on this solution would be of great help. > > Thanks, > Sunil > > ________________________________ > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Tue 10/24/2006 9:51 PM > To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > > > > Thanks a lot. Its a very valid comment. That means, if at all > > we have to intercept any SIP Message on the > > NAT/Firewall/SIP-ALG which was sent over TLS, there MUST be a > > proxy server coexisting with the SIP-ALG/NAT so that it'll > > become a SIP Entity and can be on the path of any SIP Message > > in-coming to or outgoing from the trusted network. > > Why do you believe this is a requirement? There are several > disadvantages to such an approach, and few -- if any -- > advantages. > > -d > > > if one can > > suggest what should be minimal proxy functionality? I am sure > > that just Stateless Proxy won't suffice. Please comments. > > > > Best Regards, > > Sunil > > > > ________________________________ > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Mon 10/23/2006 6:36 PM > > To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > > > > > > > > Hi, > > > > > > Would like to know about SIP negotiations on TLS. It is the > > > fact that TLS strictly provides hop-by-hop security in a SIP > > > Network and even encryption is also on hop-by-hop basis. > > > > > > It'll be great if someone let me know if there is a SIP ALG > > > coexisting with NAT/Firewall on the edge of an enterprise > > > network and there is a SIP Server on the public network. If > > > suppose an UA sends a SIP request message on TLS, can it be > > > incepted by NAT/Firewall on the edge > > > > No, a TLS-encrypted message cannot be intercepted by a NAT > or firewall > > device. If a NAT or firewall could examine the plaintext > > contents of a > > TLS-encrypted message, TLS wouldn't have much value! > > > > -d > > > > > or it'll bypass > > > NAT/Firewall and directly go to the SIP Server on the public > > > network? > > > > > > > > > Private Network | > > > Public Network > > > > > > | > > > > > > UA-----------------> NAT/Firewal > > > l/SIP-ALG------------------------------------> SIP Server > > > > > > tls | > > > tls > > > > > > | > > > > > > > > > > > > Regards, > > > > > > Sunil > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > From sunilkumar_j@spanservices.com Tue, 24 Oct 2006 14:11:42 -0500 (CDT) (envelope-from sunilkumar_j@spanservices.com) From: "SUNIL J. KUMAR" Date: Tue, 24 Oct 2006 14:11:42 -0500 (CDT) (envelope-from sunilkumar_j@spanservices.com) Subject: Re: [Ietf-behave] SIP over TLS via NAT/Firewall In-Reply-To: <143001c6f798$ce876ff0$c5f0200a@amer.cisco.com> Message-ID: <8DA47B9A5400DE40ADB30B051C215CCE02C05954@mail.spanservices.com> MIME-Version: 1.0 Content-Type: text/plain Looks like a good draft. But SIP security still a major concern in this draft as well. Many of the functions this document describes have important SIP security and privacy implications, which I am planning to provide at NAT/Firewall itself for SIP Message (Requests/responses. ________________________________ From: Dan Wing [mailto:dwing@xxxxxxxxx] Sent: Tue 10/24/2006 11:48 PM To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall Check out draft-camarillo-sipping-sbc-funcs-04.txt which is what I think you're asking about? -d > -----Original Message----- > From: SUNIL J. KUMAR [mailto:sunilkumar_j@xxxxxxxxxxxxxxxx] > Sent: Tuesday, October 24, 2006 11:01 AM > To: Dan Wing; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > Hi Dan, > > Since we are planning to provide more security at SIP ALG > level from number of possible attacks like evesdropping, > session hijacking, DOS Attacks, sessions tear down, > impersonnating a server, Registration hijacking etc and SIP > RFC 3261 suggests that TLS can be a good way to provide > security. But this security we want to have at SIP-ALG/NAT > level itself. An idea on this solution would be of great help. > > Thanks, > Sunil > > ________________________________ > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Tue 10/24/2006 9:51 PM > To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > > > > Thanks a lot. Its a very valid comment. That means, if at all > > we have to intercept any SIP Message on the > > NAT/Firewall/SIP-ALG which was sent over TLS, there MUST be a > > proxy server coexisting with the SIP-ALG/NAT so that it'll > > become a SIP Entity and can be on the path of any SIP Message > > in-coming to or outgoing from the trusted network. > > Why do you believe this is a requirement? There are several > disadvantages to such an approach, and few -- if any -- > advantages. > > -d > > > if one can > > suggest what should be minimal proxy functionality? I am sure > > that just Stateless Proxy won't suffice. Please comments. > > > > Best Regards, > > Sunil > > > > ________________________________ > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Mon 10/23/2006 6:36 PM > > To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > > > > > > > > Hi, > > > > > > Would like to know about SIP negotiations on TLS. It is the > > > fact that TLS strictly provides hop-by-hop security in a SIP > > > Network and even encryption is also on hop-by-hop basis. > > > > > > It'll be great if someone let me know if there is a SIP ALG > > > coexisting with NAT/Firewall on the edge of an enterprise > > > network and there is a SIP Server on the public network. If > > > suppose an UA sends a SIP request message on TLS, can it be > > > incepted by NAT/Firewall on the edge > > > > No, a TLS-encrypted message cannot be intercepted by a NAT > or firewall > > device. If a NAT or firewall could examine the plaintext > > contents of a > > TLS-encrypted message, TLS wouldn't have much value! > > > > -d > > > > > or it'll bypass > > > NAT/Firewall and directly go to the SIP Server on the public > > > network? > > > > > > > > > Private Network | > > > Public Network > > > > > > | > > > > > > UA-----------------> NAT/Firewal > > > l/SIP-ALG------------------------------------> SIP Server > > > > > > tls | > > > tls > > > > > > | > > > > > > > > > > > > Regards, > > > > > > Sunil > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ietf-behave mailing list > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > From dwing@cisco.com Tue, 24 Oct 2006 15:07:07 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Tue, 24 Oct 2006 15:07:07 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] SIP over TLS via NAT/Firewall In-Reply-To: <8DA47B9A5400DE40ADB30B051C215CCE02C05954@mail.spanservices.com> Message-ID: <019001c6f7a7$f4ea6940$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain It might be best if you asked your question on the SIPPING working group's mailing list. I believe many of the things you want to do will require a SIP back-to-back user agent (B2BUA) that also handles media. Those functions, when combined, are commonly called an SBC. -d > -----Original Message----- > From: SUNIL J. KUMAR [mailto:sunilkumar_j@xxxxxxxxxxxxxxxx] > Sent: Tuesday, October 24, 2006 12:10 PM > To: Dan Wing; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > Looks like a good draft. But SIP security still a major > concern in this draft as well. Many of the functions this > document describes have important SIP security and privacy > implications, which I am planning to provide at NAT/Firewall > itself for SIP Message (Requests/responses. > > ________________________________ > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > Sent: Tue 10/24/2006 11:48 PM > To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > > > Check out draft-camarillo-sipping-sbc-funcs-04.txt which is > what I think you're asking about? > > -d > > > > -----Original Message----- > > From: SUNIL J. KUMAR [mailto:sunilkumar_j@xxxxxxxxxxxxxxxx] > > Sent: Tuesday, October 24, 2006 11:01 AM > > To: Dan Wing; ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > > > Hi Dan, > > > > Since we are planning to provide more security at SIP ALG > > level from number of possible attacks like evesdropping, > > session hijacking, DOS Attacks, sessions tear down, > > impersonnating a server, Registration hijacking etc and SIP > > RFC 3261 suggests that TLS can be a good way to provide > > security. But this security we want to have at SIP-ALG/NAT > > level itself. An idea on this solution would be of great help. > > > > Thanks, > > Sunil > > > > ________________________________ > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > Sent: Tue 10/24/2006 9:51 PM > > To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > > > > > > > > Thanks a lot. Its a very valid comment. That means, if at all > > > we have to intercept any SIP Message on the > > > NAT/Firewall/SIP-ALG which was sent over TLS, there MUST be a > > > proxy server coexisting with the SIP-ALG/NAT so that it'll > > > become a SIP Entity and can be on the path of any SIP Message > > > in-coming to or outgoing from the trusted network. > > > > Why do you believe this is a requirement? There are several > > disadvantages to such an approach, and few -- if any -- > > advantages. > > > > -d > > > > > if one can > > > suggest what should be minimal proxy functionality? I am sure > > > that just Stateless Proxy won't suffice. Please comments. > > > > > > Best Regards, > > > Sunil > > > > > > ________________________________ > > > > > > From: Dan Wing [mailto:dwing@xxxxxxxxx] > > > Sent: Mon 10/23/2006 6:36 PM > > > To: SUNIL J. KUMAR; ietf-behave@xxxxxxxxxxxxxxxxxxx > > > Subject: RE: [Ietf-behave] SIP over TLS via NAT/Firewall > > > > > > > > > > > > > Hi, > > > > > > > > Would like to know about SIP negotiations on TLS. It is the > > > > fact that TLS strictly provides hop-by-hop security in a SIP > > > > Network and even encryption is also on hop-by-hop basis. > > > > > > > > It'll be great if someone let me know if there is a SIP ALG > > > > coexisting with NAT/Firewall on the edge of an enterprise > > > > network and there is a SIP Server on the public network. If > > > > suppose an UA sends a SIP request message on TLS, can it be > > > > incepted by NAT/Firewall on the edge > > > > > > No, a TLS-encrypted message cannot be intercepted by a NAT > > or firewall > > > device. If a NAT or firewall could examine the plaintext > > > contents of a > > > TLS-encrypted message, TLS wouldn't have much value! > > > > > > -d > > > > > > > or it'll bypass > > > > NAT/Firewall and directly go to the SIP Server on the public > > > > network? > > > > > > > > > > > > Private Network | > > > > Public Network > > > > > > > > | > > > > > > > > UA-----------------> NAT/Firewal > > > > l/SIP-ALG------------------------------------> SIP Server > > > > > > > > tls | > > > > tls > > > > > > > > | > > > > > > > > > > > > > > > > Regards, > > > > > > > > Sunil > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ietf-behave mailing list > > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx > > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > > > > > > From dwing@cisco.com Tue, 24 Oct 2006 15:30:18 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Tue, 24 Oct 2006 15:30:18 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: [Ietf-behave] draft agenda Message-ID: <02a101c6f7ab$32a21870$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Draft agenda is now at the following URL and the current version is in this email. http://www3.ietf.org/proceedings/06nov/agenda/behave.html -d ----- BEHAVE Agenda -- IETF 67, San Diego WEDNESDAY, November 8, 2006, 9:00-11:30 (agenda last revised 2006-10-24 13:16 PDT) ** DRAFT AGENDA ** Chair: Dan Wing, dwing@xxxxxxxxx 9:00 Agenda and document status, Dan Wing (10 mins) draft-ietf-behave-multicast-03, scope change; still needed? draft-ietf-behave-nat-udp-08, now in RFC editor queue draft-ietf-behave-p2p-state-00, new WG document, WGLC soon draft-ietf-behave-turn-02, removed 'doors' draft-ietf-behave-turn-ipv6-00 (expired), waiting for TURN Adopt draft-ford-behave-app-04 to meet our Application milestone? Working Group documents: 9:10 STUNbis, Jonathan Rosenberg (20 mins) draft-ietf-behave-rfc3489bis-04 9:30 TCP, Philip Matthews (10 mins) status: ready for technical review and WGLC draft-ietf-behave-tcp-02 (missed I-D cutoff; link will be provided) 9:40 ICMP, Fernando Gont (20 mins) status: ready for technical review and WGLC draft-ietf-behave-nat-icmp-01 Individual documents: 10:00 NAT Behavior Discovery, Derek MacDonald (10 mins) draft-macdonald-behave-nat-behavior-discovery-00 status: adopt as working group document? 10:10 Application Keepalive for NATs, Xavier Marjou (10 mins) draft-marjou-behave-app-rtp-keepalive-00 status: separate from ICE, or integrate into Application milestone document? 10:20 NAT Control STUN Usage, Dan Wing/Jonathan Rosenberg (15 mins) draft-wing-behave-nat-control-stun-usage-00 status: adopt as working group document? 10:35 end From saikat@cs.cornell.edu Tue, 24 Oct 2006 17:33:17 -0500 (CDT) (envelope-from saikat@cs.cornell.edu) From: Saikat Guha Date: Tue, 24 Oct 2006 17:33:17 -0500 (CDT) (envelope-from saikat@cs.cornell.edu) Subject: [Ietf-behave] draft-ietf-behave-tcp-02.txt Message-ID: <1161729177.23250.33.camel@sioux.systems.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630137.multipart/signed" --Boundary..27398.1163630137.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi folks, A new version of the TCP behavior document is now available at: http://saikat.guha.cc/pub/draft-ietf-behave-tcp-02.txt (missed the I-D cutoff) The diff from -01 is at: http://tinyurl.com/yhuhla The document incorporates (largely cosmetic) changes from the last IETF, mailing-list and off-list discussions. Specifically: - Normative references to BEHAVE-UDP and BEHAVE-ICMP - Removal of TCP port preservation for r-services (decided in IETF66) - ICMP payload translation is a MUST (for TCP PMTU). Refer to upcoming mailing-list thread. The document is now ready for technical review (and once the I-D blackout is lifted) for WGLC. cheers, -- Saikat Attachment: signature.asc --Boundary..27398.1163630137.multipart/signed Content-Type: application/octet-stream; name="pgpbW6hIRAxgs.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpbW6hIRAxgs.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC41IChHTlUv TGludXgpCgppRDhEQlFCRlBwU1puRmx0cWk2OTEvb1JBa3hlQUo5Q3FYb2dxcWs4ckZ3cXFvczVV L2d5cjJ6YVB3Q2FBdnZSCkhrNlNTQ1ltSTBoSXFpcmVjZlRrWHNFPQo9OS9hVAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630137.multipart/signed-- From saikat@cs.cornell.edu Tue, 24 Oct 2006 17:45:40 -0500 (CDT) (envelope-from saikat@cs.cornell.edu) From: Saikat Guha Date: Tue, 24 Oct 2006 17:45:40 -0500 (CDT) (envelope-from saikat@cs.cornell.edu) Subject: [Ietf-behave] Conflicting ICMP payload translation reqs: MUST vs. SHOULD Message-ID: <1161729920.23250.46.camel@sioux.systems.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630137.multipart/signed" --Boundary..27398.1163630137.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit UDP *RECOMMENDS* that ICMP payloads be translated and forwarded. From draft-ietf-behave-nat-udp-08.txt: The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address. Such ICMP messages SHOULD be rewritten by the NAT (specifically the IP headers and the ICMP payload) and forwarded to the appropriate internal or external host. ICMP *REQUIRES* that ICMP payloads be translated and forwarded. From draft-ietf-behave-nat-icmp-01.txt: If the the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet. a) Revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping; and ... TCP currently aligns itself with ICMP/MUST because receiving the ICMP messages and being able to link them to the actual connection is essential for path MTU discovery. From my reading of the documents, the requirements in ICMP/TCP and UDP are in conflict. Is there any particular UDP has a SHOULD and not a MUST? If so, should the recommendation be narrowed only to UDP payloads inside ICMP packets? -- Saikat Attachment: signature.asc --Boundary..27398.1163630137.multipart/signed Content-Type: application/octet-stream; name="pgpAAi9QFEVGG.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpAAi9QFEVGG.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC41IChHTlUv TGludXgpCgppRDhEQlFCRlBwZUFuRmx0cWk2OTEvb1JBbm1jQUo5ZmpFSml0b21ua1NCR1VHYWFT R08wWEVMVWJ3Q2VKM1RTCkRqUzMvZHpiTEFNdkR3L09MSmh5dnF3PQo9d2RQOQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630137.multipart/signed-- From fernando@gont.com.ar Wed, 25 Oct 2006 00:09:29 -0500 (CDT) (envelope-from fernando@gont.com.ar) From: Fernando Gont Date: Wed, 25 Oct 2006 00:09:29 -0500 (CDT) (envelope-from fernando@gont.com.ar) Subject: Re: [Ietf-behave] Conflicting ICMP payload translation reqs: MUST vs. SHOULD In-Reply-To: <1161729920.23250.46.camel@sioux.systems.cs.cornell.edu> Message-ID: <7.0.1.0.0.20061025012254.07592850@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain At 19:45 24/10/2006, Saikat Guha wrote: TCP currently aligns itself with ICMP/MUST because receiving the ICMP messages and being able to link them to the actual connection is essential for path MTU discovery. From my reading of the documents, the requirements in ICMP/TCP and UDP are in conflict. Is there any particular UDP has a SHOULD and not a MUST? If so, should the recommendation be narrowed only to UDP payloads inside ICMP packets? As a meta comment, I'd suggest that all the ICMP-related stuff be included only in the ICMP document, rather than spread it over three documents (ICMP, TCP, and UDP). As for whether to rewrite the ICMP payload is a MUST or SHOULD, I'd vote for the "MUST". Whether one likes it or not, ICMP is a signalling protocol that is part of the TCP/IP suite. You cannot just NAT the transport protocol, but kill the protocol that aids in signalling error conditions. If anybody wants to get rid of ICMP, the one should get rid of it for "non-NATed" traffic, and only then the NAT-related specs should follow. Just my two cents, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From srisuresh@yahoo.com Wed, 25 Oct 2006 08:48:33 -0500 (CDT) (envelope-from srisuresh@yahoo.com) From: Pyda Srisuresh Date: Wed, 25 Oct 2006 08:48:33 -0500 (CDT) (envelope-from srisuresh@yahoo.com) Subject: Re: [Ietf-behave] Conflicting ICMP payload translation reqs: MUST vs. SHOULD In-Reply-To: <7.0.1.0.0.20061025012254.07592850@gont.com.ar> Message-ID: <20061025134824.19825.qmail@web33306.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain I full agree with Fernando. I do believe, all normative requirements related to ICMP should be in the ICMP document and not spread across multiple documents. Repeating in multiple drafts in different words is prone to language interpretation problems. I also believe, a NAT MUST rewrite the payload. As for the requirement in UDP draft (soon to be an RFC) - During the WG last call when this issue was brought up, folks wanted to leave the requirement in there so the publication is not delayed (I dont recall discussig the SHOULD vs MUST for the requirement, however.). This exception for the UDP draft is understandable. However, the requirement shoudlnt have to be repeated in the TCP draft. TCP draft could simply refer the requirement in the ICMP draft rather than list as a distinct TCP requirement. My 2c. regards, suresh --- Fernando Gont wrote: > At 19:45 24/10/2006, Saikat Guha wrote: > > >TCP currently aligns itself with ICMP/MUST because receiving the ICMP > >messages and being able to link them to the actual connection is > >essential for path MTU discovery. > > > > From my reading of the documents, the requirements in ICMP/TCP and UDP > >are in conflict. > > > >Is there any particular UDP has a SHOULD and not a MUST? If so, should > >the recommendation be narrowed only to UDP payloads inside ICMP packets? > > As a meta comment, I'd suggest that all the ICMP-related stuff be > included only in the ICMP document, rather than spread it over three > documents (ICMP, TCP, and UDP). > > As for whether to rewrite the ICMP payload is a MUST or SHOULD, I'd > vote for the "MUST". > > Whether one likes it or not, ICMP is a signalling protocol that is > part of the TCP/IP suite. You cannot just NAT the transport protocol, > but kill the protocol that aids in signalling error conditions. > > If anybody wants to get rid of ICMP, the one should get rid of it for > "non-NATed" traffic, and only then the NAT-related specs should follow. > > Just my two cents, > > -- > Fernando Gont > e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From spencer@mcsr-labs.org Wed, 25 Oct 2006 10:03:39 -0500 (CDT) (envelope-from spencer@mcsr-labs.org) From: "Spencer Dawkins" Date: Wed, 25 Oct 2006 10:03:39 -0500 (CDT) (envelope-from spencer@mcsr-labs.org) Subject: Re: [Ietf-behave] Conflicting ICMP payload translation reqs: MUSTvs. SHOULD In-Reply-To: <20061025134824.19825.qmail@web33306.mail.mud.yahoo.com> Message-ID: <023c01c6f846$5e810230$6501a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain I'm just watching out for the poor Gen-ART reviewer who gets the last document in this string... - Is it the intention that the ICMP document UPDATEs the UDP document, in the RFC Editor sense of the word? - Is it the intention that the TCP document updates the ICMP document? Given that the UDP draft is in the RFC Editor Queue, and the ICMP and TCP documents are not even assigned to a shepherding AD in the tracker yet, your best path forward really may be to issue UDP, UPDATE it with ICMP, and refer to ICMP for the ICMP requirements supporting TCP... assuming that the TCP draft doesn't pass the ICMP draft in the chute. This does tend to make our archival document series denser and less implementer-friendly, but sometimes "good enough" is the best we can do. If I got this hand grenade over the review transom, I'd definitely be asking this at IETF Last Call time, and probably at IESG Telechat time as well, so thinking about this now is probably better than thinking about it some other times... Thanks, Spencer I full agree with Fernando. I do believe, all normative requirements related to ICMP should be in the ICMP document and not spread across multiple documents. Repeating in multiple drafts in different words is prone to language interpretation problems. I also believe, a NAT MUST rewrite the payload. As for the requirement in UDP draft (soon to be an RFC) - During the WG last call when this issue was brought up, folks wanted to leave the requirement in there so the publication is not delayed (I dont recall discussig the SHOULD vs MUST for the requirement, however.). This exception for the UDP draft is understandable. However, the requirement shoudlnt have to be repeated in the TCP draft. TCP draft could simply refer the requirement in the ICMP draft rather than list as a distinct TCP requirement. My 2c. regards, suresh --- Fernando Gont wrote: At 19:45 24/10/2006, Saikat Guha wrote: >TCP currently aligns itself with ICMP/MUST because receiving the ICMP >messages and being able to link them to the actual connection is >essential for path MTU discovery. > > From my reading of the documents, the requirements in ICMP/TCP and UDP >are in conflict. > >Is there any particular UDP has a SHOULD and not a MUST? If so, should >the recommendation be narrowed only to UDP payloads inside ICMP packets? As a meta comment, I'd suggest that all the ICMP-related stuff be included only in the ICMP document, rather than spread it over three documents (ICMP, TCP, and UDP). As for whether to rewrite the ICMP payload is a MUST or SHOULD, I'd vote for the "MUST". Whether one likes it or not, ICMP is a signalling protocol that is part of the TCP/IP suite. You cannot just NAT the transport protocol, but kill the protocol that aids in signalling error conditions. If anybody wants to get rid of ICMP, the one should get rid of it for "non-NATed" traffic, and only then the NAT-related specs should follow. Just my two cents, From dwing@cisco.com Wed, 25 Oct 2006 10:49:29 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Wed, 25 Oct 2006 10:49:29 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: Re: [Ietf-behave] Conflicting ICMP payload translation reqs:MUSTvs. SHOULD In-Reply-To: <023c01c6f846$5e810230$6501a8c0@china.huawei.com> Message-ID: <192a01c6f84d$2295a300$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Spencer Dawkins wrote: > Given that the UDP draft is in the RFC Editor Queue, and the > ICMP and TCP documents are not even assigned to a shepherding > AD in the tracker yet, your best path forward really may be > to issue UDP, UPDATE it with ICMP, and refer to ICMP for > the ICMP requirements supporting TCP... assuming that the TCP > draft doesn't pass the ICMP draft in the chute. Yes, I agree that's what we should do. ICMP's text can clearly indicate this one UDP requirement that it's updating from Should to Must. -d From huitema@windows.microsoft.com Wed, 25 Oct 2006 13:43:01 -0500 (CDT) (envelope-from huitema@windows.microsoft.com) From: Christian Huitema Date: Wed, 25 Oct 2006 13:43:01 -0500 (CDT) (envelope-from huitema@windows.microsoft.com) Subject: Re: [Ietf-behave] Conflicting ICMP payload translation reqs:MUSTvs.SHOULD In-Reply-To: <023c01c6f846$5e810230$6501a8c0@china.huawei.com> Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0640277A90C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain > > Given that the UDP draft is in the RFC Editor Queue, and the > > ICMP and TCP documents are not even assigned to a shepherding > > AD in the tracker yet, your best path forward really may be > > to issue UDP, UPDATE it with ICMP, and refer to ICMP for > > the ICMP requirements supporting TCP... assuming that the TCP > > draft doesn't pass the ICMP draft in the chute. > > Yes, I agree that's what we should do. ICMP's text can > clearly indicate this one UDP requirement that it's updating > from Should to Must. I do not agree with the rationale for this argument. We can see two different set of problems, and they have different solutions: 1) Specify how the NAT will translate ICMP packets, either incoming or outgoing: this belongs logically to the ICMP specification. 2) Specify how the translation state for another protocol is affected by the reception of UDP packets: this belongs logically in the specification of that protocol. For example, the reaction of TCP to "soft errors" or "hard errors" belongs in TCP, not in ICMP. -- Christian Huitema From saikat@cs.cornell.edu Wed, 25 Oct 2006 13:51:01 -0500 (CDT) (envelope-from saikat@cs.cornell.edu) From: Saikat Guha Date: Wed, 25 Oct 2006 13:51:01 -0500 (CDT) (envelope-from saikat@cs.cornell.edu) Subject: Re: [Ietf-behave] Conflicting ICMP payload translation reqs:MUSTvs.SHOULD In-Reply-To: <023c01c6f846$5e810230$6501a8c0@china.huawei.com> Message-ID: <1161802242.2618.7.camel@sioux.systems.cs.cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Boundary..27398.1163630137.multipart/signed" --Boundary..27398.1163630137.multipart/signed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2006-10-25 at 11:42 -0700, Christian Huitema wrote: > 1) Specify how the NAT will translate ICMP packets, either incoming or > outgoing: this belongs logically to the ICMP specification. > > 2) Specify how the translation state for another protocol is affected by > the reception of UDP packets: this belongs logically in the > specification of that protocol. > > For example, the reaction of TCP to "soft errors" or "hard errors" > belongs in TCP, not in ICMP. I second this argument, which incidentally, was what I understood to be the outcome of IETF65: - BEHAVE-ICMP should be responsible for ONLY ICMP requests and responses - BEHAVE-[proto] should be responsible for ICMP messages earned from the network in response to [proto] packets. -- Saikat Attachment: signature.asc --Boundary..27398.1163630137.multipart/signed Content-Type: application/octet-stream; name="pgpKi7IbFNnfq.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpKi7IbFNnfq.pgp" Content-Description: "Description: This is a digitally signed message part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC41IChHTlUv TGludXgpCgppRDhEQlFCRlA3SUNuRmx0cWk2OTEvb1JBcHhUQUo0cTg3VU9CNis4TU9uZ0xCRGRC dXROeHZNWGp3Q2RFYWtBClMxdnNVeHpTY21aTnAwOElxcjMwc3dzPQo9MXN1dAotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --Boundary..27398.1163630137.multipart/signed-- From huitema@windows.microsoft.com Wed, 25 Oct 2006 15:23:41 -0500 (CDT) (envelope-from huitema@windows.microsoft.com) From: Christian Huitema Date: Wed, 25 Oct 2006 15:23:41 -0500 (CDT) (envelope-from huitema@windows.microsoft.com) Subject: Re: [Ietf-behave] Conflicting ICMP payload translationreqs:MUSTvs.SHOULD In-Reply-To: <023c01c6f846$5e810230$6501a8c0@china.huawei.com> Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0640277AA2B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain > I do not agree with the rationale for this argument. We can see two > different set of problems, and they have different solutions: > > 1) Specify how the NAT will translate ICMP packets, either incoming or > outgoing: this belongs logically to the ICMP specification. > > 2) Specify how the translation state for another protocol is affected > by the reception of UDP packets: this belongs logically in the ^^^ => I really meant ICMP. Sorry. > specification of that protocol. > > For example, the reaction of TCP to "soft errors" or "hard errors" > belongs in TCP, not in ICMP. > > -- Christian Huitema From kbiswas@cisco.com Wed, 25 Oct 2006 22:34:53 -0500 (CDT) (envelope-from kbiswas@cisco.com) From: "Kaushik Biswas \(kbiswas\)" Date: Wed, 25 Oct 2006 22:34:53 -0500 (CDT) (envelope-from kbiswas@cisco.com) Subject: Re: [Ietf-behave] Application milestone Message-ID: <378E78E5F361564BB066432F6415764B028C1A79@xmb-sjc-228.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain I support adopting this as a WG document to meet the existing BEHAVE milestone and am willing to review the same. Thanks, Kaushik > -----Original Message----- > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Dan Wing (dwing) > Sent: Thursday, October 12, 2006 10:25 AM > To: ietf-behave@xxxxxxxxxxxxxxxxxxx > Cc: 'Dan Kegel' > Subject: [Ietf-behave] Application milestone > > The authors of draft-ford-behave-app-04.txt have proposed the > WG to adopt that document to meet an existing BEHAVE milestone: > > Dec 2006 Submit a BCP that discusses protocol > design techniques for using the existing > set of NAT traversal approaches to IESG > > > Please review draft-ford-behave-app-04.txt and comment to the > list on its suitability for that milestone -- if more > sections are needed, we need to combine it with other work, > or its suitability as-is. > > I hope to have one of the authors present the document at San > Diego meeting. > > -d > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From srisuresh@yahoo.com Thu, 26 Oct 2006 08:01:22 -0500 (CDT) (envelope-from srisuresh@yahoo.com) From: Pyda Srisuresh Date: Thu, 26 Oct 2006 08:01:22 -0500 (CDT) (envelope-from srisuresh@yahoo.com) Subject: Re: [Ietf-behave] Conflicting ICMP payload translation reqs:MUSTvs.SHOULD In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0640277A90C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <20061026130113.17837.qmail@web33304.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain --- Christian Huitema wrote: > > > Given that the UDP draft is in the RFC Editor Queue, and the > > > ICMP and TCP documents are not even assigned to a shepherding > > > AD in the tracker yet, your best path forward really may be > > > to issue UDP, UPDATE it with ICMP, and refer to ICMP for > > > the ICMP requirements supporting TCP... assuming that the TCP > > > draft doesn't pass the ICMP draft in the chute. > > > > Yes, I agree that's what we should do. ICMP's text can > > clearly indicate this one UDP requirement that it's updating > > from Should to Must. > > I do not agree with the rationale for this argument. We can see two > different set of problems, and they have different solutions: > > 1) Specify how the NAT will translate ICMP packets, either incoming or > outgoing: this belongs logically to the ICMP specification. > [suresh] Right, We both agree on this. This directly addresses the comment from Saikat. The specific comment from Saikat was to do with a) MUST/SHOULD requirement on ICMP payload translation. b) TCP draft alignment with the MUST requirement in the ICMP draft. As you say, I too believe, the normative text for ICMP payload translation requirement belongs in the ICMP draft. Req-4 and Req-5 of the ICMP draft specify this. I just looked up the TCP and UDP drafts. Neither of the drafts specify this language in the Requirements text. This language is mentioned only in the text preceding a requirement. In the UDP draft, this is mentioned in section 9, preceding REQ-12. In the TCP draft, this is only mentioned in the text preceding REQ-9 in section 7.3. Neither of the drafts mention it in the actual requirements. Given that the normative text only appears in the descriptive text and not in the requirements in the UDP draft(soon-to-be RFC), it is *not* likely to cause much confusion. People usually pay attention to the final requirements text. As for the TCP draft, it is simply a matter of refering the ICMP draft requirements in the text, instead of stating in absolute terms. > 2) Specify how the translation state for another protocol is affected by > the reception of UDP packets: this belongs logically in the > specification of that protocol. > > For example, the reaction of TCP to "soft errors" or "hard errors" > belongs in TCP, not in ICMP. > [suresh] This comment, I believe, refers to ICMP error messages effecting the state of NAT Sessions pertaining to embedded packets. This was not the subject of Saikat's e-mail, as far as I can tell. But, you do bring up a good point here. This is another area where there is overlap in requiremens between ICMP, UDP and TCP drafts. The ICMP states this requirement as follows. REQ-6: While processing an ICMP error packet, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP error packet. The text is neutral to the transport protocol of the embedded packet. SO, it seemed to make sense to keep the normative text in the ICMP draft. However, if you believe, the text belongs in each of the protocol drafts, I am willing to go with that. Thanks. regards, suresh > -- Christian Huitema > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@xxxxxxxxxxxxxxxxxxx > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > From Internet-Drafts@ietf.org Thu, 26 Oct 2006 14:50:18 -0500 (CDT) (envelope-from ietf@ietf.org) From: Internet-Drafts@ietf.org Date: Thu, 26 Oct 2006 14:50:18 -0500 (CDT) (envelope-from ietf@ietf.org) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-multicast-04.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Network Address Port Translator (NAPT) Any-Source Multicast Requirement Author(s) : D. Wing Filename : draft-ietf-behave-multicast-04.txt Pages : 8 Date : 2006-10-26 This document places a requirement on a Network Address Translator (NAT) and Network Address and Port Translator (NAPT) that supports any-source multicast. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-multicast-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-multicast-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From Internet-Drafts@ietf.org Thu, 26 Oct 2006 14:50:21 -0500 (CDT) (envelope-from ietf@ietf.org) From: Internet-Drafts@ietf.org Date: Thu, 26 Oct 2006 14:50:21 -0500 (CDT) (envelope-from ietf@ietf.org) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-rfc3489bis-05.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Simple Traversal Underneath Network Address Translators (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-05.txt Pages : 61 Date : 2006-10-26 Simple Traversal Underneath NATs (STUN) is a lightweight protocol that serves as a tool for application protocols in dealing with NAT traversal. It allows a client to determine the IP address and port allocated to them by a NAT and to keep NAT bindings open. It can also serve as a check for connectivity between a client and a server in the presence of NAT, and for the client to detect failure of the server. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From aeh@db.org Thu, 26 Oct 2006 18:52:57 -0500 (CDT) (envelope-from aeh@db.org) From: "Alfred E. Heggestad" Date: Thu, 26 Oct 2006 18:52:57 -0500 (CDT) (envelope-from aeh@db.org) Subject: Re: [Ietf-behave] I-D ACTION:draft-ietf-behave-rfc3489bis-05.txt In-Reply-To: Message-ID: <45414A1C.7020501@db.org> MIME-Version: 1.0 Content-Type: text/plain hi some comments on draft-ietf-behave-rfc3489bis-05: > Section 11.13 REFRESH-INTERVAL > > that are being used for keepalives. The REFRESH-INTERVAL provies a > ^^^^^^^ typo - should be "provides" > Section 11.13 REFRESH-INTERVAL > > represents an interval measured in millseconds. It can be present in > ^^^^^^^^^^^ typo - should be "milliseconds" Section 6. STUN Message Structure +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|M|M|M|M|C|M|M|M|C|M|M|M|M| |1|1|9|8|7|1|6|5|4|0|3|2|2|0| |1|0| | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | should be "M1" ? ------' Section 7.1. Request/Response Transactions The STUN application SHOULD NOT retransmit STUN requests when running over TCP. -> could we change this to "MUST NOT" ? Section 9.1.1. Receive Request Message generate an error response which includes an ERROR-CORE attribute ^^^^^^^^^^ -> typo? I think this should be "ERROR-CODE".. Section 15.2. STUN Attribute Registry 0x8023: FINGERPRINT 0x8022: SERVER 0x8023: ALTERNATE-SERVER 0x8024: REFRESH-INTERVAL -> it seems like the FINGERPRINT and ALTERNATE-SERVER have got the same value (0x8023) ? In my implementation I have chosen the value 0x8025 instead. /alfred Internet-Drafts@xxxxxxxx wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Simple Traversal Underneath Network Address Translators (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-05.txt Pages : 61 Date : 2006-10-26 Simple Traversal Underneath NATs (STUN) is a lightweight protocol that serves as a tool for application protocols in dealing with NAT traversal. It allows a client to determine the IP address and port allocated to them by a NAT and to keep NAT bindings open. It can also serve as a check for connectivity between a client and a server in the presence of NAT, and for the client to detect failure of the server. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From dwing@cisco.com Thu, 26 Oct 2006 20:20:32 -0500 (CDT) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Thu, 26 Oct 2006 20:20:32 -0500 (CDT) (envelope-from dwing@cisco.com) Subject: [Ietf-behave] multicast-04: need WG discussion Message-ID: <3e2401c6f966$1238ca90$5b82200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain (As individual contributor) I rewrote the BEHAVE multicast document, which was just announced. The changes are based on a brief discussion on the AVT mailing list: http://www1.ietf.org/mail-archive/web/avt/current/msg07273.html http://www1.ietf.org/mail-archive/web/avt/current/msg07282.html and based on comments I received from other reviewers. The change is significant: the document only places one requirement on NATs that support any-source multicast and have hosts that send traffic into the same multicast group (requirement reproduced below). And that is it. The document says nothing else of substance. With the existance of RFC4605 on IGMP/MLD Proxying, I feel -- as an individual contributor -- that there is little value in the BEHAVE multicast document and we should consider removing it from our milestones. Comments? -d ----- http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-04.txt 3. Extend Mapping Timer for ASM Traffic If a NAPTed host is receiving any multicasts stream, and that NAPTed host sends UDP traffic to the same multicast address the NAPTed host is receiving, the NAPT MUST have a UDP mapping timer of 60 minutes. If a NAPT has exhausted its resources, the NAPT MAY time out a mapping before 60 minutes have elapsed. However, a NAPT is still required to follow the minimum mapping duration (REQ-5 of [I-D.ietf-behave-nat-udp]). Discussion: RTP [RFC3550] uses the source transport address (source IP address and source UDP port), in addition to the the RTP/RTCP SSRC value, to identify session members. If a session member sees the same SSRC arrive from a different transport address, that session member will perform RTP collision detection (section 8.2 of [RFC3550]). If a NAPT merely followed the requirements of [I-D.ietf-behave-nat-udp] and timed out a UDP session after 2 minutes of inactivity and RTCP receiver reports are sent less often than every 2 minutes, RTP collision detection would be performed by other session members sharing the same SSRC, complicating diagnostic tools. This situation can occur, for example, with a multicast group of approximately 300 members with a normal 50kbps audio RTP stream. To prevent this unnecessary RTP collision detection by other session members, the other session members need to see the same source transport address for the RTP and RTCP traffic from the NAPTed host. This requires the NAPT to assign the same UDP source port for that RTCP traffic. This requirement also facilitates other, non-RTP multicast applications which may function similarly. (During editing and review of this document, several prople asked about source-specific multicast and wondered why it doesn't have a similar requirement. I explain this in the document as well, but this may not be appropriate in the final version of the document:) 4. Considerations for Source-Specific Multicast (SSM) There are no special requirements on a NAPT when NAPTing Source- Specific Multicast [RFC4604] traffic. This is because with SSM, the RTCP feedback traffic from a NAPTed host is sent to a unicast address and [I-D.ietf-avt-rtcpssm] encourages SSM applications to not rely exclusively on transport address for collision detecti From magnus.westerlund@ericsson.com Fri, 27 Oct 2006 03:55:04 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) From: Magnus Westerlund Date: Fri, 27 Oct 2006 03:55:04 -0500 (CDT) (envelope-from magnus.westerlund@ericsson.com) Subject: Re: [Ietf-behave] multicast-04: need WG discussion In-Reply-To: <3e2401c6f966$1238ca90$5b82200a@amer.cisco.com> Message-ID: <4541C95D.9010604@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, (As Individual) I think it would be a mistake to scrap this document. Multicast is seeing more and more actual usage, especially in local access networks. One such application is IPTV, where the IPTV top-set box preferably can work across your home NAT. Also I don't share your thinking that RFC 4605 will be sufficient. I think it is important to include in the BEHAVE series of document to also discuss the need to have a IGMP Proxy in the NAT. In addition I think the single hard requirement included within this specification is fully sufficient for publishing this document. A few comments on the document. 1. Why did you remove the formulation that a RFC 4605 was mandated to be supported. 2. In section 3: " To prevent this unnecessary RTP collision detection by other session members, the other session members need to see the same source transport address for the RTP and RTCP traffic from the NAPTed host. This requires the NAPT to assign the same UDP source port for that RTCP traffic. This requirement also facilitates other, non-RTP multicast applications which may function similarly." I think the second sentence is wrong and confusing: "This requires the NAPT to assign the same UDP source port for that RTCP traffic." Although RTP and RTCP should have the same source IP address, they shall not share UDP port. If they are sent on different ports from the internal host, they should go out on separate ports. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx From Gonzalo.Camarillo@ericsson.com Sat, 28 Oct 2006 11:18:38 -0500 (CDT) (envelope-from gonzalo.camarillo@ericsson.com) From: Gonzalo Camarillo Date: Sat, 28 Oct 2006 11:18:38 -0500 (CDT) (envelope-from gonzalo.camarillo@ericsson.com) Subject: Re: [Ietf-behave] I-D ACTION:draft-ietf-behave-rfc3489bis-05.txt In-Reply-To: Message-ID: <4543828C.4040102@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, this draft defines two address families but does not create an IANA registry for them. It should, in case it is necessary to register more address families at some point in the future. Thanks, Gonzalo Internet-Drafts@xxxxxxxx wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Simple Traversal Underneath Network Address Translators (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-05.txt Pages : 61 Date : 2006-10-26 Simple Traversal Underneath NATs (STUN) is a lightweight protocol that serves as a tool for application protocols in dealing with NAT traversal. It allows a client to determine the IP address and port allocated to them by a NAT and to keep NAT bindings open. It can also serve as a check for connectivity between a client and a server in the presence of NAT, and for the client to detect failure of the server. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Gonzalo.Camarillo@ericsson.com Sun, 29 Oct 2006 03:16:39 -0600 (CST) (envelope-from gonzalo.camarillo@ericsson.com) From: Gonzalo Camarillo Date: Sun, 29 Oct 2006 03:16:39 -0600 (CST) (envelope-from gonzalo.camarillo@ericsson.com) Subject: [Ietf-behave] IPv6 extension draft Message-ID: <4544712F.9060806@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Folks, given that we do not need to discuss this draft in San Diego, we did not revise it for the meeting. However, we did not notice in time that the previous revision (00) has expired. We will be submitting a new revision (01) right after San Diego. In any case, we have posted a working copy of the draft at: http://users.piuha.net/gonzalo/temp/draft-ietf-behave-turn-ipv6-01.txt There are no known open issues. We are just keeping it aligned to the STUN and STUN relay usage specs. Cheers, Gonzalo From rohan@ekabal.com Sun, 29 Oct 2006 08:44:45 -0600 (CST) (envelope-from rohan@ekabal.com) From: Rohan Mahy Date: Sun, 29 Oct 2006 08:44:45 -0600 (CST) (envelope-from rohan@ekabal.com) Subject: Re: [Ietf-behave] I-D ACTION:draft-ietf-behave-rfc3489bis-05.txt In-Reply-To: Message-ID: <864cfdaa1e44eb0691d4c87a666c27fc@ekabal.com> MIME-Version: 1.0 Content-Type: text/plain Gonzalo, The purpose of a registry is to make sure that there are no conflicts and that one specific item in a large number of items can be easily found. It is not necessary to place in the registry every element of any protocol. I am skeptical that the IETF will ever define a new address family. The IPv6 address space is large enough to address every atom in the known universe. If the IETF defines a new address family there will be such a substantial number of changes needed to STUN (for example replacing all the attributes that can contain IP addresses). I am confident that there will be no conflicts at that time with other address families and that the community will be able to notice the change without consulting a registry. thanks, -rohan On Oct 28, 2006, at 9:17, Gonzalo Camarillo wrote: Hi, this draft defines two address families but does not create an IANA registry for them. It should, in case it is necessary to register more address families at some point in the future. Thanks, Gonzalo Internet-Drafts@xxxxxxxx wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Simple Traversal Underneath Network Address Translators (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-05.txt Pages : 61 Date : 2006-10-26 Simple Traversal Underneath NATs (STUN) is a lightweight protocol that serves as a tool for application protocols in dealing with NAT traversal. It allows a client to determine the IP address and port allocated to them by a NAT and to keep NAT bindings open. It can also serve as a check for connectivity between a client and a server in the presence of NAT, and for the client to detect failure of the server. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis -05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---------------------------------------------------------------------- -- _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From Gonzalo.Camarillo@ericsson.com Sun, 29 Oct 2006 09:20:21 -0600 (CST) (envelope-from gonzalo.camarillo@ericsson.com) From: Gonzalo Camarillo Date: Sun, 29 Oct 2006 09:20:21 -0600 (CST) (envelope-from gonzalo.camarillo@ericsson.com) Subject: Re: [Ietf-behave] I-D ACTION:draft-ietf-behave-rfc3489bis-05.txt In-Reply-To: Message-ID: <4544C6AB.8080901@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain Hi, if not creating the registry was not an oversight but a conscious decision, I am OK with it. Cheers, Gonzalo Rohan Mahy wrote: Gonzalo, The purpose of a registry is to make sure that there are no conflicts and that one specific item in a large number of items can be easily found. It is not necessary to place in the registry every element of any protocol. I am skeptical that the IETF will ever define a new address family. The IPv6 address space is large enough to address every atom in the known universe. If the IETF defines a new address family there will be such a substantial number of changes needed to STUN (for example replacing all the attributes that can contain IP addresses). I am confident that there will be no conflicts at that time with other address families and that the community will be able to notice the change without consulting a registry. thanks, -rohan On Oct 28, 2006, at 9:17, Gonzalo Camarillo wrote: Hi, this draft defines two address families but does not create an IANA registry for them. It should, in case it is necessary to register more address families at some point in the future. Thanks, Gonzalo Internet-Drafts@xxxxxxxx wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Simple Traversal Underneath Network Address Translators (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-05.txt Pages : 61 Date : 2006-10-26 Simple Traversal Underneath NATs (STUN) is a lightweight protocol that serves as a tool for application protocols in dealing with NAT traversal. It allows a client to determine the IP address and port allocated to them by a NAT and to keep NAT bindings open. It can also serve as a check for connectivity between a client and a server in the presence of NAT, and for the client to detect failure of the server. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------------------------ _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From aeh@db.org Tue, 31 Oct 2006 02:48:15 -0600 (CST) (envelope-from aeh@db.org) From: "Alfred E. Heggestad" Date: Tue, 31 Oct 2006 02:48:15 -0600 (CST) (envelope-from aeh@db.org) Subject: [Ietf-behave] UNKNOWN-ATTRIBUTES in draft-ietf-behave-rfc3489bis-05.txt Message-ID: <45470D92.1060102@db.org> MIME-Version: 1.0 Content-Type: text/plain hi In draft-ietf-behave-rfc3489bis-05.txt, Section 11.9 UNKNOWN-ATTRIBUTES states: "If the number of unknown attributes is an odd number, one of the attributes MUST be repeated in the list, so that the total length of the list is a multiple of 4 bytes." Would it be possible to change this to the same padding logic used for all other attributes? is there any reason for have a special padding logic for this attribute? The length field already specifies the number of valid bytes in the payload, so if the number of unknown attributes is an odd number of N, the length field should be 2*N - with 2 bytes of 0x0000 padding. /alfred From philip_matthews@magma.ca Tue, 31 Oct 2006 15:25:29 -0600 (CST) (envelope-from philip_matthews@magma.ca) From: Philip Matthews Date: Tue, 31 Oct 2006 15:25:29 -0600 (CST) (envelope-from philip_matthews@magma.ca) Subject: [Ietf-behave] Comments on draft-ietf-behave-nat-icmp-01 Message-ID: <6BAECD7B-BC14-4EE4-87E8-A50C590DDAAF@magma.ca> MIME-Version: 1.0 Content-Type: text/plain Dan Wing asked me to review draft-ietf-behave-nat-icmp-01. Below are my comments. - Philip Major comments ============== * (Section 3.2) Is the query session freed up when the query response is received by the NAT, or does it stay active for the duration of the timer? If the former, then the case for having having the mapping of the query identifier be endpoint-independent seems weakened. * In section 4.2.2, the document contains the following paragraph "In the outer header, the destination IP address will remain unchanged, as the IP addresses for Host-x is already in the external domain. If the ICMP error message is generated by Host-y, the NAT a NAPT device must simply use the NAT Session to translate the source IP address Host-y to Host-y'. However, if the ICMP error message is originated by the intermediate node Router-y, and the NAT device is a Basic NAT ([NAT-TRAD]), and it has active mapping for the IP address that sent the ICMP error, the NAT device MUST translate the source IP address of the ICMP error packet with the public IP address in the mapping. Otherwise, the NAT device MUST simply use its own IP address in the external domain to translate the source IP address." It took me a few re-reads to understand what this paragraph was getting at. If I understand correctly, it is talking about the address that should be used as the public IP address in the ICMP Error packet in the case where the NAT has more than one public address. If the ICMP packet comes from the host, then the paragraph says that the choice is easy: use the public IP address in the mapping for the TCP or UDP session that caused the error. The problem is when the ICMP error packet comes from an intermediate router behind the NAT. In this case, the above paragraph talks about an "active mapping for the IP address that sent the ICMP error". The question is: What sort of mapping? Does a mapping for a UDP or TCP session count? And what if the NAT does not support the Address Pooling behavior of Paired (which is just a SHOULD in the BEHAVE-UDP document) -- in this case, which address is used? * Section 6 talks about outbound flows that are rejected by the NAT and says that the NAT SHOULD send an ICMP message back to the internal host when this happens. However, some NAT designers may say "We never reject an outbound flow; if we get close, we just steal the entry from an existing flow". By doing this, they may claim to conform to REQ-8, while violating the spirit of the requirement. I would like to see the document discuss this issue, and perhaps make a recommendation discouraging this potential practice. * Should this document mandate support for draft-bonica-internet-icmp? Note that an early version of this work has been widely implemented in routers (since about 2000). Minor and editorial comments ============================ * Section 1 states: "Even though ICMP is a transport protocol on top of IP, ICMP message processing is often considered an integral of IP and is independent of other transport protocols. As such, many of the ICMP behavioral requirements discussed in this document apply to all IP protocols." Three comments on this: a) ICMP is not a transport protocol, but a network control protocol. b) "an integral of IP" --> "an integral part of IP" c) I don't understand what you are trying to say with this paragraph. When I review the requirements for ICMP, they seem pretty ICMP- specific, and not applicable to UDP or TCP or some other protocol running on top of IP. * In section 3.2 "an ICMP query transiting a NAT device" Not sure about "transiting". Suggest replacing with "an ICMP query that transits a NAT device" * In section 4.2 "Section 4.3 of the RFC 3022 describes the various fields within an ICMP error message a NAT device translates." Two comments: a) Missing a "that" after message. b) Everywhere else, the document say just "RFC XXXX", not "the RTC XXXX". * Also in section 4.2: "domains. Whereas, the subnets in the private network ..." Suggest either changing the "." to a ",", or changing "Whereas" to "By contrast". * And more in section 4.2: "... to Host-x, let us say that the NAT device assigned a mapping of Host-y' to associate with Host-y in the external network." This implies that the mapping is just an IP address to IP address mapping, but in some cases it also involved the Information field. * In section 4.2.2: "If the ICMP error message is generated by Host-y, the NAT a NAPT device must simply use the NAT Session to translate the ..." Delete "a NAPT". * In section 4.3 "By not effecting the NAT Sessions, the NAT device is able to retain them, even as someone spoofs ICMP error messages pertaining to the NAT Sessions." Here "effecting" should be "affecting", but I really suggest rewording this entire sentence to: "This ensures that the NAT Session will not be modified if someone is able to spoof ICMP error messages for the session." * In section 5 "REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the traversal of hairpinned ICMP query sessions. All NAT devices (i.e, Basic NAT as well as NAPT devices) MUST support the traversal of hairpinned ICMP error messages." I suggest replacing this with just "REQ-7: NAT devices MUST support the hairpin traversal of ICMP messages." The proceeding discussion mentions why this is a bit more difficult for Basic NAT devices, but I suggest that the requirement itself be stated as cleanly and simply as possible. "If the DF bit is not set and the MTU on the forwarding interface of the NAT device mandates fragmentation, the NAT device must simply send this fragmented, just as any router does [RFC1812]." Suggest rewording this as "If the DF bit is not set and the MTU on the forwarding interface of the NAT device mandates fragmentation, the NAT device MUST fragment the packet and forward the fragments [RFC1812]." * In section 7.1.1: "If the DF bit is not set and the MTU on the forwarding interface of the NAT device mandates fragmentation, the NAT device must simply send this fragmented, just as any router does [RFC1812]." Suggest rewording this as "If the DF bit is not set and the MTU on the forwarding interface of the NAT device mandates fragmentation, the NAT device MUST fragment the packet and forward the fragments [RFC1812]." From pekkas@netcore.fi Wed, 1 Nov 2006 03:58:51 -0600 (CST) (envelope-from pekkas@netcore.fi) From: Pekka Savola Date: Wed, 1 Nov 2006 03:58:51 -0600 (CST) (envelope-from pekkas@netcore.fi) Subject: Re: [Ietf-behave] Last Call: 'Multicast Requirements for a Network Address Port Translator (NAPT)' to BCP (draft-ietf-behave-multicast) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain On Mon, 18 Sep 2006, The IESG wrote: > The IESG has received a request from the Behavior Engineering for > Hindrance Avoidance WG to consider the following document: > > - 'Multicast Requirements for a Network Address Port Translator (NAPT) ' > as a BCP ... This is a late comment, but -04 version was posted to address IETF LC comments and is still being digested. Certainly the -04 versions still needs revision (see below). The biggest issue is that the document only describes IGMPv1/IGMPv2 in proxy-IGMP configuration. It would have been nice if review had been asked from MBONED WG; I don't recall seeing that. I recall a query on MAGMA WG, but that WG has been winding down for the last couple of years and is no longer active. substantial ----------- Network Address Port Translator (NAPT) Any-Source Multicast Requirement ==> I'm slightly puzzled about this title and the current way to focus the work. First, the document is supposed to support both ASM and SSM (though you describe in a section that SSM doesn't require anything, except that multicast passes through without translation) and that's what the WG has been charged to produce. So, the title seems too specific. Second, AFAICT, Behave WG doesn't produce 'NAT requirements'. It documents behavioural requirements for NATs that want to conform to BEHAVE requirements. I believe there is a difference between the two. (Similar comment applies to the Abstract.) For example, the unicast UDP document seems to have a better phrased title. ... Updates: RFC4605 (if approved) October 23, 2006 ==> looking at point above, it is not clear whether it's in the mandate of BEHAVE to Update Proxy-IGMP RFC. Even if it was, it isn't obvious to me how this document does update it. By imposing NAT timer requirements if IGMP proxy happens to implement NAT as well..? It isn't clear how that relates to IGMP proxy function specified in RFC4605. I suggest removing the Updates: line. ... This document describes the behavior of a device providing any-source multicast proxy functions as described in [RFC4605] using ICMPv1 [RFC1112] or ICMPv2 [RFC2236], and that additionally functions as a Network Address and Port Translator (NAPT), as described in section 4.1.2 of [RFC2663]. Specifically out of scope of this document are PIM-SM [RFC2362], and IPv6. PIM is used only between routers and the IGMP Proxy devices that are scoped in this document do not function as routers. IPv6 is out of scope because NAPT is not considered necessary with IPv6. ==> again this scope is more restricted than what's set out in BEHAVE charter. You restrict the solution to IGMPv1/IGMPv2 proxies only. What about IGMPv3? What about NATs which might support multicast without proxying (e.g., PIM-SM -- which many routers also supporting NAT do support)? In any case, 'IGMP Proxy devices that are scoped in this document do not function as routers' requires rewording, as the NAT boxes do decrement TTL, so they are in fact for many purposes to be considered as routers. (Also s/ICMP/IGMP/ above.) Packets with a multicast destination IP address do not have their destination IP address changed by a NAPT. ==> Actually, this could also be phrased as a behavioural requirement. You are assuming that this is how NAT has been implemented. Has this behaviour been specified somewhere? If yes, refer to it. This is however rather obviously the way this is implemented, if multicast support is implemented at all, although in theory it might be possible to translate between global-scope and scope-relative multicast addresses at the border. If a NAPTed host is receiving any multicasts stream, and that NAPTed host sends UDP traffic to the same multicast address the NAPTed host is receiving, the NAPT MUST have a UDP mapping timer of 60 minutes. ==> this is unclear. _Exactly_ 60 minutes? Or the minimum (or some other bound) of 60 minutes? It is also unclear if the timer is meant to apply to transmission, receipt, or both; if draft-ietf-behave-udp specifies this adequately, maybe provide explicit reference. (Btw. s/multicasts/multicast/ or the like) Discussion: RTP [RFC3550] uses the source transport address (source IP address and source UDP port), in addition to the the RTP/RTCP SSRC value, to identify session members. ==> IIRC, RTP and RTCP also employ consecutive port numbers. This is not mentioned here. Does that impose requirements for source port selection? But maybe this is already covered by draft-ietf-behave-nat-udp. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. ==> Is this a normative reference to an informational document? This requires variance or moving to informative references if it's not critical to understand this doc. [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. ==> this document has been obsoleted. Is it appropriate for a BCP document to normatively refer to an obsoleted document? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jdrosen@cisco.com Wed, 1 Nov 2006 09:30:15 -0600 (CST) (envelope-from jdrosen@cisco.com) From: Jonathan Rosenberg Date: Wed, 1 Nov 2006 09:30:15 -0600 (CST) (envelope-from jdrosen@cisco.com) Subject: Re: [Ietf-behave] UNKNOWN-ATTRIBUTES in draft-ietf-behave-rfc3489bis-05.txt In-Reply-To: <45470D92.1060102@db.org> Message-ID: <4548BD7C.7030804@cisco.com> MIME-Version: 1.0 Content-Type: text/plain OK, I'll make this change. -Jonathan R. Alfred E. Heggestad wrote: hi In draft-ietf-behave-rfc3489bis-05.txt, Section 11.9 UNKNOWN-ATTRIBUTES states: "If the number of unknown attributes is an odd number, one of the attributes MUST be repeated in the list, so that the total length of the list is a multiple of 4 bytes." Would it be possible to change this to the same padding logic used for all other attributes? is there any reason for have a special padding logic for this attribute? The length field already specifies the number of valid bytes in the payload, so if the number of unknown attributes is an odd number of N, the length field should be 2*N - with 2 bytes of 0x0000 padding. /alfred _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From msondhi@gmail.com Wed, 1 Nov 2006 22:55:31 -0600 (CST) (envelope-from msondhi@gmail.com) From: "Mayank Dev Sondhi" Date: Wed, 1 Nov 2006 22:55:31 -0600 (CST) (envelope-from msondhi@gmail.com) Subject: [Ietf-behave] [ietf-behave][draft-ietf-behave-turn-02.txt] -- Custom STUN/TURN Message Ids? Message-ID: MIME-Version: 1.0 Content-Type: text/plain Is there some particular postulate or range number that can be used for custom Message Ids apart from the normal list of CONNECT etc.?Our problem is that we have another message Id that we use that is unfortunately conflicting with the 0x0007 Message Id for the CONNECT request. As with custom attributes I have proposed the usage of 0x8 in the high order nibble for the mask for custom messages? This is similar to what is done for Custom attributes. Thus our custom message becomes: 0x8001 -- Request0x8101 -- Success Response0x8111 -- Failed/Error ResponseAny thoughts on the recommended approach?RegardsMayank Dev Sondhi From eric_d_cooper@sympatico.ca Fri, 3 Nov 2006 15:25:03 -0600 (CST) (envelope-from eric_d_cooper@sympatico.ca) From: "Eric Cooper" Date: Fri, 3 Nov 2006 15:25:03 -0600 (CST) (envelope-from eric_d_cooper@sympatico.ca) Subject: [Ietf-behave] Question re: State of P2P Communication Across NATs Message-ID: MIME-Version: 1.0 Content-Type: text/plain I was just reading section 3.2 (Connection Reversal,) and I was a bit confused by the final paragraph, which states: "It's main limitation, of course, is that it only works as long as only one of the communicating peers is behind a NAT *and the NAT is P2P-friendly, employing Address Independent Mapping*." The 'P2P-friendly part' is the bit that I don't understand. In this scenario, A (behind a NAT) is ultimately establishing a connection to B (publicly addressable). Wouldn't this work with 'unfriendly' NATs as well? Thanks, Eric Cooper. From dwing@cisco.com Mon, 6 Nov 2006 16:56:38 -0600 (CST) (envelope-from dwing@cisco.com) From: "Dan Wing" Date: Mon, 6 Nov 2006 16:56:38 -0600 (CST) (envelope-from dwing@cisco.com) Subject: [Ietf-behave] BEHAVE agenda Message-ID: <080e01c701f6$cb359ee0$7259150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Final BEHAVE agenda is now posted at http://www3.ietf.org/proceedings/06nov/agenda/behave.html If you're presenting, please email me your presentation in PDF or PowerPoint format. -d From Internet-Drafts@ietf.org Mon, 6 Nov 2006 17:50:15 -0600 (CST) (envelope-from ietf@ietf.org) From: Internet-Drafts@ietf.org Date: Mon, 6 Nov 2006 17:50:15 -0600 (CST) (envelope-from ietf@ietf.org) Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-tcp-02.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for TCP Author(s) : S. Guha, et al. Filename : draft-ietf-behave-tcp-02.txt Pages : 19 Date : 2006-11-6 This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-tcp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-ietf-behave-tcp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From aeh@db.org Mon, 6 Nov 2006 18:11:16 -0600 (CST) (envelope-from aeh@db.org) From: "Alfred E. Heggestad" Date: Mon, 6 Nov 2006 18:11:16 -0600 (CST) (envelope-from aeh@db.org) Subject: Re: [Ietf-behave] draft-macdonald-behave-nat-behavior-discovery-00 In-Reply-To: <47399.10.238.10.70.1160969882.webmail@10.238.10.70> Message-ID: <454FCF1A.1010407@db.org> MIME-Version: 1.0 Content-Type: text/plain Hi here are some comments on draft-macdonald-behave-nat-behavior-discovery-00 > 1. Applicability > > reliability is not as strong a requirment, applications can use this ^^^^^^^^^^ typo, should be "requirement" > 3.3. Binding Lifetime Discovery > > Binding lifetime can be discovered by performing timed tests that use > XOR-RESPONSE-ADDRESS. The client uses a second port and the STUN ^^^^^^^^^^^^^^^^^^^^ should be RESPONSE-ADDRESS ? > 3.4. Diagnosing NAT Hairpinning > > determine its mapped address. The client then sends a STUN Binding > Request to this mapped address from a different port. If the client ^^^^^^^^^^^^^^ is it enough to send from a different port? what if a packet is sent from a different host on the same LAN? according to Section 6. "Hairpinning Behavior" of draft-ietf-behave-nat-udp-08.txt there are two different hosts behind the same NAT... > 4.3. Determining NAT Filtering Behavior > > In test II, the client sends a binding request to the primary address > of the server with the CHANGE-REQUEST attribute set to change-port > and change-IP. This will cause the server to send its response from > its alternate IP address and alternate port. If the client receives > a response the current behaviour of the NAT is Address Independent > Filtering. ^^^^^^^^^^^^^^^^^^^ > I think this should be "Endpoint Independent" filtering > 7. New Attributes > > 0x0x0002: RESPONSE-ADDRESS > 0x0003: CHANGE-REQUEST > 0x0004: SOURCE-ADDRESS > 0x0005: OTHER-ADDRESS > 0x000b: REFLECTED-FROM > 0x0023: XOR-REFLECTED-FROM extra 0x in "0x0x0002". the attribute "0x8024: PADDING" is mentioned in Section 9 but not here. also this value is in conflict with "0x8024: REFRESH-INTERVAL" which is defined in draft-ietf-behave-rfc3489bis-05 > 7.1. RESPONSE-ADDRESS > > 7.3. SOURCE-ADDRESS > > 7.4. OTHER-ADDRESS > the packet format of these attributes are omitted, I guess the description should include the text: "Its syntax is identical to the MAPPED-ADDRESS attribute." /alfred derek@xxxxxxxxxxxxxxx wrote: Bruce and I submitted the NAT discovery draft discussed last IETF. Until in shows up in the repository you can find it at: https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdonald-behave-nat-behavior-discovery-00.txt and https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdonald-behave-nat-behavior-discovery-00.html -Derek _______________________________________________ Ietf-behave mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/ietf-behave From jdrosen@cisco.com Tue, 7 Nov 2006 02:04:50 -0600 (CST) (envelope-from jdrosen@cisco.com) From: Jonathan Rosenberg Date: Tue, 7 Nov 2006 02:04:50 -0600 (CST) (envelope-from jdrosen@cisco.com) Subject: [Ietf-behave] comments on draft-ietf-behave-p2p-state Message-ID: <45503E18.3090705@cisco.com> MIME-Version: 1.0 Content-Type: text/plain A high level comment - the document needs some additional context to explain the role of the "server" in each of the different approaches, there to facilitate rendezvous. Also, it would be great to include references or discussions of what existing p2p applications are actually using each technique. I'm glad to see the document use the new terms from the behave-udp document. However I don't see why the document needs to restate and re-explain those definitions in section 2. The table of contents is missing page numbers. Section 3.2, you say that connection reversal only works if one side is public and the other is behind a p2p-friendly nat. I don't see why the latter is required; you are not relying on the Nat to allocate the same ip address and port for this to work. the load on the initial introduction server S. The application does not need to attempt to detect the kind of NAT device it is behind, if any [STUN], since the procedure above will establish peer-to-peer I think you mean, "as in [STUN]" by themselves, as well as their addresses as observed by S. The clients then simultaneously start sending packets to each other at each of the alternative addresses they know about, and use the first address that leads to successful communication. If the two clients are behind the same NAT, then the packets directed to their private addresses are likely to arrive first, resulting in a direct communication channel not involving the NAT. That need not be the case; packet loss and other things can make this ordering reversed. Is "first come first served" really what is being used? Dependent Mapping. For all of these reasons, it is NOT recommended that new applications implement this trick. This technique is mentioned here only for historical and informational purposes. I agree with the sentiment; but if this is an informational document, making recommendations on techniques to use (or not) seems out of scope. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From jdrosen@cisco.com Tue, 7 Nov 2006 11:56:58 -0600 (CST) (envelope-from jdrosen@cisco.com) From: Jonathan Rosenberg Date: Tue, 7 Nov 2006 11:56:58 -0600 (CST) (envelope-from jdrosen@cisco.com) Subject: [Ietf-behave] comments on draft-macdonald-behave-nat-behavior-discovery-00 Message-ID: <4550C8DD.6060003@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Overall this is pretty decent. I'm still uncomfortable overall with some of the tone which suggests its usage to adjust application behavior, and I have comments in several places below about that. My other big technical issues are on usage determination and discovery and backwards compatibility with rfc3489. Specific comments: 1. Applicability This STUN usage does not allow an application behind NAT to make an absolute determination of the NAT's characteristics. NAT devices do not behave consistently enough to predict future behaviour with any guarantee. Applications requiring reliable reach must establish a communication channel through a NAT using another technique such as ICE [I-D.ietf-mmusic-ice] or OUTBOUND [I-D.ietf-sip-outbound]. Where reliability is not as strong a requirment, applications can use this STUN usage to select operating modes and optimizations. I think more meat is needed here. In particular, I think you need to call out that this is primarily meant for diagnostics. A little bit more on the unreliability of this is needed. You also need to discuss that this mechanism is basically "black box testing" based on modeled properties of nat which may or may not be true over time. OPEN ISSUE: should we have an SRV target for this usage, or piggyback on 3489-bis SRV discovery. If we had a separate SRV we wouldn't have to rely on 420 when dns is used. I think you need a separate SRV target. The reason is that you are assuming that the server supports extra features (change requests and the like), and this means a "discovery stun server" could be different from one used just for binding requests. The overview in section 3.1 - 3.5 would be more useful if it explained a little on how each worked, rather than just talking about which attributes get used. STUN Binding Requests allow a a client to determine whether it is behind a NAT that support hairpinning of datagrams. To perform this test, the client first sends a Binding Request to its STUN server to determine its mapped address. The client then sends a STUN Binding Request to this mapped address from a different port. If the client receives its own request, the NAT hairpins datagrams. This test applies to UDP, TCP, or TCP/TLS connections. Hmm. I wonder if the fact that the source IP address matches the target will have an impact on whether this hairpinning works or not. Have you tested this? By forcing the STUN message to be dividing into multiple fragments, the NAT's behavior can be observed. divided All of the previous tests can be performed with PADDING if a NAT's fragment behavior is important for an application, or only those tests which are most interesting to the application can be retested. PADDING only applies to UDP datagrams. Is there any expectation that behavior varies based on padding? change behaviour under load and over time. An application must assume that NAT behvaiour can become more restrictive at any time. The tests described here are for UDP connectivity, NAT mapping behaviour, and NAT filtering behaviour; additional tests could be designed. Definitions for NAT filtering and mapping behaviour are What happened to hairpinnning and timeout? 4.1. Checking if UDP is Blocked The client sends a STUN Binding Request to a server. This causes the server to send the response back to the address and port that the should clarify that this omits these various attributes defined here. Also should note that the request gets send over UDP. You can repeat the test for tcp too btw. This will require at most three tests. In test I, the client performs the UDP connectivity test but includes the OTHER-ADDRESS attribute in the binding request, with the attribute length set to 0. The server will return its alternate address and port in OTHER- ADDRESS in the binding response. So these attributes are different than rfc3489, so this won't be backwards compatible. Was there a reason you changed this? The client examines the XOR-MAPPED- ADDRESS attribute. If this address and port are the same as the local IP address and port of the socket used to send the request, the client knows that it is not NATed and the effective mapping will be Endpoint Independent. Should caveat that if the user is behind multi-layer nat, the reflexive address may actually match the source (1 in 65536 probability in such a topology). local IP address and port of the socket used to send the request, the client knows that it is not NATed and the effective mapping will be Endpoint Independent. if you're not natted there is really no such thing as mapping. I wouldn't characterize this case as "endpoint independent". If not, test III is performed: the client sends a Binding Request to the alternate address and port. Need to clarify that this is a different port than test II. This will also require at most three tests. If these tests should be performed using a port that wasn't used for mapping or other tests as packets sent during those tests may affect results. this doesnt parse. Mapping behaviour would not matter as ICE [I-D.ietf-mmusic-ice] would establish connectivity if an incoming packet can be received from the peer. This could be accomplished in only two tests: test I and test II of filtering discovery. You don't need any of this with ICE. Care must be taken when parallelizing tests, as some NAT devices have an upper limit on how quickly bindings will be allocated. you need to give more guidance. For this reason applications that require reliable bindings should send keep-alives as frequently as required by: OPEN ISSUE: ice specifies 15 seconds, outbound specifes 24-29..is there consensus here? Or can we say "the appropriate keep-alive interval" Some applications may wish to trade reliability for bandwidth savings. Applications can use this test to determine the best estimate of the NAT binding lifetime. actually I don't think its the scope of this document to even say what this should be. It is possible that the client can get inconsistent results each time this process is run. For example, if the NAT should reboot, or be reset for some reason, the process may discover a lifetime than is shorter than the actual one. For this reason, implementations are encouraged to run the test numerous times, and be prepared to get inconsistent results. also note load might impact this. OPEN ISSUE: The only attack made possible by the RESPONSE-ADDRESS that wasn't possibly before is using the STUN server to reflect a dos against a cient that is behind a Address-Dependent Filtering NAT and has openend permission to the STUN server. A direct DOS against the same endpoint would prevent this attack. As REFLECTED-FROM already provides traceability the shared secret requirement could be replaced with rate-limiting behaviour on the server. This would allow the deployment of STUN servers w/out shared secrets. I prefer having the shared secret and am glad that is what you specified. This is a disaster waiting to happen. The client indicates it is interested in the NAT Behavior Discovery usage by including one of the attributes defined in this draft. I don't think this really means anything. A client MUST be prepared for receiving a 420 (Unknown Attribute) error to its requests. This response indicates that the server does not implement that particular attribute. An unsupported attribute prevents some tests from being run, but others may work. For example, only RESPONSE-ADDRESS is necessary for binding lifetime discovery, whereas mapping and filtering discovery do not require it, but do require OTHER-ADDRESS and CHANGE-REQUEST. Yuck. This introduces a lot of complexity in the client. You should use a different SRV for this usage and require servers to implement all attributes. The server MUST NOT include any attribute defined in this document in the Response to a Request that does not contain at least one attribute defined in this document. Huh? If the Request contains a RESPONSE-ADDRESS attribute, but the message does not contain a MESSAGE-INTEGRITY attribute and a USERNAME, the server MUST generate an error response of type 401. If RESPONSE- ADDRESS is included, then the server must verify that it has previously received a binding request from the same address as is specified in RESPONSE-ADDRESS. If it has not, or if sufficient time has passed that it no longer has a record of having received such a request due to limited state, it MUST respond with an error response of type 430. OPEN-ISSUE: is this too strong? There is no amplification attack here. Maybe either require a shared secret, but don't track addresses, or track addresses that have done binding requests but not relate them to shared secret or just put in a rate limit and leave it at that? This introduces a big burden on the server. I'm on the fence about whethre its needed. Will think about it more... The server MUST add a SOURCE-ADDRESS attribute to the Binding Response, containing the source address and port used to send the Binding Response. where does this get used? If it supports an alternate address and port and the Binding request contained a zero-length OTHER-ADDRESS attribute the server MUST add an OTHER-ADDRESS attribute to the Binding Response. This contains the source IP address and port that would be used if the client had set the "change IP" and "change port" flags in the Binding Request. As summarized in Table 1, these are Ca and Cp, respectively, regardless of the value of the CHANGE-REQUEST flags. So you are using the zero-length OTHER-ADDRESS as a flag to return the actual value in the response? Yuck. Per above, you should just always send it and use SRV to differentiate usage. 8.1. Problem Definition >From RFC 3424 [RFC3424], any UNSAF proposal must provide: extra ">" diagnose the cause of problems experienced by that or other applications or for an application to modify its behavior based on the current behavior of the NAT. I'm uncomfortable with the second half of this. The STUN NAT Behavior Discovery usage does not itself provide an exit strategy. Instead, that is provided by other protocols. Specifically, the Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice] mechanism allows two cooperating clients to interactively determine the best addresses to use when communicating, regardless of the type of NAT involved. I disagree with the statements here. If you stick to just diagnostics, then the exit path is easy - no nATs, no problems, no diagnostics needed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com From lowekamp@sipeerior.com Tue, 7 Nov 2006 13:51:27 -0600 (CST) (envelope-from lowekamp@gmail.com) From: "Bruce Lowekamp" Date: Tue, 7 Nov 2006 13:51:27 -0600 (CST) (envelope-from lowekamp@gmail.com) Subject: Re: [Ietf-behave] review of rfc3489bis-04 In-Reply-To: <20d2bdfb0610091056iba0cf7bx9ecc431a2e7a777a@mail.gmail.com> Message-ID: <20d2bdfb0611071151v3f10e661o8e9f592476444420@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Jonathan, I think that -05 addresses my concerns. Just a couple outstanding issues after reading -05. Bruce > Protocol issues: > > There are several issues that are motivated by the combination of > supporting new usages as extensions and trying to integrate our > implementation into an entire SIP stack. > > - It would be much easier to implement a stack-level for STUN if > specific bits indicated whether a message is a request, response, > error response, or indication. In several spots the draft refers to > response and error response types as 0x100 and 0x110 higher, which I > assume is intended to indicate bits to be set, but I don't think it > technically reads that way. However, no way of determining whether > a type is an indication is mentioned in the draft. Providing for > future message types to be identified without recompiling the code > with a new list of types for a new usage would be very helpful. I think this is a good idea, almost a necessity based on the layering that is now introduced. You are correct that currently nothing indicates that a message is an indication, and it should. Unfortunately the currently allocated values for the TURN indications (which is the only place they are being used) doesn't allow an easy way to identify them. However I think we are better off changing the turn message values to fix this. I wouldn't object to leaving the existing turn values as legacy, but if there's not much concern about backwards compatibility, I agree that the best approach would be to start with the right vaues. > > - There are a number of issues if future usages are defined that are > not idempotent. For example, Section 6 allows bit-wise identical > requests to use the same transaction ID. I assume this is intended > to simplify periodic keepalives for low-power devices, however I > don't think that assuming re-using transaction IDs is safe for future > usages is a good idea. I suggest revising the two sentences (or one > if changed) in that paragraph that allow TID reuse to indicate that > TIDs cannot be reused except for retransmissions of the same request > unless allowed by the particular usage. It wasn't meant to imply that you can reuse a TID for future transactions. I'll reword. Section 6, page 13 of -05 still has the text: Unless a request or indication is bit-wise identical to a previous request, and was sent to the same server from the same transport address, a client MUST choose a new transaction ID for it. Perhaps wording: Unless a request is a retransmission of a previous request due to the timer expiring (see Section 7.1), is bit-wise identical to the previous transmission, and is sent to the same server from the same transport address, a client MUST choose a new transaction ID for it. Each indication sent, regardless of whether it is bit-wise identical to a previous indication, MUST have a new transaction ID. > - Are NONCEs intended to be used to challenge each individual > request/response or as a per-session value? Per-session. That is, they are cached and reused in subsequent requests to the same IP/port. 8.3.1 top of page 18 has this text: The NONCE is included in the request only if a short or long term credential is being used, and only if the STUN request is a retry as a consequence of a previous error response which provided the client with a NONCE. perhaps replace with The NONCE is included in the request only if a short or long term credential is being used, and only if the STUN server to which the request is sent previously gave the client an error response that provided the client with a NONCE. > - I don't see an error code for unknown message type. Perhaps 405? > (generating these properly also requires being able to identify whether > the unknown type is a request or an indication) Per above we can now do this. I am somewhat conflicted on whether we need to. The original STUN didn't include this sicne there just wasn't the level of flexibility and extensibility to merit it. Even now, its not clear. We're tying extensibility more to usages than methods. I'm inclined to omit it, and add text that says to reject with a 400 if the method is unknown. If I added a code for unknown methods, you'd need to add a "supported"-like mechanism as SIP has for that code to be useful, and furthermore only under the assumption that there is remedy (i.e., another method to try). I would personally prefer an error code, but don't have a strong preference. > > - in section 12, there is an explicit assumption that binding requests > will always require integrity, but keepalives won't. I don't think > I agree with this in all cases. If using STUN for binding inside a > TLS connection, I don't think integrity is required. Fair enough; I dont think the spec says you have to use it though. So I'm not sure what you are asking me to change with the binding usage. I'm happy with the new wording in Section 12. A couple other issues: Section 10. FINGERPRINT is no longer cryptographic 11.3, 11.11 USERNAME is here in text copied into this section. From lowekamp@sipeerior.com Tue, 7 Nov 2006 14:30:22 -0600 (CST) (envelope-from lowekamp@gmail.com) From: "Bruce Lowekamp" Date: Tue, 7 Nov 2006 14:30:22 -0600 (CST) (envelope-from lowekamp@gmail.com) Subject: Re: [Ietf-behave] draft-macdonald-behave-nat-behavior-discovery-00 In-Reply-To: <47399.10.238.10.70.1160969882.webmail@10.238.10.70> Message-ID: <20d2bdfb0611071230k5dfb1728p4b277f1ded02e4dc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Alfred, Thanks for the comments. We'll try to fix them in the next version. On 11/6/06, Alfred E. Heggestad wrote: > 3.4. Diagnosing NAT Hairpinning > > determine its mapped address. The client then sends a STUN Binding > Request to this mapped address from a different port. If the client ^^^^^^^^^^^^^^ is it enough to send from a different port? what if a packet is sent from a different host on the same LAN? according to Section 6. "Hairpinning Behavior" of draft-ietf-behave-nat-udp-08.txt there are two different hosts behind the same NAT... I think sending it from a different port is sufficient, since it's mostly a matter of whether the NAT is capable of realizing it needs to route it back to the private network. Actually, if a NAT applies filtering to hairpinning packets, it might be necessary to send packets in both directions to complete this check. Practically speaking, the best you can typically do is use a different port. I think we can put text in suggesting the use of a different host/private IP address to send the probes from, but that's not an option for most clients. Bruce From lowekamp@sipeerior.com Tue, 7 Nov 2006 18:58:10 -0600 (CST) (envelope-from lowekamp@gmail.com) From: "Bruce Lowekamp" Date: Tue, 7 Nov 2006 18:58:10 -0600 (CST) (envelope-from lowekamp@gmail.com) Subject: Re: [Ietf-behave] comments on draft-macdonald-behave-nat-behavior-discovery-00 In-Reply-To: <4550C8DD.6060003@cisco.com> Message-ID: <20d2bdfb0611071658p7f60e2c8r926971250298afe3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Jonathan, Thanks for the feedback. Responses inline. On 11/7/06, Jonathan Rosenberg wrote: Overall this is pretty decent. I'm still uncomfortable overall with some of the tone which suggests its usage to adjust application behavior, and I have comments in several places below about that. My other big technical issues are on usage determination and discovery and backwards compatibility with rfc3489. Specific comments: > 1. Applicability > > This STUN usage does not allow an application behind NAT to make an > absolute determination of the NAT's characteristics. NAT devices do > not behave consistently enough to predict future behaviour with any > guarantee. Applications requiring reliable reach must establish a > communication channel through a NAT using another technique such as > ICE [I-D.ietf-mmusic-ice] or OUTBOUND [I-D.ietf-sip-outbound]. Where > reliability is not as strong a requirment, applications can use this > STUN usage to select operating modes and optimizations. I think more meat is needed here. In particular, I think you need to call out that this is primarily meant for diagnostics. A little bit more on the unreliability of this is needed. You also need to discuss that this mechanism is basically "black box testing" based on modeled properties of nat which may or may not be true over time. agreed. In particular, we probably should have a very large explicit warning not to use this to decide not to do appropriate NAT traversal, such as doing ICE passive mode. > OPEN ISSUE: should we have an SRV target for this usage, or piggyback > on 3489-bis SRV discovery. If we had a separate SRV we wouldn't have > to rely on 420 when dns is used. I think you need a separate SRV target. The reason is that you are assuming that the server supports extra features (change requests and the like), and this means a "discovery stun server" could be different from one used just for binding requests. I think it's fine to add an additional SRV target, but I think we need to be careful to not essentially prohibit backward compatibility with 3489 with that requirement, i.e. if we say MUST NOT send a behavior discovery question unless it finds an SRV mapping, a client wouldn't contact a legacy server. Personally, I think that UNKNOWN-ATTRIBUTE is sufficient for what we need, but I agree that it's better to try an SRV target first. The overview in section 3.1 - 3.5 would be more useful if it explained a little on how each worked, rather than just talking about which attributes get used. agreed > STUN Binding Requests allow a a client to determine whether it is > behind a NAT that support hairpinning of datagrams. To perform this > test, the client first sends a Binding Request to its STUN server to > determine its mapped address. The client then sends a STUN Binding > Request to this mapped address from a different port. If the client > receives its own request, the NAT hairpins datagrams. This test > applies to UDP, TCP, or TCP/TLS connections. Hmm. I wonder if the fact that the source IP address matches the target will have an impact on whether this hairpinning works or not. Have you tested this? Interesting question. I've never tested, but it's probably true that we should try to send packets in each direction in case filtering is appled. While I think it would be better to use different IP addresses, I don't think that's a possibility for most clients. > All of the previous tests can be performed with PADDING if a NAT's > fragment behavior is important for an application, or only those > tests which are most interesting to the application can be retested. > PADDING only applies to UDP datagrams. Is there any expectation that behavior varies based on padding? Older netgear NATs (at least) drop hairpinned fragments. I think Cullen told me that a couple other vendors have this same bug. This was a PITA to diagnose... > change behaviour under load and over time. An application must > assume that NAT behvaiour can become more restrictive at any time. > The tests described here are for UDP connectivity, NAT mapping > behaviour, and NAT filtering behaviour; additional tests could be > designed. Definitions for NAT filtering and mapping behaviour are What happened to hairpinnning and timeout? good point > 4.1. Checking if UDP is Blocked > > The client sends a STUN Binding Request to a server. This causes the > server to send the response back to the address and port that the should clarify that this omits these various attributes defined here. Also should note that the request gets send over UDP. You can repeat the test for tcp too btw. > This will require at most three tests. In test I, the client > performs the UDP connectivity test but includes the OTHER-ADDRESS > attribute in the binding request, with the attribute length set to 0. > The server will return its alternate address and port in OTHER- > ADDRESS in the binding response. So these attributes are different than rfc3489, so this won't be backwards compatible. Was there a reason you changed this? Sorry, this wasn't clear. The intention is to be backward compatible, but both Derek and I agreed that the CHANGED-ADDRESS name didn't make any sense to us when we first read the 3489, and even after reading it we found the name confusing, so we decided to propose renaming it to OTHER-ADDRESS. However, the definition of the field and its attributed code are identical, so it's still the same protocol and should be backward compatible. > The client examines the XOR-MAPPED- > ADDRESS attribute. If this address and port are the same as the > local IP address and port of the socket used to send the request, the > client knows that it is not NATed and the effective mapping will be > Endpoint Independent. Should caveat that if the user is behind multi-layer nat, the reflexive address may actually match the source (1 in 65536 probability in such a topology). > local IP address and port of the socket used to send the request, the > client knows that it is not NATed and the effective mapping will be > Endpoint Independent. if you're not natted there is really no such thing as mapping. I wouldn't characterize this case as "endpoint independent". > If not, test III is performed: the client sends a Binding Request to > the alternate address and port. Need to clarify that this is a different port than test II. all agreed > This will also require at most three tests. If these tests should be > performed using a port that wasn't used for mapping or other tests as > packets sent during those tests may affect results. this doesnt parse. Remove the "If" and maybe change the "as" to "because": to: This will also require at most three tests. These tests should be performed using a port that wasn't used for mapping or other tests because packets sent during those tests may affect results. > Mapping behaviour > would not matter as ICE [I-D.ietf-mmusic-ice] would establish > connectivity if an incoming packet can be received from the peer. > This could be accomplished in only two tests: test I and test II of > filtering discovery. You don't need any of this with ICE. You're right, that paragraph is trying to cover too many concepts too quickly. Definitely need to fix. > Care must be taken when parallelizing tests, as some NAT devices have > an upper limit on how quickly bindings will be allocated. you need to give more guidance. > For this reason > applications that require reliable bindings should send keep-alives > as frequently as required by: > > OPEN ISSUE: ice specifies 15 seconds, outbound specifes 24-29..is > there consensus here? Or can we say "the appropriate keep-alive > interval" Some applications may wish to trade reliability for > bandwidth savings. Applications can use this test to determine the > best estimate of the NAT binding lifetime. actually I don't think its the scope of this document to even say what this should be. Agreed, I think in both cases the right approach is to reference nat-udp and the other docs that go into more detail on these issues. > It is possible that the client can get inconsistent results each time > this process is run. For example, if the NAT should reboot, or be > reset for some reason, the process may discover a lifetime than is > shorter than the actual one. For this reason, implementations are > encouraged to run the test numerous times, and be prepared to get > inconsistent results. also note load might impact this. > OPEN ISSUE: The only attack made possible by the RESPONSE-ADDRESS > that wasn't possibly before is using the STUN server to reflect a dos > against a cient that is behind a Address-Dependent Filtering NAT and > has openend permission to the STUN server. A direct DOS against the > same endpoint would prevent this attack. As REFLECTED-FROM already > provides traceability the shared secret requirement could be replaced > with rate-limiting behaviour on the server. This would allow the > deployment of STUN servers w/out shared secrets. I prefer having the shared secret and am glad that is what you specified. This is a disaster waiting to happen. > The client indicates it is interested in the NAT Behavior Discovery > usage by including one of the attributes defined in this draft. I don't think this really means anything. That depends on the SRV issue and backward compatibility issue above. The client indicates it's interested in the behavior usage by including one of the behavior attributes. Otherwise a new client can't talk with an old server that's not properly listed with the SRV) and it's not possible to multiplex the two usages on the same port. > A client MUST be prepared for receiving a 420 (Unknown Attribute) > error to its requests. This response indicates that the server does > not implement that particular attribute. An unsupported attribute > prevents some tests from being run, but others may work. For > example, only RESPONSE-ADDRESS is necessary for binding lifetime > discovery, whereas mapping and filtering discovery do not require it, > but do require OTHER-ADDRESS and CHANGE-REQUEST. Yuck. This introduces a lot of complexity in the client. You should use a different SRV for this usage and require servers to implement all attributes. I disagree (well, yes, it's a bit more complex, but it shouldn't be *that* controversial to say a client must be prepared for a 420 error). It's harder to deploy a server with multiple addresses than with only a single address, and binding lifetime discovery can be very useful by itself. Part of the goal was to provide tools that allow useful behavior tests to be built, but not necessarily proscribe only a specific set of tests (the tests themselves are descriptive, not normative). In this particular case, though, it's a bit simpler, in that a client shouldn't send a request with a CHANGE-REQUEST attribute without having previously received a response from the server with an OTHER-ADDRESS field. Will make sure that is specified. > The server MUST NOT include any attribute defined in this document in > the Response to a Request that does not contain at least one > attribute defined in this document. Huh? This allows a server to multiplex both the behavior discovery usage and traditional binding usage on the same port. Otherwise, a plain 3489bis client could receive a response with an OTHER-ADDRESS attribute and reject it. > If the Request contains a RESPONSE-ADDRESS attribute, but the message > does not contain a MESSAGE-INTEGRITY attribute and a USERNAME, the > server MUST generate an error response of type 401. If RESPONSE- > ADDRESS is included, then the server must verify that it has > previously received a binding request from the same address as is > specified in RESPONSE-ADDRESS. If it has not, or if sufficient time > has passed that it no longer has a record of having received such a > request due to limited state, it MUST respond with an error response > of type 430. > > OPEN-ISSUE: is this too strong? There is no amplification attack > here. Maybe either require a shared secret, but don't track > addresses, or track addresses that have done binding requests but not > relate them to shared secret or just put in a rate limit and leave it > at that? This introduces a big burden on the server. I'm on the fence about whethre its needed. Will think about it more... Agreed. We talked about this awhile. Really seems to depend on how bad you think the threat of misuse of RESPONSE-ADDRESS is and how much you trust clients before you give them a shared secret in the first place. If RESPONSE-ADDRESS isn't too big of a threat and short term credentials are only issued to trusted nodes, it's probably unnecessary. If untrusted nodes are involved, I'm still not sure. It's not an amplification, but it sort of anonymizes the attack and it could be obnoxious if used to attack an unsecured protocol. > The server MUST add a SOURCE-ADDRESS attribute to the Binding > Response, containing the source address and port used to send the > Binding Response. where does this get used? preserved from 3489, the definition of SOURCE-ADDRESS in 7.3 suggests that it could be used to detect twice NAT configurations, which I think means trying to detect when the STUN server is behind a NAT. > If it supports an alternate address and port and the Binding request > contained a zero-length OTHER-ADDRESS attribute the server MUST add > an OTHER-ADDRESS attribute to the Binding Response. This contains > the source IP address and port that would be used if the client had > set the "change IP" and "change port" flags in the Binding Request. > As summarized in Table 1, these are Ca and Cp, respectively, > regardless of the value of the CHANGE-REQUEST flags. So you are using the zero-length OTHER-ADDRESS as a flag to return the actual value in the response? Yuck. Per above, you should just always send it and use SRV to differentiate usage. Again, both multiplexing and backward compatibility come into play here. I think the other idea to support multiplexing was to have a CHANGE-REQUEST without either bit set. > 8.1. Problem Definition > > >From RFC 3424 [RFC3424], any UNSAF proposal must provide: extra ">" > diagnose the cause of problems experienced by that or other > applications or for an application to modify its behavior based on > the current behavior of the NAT. I'm uncomfortable with the second half of this. how about "optimize" or a statement to the effect that it can be used for trying to pick a starting algorithm for the application, but that the application must be able to change (and detect the need to) if the nat behavior changes from what is initially discovered? > The STUN NAT Behavior Discovery usage does not itself provide an exit > strategy. Instead, that is provided by other protocols. > Specifically, the Interactive Connectivity Establishment (ICE) > [I-D.ietf-mmusic-ice] mechanism allows two cooperating clients to > interactively determine the best addresses to use when communicating, > regardless of the type of NAT involved. I disagree with the statements here. If you stick to just diagnostics, then the exit path is easy - no nATs, no problems, no diagnostics needed. true. Bruce From lowekamp@sipeerior.com Tue, 7 Nov 2006 20:20:48 -0600 (CST) (envelope-from lowekamp@gmail.com) From: "Bruce Lowekamp" Date: Tue, 7 Nov 2006 20:20:48 -0600 (CST) (envelope-from lowekamp@gmail.com) Subject: Re: [Ietf-behave] comments on draft-macdonald-behave-nat-behavior-discovery-00 In-Reply-To: <4550C8DD.6060003@cisco.com> Message-ID: <20d2bdfb0611071820m49789327wbf85ed901167e9f8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain I thought a bit more about backward compatibility with both behavior discovery and 3489bis in general. There's generally not a problem with a 3489 client to a bis server, because of the magic cookie. A bis server that supports behavior discovery can include the OTHER-ADDRESS/CHANGED-ADDRESS that is MUST in 3489 and one that doesn't support it won't include it and will 420 on any nat type query from the 3489 client. A bis client to a 3489 server seems to be a bit harder. I think right now a bis client would fail any transaction from a 3489 server because the CHANGED-ADDRESS is a MUST in the response in 3489. Unless I'm missing something, maybe this is a problem that should actually be worked around in 3489bis. As far as a bis client supporting behavior discovery to a 3489 server, I *think* that's OK, although since the original spec didn't support the probing for support of our discovery draft, it's hard to be sure what the server would do with either an empty OTHER-ADDRESS or an empty CHANGE-REQUEST. I think this was the basis for picking an empty OTHER-ADDRESS---it seems less likely that a 3489 server would have a problem with it than with an empty CHANGE-REQUEST. I think you're right that not multiplexing behavior discovery with conventional binding discovery makes things a little bit cleaner, but I don't feel like adding the probe for support is that awkward. I think it's a question of comparing this unusual use of an empty attribute with the cost of not interoperating with 3489 servers that are only registered with the regular SRV entry (if that). But another approach that might work is to require a behavior discovery compliant server to have an SRV entry and identifying a 3489 server that supports the usage by its inclusion of CHANGED-ADDRESS in its response to a simple binding request. That might work, but it still essentially results in a probe to see if the server supports the usage. Maybe there aren't really enough 3489 servers around that support this usage to be worth worrying about, though... Bruce