[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC requirements
Steve;
> I understand the difference between transport and application
> layers, and I meant what I said about pure transport relaying
> vs. application relaying (or proxy applications).
Are you still cheating? I have no idea on what "inpure transport relaying"
means. :-)
> Looking at TCP/UDP port values is a layer violation for an IP
> layer intermediate system,
I think "IP layer" means "Internetwork layer". OK?
> and one which I do not endorse.
I endorse what people are using without difficulty and working quite
efficiently.
To do so, just say firewalls are operating at the transport layer.
> I don't
> think it causes problems for the reason you cite.
I don't think transport layer firewalls causes problems.
> If one makes
> filtering (screening) decisions based on port fields,
It is important to distinguish transport layer filtering and transport
layer relaying.
Transport layer filtering, only which is required for transport firewalls,
is easy and does not need state tracking.
Transport layer filtering does allow the selection of multiple routes
and multiple firewalls, though thier filtering policy should be consistent
each other which requires some protocol (I don't want to develop it)
to propagate dynamic policy changes.
> Also, the reliability of machines used as application layer firewalls
> has usually been excellent, so the single piont of failure posed by a
> firewall of this sort also may not be as bad as one might think.
That's perfectly endorsable. If there are no alternative routes, it is
possible to view the situation that incoming and outgoing transport layer
connections, having the same port #, are terminated and relayed on the
application layer firewall (src/dst address cheating used here is no
layering cheating). Note that such a view is impossible if there are
multile parallel firewalls.
> What would be a terrible problem for an intermediate system is
> trying to eumlate or track the TCP state information for each
> connection through that system. That is where alternate routes can
> kill you. So, in that light, looking at the port fields is cheating a
> little, but looking at the sequence numbers and flags would be really
> severe cheeting!
When speaking on specification, cheating is cheating. I'm not interested
in the degree of cheating.
Looking at the port fields is no cheating at all, but looking at the
sequence numbers and flags is cheating.
> Applications behind a firewall do not automatically get login
> info from a firewall, e.g., the target machine and the firewall may
> require different user ID technology and thus be incompatible in terms
> of relaying user I&A.
That's a user interface issue on how can we design a firewall friendly
applications.
> Also, application layer firewalls often are set
> up to control outgoing connections, where the user is behind the
> firewall and the target application is outside. Here the target may
> not be willing to trust user I&A info provided by some firewall
> elsewhere, and that results in multiple logins.
That's an issue of multipel firewalls and inessential.
UNIX 'su' command is a firewall to the super user previledges and
requires its own password. So, call it double login. But does that
matter?
> Finally, yes, we do agree that application-dependent firewalls
> are a long term problem because they require tracking evolving
> applications and the intermediate implementation of these applications
> may loose functionality for the users.
And, anyway, we need transport layer security to make all the TCP
and most of UDP applications we are using today work securely without
modification.
Application firewalls may be developped. They may or may not make use
of transport layer security/firewalls. But there are no reason not to
have transport layer security/firewalls.
Masataka Ohta