Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 28-okt-2005, at 14:20, Pekka Savola wrote:

> > > The last sentence does not follow.  Firewalls may accept just  
> > > fine packets with a shim6 extension header but no data, but could  
> > > (and I'd expect many WOULD) drop packets with shim6 ext header  
> > > WITH data.

> > Why??

> A site administrator may be able to specify in the firewall rules  
> that a particular next-header type should be accepted.

So far so good.

> 1) Specifying such a rule is safe if it's known that the firewall  
> would only accept packets with a particular header type if there is  
> no proceeding header.

No header following the one that the firewall is looking at, you mean?

Well, if the firewall doesn't understand the shim header, how would  
it know whether other headers follow the shim header? (Next header  
field isn't necessarily in the same place in all headers. The prime  
example is ESP where it actually follows the "next" header data.)

And if the firewall does understand the shim header, it can obviously  
interpret the TCP/UDP/other header that follows so there is no reason  
for the firewall to behave in the way you mentioned.

> 2) Specifying such a rule would result in completely open firewall  
> policy if the firewall cannot parse the next headers but would  
> accept packets if there was one.

We can debate "completely" but your point is clear.

> I don't think there are many acl implementations which are smart  
> enough to parse TCP/UDP ports, etc. after the extension headers.

I did a quick test with Cisco IPv6 access lists some time ago and  
they didn't "catch" TCP following AH, so it's certainly true that at  
least some filters don't look past the first header following the  
IPv6 header.

Fortunately, that's not our problem.