You are far too dogmatic in your assertion of what is a security control here. I do not think that there are many folk in the security area who would make such a direct contradiction. There might be dispute as to whether NAT is an effective security control, Steve Bellovin has written papers on that (which I consider less than conclusive) but NAT is certainly employed as a security control and is certainly effective against certain types of real world attack. NAT is used to provide two types of security: 1) A lighweight, verifiable means of blocking inbound connections 2) A lightweight means of limiting the ability of external observers to map the internal structure of a network. The first is interesting as the property that is provided by NAT that is not provided by a standard firewall is auditability and provability. A NAT design is failsafe, it is highly unlikely that a mistake in the NAT code will cause inboud connections to work.it takes effort to make it work. A firewall with no NAT component is not failsafe, if there are bugs packets can get through. There is no way for an independent auditor to determine if a black box is a firewall or a standard ethernet hub unless it is seen in the act of rejecting a packet. The second is something that some folk dispute, but nevertheless is a real obstacle to certain types of (legitimate) investigation. The amount of effort and network access required to circumvent a NAT scheme is considerable and does not lend itself to simple automation. So what we have here is the ongoing dispute between the adherents of old style 'security perfectionists' who think that any security flaw renders a system ineffective and the folk like myself who have long argued that security is risk management (yes, even before that book came out).
________________________________ From: Eric Klein [mailto:[EMAIL PROTECTED] Sent: Thu 11/13/2008 2:07 PM To: Hallam-Baker, Phillip Cc: Mark Townsley; Routing Research Group Mailing List; Behave WG; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [BEHAVE] Can we have on NAT66 discussion? Hi Phillip, On Thu, Nov 13, 2008 at 5:06 PM, Hallam-Baker, Phillip <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] on behalf of Mark Townsley Sent: Thu 11/13/2008 9:10 AM To: Eric Klein Cc: Routing Research Group Mailing List; Behave WG; [EMAIL PROTECTED]; ietf@ietf.org 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 <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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, [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > https://www.ietf.org/mailman/listinfo/behave > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
