Subject: RE: [Ietf-behave] Standard Disclosure

From: "Francois Audet" <[email-masked]>
Date: Tue, 12 Jul 2005 14:25:11 -0700 (PDT)

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" <audet@xxxxxxxxxx> 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:
> >>>>         <seconds> |
> >>>>         "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:
> >>>>         <seconds> |
> >>>>         "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:
> >>>>         <DNS, FTP, etc.> |
> >>>>         "none"
> >>>>     Configurable application level gateways:
> >>>>         <DNS, FTP, etc.> |
> >>>>         "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):
> >>>>         <bytes> |
> >>>>         "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: Cullen Jennings <[email-masked]>
Date: Tue, 12 Jul 2005 15:09:23 -0700 (PDT)

I'm very uneasy about this - are there outer places where IETF has done
this?

---

From: David Barrett <[email-masked]>
Date: Tue, 12 Jul 2005 17:55:59 -0700 (PDT)

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: Cullen Jennings <[email-masked]>
Date: Wed, 13 Jul 2005 20:02:57 -0700 (PDT)

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 <not as chair>

---

From: David Barrett <[email-masked]>
Date: Wed, 13 Jul 2005 20:23:14 -0700 (PDT)

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:

Francois Audet wrote:

Hi David,