Subject: [Ietf-behave] Thinking about the BoF

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 3 Aug 2004 23:15:46 -0700 (PDT)

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: Melinda Shore <[email-masked]>
Date: Wed, 4 Aug 2004 09:50:37 -0700 (PDT)

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: Ahmed Bashandy <[email-masked]>
Date: Wed, 4 Aug 2004 11:49:47 -0700 (PDT)

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:

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Wed, 4 Aug 2004 22:42:39 -0700 (PDT)

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" <spencer@xxxxxxxxxxxxx>
To: "IETF Behave Mailing List" <ietf-behave@xxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, August 03, 2004 11:15 PM
Subject: [Ietf-behave] Thinking about the BoF

> Hmmm in favor? Room sense is "yes".

**********************************
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: Geoff Huston <[email-masked]>
Date: Thu, 5 Aug 2004 08:00:44 -0700 (PDT)

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.

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 Kuthan <[email-masked]>
Date: Thu, 5 Aug 2004 14:10:23 -0700 (PDT)

At 08:15 AM 8/4/2004, Spencer Dawkins wrote:
[...]
>can start volunteering?
> I'm expecting to see an UDP document called

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 Kuthan <[email-masked]>
Date: Thu, 5 Aug 2004 17:18:22 -0700 (PDT)

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

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 15 Aug 2004 12:12:25 -0700 (PDT)

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

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sun, 15 Aug 2004 12:21:39 -0700 (PDT)

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" <fluffy@xxxxxxxxx>
To: "Geoff Huston" <gih@xxxxxxxxx>; "JORDI PALET MARTINEZ" 
<jordi.palet@xxxxxxxxxxxxxx>; "Behave" <ietf-behave@xxxxxxxxxxxxxxxxxxx>
Sent: Sunday, August 15, 2004 8:08 PM
Subject: Re: [Ietf-behave] Thinking about the BoF

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 15 Aug 2004 12:28:15 -0700 (PDT)

Give Brian Carpenter a ping - I was talking to him about it.

---

From: Harald Welte <[email-masked]>
Date: Thu, 19 Aug 2004 00:35:08 -0700 (PDT)

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? 

-- 
- Harald Welte <laforge@xxxxxxxxxxxx>               http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime
Attachment:
signature.asc