Subject: RE: FW: Why?

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 14 Mar 2005 18:17:01 -0800 (PST)

Hi Tony,

I have not been followign this thread at all. But, I did happen to look at this
e-mail and decided to respond. Please see my comments below. Thanks.

regards,
suresh

--- Tony Hain <[email-masked]> wrote:
> Jonathan Rosenberg wrote:
> > ...
> > I agree that ALGs are not the answer, and I believe the reasons for that
> > are treated in:
> > 
> > http://www.ietf.org/internet-drafts/draft-iab-nat-traversal-
> > considerations-00.txt
> 
> I have a fundamental problem with an IAB document that implies NAT provides
> a firewall. The artifact of lack of state is exploited to prevent inbound

[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?

> 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?

> As I said in an earlier post, the entire focus of this document is the wrong
> direction for the IAB. It should be focused on simplifying application
> operation, so there should be no NAT in the title. The IAB should be looking
> at how applications can avoid worrying about the convolution in the network,
> not focusing on how to navigate it.
> 
[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 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.

> It is also broken in that it focuses on Client/Server application models,
> which are generally less of an issue for applications in a NAT environment.
> Peer-to-peer applications have more trouble with mangled headers so the
> second thing to do (after changing the title & focus) is to rework this so
> that P2P issues are up front.
> 

[suresh] The focus is principaly on the P2P applications in the draft, from
what I can tell.

> > 
> > As I mentioned during the plenary, the document above makes a case that
> > the right answer in many situations are vpn-ish technologies that
> > include v6 tunnels. However, different applications have different
> > needs, and there are real differences between the various vpn-ish
> > solutions (TURN, STUN, teredo, etc.) that are driving their development
> > and adoption. For VoIP, where the nat traversal issue has been
> > especially painful, the increase in voice latency, packet loss, and
> > substantial cost increase of relaying traffic through the tunnel
> > servers, has driven people to solutions like STUN. Thus, I cannot agree
> > that there only needs to be a single solution here.
> 
> You appear to be too focused on the weeds to notice the path forward. Yes
> many of the IPv6 transition technologies have the same issues as the NAT
> traversal technologies in IPv4 (in many cases they do exactly the same thing
> but with different encapsulated packets). That said if the applications
> community doesn't get the point that they can leave all that crap behind
> when native IPv6 is available to them then they will never move. If the
> applications community doesn't do their part we will always be stuck with
> the garbage in the network. 
> 
[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. 

> > 
> > That said, I agree that the IAB nat traversal consideration document
> > lacks adequate consideration of how evolution plays into this, and I'll
> > endeavor to improve the document on that front.
> 
> I will try to send text, but I am buried for the next couple of months.
> 
[suresh] That sounds good.

> > 
> > Another concern I have is that, in an IPv6-only world, even if you
> > eliminate NAT, there will still be firewalls, and those firewalls will
> > frequently have the property that they block traffic coming from the
> > outside to a particular IP/port on the inside unless an outbound packet
> > has been generated from the inside from that IP/port. 
> 
> There is work going on outside the IETF to deal with this issue. There is no
> point in wasting years arguing when progress can be made in the real world.
> 
> > This means that IP
> > addresses are not globally reachable. You'd still need most of the same
> > solutions we have on the table today to deal with this problem. 
> 
> Not necessarily. 
> 
[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. 

regards,
suresh

> > Indeed,
> > in the VoIP space, I believe you'd need pretty much everything,
> > excepting you'd be able to remove a single attribute from a few of the
> > protocols (STUN and TURN in particular), which tell the endpoint its
> > address on the other side of the NAT. The endpoint knows its address,
> > but all of the protocol machinery is still needed to rendezvous with the
> > other participant in the call.
> > 
> > 
> > -Jonathan R.
> > --
> > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
> > Cisco Systems
> > [email-masked]                              FAX:   (973) 952-5050
> > http://www.jdrosen.net                         PHONE: (973) 952-5000
> > http://www.cisco.com
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 14 Mar 2005 20:00:31 -0800

> 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. 

> organization by not permitting inbound connections, but not OK to draw the

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.

> 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

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,

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.

> ignore the current deployment. After all, they want their apps to be

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. 

> firewall and NAT share the same ALG for protocol monitoring and

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

---

From: David R Oran <[email-masked]>
Date: Tue, 15 Mar 2005 07:51:33 -0500

Snipping out everything not related to one error I'd like to correct.

> change to traditional firewalls and policies.
SRTP only encrypts the media payload, not the RTP headers, so in fact 
SRTP is one protocol not broken by ALGs.

(The above is not to be taken as an endorsement of ALGs, NATs or any 
other middleboxes which break end-to-end transparency.)