[09:33:28] --- jfischl has become available
[09:34:11] --- Melinda has become available
[09:34:42] --- jgre has become available
[09:37:34] --- dotis has become available
[09:37:47] --- fluffy has become available
[09:38:16] <dotis> Behave getting started
[09:39:38] --- bhoeneis has become available
[09:40:08] --- csp has become available
[09:40:10] <dotis> Brian Ford asks for time to address 6 conflicts.
[09:40:48] <dotis> See what time allows.
[09:42:24] <dotis> Alignment of terminolgy is paramont. These issue are already on the agenda.
[09:43:15] <dotis> draft-ietf-behave-nat-udp-00
[09:43:27] <dotis> No major issues...
[09:44:25] <dotis> Clarifies this applies traditional Nats, (used to include bi and twice nats)
[09:45:02] <dotis> address dependent mapping rather than based upon the end point
[09:45:21] <dotis> Listed requirements in flow with text.
[09:45:42] <dotis> Combined mapping refresh scope and mapping refresh direction.
[09:46:19] <dotis> remove description of Cone/Symetric as no one would agree what it means.
[09:46:45] <dotis> Added clarifications for ICMP and fragmentation sections.
[09:47:13] <dotis> Changes to Requirement 3 slide.
[09:47:45] <dotis> Mostly a clean up of the language by getting rid of the double negatives.
[09:48:38] <dotis> Deleted Req 6b. Mapping refresh direction method.
[09:48:54] <dotis> Req 7 still has an open issue.
[09:49:55] <dotis> There are reasons to have filtering that is address end point dependent.
[09:50:37] <dotis> filtering behavior is an option configurable by the administrator. This is the open issue.
[09:51:13] <dotis> Req 9 slide, ALGs default off,
[09:51:47] <dotis> Req 11, ICMP must not destroy NAT mapping.
[09:52:13] --- csp has left
[09:52:15] <dotis> Req 7a Should the MAY be a SHOULD?
[09:52:58] <dotis> Forgot to remove 5.2 as agreed. This will be removed if everyone still agrees, yes.
[09:53:16] <dotis> Req 7
[09:53:49] <dotis> There is a desire to have a stonger endorsement for administrative configuration.
[09:54:49] --- bew has become available
[09:54:57] <Melinda> Could people at the mike identify themselves? Thanks.
[09:56:03] <dotis> Applicatons behind nats with address depend filter behavior need help.
[09:56:03] --- dotis has left: Disconnected
[09:58:35] --- jfischl has left: Replaced by new connection
[09:58:36] --- jfischl has become available
[09:59:13] --- nm has become available
[10:03:34] --- dotis has become available
[10:04:02] <dotis> Long talk about what is involve when using the term SHOULD.
[10:05:12] <dotis> We want both options, why word smith a desire to have both options?
[10:05:19] --- nm has left: Replaced by new connection
[10:05:20] --- nm has become available
[10:05:22] --- nm has left
[10:05:44] <dotis> What will resolve this issue with wording?
[10:06:40] <dotis> This is at odds with a goal for a minimal set.
[10:06:55] --- nm has become available
[10:07:19] <dotis> Already applications must accommodate either option.
[10:09:03] <dotis> This changes how P-P operate. There some will assist to setup connections but require NAT that allow first class Internet Presence.
[10:09:52] <dotis> By allowing NATs to have address depend filtering behavior, this will errode this mode of operation where there will be super nodes that act to setup other connections.
[10:09:59] <dotis> Many P-P must have this feature.
[10:10:36] <dotis> How is this germain with this being a may or should?
[10:12:40] <dotis> Why would they want a recommend? They want to have a higher percentage of compliance. This requires more choices, they will then include this option which allows the desired operation.
[10:13:00] <dotis> Are there NAT vendors here that see this as a problem?
[10:13:25] <dotis> We don't represent NAT vendors, so our expectatons are low.
[10:13:48] <dotis> They don't want to make changes, and so will ignore the recommendations for change.
[10:14:10] --- lars has become available
[10:15:07] <dotis> This document should provide guidance for applications rather than how to build the NATS.
[10:15:45] <dotis> This may provide guidance on this wording issue as this type of advice will be ignored.
[10:16:06] <dotis> This will not be ignored, as they understand what is being said.
[10:16:35] <dotis> This wording is finely tuned. Too much wording may create a problem.
[10:17:13] --- fluffy has left: Disconnected
[10:17:45] --- lars has left: Logged out
[10:17:51] <dotis> I think that the wg should go with should. It is hard to put in these requirements.
[10:18:10] <dotis> How to close this issue?
[10:18:29] <dotis> Plea to NAT vendors...
[10:18:59] --- andrewdmcgregor@psg.com has become available
[10:20:05] <dotis> Representing an application vendor, this is where the NATs differ. Most NATs are not configurable, as they are largely plug and play. Only the higher end may do this but then they worry about security where this could be a problem.
[10:20:35] <dotis> We shot for making our product to work with NATs that are end point independent.
[10:21:01] <dotis> Adding more knobs does not help with the goals.
[10:21:50] <dotis> The NATs that are address dependent are going away and this problem only exists at the high end.
[10:22:43] <dotis> Low end vendors can not handle support calls, so they must make their products look like others in the market.
[10:22:58] <dotis> Adding options will create support calls.
[10:23:11] <dotis> It seems we are not closer...
[10:23:37] <dotis> Is there anyone in favor of should.... No one says anything?
[10:23:49] <dotis> No one willing to support Should.
[10:25:31] <dotis> Nat vendor expressing an their view. Asking about the definitions of tuples used when permiting connections.
[10:25:47] <dotis> Security dictates these issues.
[10:26:35] <dotis> Most customers would be foolish to allow this option.
[10:26:36] --- nm has left: Disconnected
[10:27:29] <dotis> ALGs may provide a solution.
[10:27:56] <dotis> There is a window open to Hijacking however.
[10:28:17] --- nm has become available
[10:28:35] <dotis> This issue stays a MAY.
[10:29:26] <dotis> Bringing up the issue of fragmented packets.
[10:29:54] <dotis> Nats must handle fragments may create DoS concerns.
[10:31:09] <dotis> Many version of Linux may actually send in the wrong order, which means NATS that don't process this, will mean these systems will not work.
[10:31:34] <dotis> This is a MAY to MUST change in Req 13.
[10:32:50] <dotis> Advise to try up to a point. Must support out of order.
[10:33:24] <dotis> No vendor can do this because there is no means to defend against the attack.
[10:34:17] <dotis> This attack cause those that implement out of order packets will be seen as having a bug with respect to DoS attack.
[10:34:51] <dotis> There is a RFC that requires support of out of order.
[10:35:37] <dotis> I don't understand the DoS attack problem. Limit the amount of reassembly rather then failing totally.
[10:35:58] <dotis> The problem is related to the size of the packet.
[10:36:14] <dotis> Allow a reassembly pool to handle this issue.
[10:36:56] <dotis> This is a requirement that vendors try by allowing a buffer for this effort.
[10:37:48] --- dumdidum has become available
[10:37:50] <dotis> The behavior would only be affected when under attack with the buffer allocation?
[10:38:06] <dotis> Should we recommend the amount of memory for this feature?
[10:38:19] <dotis> What size?
[10:38:52] <dotis> Leave it open and just suggest a reasonable amount.
[10:39:14] <dotis> Next topic.
[10:39:44] --- andrewdmcgregor@psg.com has left: Disconnected
[10:40:03] <dotis> Twice NAT is a growing issue for hair-pin traffic, for example.
[10:40:19] <dotis> These NATs use DHCP to find their IP address.
[10:40:45] <dotis> This is great if these are routable address, but what happens when these are private addresses?
[10:41:29] <dotis> There can be conflicts within the private address space.
[10:42:12] <dotis> This creates a difficult problem for people to resolve.
[10:42:42] <dotis> Can you provide data about this twice NAT becoming worse?
[10:43:04] <dotis> No, just by comments that the developing world is seeing this more.
[10:43:34] <dotis> Replies from NANOG is that this is rather common.
[10:43:57] <dotis> This is common within wireless world and cable.
[10:44:20] <dotis> This is based upon about 30 replies.
[10:44:53] <dotis> Act as engineers and support these "trend" statements.
[10:45:35] <dotis> There is a common misconfiguration within home networks regarding the implementation of bridging.
[10:46:12] <dotis> Don't care about how common this problem is, we should add text to the draft.
[10:46:58] <dotis> When there is a DHCP for the inside of the NAT, it should be aware of this issue. Do expect the user to repair the problem.
[10:47:25] <dotis> Don't use the term DHCP as there are other means for the IP address to be assigned.
[10:47:55] <dotis> Next issue.
[10:48:29] <dotis> How many issues are remaining?
[10:51:10] <dotis> We do not need to discuss this issue. This is between the chairs and AD. This should not be taken to the WG. There is no need for consensus.
[10:51:19] <dotis> Now moving to TCP...
[10:51:46] <dotis> Terminology issues may still be open withn the UDP draft...
[10:52:25] <dotis> Back to UDP terms...
[10:53:28] <dotis> There has been difficulty getting feedback from the list.
[10:54:00] <dotis> There has been a profound amount of discussion...
[10:54:34] --- dotis has left: Disconnected
[10:55:54] --- dotis has become available
[10:55:55] --- jfischl has left: Replaced by new connection
[10:55:56] --- jfischl has become available
[10:56:39] --- dumdidum has left: Replaced by new connection
[10:56:50] <dotis> The problems of terms is related to testing versus application.
[10:57:58] --- dumdidum has become available
[10:58:11] --- dumdidum has left
[10:58:17] <dotis> There is not a view that the target audience is NAT or APP vendors.
[10:59:00] <dotis> Asking about who read the draft.. about 10 raise their hands.
[10:59:49] <dotis> No one else has concerns...
[10:59:59] <dotis> Moving to TCP.
[11:00:06] --- dumdidum has become available
[11:00:20] --- dumdidum has left
[11:00:22] <dotis> Bing out of time.
[11:00:35] --- bew has left
[11:00:40] <dotis> Opps.
[11:01:04] --- Melinda has left
[11:05:19] --- jgre has left: Replaced by new connection
[11:09:34] --- dotis has left: Logged out
[11:09:57] --- dotis has become available
[11:12:56] --- nm has left: Replaced by new connection
[11:12:57] --- nm has become available
[11:13:00] --- nm has left
[11:17:01] --- dotis has left: Disconnected
[11:17:13] --- dotis has become available
[11:17:22] --- dotis has left
[11:19:08] --- jfischl has left: Disconnected
[11:20:21] --- bhoeneis has left: Disconnected