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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf