[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: raw thoughts on v6 firewalls



This isn't v6 specific, but we should encourage the notion
that IPv6 firewalls should support MIDCOM pinholes as a mandatory
feature (like IPv6 stacks are supposed to support IPSEC as
a mandatory feature). That will allow firewalls to co-exist with
e2e IPSEC.

It would help if the MIDCOM protocol was already defined, of course.

   Brian

Rod.VanMeter@nokia.com wrote:
> 
> Unless I'm suffering total brain failure (never out of
> the question), every extension header is supposed to have
> the length in the same place, and one use is exactly that
> reason.
> 
> grepgrepgrep...from RFC2460:
> 
>    With one exception, extension headers are not examined or processed
>    by any node along a packet's delivery path, until the packet reaches
>    the node (or each of the set of nodes, in the case of multicast)
>    identified in the Destination Address field of the IPv6 header.
>    There, normal demultiplexing on the Next Header field of the IPv6
>    header invokes the module to process the first extension header, or
>    the upper-layer header if no extension header is present.  The
>    contents and semantics of each extension header determine whether or
>    not to proceed to the next header.  Therefore, extension headers must
>    be processed strictly in the order they appear in the packet; a
>    receiver must not, for example, scan through a packet looking for a
>    particular kind of extension header and process that header prior to
>    processing all preceding ones.
> 
> I suspect that someone excessively literal could read this as
> a prohibition on intermediate nodes *looking* any deeper into the
> packet than the hop-by-hop, which would effectively kill firewalls
> and complex packet classification for QoS, but in practice we *know*
> that firewalls will get built.
> 
> I can't off hand think of any specific reason that the classical-
> music-ignorant Superdumb Firewall Model 88888 couldn't skip the
> "Beethoven extension header" that plays the Fifth on iFruit
> 99999 hosts and go on to the TCP header, but there may be a corner
> case buried there somewhere.  It's worth a look.
> 
> Firewall products are starting to appear; I wonder how they will handle
> extension headers they don't recognize.  My guess is they will discard
> the packet, which is the paranoid (read: "correct if you're a firewall")
> thing to do.
> 
> Pekka, are there other v6-specific firewall issues, and is this
> the right place to discuss them?
> 
>                 --Rod
> 
> -----Original Message-----
> From: ext Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Wednesday, September 18, 2002 2:52 PM
> To: v6ops@ops.ietf.org
> Subject: raw thoughts on v6 firewalls
> 
> Hi,
> 
> Regarding v6ops meeting discussion..
> 
> I don't think v6 firewalls can be killed.  They're a mechanism to ensure
> some form of security policy; trusting end nodes to do the right thing is
> not enough.
> 
> But there are problems with v6 firewalling.  I've been trying to get
> around to writing a draft for a year or so now but never did it (further
> than the baseline summary of the content): perhaps now it's a better time.
> 
> One potentially major deployment issue is how the firewall is supposed to
> handle packets where extension header contains a header it does not not
> recognize and thus cannot parse e.g. UDP/TCP headers.
> 
> --
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland