Pyda Srisuresh wrote: > [suresh] Why is it a problem with what Jonathan said in the IAB document? > It is > true that traditinal NATs do inherently provide a limited firewall > functionality. Jonathan did not say that NAT function implies full > Firewall > functionality. > > Also, what exactly do you mean by the comment about "lack of state" being > exploited to prevent inbound connections? Many firewalls are stateful and > so > are NATs. Who is exploiting "lack of state" in what? Lack of state is what is being marketed as a firewall function. As soon as any node behind the nat establishes state there is no firewall for the opened path. If addressing behind the nat changes while the state persists the new node with the mapped address is unexpectedly exposed. > > > connections, but that has nothing to do with a policy rich firewall, and > > even less to do with anything resembling 'security'. > > > [suresh] Agree with your comment about firewalls being policy rich. The > comment > about security in the draft relates just to the filtering of inbound > connections. Given that, why is it OK to say that a firewall secures an > organization by not permitting inbound connections, but not OK to draw the > same > conclusion about a NAT? No, because a firewall may in fact permit inbound connections according to policy. A nat may also be pre-mapped to a specific node to allow inbound connections. It is wrong to imply that a nat is any kind of firewall or security mechanism because it is neither. It is simply an impediment to applications that under some circumstances allows utility. > > [suresh] This sounds like some kind of an unwritten rule, or something. > Why is > it wrong for the IAB to address real-life problems involving NATs? A > tremendous > amount of work has been ongoing in the IETF lately concerning how > applications > should traverse NATs. 'A tremendous amount of work' is the fundamental point of my complaint. We are wasting valuable resources patching a hack. It is marginally acceptable for the IESG to deal with this, but the IAB should be looking forward and charting the course, not focusing on the weeds. In any case there is no need for new standardization work involving nats, they are a dead end, we know they are a dead end, yet because they present intellectual challenges people want to focus on them. Get over it and move on. > A new IPsec standard has emerged to deal with NAT > traversal. I think, it makes sense that the IAB recognizes that and makes > a > statement about NAT traversal for the apps. That is not to say that > application > designers should not design for the V6 networks. And how much further would we all have been if the effort that was wasted on that had been focused on simplifying the application environment by getting rid of nat? > > ... > [suresh] The focus is principaly on the P2P applications in the draft, > from > what I can tell. I just browsed through it, but the entirety of section 2 lays out the model and it is clearly client/server. Section 3 talks about the techniques for nat traversal and 4 is deployment issues. So where is the P2P model? I will have to spend more time on it, but it is not jumping out. > > > > [suresh] It sounds like you are suggesting that the IAB should advocate > the > mantra that application desginers shoudl jettison the issue of NAT > traversal > and simply write apps that work with v6 only. Why do you believe the > application designers will heed that? Application desginers cannot afford > to > ignore the current deployment. After all, they want their apps to be > deployed. Their apps will be easier to deploy and maintain by using the IPv6 tunneling approaches to traverse nat. They don't need to wait, and for those that are targeted at the Windows environment all they need to do is turn on the existing IPv6 stack in XP as the app is installed. The whole point of automated tunneling is to remove the ISPs from being deployment blockers. Applications MUST work or else there is no 'demand' for ISPs to deploy the service. NAT traversal for an IPv4 app is complex and requires a significant amount of operational effort to maintain, so everyone is better off moving to IPv6 because the transition technologies go away where the nat traversal components only persist and get more complex. > > >... > [suresh] VOIP appls go through the same kind of paylod processing in > firewalls > as do NATs with ALG support for the application. In many implementations, > firewall and NAT share the same ALG for protocol monitoring and > application > processing. This will be interesting when the VoIP apps start encrypting end to end. SRTP is just as opaque to those ALGs as IPsec, so either route will mean a change to traditional firewalls and policies. Tony _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf