Subject: RE: raw thoughts on v6 firewalls

From: <[email-masked]>
Date: Wed, 18 Sep 2002 21:40:11 -0700

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:[email-masked]]
Sent: Wednesday, September 18, 2002 2:52 PM
To: [email-masked]
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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Sep 2002 11:05:54 +0200

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

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

---

From: Robert Elz <[email-masked]>
Date: Thu, 19 Sep 2002 16:58:15 +0700

Date:        Wed, 18 Sep 2002 21:40:11 -0700
    From:        <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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

No, they're not.   Most probably will, but there's no guarantee that
things will always be that way - if only because the standard layout
puts a (smallish) length limit on the size of extension headers.

These things are parsable only if you know their individual syntax.

This (aside from its effect on firewalls) is one of the reasons that
new headers are so hard to deploy, and why there's a pretty good chance,
that, apart from new application protocols, there never will be any new
ones now - anything new will be turned into an option instead.

kre

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Sep 2002 23:41:09 +0300 (EEST)

> the length in the same place, and one use is exactly that

Not really, see other messages.

> the right place to discuss them?

Yes, but that is the most major issue (the same applies to some specific 
destination options too).

Others, not necessarily all IPv6-specific:

 - peer2peer recognition allow/disallow mechanism
 - need to be able to, in some cases, to be able to parse routing header 
or home-address option contents
 - the role of firewall in the presence of ESP-encrypted traffic