[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shim-header in every re-located packet [Re: Design decisions made at the interim SHIM6 WG meeting]
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
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
Fortunately, that's not our problem.