On 06/11/2013 11:01 AM, Ole Troan wrote: > > a router does ECMP on the 5-tuple. the extension header chain doesn't > help with that. a middlebox makes some policy decision on arbitrary > bits in the packet (including L7). I'm not sure I see what help the > middlebox gets from the extension header chain here? > > in my view there is no difference between the following cases: > - 2nd fragment > - extension header chain longer than first packet > - unknown extension header > - unknown L4 - ESP
These cases are different (at least from a fw point of view). - 2nd fragment is okay, beacuse you'd apply the fltering policy t the first fragment. - extension header chain longer than first apcket is harmful - Unknown ext header is enough to block as "unwanted traffic" - unknown layer 4 is enough to block - ESP may or may not be okay depending on your policy > a firewall/filtering router with the policy of only allowing packets > with known L4, will drop the packet in all the above cases. Not really. For instance, stateless filters allow non-first fragments. > what should we as the IETF do? > > we could accommodate our protocols to become more firewall friendly, Yes -- or be prepared that more traffic is blocked. > e.g. deprecate IP layer fragmentation, deprecate extension headers > (or limit their length). Me, I would deprecate fragmentation, nor would I deprecate extension headers. I would, however, limit the size of the extension header chain (to some value... whether 256 bytes, 1280 bytes, or whatever). > but, do we then also push the Internet > further away from an open end to end capable Internet, stifle > innovation in transport etc? This cat is out of the bug (and has been out of the bag for.. what? 20 years?). Firewalls block unknown traffic. And from a netadmin pov, you usually want your network to do what's required to do, and not more than that -- that's what "default deny" is about. You don't really want an attacker to hack your network using something for which there wasn't a legitimate use case (legitimate == such traffic was needed by the task to be performed, and this was known as such to the admin). -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
