Re: [BEHAVE] Can we have on NAT66 discussion?

["Eric Klein" <[e-mail]>]

Hi Phillip,

On Thu, Nov 13, 2008 at 5:06 PM, Hallam-Baker, Phillip
<[e-mail]>wrote:

>  I beleive that the question would not arise If we had a coherent Internet
> architecture
>
> The idea that an application can or should care that the IP address of a
> packet is constant from source to destination is plain bonkers. It was no an
> assumption in the original Internet architecture and should not be an
> assumption that any application should rely on.
>
> If you want to effect a transition from IPv4 to IPv6, the only way to do
> that effectively is to design a protocol stack in which the applications
> simply do not care whether their packets are routed over IPv4, IPv6 or
> carrier pidgeon.
>
>
Agreed


>  NAT66 is in fact a security requirement in many applications and in
> others it is a compliance requirement. Stampy feet protests that the idea is
> profane don't change those facts.
>
>
NAT is not and never was a security feature, it was a way to use fewer
numbers because they were hard to get. Please stop the falacy that NAT in
any way is related to security, otherwise we would not need firewalls.


>  I know that there are some people in the security area who claim
> otherwise but they have been wrong on many issues in the past and they are
> likely wrong on this one. Let us consider for a minute the list of real
> world security measures that the IETF has successfully deployed, well there
> is DKIM (sort of) and there is the post-facto cleanup of SSL after it was
> successful and the post facto cleanup of X.509 after that was successful.
> IPSEC is used as a VPN solution despite being unsuited for the role as
> originally designed.
>
> On the negative side the same consensus that opposes NAT66 has in the past
> opposed firewalls, the single most widely used network security control. It
> has also promoted the idea of algorithm proliferation and negotiation as a
> good thing (these days we consider it bad). It has promoted the idea that
> the most important feature in a security protocol is that it be absolutely
> secure against theoretical attacks rather than easy enough to deploy and use
> that people actually use it.
>

This is not quite true, the ones who have been argueing against it have
constantly asked why we need it. But we still do not know why we need NAT,
no one has done the gap analysis.

>
> And yes, I have been guilty of many of the same mistakes. But unlike some
> folk I am not about to compound that mistake by telling the folk who want
> NAT66 that they should visit a re-education camp and unlearn their heretical
> thoughts.
>
> The only reason NAT is bad in practice is because some people were so
> opposed to the concept that they decided it would be a good thing to allow
> designs that were purposefully designed to be NAT-unfriendly.
>
>
> If we don't want to have these discussions on the IETF list we should have
> a separate architecture list.
>
> NAT66 is a reasonable protocol proposal to make. If BEHAVE does not like
> the idea let the advocates start a new group.
>

This is why I am proposing a wider audience make a decission rather than
having several groups making solutions without understanding the need.

>
> ------------------------------
> *From:* [e-mail] on behalf of Mark Townsley
> *Sent:* Thu 11/13/2008 9:10 AM
> *To:* Eric Klein
> *Cc:* Routing Research Group Mailing List; Behave WG; [e-mail];
> [e-mail]
> *Subject:* Re: [BEHAVE] Can we have on NAT66 discussion?
>
>   Eric Klein wrote:
> > Mark,
> >
> > I agree with the sentiment, the problem is that the 5 different groups
> > are doing different things that all relate back to NAT in v6 (rather
> > than just coexistence) each under their own charter.
> >
> > I have had suggestions that I bring this to ietf or inter-area mailing
> > lists for general consensus on a need and IETF overall position prior
> > to defining a solution.
> > Behave seems a little limited in scope for the decision about do we or
> > don't we want to allow any form of native mode NAT into v6.
> I agree, and it is not behave's place to make that decision at this
> time. I had originally proposed that this be discussed in int-area (if
> nothing else because behave's plate is rather full), but some folks
> pointed out that some modes may have affects on applications and that
> behave was best able to determine that, particularly within context of
> the other NATxy work. I'm looking forward to that assessment. So for now
> this should remain discussion to understand the problem space and
> potential solution space better, not a final referendum on whether or
> not the IETF is going to charter work in or otherwise endorse NAT66 in
> any manner.
>
> Thanks,
>
> - Mark
> >
> > Eric
> > On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley <[e-mail]
> > <mailto:[e-mail] <[e-mail]>>> wrote:
> >
> >
> >     I would prefer not to have the same discussion again and again in
> >     multiple places. Let's just try and stick to behave for the
> >     moment, though at some point if the work continues it would need
> >     to be passed around elsewhere. We are not chartering the work one
> >     way or another at the moment, for now this is merely "discussion"
> >     of the topic.
> >
> >     - Mark
> >
> >
> >
> >
> >
> >     Margaret Wasserman wrote:
> >
> >
> >         Hi Eric,
> >
> >         According to the ADs and WG chairs, the correct forum for the
> >         NAT66 discussion is the BEHAVE WG.  So, let's discuss it there.
> >
> >         Margaret
> >
> >         On Nov 12, 2008, at 9:44 AM, [e-mail]
> >         <mailto:[e-mail] <[e-mail]>>
> wrote:
> >
> >             Cross posted to several lists
> >             Can we keep the NAT66 discussion to less than WGs at a time?
> >             I am trying to keep up with multiple threads on this and
> >             trying to explain that we do not have a valid requirement
> >             for NAT66 defined on any of the mailing lists (v6OPS,
> >             BEHAVE, Softwires, RRG, and now v6).
> >             Le's get this to one group (maybe we need a new mailing
> >             list just for NAT66 discussions, but this is getting out
> >             of hand.
> >             Until now the simple response is that "the IETF does not
> >             support NAT in the v6 architecture." If this needs
> >             changing lets do it right with proper gap analysis and
> >             needs assessment, and then seeing if there is a solution
> >             (several have been proposed that are not NAT) or if we
> >             need to create one, and if those fail then see about
> >             changing the architecture of IPv6.
> >             Eric _______________________________________________
> >             Behave mailing list
> >             [e-mail] <mailto:[e-mail] <[e-mail]>>
> >             https://www.ietf.org/mailman/listinfo/behave
> >
> >
> >         _______________________________________________
> >         Behave mailing list
> >         [e-mail] <mailto:[e-mail] <[e-mail]>>
> >         https://www.ietf.org/mailman/listinfo/behave
> >
> >
> >     _______________________________________________
> >     Behave mailing list
> >     [e-mail] <mailto:[e-mail] <[e-mail]>>
> >     https://www.ietf.org/mailman/listinfo/behave
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Behave mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave
> >
>
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>
>

_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf