Re: SOI QUESTIONS: 2.3 Authentication styles

[Stephen Kent <kent@bbn.com>]

At 4:44 PM -0700 6/19/02, Chinna N.R. Pellacuru wrote:
>On Wed, 19 Jun 2002, Stephen Kent wrote:
>
>>  At 3:49 PM -0700 6/19/02, Chinna N.R. Pellacuru wrote:
>>  >Hi Steve,
>>  >
>>  >Can you please elaborate on what access control features IPsec provides.
>>  >
>>  >I think we discussed the access control features of IPsec not very long
>>  >ago in this forum, and decided that we acknowledge that IPsec doesn't
>>  >provide much of any access control features.
>>  >
>>  >     thanks,
>>  >     chinna
>>  >
>>
>>
>>  You dismissed the value of having IPsec enforce static packet
>>  filtering firewall rules on traffic, but I don't consider your
>>  position on this to be representative of the WG's consensus. There
>>  were a number of rebuttals of your position from multiple, regular
>>  contributors to the list to suggest that your position was in the
>>  minority.
>>
>>  So, my question still stands. if you're uncertain about the features
>>  in question, look at 2401, especially sections 4.4 and 5.
>>
>>  Steve
>
>As I saw it, a minority of implementors who build high end security
>gateways, complained about not just the value of minimal access control in
>IPsec, but also about the inefficiency of doing this in IPsec and having
>to do it in the firewall feature processing anyway (because firewall
>provides extensive and true access control and intrution detection).

I guess I should start by asking who you think builds high assurance 
security gateways? (or by "high end" do you just mean big and fast?) 
I know quite a bit about high assurance security system, having 
worked on such systems for over 2 decades. I can think of only 2 
companies whose firewall products fall into this area. Both, to the 
best of my knowledge, implement IPsec and understand the benefits of 
employing IPsec authentication for traffic from authenticated 
sources. Thise benefits are not present if the firewall processing is 
independent of IPsec, e.g., if implemented in a separate machine. If 
the features are all in the same box, and SA information is used to 
maintain the binding between packets and the negotiated SAs, then 
that counts as an IPsec security gateway and we have no argument.

I agree that proxy firewalls can offer better security than packet 
filtering firewalls, assuming suitable care is applied to the 
proxies, and for certain  classes of applications. But, absent 
crypto-based security for authentication and integrity, proxy 
firewalls are not all that secure in the grand scheme of things.

As for "intrution detection" this is not an intrinsic firewall 
feature. There are various approaches to ID, and many are completely 
independent of firewall filtering, so this is a red herring.

Finally, re performance, I have played an advisory role in the 
development of very high speed (10 Gb/s) IPsec technology that will 
be coming to the market over the next 6-12 months.  That argues 
against the inefficiency arguments you make.

>There was also a concern from a sizable minority, that the majority is
>imposing inefficiencies that they are not concerned about, on everyone.
>Due to the layer violations that IPsec does when doing limited 'static
>packet filtering', by having to look into the transport (TCP/UDP) headers,
>this limited benefit introduces a serious design hurdle for modularity and
>scalability.

You keep harping on layer violations. Certainly this means that when 
you talk about the superior security offered by firewalls vs. IPsec, 
you are NOT referring to proxy firewalls, which certainly qualify as 
layer violating devices!

I have long been a champion of not violating layering. I suspect my 
activity in this regard significantly predates any of your 
involvement in the Internet. But, one has to understand why layering 
exists and what are its merits and not make arbitrary decisions about 
what is or is not legitimate processing at an intermediate system. 
Today we are awash in intermediate systems that one might think 
should only examine IP headers, but which instead examine transport 
layer headers and make decisions based on these headers. Worse still, 
we have many examples of such systems that modify transport layer 
headers. Against this backdrop, I cannot take your complaint 
seriously that having a security gateway examine the port fields 
transport headers is a bad thing. Especially since the paragons of 
security you allude to in the first paragraph (firewalls that do more 
than static packet filtering) MUST by definition be examining these 
headers (or more) in their operation.

>There was a request from the sizable minority to the majority that, all
>inefficiencies, and layer violations be revisited, and possibly make these
>implementation details not mandatory by the standards.

We obviously have different recollections of the traffic on this 
matter.  I defer to the WG chairs to keep count.

Steve

P.S.  You still have not answered my question, so I assume the answer 
is not one that supports your suggestion that IPsec delegate 
responsibility for remote access security to the L2TP WG.