On 5-mrt-2006, at 12:09, Ian Dickinson wrote:
As an irrelevent aside, when someone comes up with a way to firewall/acl shim6, how much breaks?
The idea is that there will be a shim6 header that can do two things: carry shim6 signalling and carry data packets with rewritten addresses after a rehoming. Since data packets with rewritten addresses can only occur after there have been shim6 signalling packets on the same path, filtering out packets with the shim6 header on the initially chosen path makes it impossible for the shim state to be created so there is no multihoming. If shim packets are allowed on the initially chosen path but not on the backup path, shim6 (un) reachability detection won't work over the backup path so the backup path will be considered broken and won't be used. In other words: you fall back to single homing without ill effects. Of course having a TCP session or the like change addresses halfway through the session may throw stateful firewalls a bit.
On Sun, 5 Mar 2006, Iljitsch van Beijnum wrote:
Of course having a TCP session or the like change addresses halfway through the session may throw stateful firewalls a bit.
I just love that shim6 basically == natv6... It WILL be implemented as such if available to folks in that manner. I do think there wiill be a market for a 'firewall' that is really a shim6 box that 'nat's the internal network behind a single prefix, this is going to be 'fun' (but not in the good way). Oh, not just stateful firewalls... How are you planning on dealing with LEO requests for CALEA when the addr changes mid-stream to some newly arbitrary prefix? What about log correlation on web/content servers? what about loadbalancers that balance on 'flows' ? this is quite the rabbit-hole dorothy jumped down :(
participants (2)
-
Christopher L. Morrow
-
Iljitsch van Beijnum