Re: Proxy 2.0 secure? (AG vs. SPF)

["Paul D. Robertson" <proberts () clark net>]

On Thu, 9 Jul 1998, Ryan Russell wrote:

> I didn't intend to imply that it was anything more than the
> most minute possibility, nor pro or con for SPF or AG.
> I was just mentioning the possibility, so that someone
> wouldn't try to claim that AGs always defrag right, and
> SPFs can't, when in fact they could just use the same
> algorithm.

Well, though _technically_ reassembling fragments isn't filtering, the 
premise is certainly acceptable, however anything in the path 
reassembling fragments takes away the problem of overlapping fragments, 
but it isn't a packet filtering function per se.  Of course, once again, 
the gateway in quesiton needs sufficient buffer space to reassemble said 
fragments.  I seem to recall some routers (Livingston or Ascend?) having 
serious trouble with multiple 64K ICMP packets fragged with the last few bytes 
never getting sent, but that was about 3 years ago.  

> FWIW, I have had problems with routers not fragging
> due to software bugs in the router OS, and it had an
> impact on a security design I was implementing.  In

Not fragging is a different beast altogether, and those of us who block ICMP
wantonly *really* know to watch for path MTU variances in a design.  It's 
unfortunate that in today's plug and pray world, most network designs 
don't get this built in to the design phase, let alone tested.  I'll 
admit that it would be nice to have an internal MTU-fixing pipe in IOS, 
just for the purpose of unbreaking TCP's path MTU discovery when forced 
to reactionarily throw up ICMP blocks though.  Fast switched, on a VIP 
card while I'm daydreaming :)   

In an ideal world, frags get reassembled at your border routers, which 
have enough buffer memory and the right timers to handle such things.  In a 
less than ideal world, you do it at the firewall, which is the only way AGs 
function, and needs to be built into any PF.  If the datagrams are 
assembled prior to hitting the 'wall, even  the PF will benifit by being 
able to do its filtering much more quickly.

Other than this nebulous "access to lower level data by proxy code", you've 
yet to come up with anything I consider remotely interesting as a reason to 
move from an AG to any sort of SPF, even one which stretches the definition of
the product six ways to hell and back.  As we've seen, SYN floods can be 
fixed in the stack, moving the protection service out of the kernel 
doesn't gain much, since compromise of the protection mechanism nullifies 
the gateway function, and fragment problems are in the realm of packet 
filters.  

While packet filters certainly comprise components of a good firewall 
design, and indeed adding state _could_ be construed as an additional 
bonus for some installations, the only real gain any sort of SPF has is 
for allowing strange unwieldy protocols through the firewall with a 
little more protection than simply opening a hole.  Well, I'll pass on 
that, I can wait for a protocol to be supported by an application layer 
gateway, which the SPF would need to have code written for as well to 
provide anything more than "machine A sent a packet to machine B on this 
port, so it's ok" protection.

Nor has anyone presented anything which says that an AG running on a good 
stack isn't sufficient for great security.  Add that to the "none of the 
current SPF implementations are this good" qualifier, and we seem to have 
gotten nowhere fast.

While I'll agree that all TCP/IP stacks aren't as robust as they could 
be, I remain unconvinced that SFP as a firewalling mechanism provides 
anywhere near the level of protection that an Application Layer Gateway 
does by default unless you add so many caveats and so much software that 
you've basicly built an Application Layer Gateway, at which point I still 
question the sanity of the exercise.  Move NT's URG pointer problems to 
the PUSH flag, then replay the packet filter exercise, and the 
"protectees" are still crashing, while an AG's protectees are indeed 
protected.  

Make the SPF transparently hijack the connection, generate new packets 
all around, and it's no longer a PF, not to mention the trouble you'll 
have with multi-homed firewalls having to accept packets for internal 
hosts on all interfaces in dynamic routing situations with multiple 
links, or attempting to manage a scheme of which interfaces can accept 
which packets with which destination addresses unless the addresses are 
rewritten, in which case, you've just recreated the AG.  Not that you've 
gained anything over the AG, you just have a new one.  

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () clark net      which may have no basis whatsoever in fact."
                                                                     PSB#9280